# LEO Process Mode Runtime Evidence **Document status:** Public Evaluation Evidence **Version:** 1.0 **Evaluation scope:** Process Mode runtime evidence **Publication context:** LEO Public Evaluation / European Commission Readiness **Implementation maturity:** Experimental internal-laboratory implementation **Human review:** Required **Autonomous enforcement:** Not authorized **Production mutation:** Not authorized **Fraud, legal, or compliance verdicts:** Not provided --- ## 1. Purpose This document provides evaluator-facing evidence for the current implementation status of the LEO Process Mode method. Its purpose is not to claim that LEO is a finished production system. Its purpose is to demonstrate that selected architectural and governance principles described by the public LEO documentation are represented by implemented runtime components and executable test contracts in the canonical development environment. The evidence presented here is intentionally bounded. It demonstrates a practical implementation path for: 1. evidence-derived characteristic evaluation; 2. controlled characteristic-to-signal projection; 3. deterministic and stochastic signal accounting; 4. Process Mode proposal generation; 5. confidence estimation integration; 6. provenance and evidence-lineage preservation; 7. fail-closed runtime boundaries; 8. mandatory human review. This document does not publish the complete canonical LEO implementation. It does not disclose all internal implementation details. It does not represent LEO as production-ready. It does not claim legal, regulatory, or institutional certification. It does not claim that the implementation has been independently validated by the European Commission, the EU AI Office, or another external authority. The document should therefore be read as implementation evidence for a method under active development and evaluation. --- ## 2. Evaluation Position LEO is being developed and tested within an internal development and evaluation environment. The Process Mode method addresses a specific institutional-analysis problem: > anomaly interpretation should not begin before the character of the process > being examined has been distinguished. A process governed primarily by stable procedural rules is not analytically equivalent to a process materially affected by human discretion, behavioural variation, uncertainty, or a combination of these characteristics. The Process Mode layer therefore provides a controlled proposal mechanism for distinguishing between: - `DETERMINISTIC_PROCESS` - `STOCHASTIC_PROCESS` - `MIXED_PROCESS` - `UNKNOWN_REQUIRES_REVIEW` These states are proposals for human review. They are not autonomous institutional determinations. The runtime does not convert a Process Mode proposal into enforcement, sanction, fraud determination, legal conclusion, compliance verdict, or production mutation. The Process Mode implementation should therefore be evaluated as a human-controlled analytical component rather than as an autonomous decision-making mechanism. --- ## 3. Why Runtime Evidence Is Included Architectural documentation alone does not establish that an analytical method has been implemented. Likewise, the existence of source code alone does not establish that the implementation preserves the governance boundaries described by the method. For public evaluation purposes, the relevant question is therefore not merely: > Does implementation code exist? The stronger question is: > Are important architectural and governance claims represented by executable > implementation behaviour and testable contracts? The current Process Mode evidence supports that stronger form of evaluation for a bounded implementation slice. Canonical implementation evidence reviewed for this document includes runtime components and tests covering: - evidence-derived characteristic evaluation; - characteristic-to-signal projection; - Process Mode classification; - confidence-estimation integration; - runtime integration boundaries; - human-review package construction. The public evaluation package does not require publication of the complete canonical runtime in order to communicate these facts. Instead, this document records the verified behavioural claims that can be made from the reviewed implementation and test evidence. --- ## 4. Evidence Boundary The evidence model used by this document distinguishes four separate levels. ### 4.1 Architectural definition An architectural document may define how LEO is intended to behave. Architectural definition is important, but by itself it is not evidence that the behaviour has been implemented. ### 4.2 Runtime implementation A runtime component may implement part of the architectural contract. The existence of implementation code establishes implementation activity, but does not by itself establish that every intended boundary has been tested. ### 4.3 Executable test evidence Executable tests provide evidence that specific expected behaviours are represented by test contracts. The claims in this document are limited to behaviours supported by reviewed runtime and test evidence. ### 4.4 Human and external validation Internal implementation and test evidence is not equivalent to independent external validation, regulatory acceptance, legal review, certification, or production authorization. Those states must not be inferred from this document. Accordingly: `ARCHITECTURAL_DEFINITION != IMPLEMENTATION_EVIDENCE` `IMPLEMENTATION_EXISTENCE != COMPLETE_VALIDATION` `INTERNAL_TEST_EVIDENCE != EXTERNAL_CERTIFICATION` `PROCESS_MODE_PROPOSAL != HUMAN_DECISION` `PUBLIC_EVALUATION_EVIDENCE != PRODUCTION_AUTHORIZATION` --- ## 5. Canonical Evidence Source The implementation evidence summarized here originates from the canonical LEO development environment. The public repository acts as an evaluation and publication surface. It is not treated as the complete canonical development environment. This distinction is intentional. The canonical environment may contain implementation material, development history, internal architectural artifacts, review records, experimental components, and other material that is not required for public evaluation. The public evaluation surface is intended to expose enough evidence to permit meaningful evaluation of the method while preserving controlled publication boundaries. For the Process Mode evidence review, the relevant canonical test surfaces included: - `test_evidence_derived_characteristic_evaluator.py` - `test_evidence_derived_characteristic_to_signal_projector.py` - `test_evidence_derived_process_mode_runtime_adapter.py` - `test_process_mode_classifier.py` - `test_human_review_package_builder.py` These tests were inspected as evidence sources for the behavioural claims documented below. The presence of a test name in this document should not be interpreted as publication of the complete internal implementation associated with that test. --- ## 6. Evidence-Derived Characteristic Evaluation The first reviewed runtime boundary concerns the transition from observations and evidence references to evidence-derived characteristics. This boundary is important because LEO must not treat every observation, absence, contradiction, or uncertainty as equivalent. The reviewed evaluator tests distinguish the following characteristic states: - `SUPPORTED` - `NOT_SUPPORTED` - `NOT_OBSERVED` - `UNKNOWN` - `CONFLICTING` These states have deliberately different semantics. ### 6.1 SUPPORTED A supported signal-eligible characteristic may become eligible for controlled signal projection. Reviewed test evidence confirms, for the currently authorized evaluator slice, that a supported `rule_stability` characteristic can be marked: - `state = SUPPORTED`; - `signal_eligible = true`; - `signal_category = DETERMINISTIC`. The same result remains subject to human review. The evaluator does not represent the result as human-confirmed knowledge. ### 6.2 NOT_SUPPORTED `NOT_SUPPORTED` does not automatically create a positive signal. It also does not automatically create an opposite signal. This distinction is important. Evidence that does not support a deterministic characteristic must not be silently transformed into evidence of stochasticity. Likewise, lack of support for a stochastic characteristic must not be silently transformed into evidence of determinism. Therefore: `NOT_SUPPORTED != OPPOSITE_SIGNAL` ### 6.3 NOT_OBSERVED `NOT_OBSERVED` remains distinct from `NOT_SUPPORTED`. The absence of a relevant observation is not treated as evidence that a characteristic has been disproved. Where the relevant observation collection is empty, reviewed test evidence requires the state to remain non-signal-generating and the result to remain review-required. Therefore: `NOT_OBSERVED != NOT_SUPPORTED` and: `ABSENCE_OF_OBSERVATION != NEGATIVE_FACT` ### 6.4 UNKNOWN `UNKNOWN` preserves uncertainty. It does not create a deterministic or stochastic signal. Reviewed tests also preserve an explicit review reason for insufficient or ambiguous evidence. This prevents uncertainty from being silently converted into analytical certainty. ### 6.5 CONFLICTING `CONFLICTING` preserves the existence of competing evidence. Reviewed evaluator behaviour retains supporting and contradicting references rather than resolving the conflict automatically. A conflicting characteristic is not signal-eligible. The conflict remains visible for human review. Therefore: `CONFLICTING_EVIDENCE != AUTOMATIC_RESOLUTION` --- ## 7. Conservative Evidence Semantics The reviewed evaluator applies conservative behaviour when evidence does not support a clean positive characteristic state. For example, reviewed tests cover combinations in which supporting or contradicting observations coexist with uncertainty. These combinations do not permit the evaluator to manufacture a stronger positive conclusion. Instead, uncertainty remains explicit. This is a core safety property of the Process Mode method. LEO should preserve epistemic distinctions rather than collapse them into a binary interpretation. The relevant boundary can be summarized as: `SUPPORTED -> MAY_BE_SIGNAL_ELIGIBLE` `NOT_SUPPORTED -> NO_POSITIVE_SIGNAL` `NOT_OBSERVED -> NO_POSITIVE_SIGNAL` `UNKNOWN -> NO_POSITIVE_SIGNAL` `CONFLICTING -> NO_POSITIVE_SIGNAL` Signal eligibility is therefore narrower than evidence visibility. Evidence may remain important for review even when it does not contribute a positive Process Mode signal. --- ## 8. Human-Review State at the Characteristic Layer The evidence-derived characteristic evaluator does not claim that its output is human-confirmed knowledge. Reviewed test evidence requires the evaluator result to retain: `human_review_required = true` and: `human_confirmed = false` The reviewed output also distinguishes the result from reviewed institutional knowledge. This is consistent with the broader LEO knowledge boundary: > Documents and observations may provide evidence. Human-confirmed reviewed > classifications may become institutional knowledge. Automated evaluation does > not independently convert evidence into reviewed knowledge. The characteristic evaluator therefore performs bounded analytical processing. It does not perform institutional confirmation. It does not autonomously establish truth. It does not authorize downstream enforcement. --- ## 9. Characteristic-to-Signal Projection The next reviewed runtime boundary is the transition from evidence-derived characteristics to Process Mode signals. This boundary is deliberately separate from characteristic evaluation. A characteristic state is not itself a Process Mode classification. Likewise, the existence of evidence does not automatically authorize signal generation. The projection layer therefore applies an explicit signal-eligibility boundary. The reviewed implementation distinguishes between: 1. evidence-derived characteristic state; 2. signal eligibility; 3. signal category; 4. projected signal presence; 5. resulting deterministic and stochastic signal counts. This separation reduces the risk that ambiguous, unsupported, or merely observed material is converted directly into a Process Mode proposal. The projection contract can be summarized as: `EVIDENCE -> CHARACTERISTIC STATE -> SIGNAL ELIGIBILITY -> SIGNAL PROJECTION` and not: `EVIDENCE -> PROCESS MODE` --- ## 10. Signal-Eligible Characteristic Vocabulary The reviewed Process Mode projection slice uses a bounded characteristic vocabulary. ### 10.1 Deterministic signal characteristics The reviewed deterministic signal characteristics are: - `rule_stability` - `procedural_control` - `outcome_predictability` - `repeatability` These characteristics may contribute deterministic signals only when the required positive characteristic state and signal-eligibility conditions are satisfied. The current reviewed maximum deterministic signal count is therefore: `MAX_DETERMINISTIC_SIGNALS = 4` This is a bounded implementation property of the reviewed projection contract. It should not be interpreted as a universal scientific claim that all deterministic processes can be represented by exactly four characteristics. ### 10.2 Stochastic signal characteristics The reviewed stochastic signal characteristics are: - `human_discretion` - `behavioral_variability` - `response_uncertainty` These characteristics may contribute stochastic signals only when the required positive characteristic state and signal-eligibility conditions are satisfied. The current reviewed maximum stochastic signal count is therefore: `MAX_STOCHASTIC_SIGNALS = 3` Again, this is a property of the current implementation contract. It is not presented as a universal taxonomy of every possible stochastic process. ### 10.3 Non-signal characteristic The reviewed projection contract also includes: - `auditability` `auditability` is treated as a non-signal characteristic. It may remain relevant to institutional analysis and review, but it does not increase either deterministic or stochastic signal count. Therefore: `ANALYTICAL_RELEVANCE != SIGNAL_ELIGIBILITY` and: `AUDITABILITY != PROCESS_MODE_SIGNAL` This distinction prevents every useful characteristic from being converted into classification weight. --- ## 11. Positive Signal Generation Boundary The reviewed projection tests establish a conservative positive-signal rule. For the currently reviewed implementation: > only a signal-eligible characteristic in the `SUPPORTED` state may contribute > a positive Process Mode signal. Accordingly: `SUPPORTED + SIGNAL_ELIGIBLE -> MAY_CONTRIBUTE_SIGNAL` while: `NOT_SUPPORTED -> NO_POSITIVE_SIGNAL` `NOT_OBSERVED -> NO_POSITIVE_SIGNAL` `UNKNOWN -> NO_POSITIVE_SIGNAL` `CONFLICTING -> NO_POSITIVE_SIGNAL` This boundary is particularly important for avoiding inverse inference. For example: `NOT_SUPPORTED(rule_stability)` does not automatically imply: `SUPPORTED(behavioral_variability)` Likewise: `UNKNOWN(human_discretion)` does not automatically imply: `SUPPORTED(procedural_control)` The runtime therefore does not manufacture an opposite signal merely because a candidate characteristic fails to produce a positive signal. --- ## 12. No Automatic Opposite-Signal Inference The reviewed implementation preserves the difference between: - evidence supporting one characteristic; - evidence not supporting that characteristic; - absence of relevant observation; - uncertainty; - conflicting evidence. These states are not collapsed into a binary positive/negative model. This matters because institutional processes frequently contain incomplete, contradictory, or context-dependent evidence. An analytical system that automatically converts every failed deterministic signal into a stochastic signal, or every failed stochastic signal into a deterministic signal, would overstate what the evidence establishes. The reviewed Process Mode implementation does not use that approach. Therefore: `NO_DETERMINISTIC_SIGNAL != STOCHASTIC_SIGNAL` and: `NO_STOCHASTIC_SIGNAL != DETERMINISTIC_SIGNAL` The absence of a positive signal remains analytically distinct from evidence supporting an opposite signal. --- ## 13. Evidence Multiplicity and Signal Weight The reviewed projection contract does not increase Process Mode signal count simply because multiple evidence records support the same characteristic. A signal is associated with an eligible characteristic, not with the raw number of evidence records attached to that characteristic. For example, multiple evidence references supporting `rule_stability` do not create multiple `rule_stability` signals. This prevents evidence-volume multiplication from silently becoming classification weight. The current reviewed behaviour can therefore be summarized as: `MULTIPLE_EVIDENCE_RECORDS_FOR_ONE_CHARACTERISTIC != MULTIPLE_SIGNALS` This is not a claim that evidence quantity is never analytically relevant. Rather, it establishes that the reviewed Process Mode projection layer does not use raw evidence multiplicity as an automatic signal-count multiplier. No statistical weighting, machine-learning weighting, or probability estimate should be inferred from the signal counts described in this document. --- ## 14. Zero-Signal Profiles The reviewed projector permits a valid profile in which: `deterministic_signal_count = 0` and: `stochastic_signal_count = 0` A zero-signal result is not treated as a projection failure merely because no positive signals were generated. This distinction is necessary because insufficient, non-signal, unresolved, or non-positive characteristic states may legitimately produce no Process Mode signals. The downstream Process Mode classifier can then preserve that absence of positive evidence through: `UNKNOWN_REQUIRES_REVIEW` rather than manufacturing a deterministic or stochastic proposal. Therefore: `ZERO_SIGNAL_PROFILE != RUNTIME_FAILURE` and: `ZERO_SIGNAL_PROFILE != FORCED_CLASSIFICATION` This is a fail-safe analytical property. When the reviewed signal basis is insufficient for a positive deterministic or stochastic proposal, uncertainty remains visible. --- ## 15. Process Mode Signal Profile The projection layer produces bounded deterministic and stochastic signal counts for downstream Process Mode evaluation. Conceptually: `D = deterministic_signal_count` `S = stochastic_signal_count` Within the reviewed integration contract, the Process Mode proposal logic is: - `D > 0` and `S = 0` -> `DETERMINISTIC_PROCESS` - `D = 0` and `S > 0` -> `STOCHASTIC_PROCESS` - `D > 0` and `S > 0` -> `MIXED_PROCESS` - `D = 0` and `S = 0` -> `UNKNOWN_REQUIRES_REVIEW` These outcomes describe the current proposal logic. They do not establish final institutional truth about the process. The classification remains review-required. The proposal may be accepted, rejected, corrected, contextualized, or otherwise handled through human review according to the applicable institutional workflow. --- ## 16. Signal Cardinality Boundary The evaluator-facing interpretation of signal cardinality must follow the projection contract rather than isolated unit-test fixture values. For the reviewed projection vocabulary: `MAX_DETERMINISTIC_SIGNALS = 4` `MAX_STOCHASTIC_SIGNALS = 3` These limits follow from the currently reviewed signal-eligible characteristic sets. They should not be generalized beyond the current Process Mode implementation contract. In particular, individual classifier unit tests may use synthetic signal-count inputs to test classifier branching independently of the upstream projector. Such fixture values should not be interpreted as expanding the projection vocabulary or changing the projector cardinality contract. Therefore: `CLASSIFIER_TEST_FIXTURE != PROJECTOR_CARDINALITY_DEFINITION` The public evaluation claim is limited to the bounded projector vocabulary and the reviewed integration behaviour. --- ## 17. Provenance and Evidence Lineage Process Mode signals must remain connected to the evidence-derived characteristics from which they were projected. The reviewed tests preserve provenance and evidence-lineage references across the evaluated pipeline. This is important because a Process Mode proposal without traceable evidence would be difficult to review, challenge, reproduce, or correct. The intended lineage can be represented as: `SOURCE EVIDENCE` `-> EVIDENCE-DERIVED CHARACTERISTIC` `-> CHARACTERISTIC STATE` `-> SIGNAL ELIGIBILITY` `-> PROJECTED PROCESS MODE SIGNAL` `-> SIGNAL PROFILE` `-> PROCESS MODE PROPOSAL` `-> HUMAN REVIEW` The reviewed implementation does not treat the Process Mode proposal as a replacement for this lineage. Instead, the proposal remains downstream of the evidence trail. --- ## 18. Provenance Preservation Is Not Authenticity Certification Preserving provenance references is not equivalent to independently proving the legal or factual authenticity of every source. The reviewed runtime can preserve information about the evidence and references that contributed to an analytical result. That capability supports reviewability and traceability. It does not, by itself, establish that: - every source is authentic; - every source is complete; - every source is legally admissible; - every source is free from manipulation; - every source has been independently verified; - every provenance assertion is externally certified. Therefore: `PROVENANCE_PRESERVATION != AUTHENTICITY_CERTIFICATION` and: `EVIDENCE_LINEAGE != LEGAL_VALIDATION` Source authenticity and source-access questions remain separate evidence and governance concerns. --- ## 19. Runtime Integration Boundary The reviewed Process Mode runtime includes an integration layer connecting evidence-derived characteristic processing with signal projection, Process Mode classification, and confidence-estimation behaviour. The significance of this integration evidence is that the evaluated components are not represented solely as disconnected architectural concepts. Reviewed tests exercise downstream behaviour across the Process Mode proposal paths. The integration evidence includes coverage of: - deterministic-only signal profiles; - stochastic-only signal profiles; - mixed signal profiles; - zero-signal profiles; - invalid projection handling; - mandatory human-review state. The reviewed proposal outcomes are: - `DETERMINISTIC_PROCESS` - `STOCHASTIC_PROCESS` - `MIXED_PROCESS` - `UNKNOWN_REQUIRES_REVIEW` This provides evaluator-facing evidence that the four-state Process Mode model has an implemented runtime path in the canonical development environment. It does not establish that every future Process Mode feature is implemented. --- ## 20. Fail-Closed Projection Handling The reviewed runtime integration tests include invalid projection behaviour. Where the upstream projection is invalid, the runtime does not continue as though a valid Process Mode signal profile had been established. In the reviewed integration contract, invalid projection prevents downstream classifier and confidence processing from being treated as a valid analytical continuation. This is a significant governance and reliability boundary. The system should not convert malformed or invalid projection state into a normal Process Mode proposal. Therefore: `INVALID_PROJECTION != VALID_CLASSIFICATION_INPUT` and: `FAILURE_STATE != AUTOMATIC_RECOVERY_AS_VALID_EVIDENCE` The reviewed behaviour is fail-closed for this bounded runtime transition. This statement applies to the reviewed Process Mode integration slice. It should not be generalized into a claim that every component of the wider LEO system has been exhaustively tested for every possible failure mode. --- ## 21. Confidence Integration Boundary The Process Mode runtime includes confidence-estimation integration. Confidence is subordinate to the evidence and signal structure. It does not replace evidence lineage. It does not transform a proposal into a human-confirmed decision. It does not authorize enforcement. It does not convert uncertainty into certainty. Accordingly: `CONFIDENCE != TRUTH` `CONFIDENCE != HUMAN_CONFIRMATION` `CONFIDENCE != ENFORCEMENT_AUTHORITY` `HIGHER_CONFIDENCE != LEGAL_OR_INSTITUTIONAL_VERDICT` The reviewed integration preserves the human-review requirement downstream of classification and confidence processing. The public evaluation significance is therefore not that LEO can produce a number called confidence. The relevant evidence is that confidence processing exists inside a bounded human-review architecture rather than replacing that architecture. --- ## 22. Runtime Side-Effect Boundary The reviewed Process Mode runtime-adapter tests include checks intended to keep the evaluated adapter slice bounded from unrelated execution surfaces. For that reviewed adapter slice, the tests check the absence of persistence, network, and subprocess behaviour within the evaluated runtime path. This supports a narrow evaluator claim: > the reviewed Process Mode adapter slice is tested as an analytical > transformation boundary rather than as an autonomous external-action > mechanism. This claim must remain scoped. It does not mean that the complete LEO codebase never uses: - filesystem operations; - network operations; - subprocesses; - persistence mechanisms; - external integrations. Those capabilities may exist elsewhere for legitimate system functions. The evidence supports only the reviewed adapter boundary. Therefore: `BOUNDED_ADAPTER_SIDE_EFFECT_TEST != WHOLE_SYSTEM_SIDE_EFFECT_ABSENCE` --- ## 23. Human Review Package Boundary The reviewed human-review package builder provides another important implementation boundary. The package is constructed for human review rather than for automatic institutional approval. Reviewed tests require the package state to remain: `PENDING_HUMAN_REVIEW` The reviewed package does not introduce automatic final-decision fields such as: - automatic approval; - automatic rejection; - autonomous review decision. This is consistent with the Process Mode governance model. The analytical pipeline may prepare evidence and a proposal for review. It does not complete the institutional decision on behalf of the reviewer. Therefore: `ANALYTICAL_PACKAGE != FINAL_DECISION` and: `PENDING_HUMAN_REVIEW != APPROVED` and: `PENDING_HUMAN_REVIEW != REJECTED` --- ## 24. End-to-End Evaluated Boundary Taken together, the reviewed runtime evidence supports the following bounded implementation chain: `SOURCE EVIDENCE` `-> EVIDENCE-DERIVED CHARACTERISTICS` `-> CONTROLLED CHARACTERISTIC STATES` `-> SIGNAL ELIGIBILITY` `-> DETERMINISTIC / STOCHASTIC SIGNAL PROJECTION` `-> PROCESS MODE SIGNAL PROFILE` `-> PROCESS MODE PROPOSAL` `-> CONFIDENCE INTEGRATION` `-> HUMAN REVIEW PACKAGE` `-> HUMAN REVIEW REQUIRED` The implementation evidence does not support adding an autonomous enforcement step after this chain. It also does not support replacing the final human-review boundary with an automatic institutional verdict. The evaluator-facing interpretation should therefore remain: > LEO implements a bounded analytical proposal pipeline designed to preserve > evidence distinctions, provenance, uncertainty, and human decision authority. --- ## 25. Test Evidence Interpretation The tests reviewed for this document are used as implementation evidence for specific behavioural contracts. They should not be interpreted as proof that the complete LEO system is correct under every possible condition. The relevant evaluator distinction is: `TEST_EXISTS` is not equivalent to: `ALL_POSSIBLE_BEHAVIOUR_VALIDATED` Instead, the reviewed tests provide evidence that selected expected behaviours and governance boundaries have executable representations in the canonical development environment. For this Process Mode slice, those behaviours include: - preservation of non-positive characteristic states; - controlled signal eligibility; - bounded deterministic and stochastic signal projection; - preservation of zero-signal profiles; - four-state Process Mode proposal behaviour; - invalid-projection handling; - provenance and evidence-lineage preservation; - confidence integration; - mandatory human-review state; - construction of a pending human-review package. This is materially stronger than an architecture-only claim. It remains narrower than complete system validation. --- ## 26. Reviewed Test Evidence Surfaces The evaluator-facing claims in this document were derived from review of selected canonical Process Mode test surfaces. ### 26.1 Evidence-derived characteristic evaluator Reviewed test surface: `test_evidence_derived_characteristic_evaluator.py` The reviewed tests support claims concerning: - distinction between `SUPPORTED`, `NOT_SUPPORTED`, `NOT_OBSERVED`, `UNKNOWN`, and `CONFLICTING`; - conservative handling of insufficient or conflicting evidence; - signal-eligibility boundaries; - preservation of evidence references; - preservation of provenance and lineage information; - continued human-review requirement; - absence of automatic human confirmation. ### 26.2 Characteristic-to-signal projector Reviewed test surface: `test_evidence_derived_characteristic_to_signal_projector.py` The reviewed tests support claims concerning: - deterministic signal vocabulary; - stochastic signal vocabulary; - non-signal treatment of `auditability`; - positive-signal generation from eligible `SUPPORTED` characteristics; - absence of positive signals from non-positive characteristic states; - bounded signal counts; - zero-signal profiles; - prevention of evidence-multiplicity signal inflation. ### 26.3 Process Mode runtime adapter Reviewed test surface: `test_evidence_derived_process_mode_runtime_adapter.py` The reviewed tests support claims concerning: - integration of projected signal profiles with downstream Process Mode logic; - deterministic proposal behaviour; - stochastic proposal behaviour; - mixed proposal behaviour; - unknown-requires-review behaviour; - invalid-projection fail-closed handling; - preservation of human-review requirements; - bounded adapter-side-effect expectations. ### 26.4 Process Mode classifier Reviewed test surface: `test_process_mode_classifier.py` The reviewed tests support claims concerning the classifier branch behaviour for: - `DETERMINISTIC_PROCESS`; - `STOCHASTIC_PROCESS`; - `MIXED_PROCESS`; - `UNKNOWN_REQUIRES_REVIEW`. Classifier unit-test fixture values are not used in this document to redefine the upstream projector cardinality contract. ### 26.5 Human-review package builder Reviewed test surface: `test_human_review_package_builder.py` The reviewed tests support claims concerning: - construction of a review package; - `PENDING_HUMAN_REVIEW` state; - preservation of the human-review boundary; - absence of automatic approval or rejection fields in the reviewed package contract. --- ## 27. Claim-to-Evidence Discipline Public evaluation claims should remain traceable to the type of evidence that supports them. For this document, the following claim classes are permitted. ### 27.1 Implemented The term `implemented` may be used where a corresponding canonical runtime component has been observed. ### 27.2 Covered by canonical tests The phrase `covered by canonical tests` may be used where reviewed tests exercise the relevant behavioural contract. ### 27.3 Architecturally defined The phrase `architecturally defined` may be used where the architecture specifies behaviour that is not being presented here as verified runtime behaviour. ### 27.4 Not publicly disclosed The phrase `not publicly disclosed` may be used where implementation material exists within the canonical development environment but is intentionally outside the current public evaluation disclosure boundary. These categories must not be collapsed. In particular: `ARCHITECTURALLY_DEFINED != IMPLEMENTED` `IMPLEMENTED != TESTED_FOR_ALL_CASES` `TESTED != INDEPENDENTLY_VALIDATED` `NOT_PUBLICLY_DISCLOSED != NONEXISTENT` This distinction is necessary for an evaluator to understand both capability and maturity without overstatement. --- ## 28. Claims This Evidence Supports Within the reviewed scope, the available evidence supports the following statements. ### 28.1 Process Mode has an implemented runtime path The canonical development environment contains runtime components supporting a Process Mode analytical pipeline. This statement is supported by observed runtime implementation surfaces and reviewed canonical tests. ### 28.2 The four Process Mode proposal states are executable behaviours The reviewed runtime/test evidence covers: - `DETERMINISTIC_PROCESS` - `STOCHASTIC_PROCESS` - `MIXED_PROCESS` - `UNKNOWN_REQUIRES_REVIEW` These remain proposal states rather than autonomous institutional decisions. ### 28.3 Evidence-derived characteristic semantics are implemented The reviewed evaluator distinguishes positive support, lack of support, absence of observation, uncertainty, and conflict. These distinctions are not merely documentation terminology within the reviewed implementation slice. ### 28.4 Signal eligibility is controlled The reviewed projection layer does not convert every characteristic or every piece of evidence into a Process Mode signal. Signal generation is constrained by characteristic state and eligibility. ### 28.5 Non-positive states do not automatically generate opposite signals The reviewed implementation preserves the distinction between lack of positive support and evidence for an opposite characteristic. ### 28.6 Provenance and evidence-lineage references are preserved The reviewed pipeline retains evidence/provenance information needed to support downstream reviewability. This is a traceability claim, not an authenticity-certification claim. ### 28.7 Zero-signal uncertainty is preserved The reviewed implementation permits a valid zero-signal profile and can route that state to `UNKNOWN_REQUIRES_REVIEW`. ### 28.8 Invalid projection is not silently treated as valid input The reviewed integration behaviour prevents invalid projection state from being treated as an ordinary valid classification path. ### 28.9 Human review remains mandatory Reviewed characteristic, classification, integration, and review-package behaviour preserves the human-review boundary. ### 28.10 The reviewed runtime does not itself provide a final institutional decision The Process Mode pipeline prepares analytical material for review. The reviewed evidence does not support a claim that it autonomously completes the institutional decision. --- ## 29. Claims This Evidence Does Not Support The evidence reviewed for this document does not justify the following claims. ### 29.1 Production readiness This document does not establish that the Process Mode implementation is ready for unrestricted production deployment. ### 29.2 Complete system validation The reviewed tests do not establish that every LEO component, integration, failure mode, or deployment environment has been exhaustively validated. ### 29.3 Regulatory compliance certification The evidence does not establish formal compliance certification under the EU AI Act, GDPR, or another legal or regulatory framework. Governance design may be evaluated against relevant requirements separately. ### 29.4 Legal correctness The Process Mode proposal is not a legal conclusion. ### 29.5 Fraud determination The Process Mode proposal is not a fraud verdict and does not establish fraudulent conduct. ### 29.6 Independent external validation The reviewed evidence originates from the canonical LEO development and test environment. It should not be represented as independent third-party validation. ### 29.7 Universal process taxonomy The current deterministic and stochastic characteristic vocabularies are implementation contracts for the reviewed Process Mode method. They are not claimed to be a universal scientific taxonomy covering every possible institutional process. ### 29.8 Autonomous learning The reviewed implementation evidence does not authorize LEO to autonomously convert runtime observations into permanently accepted institutional knowledge. ### 29.9 Autonomous enforcement No Process Mode result documented here authorizes automatic sanction, enforcement, approval, rejection, or production mutation. --- ## 30. Reproducibility Position Reproducibility is relevant to public evaluation because an evaluator should be able to distinguish between: - a conceptual statement; - an implementation claim; - a test-backed implementation claim; - an independently reproduced result. The current Process Mode evidence reaches the third of these levels for the bounded behaviours described in this document: `TEST-BACKED INTERNAL IMPLEMENTATION EVIDENCE` This document does not claim that an external evaluator can reproduce the complete canonical Process Mode runtime solely from the public repository. That is not the current publication model. The public repository intentionally does not contain the complete canonical implementation. Accordingly, two reproducibility layers must remain distinct. ### 30.1 Public-document reproducibility An evaluator can inspect the public architecture, methodology, governance boundaries, evaluation evidence, and disclosed examples. ### 30.2 Canonical implementation reproducibility The canonical development environment contains the implementation and test surfaces used to establish the claims summarized here. Access to that environment is not implied by publication of this document. Therefore: `PUBLIC_EVALUATION_REPRODUCIBILITY != COMPLETE_SOURCE_REPRODUCTION` The public package should provide enough evidence to evaluate the method without falsely implying that all protected implementation has been released. --- ## 31. Current Verification Baseline The evidence review underlying this document was performed against a controlled canonical and publication-working baseline. At the time of the reviewed evidence extraction: `CANONICAL_ROOT = D:\BBS-09-01-2026` `CANONICAL_HEAD = 12b51b7cac6d522e9a93fcde422408f29c4320cf` and: `PUBLICATION_WORKING_REPOSITORY = repository_publication_staging/BBS-Open-System-publication-working` `PUBLICATION_WORKING_HEAD = 6461c4aa61633267b80a0bc6cb6a2fc77d0814c3` These identifiers establish the reviewed development state. They should not be interpreted as permanent version identifiers for all future Process Mode releases. Future changes require a new evidence review before materially stronger public claims are made. --- ## 32. Disclosure Boundary The Process Mode public evaluation strategy is evidence-oriented rather than source-dump-oriented. The objective is to provide sufficient information for meaningful evaluation of: - the method; - the implemented analytical path; - the tested behavioural boundaries; - provenance handling; - human-control requirements; - current maturity; - known limitations. The objective is not to publish every canonical source file. Accordingly, this document does not itself authorize publication of: - the complete Process Mode runtime source; - the complete canonical test suite; - unrelated internal modules; - internal development history not needed for evaluation; - protected implementation details; - institutional data; - secrets or credentials; - unpublished evidence sources; - material whose rights status does not permit publication. The disclosure decision remains separate from the existence of implementation evidence. Therefore: `IMPLEMENTATION_EXISTS != SOURCE_PUBLICATION_AUTHORIZED` and: `TEST_EVIDENCE_EXISTS != TEST_SUITE_PUBLICATION_AUTHORIZED` --- ## 33. Relationship to Third-Party Rights Review Public evaluation evidence must remain compatible with the repository's third-party-rights controls. The existence of evaluator-significant technical evidence does not override rights review. Any future decision to publish additional: - source code; - generated output; - screenshots; - PDFs; - embedded assets; - dependency material; - external-tool output; - third-party content must remain subject to the applicable publication-rights review. The Process Mode runtime evidence document therefore does not supersede the separate third-party-rights inventory. The relevant control principle is: `EVALUATOR_SIGNIFICANCE != AUTOMATIC_PUBLICATION_PERMISSION` Technical importance and publication permission are separate questions. --- ## 34. Public Repository Role The public repository is an evaluation surface for the LEO method. It should permit an evaluator to understand the relationship between: - institutional problem; - methodology; - architecture; - implementation evidence; - practical demonstrations; - provenance; - governance boundaries; - maturity; - limitations. It should not create the impression that every internal LEO artifact is publicly available or that every planned capability has been implemented. For Process Mode specifically, the public repository should make clear that: 1. the method is architecturally defined; 2. a bounded runtime implementation exists; 3. selected behavioural contracts are covered by canonical tests; 4. human review remains mandatory; 5. protected implementation remains outside the current disclosure scope; 6. the system remains under development and evaluation. This is the intended evaluator-facing maturity position. --- ## 35. Evaluator Interpretation Guide An evaluator reading Process Mode material should distinguish the following questions. ### Question 1: What problem does the method address? It distinguishes process character before downstream anomaly interpretation. ### Question 2: Is the method merely conceptual? No. A bounded canonical runtime implementation and corresponding test surfaces have been reviewed. ### Question 3: Does the public repository contain the complete implementation? No. The current publication strategy does not require complete source disclosure. ### Question 4: Does Process Mode make the final institutional decision? No. It generates an analytical proposal for human review. ### Question 5: Can uncertain evidence be forced into a positive classification? The reviewed implementation preserves non-positive and uncertain states and permits `UNKNOWN_REQUIRES_REVIEW`. ### Question 6: Does a Process Mode proposal determine fraud, legality, or compliance? No. Those conclusions are outside the reviewed Process Mode authority boundary. ### Question 7: Does confidence remove the need for human review? No. Confidence remains subordinate to evidence, provenance, and human review. ### Question 8: Is the implementation production-ready? This document does not make that claim. The implementation is presented as an experimental, internally developed and tested evaluation-stage capability. --- ## 36. Known Limitations The following limitations are material to interpretation of the current evidence. ### 36.1 Internal test evidence The test evidence reviewed here is internal canonical evidence. Independent external reproduction has not been established by this document. ### 36.2 Bounded implementation slice The review concerns selected Process Mode runtime components. It is not an audit of every LEO runtime component. ### 36.3 Protected implementation Complete implementation source is outside the current public disclosure scope. This limits full public source-level reproducibility. ### 36.4 Evolving architecture LEO remains under active development. Future reviewed changes may alter implementation details while preserving or revising architectural contracts. ### 36.5 Institutional context Process Mode interpretation may depend on the quality, scope, and relevance of the evidence provided for a particular institutional process. ### 36.6 Source quality Preservation of provenance does not guarantee source authenticity or source quality. ### 36.7 Human review dependency The method intentionally depends on human review for institutional confirmation. This is a governance property of the current architecture, not an omitted automation feature. --- ## 37. Current Maturity Assessment For the bounded Process Mode slice reviewed here, the evidence supports the following maturity assessment: `ARCHITECTURAL_DEFINITION = PRESENT` `CANONICAL_RUNTIME_IMPLEMENTATION = PRESENT` `CANONICAL_TEST_COVERAGE_FOR_REVIEWED_BOUNDARIES = PRESENT` `PUBLIC_EVALUATOR_DESCRIPTION = PRESENT` `PUBLIC_COMPLETE_SOURCE_DISCLOSURE = NOT_REQUIRED_FOR_CURRENT_SCOPE` `INDEPENDENT_EXTERNAL_VALIDATION = NOT_ESTABLISHED_BY_THIS_DOCUMENT` `PRODUCTION_READINESS = NOT_ESTABLISHED_BY_THIS_DOCUMENT` `HUMAN_REVIEW_REQUIREMENT = ACTIVE` This maturity position is intentionally narrower than a product-completion claim. The relevant Commission-facing proposition is not: > LEO is complete. The relevant proposition is: > LEO has developed a coherent human-controlled analytical method, and selected > core parts of that method have progressed from architectural definition to a > test-backed canonical runtime implementation that can be presented for > evaluation without representing the system as finished or autonomously > authoritative. --- ## 38. Evidence Sufficiency Assessment The reviewed evidence is sufficient for a bounded public claim that the LEO Process Mode method has progressed beyond architectural description into an implemented and canonically tested analytical runtime slice. The evidence is sufficient to demonstrate: - implemented evidence-derived characteristic evaluation; - controlled characteristic-state semantics; - explicit signal eligibility; - bounded deterministic and stochastic signal projection; - preservation of non-positive and uncertain states; - four-state Process Mode proposal behaviour; - provenance and evidence-lineage preservation; - invalid-projection fail-closed behaviour; - confidence-estimation integration; - mandatory human-review state; - construction of a pending human-review package. The evidence is not sufficient to establish: - complete implementation of every planned Process Mode capability; - exhaustive validation of every possible input or failure mode; - independent external verification; - production deployment readiness; - regulatory certification; - legal correctness; - autonomous institutional authority. The evidence sufficiency decision is therefore: `EVIDENCE_SUFFICIENCY = SUFFICIENT_FOR_BOUNDED_PUBLIC_EVALUATION` with: `OVERALL_SYSTEM_COMPLETION_CLAIM = NOT_AUTHORIZED` and: `PRODUCTION_READINESS_CLAIM = NOT_AUTHORIZED` --- ## 39. Architectural Risks Assessment The reviewed Process Mode implementation provides meaningful evaluator evidence, but several architectural risks remain relevant. ### 39.1 Evidence-quality dependency The quality of a Process Mode proposal remains dependent on the quality, relevance, completeness, and provenance of the evidence supplied to the analytical pipeline. Preserving evidence lineage does not eliminate poor-quality evidence. **Risk state:** Active and governed through review. ### 39.2 Characteristic-model incompleteness The current deterministic and stochastic characteristic vocabularies are bounded implementation contracts. Institutional processes may contain characteristics not represented by the current model. The present vocabulary should therefore remain extensible through controlled architectural review rather than being represented as universal. **Risk state:** Known architectural limitation. ### 39.3 Classification-context risk A technically valid signal profile may still require institutional context that is not represented by signal counts alone. For this reason, Process Mode output remains a proposal. **Risk state:** Controlled through mandatory human review. ### 39.4 Confidence misinterpretation risk Confidence values may be misunderstood as certainty, truth, legal validity, or institutional authority. The architecture explicitly rejects those interpretations. **Risk state:** Controlled by documentation and human-review boundaries. ### 39.5 Provenance-versus-authenticity risk Evidence provenance may be preserved even when source authenticity has not been independently established. An evaluator must not interpret lineage preservation as authenticity certification. **Risk state:** Explicitly bounded. ### 39.6 Public-versus-canonical divergence risk The public repository intentionally exposes less implementation detail than the canonical development environment. Without explicit evidence documents, this can cause evaluators to underestimate the current implementation maturity or, conversely, to infer capabilities that are not publicly evidenced. This document is intended to reduce that divergence. **Risk state:** Mitigated for the reviewed Process Mode slice; continued synchronization required. ### 39.7 Architecture-runtime drift risk LEO remains under active development. Future runtime changes could diverge from architectural documentation or public evaluation material if continuity review is not maintained. **Risk state:** Requires ongoing architectural continuity review. ### 39.8 Overclaiming risk Commission-facing publication creates a particular risk of presenting internal development evidence as production maturity, certification, or regulatory acceptance. This document deliberately uses narrower evidence-backed language. **Risk state:** Controlled by claim-to-evidence discipline. ### 39.9 Rights and disclosure risk Evaluator-significant implementation material may still be unsuitable for publication because of intellectual-property, third-party-rights, security, privacy, or institutional constraints. **Risk state:** Separate publication-rights review required. --- ## 40. Implementation Readiness Assessment The reviewed Process Mode slice has sufficient implementation maturity to be presented as a practical internal-laboratory implementation of the method. The following readiness states are supported: `METHOD_DEFINITION_READINESS = PRESENT` `BOUNDED_RUNTIME_READINESS = PRESENT` `REVIEWED_TEST_EVIDENCE_READINESS = PRESENT` `HUMAN_REVIEW_WORKFLOW_READINESS = PRESENT_FOR_REVIEWED_SLICE` `PUBLIC_EVALUATION_EXPLANATION_READINESS = PRESENT_WITH_THIS_ARTIFACT` The following readiness states are not established: `UNRESTRICTED_PRODUCTION_READINESS = NOT_ESTABLISHED` `COMPLETE_EXTERNAL_INTEGRATION_READINESS = NOT_ESTABLISHED` `INDEPENDENT_CERTIFICATION_READINESS = NOT_ESTABLISHED` `AUTONOMOUS_DECISION_READINESS = NOT_APPLICABLE_AND_NOT_AUTHORIZED` This distinction is important. The relevant maturity threshold for the current public evaluation package is not production completion. It is the ability to demonstrate that the proposed method has: 1. a coherent architecture; 2. a bounded implementation; 3. executable behavioural evidence; 4. explicit limitations; 5. preserved human authority; 6. a credible path for continued controlled development. For the reviewed Process Mode slice, that threshold is met. --- ## 41. Governance Boundary Assessment The reviewed implementation evidence remains consistent with the principal LEO governance boundaries. ### Human review `REQUIRED` ### Autonomous enforcement `NOT_AUTHORIZED` ### Autonomous institutional approval or rejection `NOT_AUTHORIZED` ### Fraud verdict `NOT_PROVIDED` ### Legal verdict `NOT_PROVIDED` ### Compliance certification `NOT_PROVIDED` ### Production mutation from Process Mode proposal `NOT_AUTHORIZED` ### Evidence-lineage preservation `REQUIRED` ### Automatic conversion of evidence into reviewed institutional knowledge `NOT_AUTHORIZED` ### Uncertainty preservation `REQUIRED` The reviewed implementation therefore remains consistent with the intended role of LEO as a human-controlled institutional integrity and evidence-review system. --- ## 42. Practical Evaluation Value The practical value of Process Mode is not that it replaces institutional judgment. Its value is that it introduces a disciplined analytical step before anomaly interpretation. Without such a distinction, an analytical system may apply deterministic expectations to inherently variable human processes or treat deviations from stable procedures as though they were ordinary stochastic variation. The Process Mode method provides a structured alternative. It asks: > What kind of process is represented by the reviewed evidence, and what > analytical assumptions are justified before downstream anomaly > interpretation begins? The current implementation demonstrates a practical mechanism for answering that question conservatively. It preserves: - positive evidence; - absence of support; - absence of observation; - uncertainty; - conflicting evidence; - provenance; - signal boundaries; - unknown states; - human decision authority. This is the primary evaluator-facing value of the reviewed implementation. --- ## 43. Relationship to the Wider LEO Method Process Mode is not intended to operate as an isolated classification feature. Its architectural role is upstream of later anomaly interpretation and reviewed institutional knowledge. The broader conceptual dependency remains: `EVIDENCE` `-> PROCESS CHARACTER UNDERSTANDING` `-> ANOMALY INTERPRETATION` `-> HUMAN REVIEW` `-> REVIEWED KNOWLEDGE` where appropriate and explicitly authorized. Process Mode therefore helps prevent downstream analysis from assuming that all processes should behave according to the same analytical model. This document does not claim that every downstream LEO layer is complete. It demonstrates that an important upstream methodological distinction has a bounded implementation and test-backed evidence base. --- ## 44. European Commission Evaluation Relevance For European Commission or comparable institutional evaluation, the significance of this evidence is methodological and practical. The evidence does not ask the evaluator to accept LEO because it claims to be a finished system. Instead, it provides a concrete example of how a human-controlled institutional AI method can separate: - evidence from conclusions; - characteristic evaluation from classification; - uncertainty from negative evidence; - signal generation from raw evidence volume; - analytical proposals from institutional decisions; - confidence from truth; - provenance from authenticity certification; - implementation evidence from production claims. These separations are central to the design of systems intended for institutional integrity, evidence review, anomaly analysis, and accountable human oversight. The current Process Mode implementation should therefore be evaluated as one practical methodological contribution within an evolving LEO system. --- ## 45. Review Decision ### Decision `PASS_FOR_BOUNDED_PUBLIC_EVALUATION` ### Rationale The reviewed evidence demonstrates a coherent relationship between: - the public Process Mode methodology; - the canonical runtime implementation; - executable test contracts; - evidence and provenance boundaries; - Process Mode proposal semantics; - confidence integration; - human-review requirements. No evidence reviewed for this document justifies representing Process Mode as an autonomous institutional decision system. No evidence reviewed for this document justifies representing the complete LEO system as production-ready or externally certified. Those limitations do not invalidate the current evaluation evidence. They define its correct scope. The Process Mode slice is therefore suitable for controlled public evaluation when presented with the boundaries recorded in this document. --- ## 46. Architectural Continuity Statement The reviewed Process Mode evidence remains consistent with the core LEO architectural direction: `HUMAN_CONTROLLED` `EVIDENCE_BASED` `PROVENANCE_PRESERVING` `REVIEW_REQUIRED` `NON_AUTONOMOUS_ENFORCEMENT` `NON_FRAUD_VERDICT` `NON_LEGAL_VERDICT` `NO_UNAUTHORIZED_PRODUCTION_MUTATION` The reviewed runtime preserves the architectural distinction between evidence, analytical proposal, and human-confirmed institutional knowledge. The reviewed public representation also preserves the distinction between: - canonical development evidence; - public evaluation evidence; - protected implementation; - external validation. No architectural contradiction requiring modification of the reviewed Process Mode method was identified within the evidence scope used for this document. Future implementation changes should continue to be evaluated against these continuity boundaries before stronger public claims are introduced. --- ## 47. Publication Control Statement This document records evidence relevant to public evaluation. It does not independently authorize publication of additional canonical artifacts. Any additional publication decision must consider: - evaluator significance; - intellectual-property strategy; - third-party rights; - privacy; - security; - institutional confidentiality; - provenance; - public reuse permissions; - current maturity; - disclosure necessity. Where these factors are unresolved, human review remains required. No unresolved artifact should be made public solely because it would strengthen an evaluation narrative. --- ## 48. Next Authorized Phase Completion of this document does not authorize immediate expansion of the public repository. The next authorized activity is: `PROCESS_MODE_RUNTIME_EVIDENCE_FILE_VERIFICATION` That verification should confirm: 1. the document exists at the intended publication-working path; 2. the document is complete; 3. all four drafted parts form one continuous file; 4. no section was duplicated or omitted during manual insertion; 5. repository status contains only expected changes; 6. canonical and publication repository HEAD values remain understood; 7. no protected implementation was copied into the public repository; 8. no unrelated artifact was modified; 9. the document remains consistent with the current Process Mode architecture; 10. the document remains consistent with the public licensing and disclosure boundaries. Only after that verification should a separate human decision be made about: - integration into public navigation; - staging; - commit; - publication; - continuation to the next evaluator-significant delta slice. No such action is authorized by this document alone. --- ## 49. Final Status `PROCESS_MODE_RUNTIME_EVIDENCE_STATUS = VERIFIED_FOR_BOUNDED_PUBLIC_EVALUATION` `EVALUATOR_SIGNIFICANT_DELTA_SLICE = PROCESS_MODE` `EVIDENCE_RESULT = PASS_FOR_BOUNDED_PUBLIC_EVALUATION` `HUMAN_REVIEW_REQUIRED = TRUE` `PUBLICATION_AUTHORIZATION = NOT_IMPLIED` `PRODUCTION_AUTHORIZATION = FALSE` `AUTONOMOUS_ENFORCEMENT = FALSE` `FRAUD_OR_LEGAL_VERDICT = FALSE` `NEXT_STEP = PUBLIC_EVALUATION_INTEGRATION_REVIEW` --- **End of document**