Chapter 1

The engineering record does not describe a single application. It describes an evolving workspace in which governance, execution, evidence, domain operations, public presentation, and later evidence reconstruction were separated into distinct technical surfaces.

The most important repository fact is not the number of directories. It is the emergence of boundaries between authority, execution, evidence, operations, and presentation.

1.1 Documentary Basis

This chapter is based on repository inventories, technical reports, commit summaries, workspace maps, and later evidence-engineering records. The strongest dated workspace snapshot presently available was generated from local repository files on 4 June 2026. Later records show continued development, including repository stabilization, replay expansion, evidence verification, runtime interfaces, and the isolation of a dedicated evidence repository.

1.2 The Workspace as an Ecosystem

By early June, the workspace had moved beyond a loose collection of pages and experiments. It contained a shared governance core, an execution-proof stack, domain-specific operational applications, public and operator-facing interfaces, infrastructure components, and technical documentation.

1.3 Repository Topology

PUBLIC / OPERATOR SURFACES
        |
        |-- app/
        |     |-- landing and doctrine routes
        |     |-- authority and proof surfaces
        |     |-- trace viewer
        |     |-- runtime console
        |     |-- client and technical reports
        |
        v
GOVERNANCE AND EXECUTION CONTROL
        |
        |-- governance-core/
        |     |-- contracts
        |     |-- runtime validation
        |     |-- cryptographic verification
        |     |-- authoritative ledger
        |     |-- replay and projection rebuild
        |
        |-- execution-proof-stack/
        |     |-- admissibility
        |     |-- boundary enforcement
        |     |-- constitutional verdict
        |     |-- failure constitution
        |     |-- evidence ledger
        |
        v
DOMAIN OPERATIONS
        |
        |-- carshunter_app/
        |     |-- governed transitions
        |     |-- transaction services
        |     |-- authority and freeze controls
        |     |-- evidence and replay lineage
        |
        |-- operations-core/
        |     |-- lead registry
        |     |-- social automation
        |
        v
INFRASTRUCTURE AND DELIVERY
        |
        |-- gateway/
        |-- docker-compose.yml
        |-- deployment and authority maps
        |-- Vercel / API / database environments

LATER EVIDENCE RECONSTRUCTION
        |
        |-- PMS_EVIDENCE_V4/
              |-- chronology
              |-- repository scanners
              |-- evidence database
              |-- knowledge graph and ontology
              |-- governance reasoning
              |-- query language
              |-- decision receipts
              |-- verification
              |-- governed replay

1.4 Boundary One — Presentation Versus Authority

The application layer exposed the architecture to users and stakeholders through landing pages, doctrine pages, authority pages, proof demonstrations, trace viewers, and runtime consoles. These surfaces explained or visualized governance, but they were not intended to become the source of authority themselves.

This distinction matters because a visually convincing interface can simulate governance without enforcing it. The repository therefore placed authority, validation, ledger behavior, and replay logic in separate backend and runtime components.

1.5 Boundary Two — Governance Versus Domain Operations

The operational applications were not designed to redefine governance independently. CARSHUNTER, lead intake, and automation components were intended to operate beneath shared authority and evidence controls.

1.6 Boundary Three — Decision Versus Evidence

A recurring architectural movement was the separation of the operational decision from the evidence proving that the decision was admissible, authorized, and historically reconstructable.

This separation became visible through authoritative ledgers, evidence ledgers, receipt structures, hash continuity, projection rebuilding, replay engines, and later independent receipt verification.

1.7 Boundary Four — Governance Runtime Versus Evidence Archive

A later architectural boundary emerged when the evidence system itself was isolated into a standalone repository. The dedicated evidence repository did not merely execute governance decisions. It reconstructed chronology, ingested repository history, normalized concepts, built evidence databases, generated knowledge graphs, verified receipts, and replayed historical records.

1.8 Boundary Five — Shared Governance Versus Multi-Entity Surfaces

The workspace technical report mapped several domains and business surfaces to different operational roles: automotive, tourism, corporate services, governance documentation, runtime demonstrations, document automation, and related support systems.

The architectural purpose of the shared governance layer was to prevent every domain from rebuilding authority, evidence, and execution logic independently.

1.9 System Boundary Principles

1.10 Repository Risks Identified by the Evidence

The same records that demonstrate architectural maturity also expose engineering risks. The workspace contained simulation-heavy presentation surfaces, local-backend dependencies, historical repository sprawl, generated files, runtime artifacts, and unrelated parent-directory content. These conditions created risks of drift, accidental commits, and confusion between documentary proof and live enforcement.

Repository cleanup, archive creation, Git hygiene, technical mapping, and later standalone evidence isolation were therefore not cosmetic tasks. They were governance controls applied to the engineering environment itself.

1.11 Documentary Conclusions

1. The CEI workspace evolved as a multi-repository and multi-surface ecosystem rather than a single application.
2. The most important technical boundaries separated presentation, authority, execution, evidence, and domain operations.
3. By June 2026, the repository contained concrete runtime, replay, ledger, proof, and operational components.
4. The later PMS Evidence V4 repository introduced a separate historical and verification layer.
5. Repository hygiene and isolation became part of governance because uncontrolled workspace boundaries threatened evidence quality.

The repository landscape shows the architecture becoming visible in code organization: authority above operations, evidence beside execution, and historical reconstruction outside the live runtime.

1.12 Next Chapter

Chapter 2 examines the earliest governance-engine repository and reconstructs the transition from deterministic rules and lifecycle controls toward a reusable runtime-governance core.