# LEO Public Demo Catalog **Project:** LEO — Human-Controlled Institutional Integrity, Provenance, Evidence Review and Anomaly Analysis System **Document role:** Canonical public demonstration catalog **Status:** Public evaluation preparation **Last updated:** 2026-08-17 **Human review:** Required --- # Purpose This document provides the canonical navigation entry point for public LEO demonstration repositories and embedded public demonstrations. Its purpose is to help evaluators distinguish: * what each public demonstration actually exercises; * where the demonstration is located; * which capabilities are demonstrated; * which governance boundaries apply; * what the demonstration does not establish; * how demonstration evidence relates to the broader current LEO architecture. The catalog supports consistency among: * `README.md`; * `PROJECT_STATUS.md`; * `index.html`; * public demonstration repositories; * public evaluation materials; * public communications. This document catalogs public demonstrations. It does not establish production authorization, autonomous institutional authority, regulatory compliance, or complete implementation of the broader LEO architecture. --- # Current Public Position LEO is under: ```text ACTIVE ARCHITECTURAL AND ENGINEERING DEVELOPMENT + CONTROLLED PUBLIC EVALUATION PREPARATION ``` All demonstrations listed in this catalog must be interpreted within that project state. The public demonstrations provide scoped runtime evidence. They do not independently represent the complete current LEO architecture. The current architecture includes broader work around: * source evidence; * provenance; * evidence lineage; * evidence-derived characteristics; * signal eligibility; * deterministic and stochastic process signals; * Process Mode; * anomaly analysis; * reviewed anomaly memory; * Reviewed / Institutional Knowledge; * reviewer support; * human governance. Some of these capabilities may be demonstrated only partially, may belong to controlled runtime baselines, may exist as reviewed architecture, or may remain under active development. A public demo should therefore be interpreted according to what it actually demonstrates rather than as evidence that every LEO architectural layer has been implemented. For the detailed current project position, see: ### [LEO Project Status](./PROJECT_STATUS.md) For the high-level repository and architecture overview, see: ### [LEO README](./README.md) --- # Demonstration Interpretation Model Public demonstrations are evidence of defined and inspectable runtime behavior within their documented scope. The intended interpretation is: ```text PUBLIC DEMONSTRATION -> SCOPED RUNTIME EVIDENCE -> INSPECTABLE OUTPUT -> HUMAN EVALUATION ``` not: ```text PUBLIC DEMONSTRATION -> COMPLETE SYSTEM VALIDATION -> PRODUCTION AUTHORIZATION ``` A demonstration may establish that a particular workflow, validation path, reviewer interface, evidence-processing function, export mechanism, or analytical capability has been implemented and exercised. It does not automatically establish: * complete-system implementation; * complete-system test coverage; * production readiness; * production deployment authorization; * autonomous institutional authority; * autonomous enforcement authority; * legal or regulatory compliance; * authoritative fraud-determination capability. --- # Public Demonstration Portfolio The current catalog contains: ```text 3 PUBLIC DEMONSTRATION TRACKS ``` They are: 1. Institutional Approval Review; 2. Procurement / Accounting Review; 3. Grant Expense Review. All three demonstrations are human-review-oriented. --- # 1. Institutional Approval Review ## Status ```text PUBLIC_MVP ``` ## Location ```text demos/institutional_approval_review ``` ## Repository ```text https://github.com/BBS-contact/BBS-Open-System ``` ## Purpose The Institutional Approval Review demonstration presents a local, human-controlled evidence-review workflow for institutional approval chains. It provides scoped runtime evidence for structured review of approval-process information. ## Demonstrated Capabilities The demonstration includes: * structured input-quality validation; * approval-workflow analysis; * evidence-backed review findings; * evidence-report generation; * human reviewer actions; * local reviewer-dashboard use; * human review-package export; * zero-autonomy safety boundaries. These capabilities should be interpreted within the documented Institutional Approval runtime scope. They do not independently establish implementation of every current LEO architectural layer. ## Operational Boundary ```text HUMAN REVIEW REQUIRED NO AUTONOMOUS APPROVAL NO AUTONOMOUS REJECTION NO AUTONOMOUS ENFORCEMENT NO AUTHORITATIVE FRAUD VERDICT NO AUTHORITATIVE LEGAL VERDICT NO PRODUCTION MUTATION ``` The demonstration supports review of institutional approval evidence. It does not independently possess authority to approve, reject, sanction, punish, or otherwise execute consequential institutional decisions. ## Historical Test Context Historical Institutional Approval runtime evidence includes a previously recorded combined test result of: ```text 2451 passed in 56.87s ``` This result belongs to its historical Institutional Approval combined runtime baseline. It is preserved as scoped historical engineering evidence. It must not be interpreted as a current global LEO repository test count. A current global test-count claim would require a new appropriately scoped validation. --- # 2. Procurement / Accounting Review ## Status ```text PUBLIC_EVALUATION_DEMO ``` ## Repository ```text https://github.com/BBS-contact/leo-procurement-accounting-demo ``` ## Public Demo ```text https://bbs-contact.github.io/leo-procurement-accounting-demo/ ``` ## Purpose The Procurement / Accounting Review demonstration presents a human-controlled, evidence-linked workflow for reviewing procurement and accounting information. Its purpose is to provide inspectable reviewer-support behavior around evidence, source quality, anomalies, reviewer questions, and controlled export. ## Demonstrated Capabilities The demonstration includes: * evidence-linked review; * source-trust review and warnings; * reviewer-question generation; * anomaly-review support; * evidence-backed reviewer context; * local export-package generation. The resulting signals, questions, warnings, or anomaly-review information are reviewer-support artifacts. They are not autonomous institutional findings. ## Operational Boundary ```text HUMAN REVIEW REQUIRED NO AUTONOMOUS ENFORCEMENT NO AUTHORITATIVE FRAUD VERDICT NO AUTHORITATIVE LEGAL VERDICT NO AUTOMATIC ACCUSATION NO PRODUCTION MUTATION ``` An anomaly, unusual transaction, source-trust warning, documentation inconsistency, or reviewer question does not independently establish fraud, wrongdoing, illegality, or regulatory violation. The demonstration does not autonomously convert analytical findings into sanctions, restrictions, enforcement actions, or production-changing decisions. --- # 3. Grant Expense Review ## Status ```text PUBLIC_EVALUATION_DEMO ``` ## Repository ```text https://github.com/BBS-contact/leo-grant-expense-review-demo ``` ## Purpose The Grant Expense Review demonstration presents a human-controlled workflow for reviewing grant-expense evidence and supporting documentation. Its purpose is to demonstrate structured reviewer support rather than autonomous expense authorization or enforcement. ## Demonstrated Capabilities The demonstration includes: * grant-expense validation; * evidence generation; * documentation-completeness review; * budget-line review; * reviewer-dashboard use; * review-package export. The demonstration provides evidence and review support within its documented runtime scope. ## Operational Boundary ```text HUMAN REVIEW REQUIRED NO EXPENSE APPROVAL AUTHORITY NO PAYMENT DECISION AUTHORITY NO AUTHORITATIVE FRAUD DETERMINATION NO AUTHORITATIVE LEGAL VERDICT NO AUTONOMOUS ENFORCEMENT NO PRODUCTION MUTATION ``` Review findings do not independently authorize payment approval, payment rejection, sanctions, fraud findings, legal conclusions, or production-system changes. --- # Shared Demonstration Governance Boundary Although each demonstration addresses a different institutional review scenario, all current public demonstrations share a common governance baseline. LEO public demonstrations do not independently authorize the system to: * approve; * reject; * block; * punish; * sanction; * make payment decisions; * issue authoritative fraud determinations; * issue authoritative legal conclusions; * autonomously enforce institutional outcomes; * mutate production records; * replace institutional authority. The common baseline is: ```text ANALYSIS / REVIEW SUPPORT -> HUMAN REVIEW ``` not: ```text ANALYSIS -> AUTOMATIC INSTITUTIONAL ACTION ``` Specific demonstration boundaries remain applicable in addition to this shared baseline. --- # Relationship to the Current LEO Architecture The public demonstration portfolio predates or represents only selected portions of some of the broader architectural development now present in LEO. The current canonical Process Mode interpretation pipeline is: ```text SOURCE EVIDENCE -> EVIDENCE-DERIVED CHARACTERISTICS -> SIGNAL ELIGIBILITY -> DETERMINISTIC / STOCHASTIC SIGNAL COUNTS -> PROCESS MODE PROPOSAL -> HUMAN REVIEW ``` The canonical Process Mode states are: * `DETERMINISTIC_PROCESS`; * `STOCHASTIC_PROCESS`; * `MIXED_PROCESS`; * `UNKNOWN_REQUIRES_REVIEW`. Public demonstrations should not be assumed to implement this entire architecture merely because they are part of the LEO public portfolio. Where a demonstration predates a current architectural layer, the demonstration remains valid historical or scoped runtime evidence for what it actually exercises. The broader architecture should be evaluated through the current architectural documentation and applicable runtime evidence rather than inferred solely from the demonstration portfolio. --- # Evidence and Signal Boundary Current LEO architecture distinguishes source evidence from evidence-derived characteristics and analytical signals. Evidence-derived characteristic states include: * `SUPPORTED`; * `NOT_SUPPORTED`; * `NOT_OBSERVED`; * `UNKNOWN`; * `CONFLICTING`. Only signal-eligible `SUPPORTED` characteristics may contribute positive deterministic or stochastic signals. The other states remain distinct and must not automatically generate a positive or opposite signal. This distinction is relevant when evaluating demonstrations that expose review findings, warnings, anomaly information, or analytical outputs. A public demonstration output should not be interpreted as an authoritative institutional conclusion merely because the system generated it. --- # Anomaly Interpretation Boundary LEO treats anomalies as review objects rather than automatic accusations. The existence of an anomaly may indicate that evidence or process behavior deserves additional review. It does not independently establish: * fraud; * wrongdoing; * illegality; * regulatory violation; * intentional misconduct; * institutional failure. The current architectural relationship is: ```text ANOMALY -> REVIEW CONTEXT -> HUMAN INTERPRETATION ``` not: ```text ANOMALY -> AUTOMATIC VERDICT ``` Public demonstrations containing anomaly-related capabilities must be interpreted according to this boundary. --- # Historical and Legacy Runtime Evidence The broader public repository also contains historical runtime evidence from earlier stages of LEO development. Earlier implementation stages included concepts and components associated with: * investigation pipelines; * risk escalation; * institutional alerts; * case handling; * automatic case triggers; * related legacy runtime mechanisms. These historical components are preserved as engineering provenance and institutional memory. Their existence does not establish that autonomous escalation or enforcement is part of the current governing LEO architecture. The governing distinction is: ```text LEGACY / HISTORICAL RUNTIME EVIDENCE != CURRENT PUBLIC ARCHITECTURAL AUTHORITY ``` Historical evidence should remain reviewable rather than being silently deleted or rewritten when architecture evolves. --- # Runtime Evidence and Production Readiness A completed or frozen demonstration runtime is evidence within its defined scope. It is not automatic evidence of complete-system production readiness. The following distinctions apply: ```text DEMONSTRATED != COMPLETE SYSTEM IMPLEMENTATION ``` ```text TESTED WITHIN DEFINED SCOPE != CURRENT GLOBAL TEST STATUS ``` ```text RUNTIME COMPLETE != PRODUCTION AUTHORIZED ``` ```text PUBLICLY EVALUABLE != AUTONOMOUS AUTHORITY ``` Production deployment requires separate explicit authorization under the applicable technical, institutional, security, legal, operational, and governance controls. --- # Regulatory Boundary The public demonstrations may operate in domains where European, Polish, institutional, accounting, data-governance, or other legal and regulatory requirements are relevant. However, the existence of: * human-review controls; * evidence lineage; * provenance; * traceability; * reviewer interfaces; * anomaly analysis; * controlled runtime behavior; does not independently establish regulatory compliance. Accordingly: ```text REGULATORY AWARENESS != VERIFIED REGULATORY COMPLIANCE ``` No demonstration in this catalog should be interpreted as independently proving GDPR, EU AI Act, or other regulatory compliance without separate appropriate review and supporting evidence. --- # Licensing Boundary The public demonstrations and their repositories may contain licensing-related artifacts, dependencies, or historical licensing statements. This catalog does not independently determine their final licensing or intellectual-property status. A dedicated: ```text LICENSE / IP / THIRD-PARTY LICENSING CONSISTENCY REVIEW ``` remains a separate publication-readiness gate. That review is intentionally not performed by this catalog. Historical licensing evidence should be preserved until the dedicated review determines the appropriate current interpretation. --- # Portfolio Status ## Institutional Approval Review ```text AVAILABLE ``` ## Procurement / Accounting Review ```text AVAILABLE ``` ## Grant Expense Review ```text AVAILABLE ``` Availability means that the demonstration is represented in the current public portfolio. It does not independently mean: * production authorization; * complete-system implementation; * regulatory certification; * autonomous institutional authority. --- # Evaluation Guidance An evaluator reviewing a public LEO demonstration should ask: 1. What exact workflow is being demonstrated? 2. What input evidence is used? 3. What provenance is preserved? 4. What output is generated? 5. Which output is evidence, interpretation, signal, proposal, or reviewer-support information? 6. Where does human review occur? 7. Which actions remain outside system authority? 8. What test or runtime evidence supports the demonstrated capability? 9. Is the artifact current, scoped, frozen, or historical? 10. Does the public claim remain within the evidence actually demonstrated? These questions help distinguish reproducible technical evidence from unsupported assumptions about broader system authority. --- # Public Documentation Alignment This catalog is being aligned as part of the current LEO public repository documentation sequence. The controlled sequence is: ```text PROJECT_STATUS.md -> README.md -> PUBLIC_DEMO_CATALOG.md -> index.html -> CROSS-DOCUMENT ARCHITECTURAL CONTINUITY / CONSISTENCY REVIEW -> LICENSE / IP / THIRD-PARTY LICENSING CONSISTENCY REVIEW -> FINAL PUBLICATION-READINESS REVIEW -> EXPLICIT HUMAN APPROVAL -> PUBLIC REPOSITORY UPDATE -> FRESH-CLONE / POST-PUSH VERIFICATION ``` Completion of this catalog alignment does not authorize skipping any later gate. --- # Current Catalog Decision The three existing public demonstration tracks remain part of the LEO public evaluation portfolio: ```text INSTITUTIONAL APPROVAL REVIEW PROCUREMENT / ACCOUNTING REVIEW GRANT EXPENSE REVIEW ``` No demonstration is removed by this alignment. Their existing runtime evidence remains relevant within its documented scope. The catalog now distinguishes their demonstrated capabilities from the broader current LEO architecture and makes the shared human-governance boundaries explicit. --- # Status Declaration ```text PUBLIC_DEMO_CATALOG STATUS: PUBLIC_EVALUATION_PREPARATION PUBLIC_DEMOS: 3 HUMAN_REVIEW_REQUIRED: YES AUTONOMOUS_ENFORCEMENT: NO AUTHORITATIVE_FRAUD_VERDICTS: NO AUTHORITATIVE_LEGAL_VERDICTS: NO PRODUCTION_MUTATION_AUTHORIZED: NO GLOBAL_TEST_COUNT_ASSERTED: NO REGULATORY_COMPLIANCE_ASSERTED: NO LICENSE_IP_REVIEW: PENDING_DEDICATED_REVIEW NEXT_DOCUMENTATION_TARGET: index.html ``` --- # Next Controlled Step After this catalog replacement has been reviewed, saved, and verified, the next public-documentation alignment target is: ```text index.html ``` No modification of `index.html`, licensing artifacts, demonstration runtimes, historical evidence, or other repository files is authorized by this catalog. Each subsequent change remains subject to controlled review and explicit human approval.