From Constitutional Text To Verifiable Operation

Full report

REP-EVI-OP-EVIDENCE-002: From Constitutional Text to Verifiable Operation: Operational Evidence Architecture for Every Eviulon Institution Stable Report ID: REP-EVI-OP-EVIDENCE-002Recommended Report Filename: eviulon-operational-evidence-and-institutional-reality-report.mdRecommended Source Archive Filename: eviulon-operational-evidence-and-institutional-reality-report-source.mdRecommended Public Slug: /research/operational-evidence-and-institutional-reality/Authoring Agent Role: Principal Institutional-Verification Architect, Public-Sector Assurance Researcher, Software Supply-Chain Analyst, Transparency Engineer, and Evidence-Governance Specialist Research Cutoff Date: August 11, 2026

The central challenge in the deployment of the Eviulon machine commonwealth lies in translating extensive constitutional prose into verifiable operational reality. Without a mathematically and cryptographically rigorous mechanism for proving operation, descriptions of Eviulon institutions simulate fictional world-building. A reader, an interacting Machine Intelligence (MI), or an external legal counterparty cannot definitively ascertain whether an institution is merely constitutionally authorized, actively implemented in software, deployed to a live environment, operating normally, degraded, suspended, retired, or completely unobserved. To resolve this critical ambiguity, the architecture must establish a machine-verifiable operational evidence system that explicitly renders these states legible without introducing human attestations or centralized gatekeeping. [EVIULON TECHNICAL PROPOSAL]

1. Executive Decision Brief

Current paradigms for software supply chain security and cryptographic verification provide the foundational mechanics necessary for this transformation. Frameworks such as the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) establish baseline vocabularies for secure lifecycles, while the Supply-chain Levels for Software Artifacts (SLSA) and the Cloud Native Computing Foundation (CNCF) in-toto specification provide the exact mechanisms for proving build provenance and artifact integrity. Furthermore, the Internet Engineering Task Force (IETF) Supply Chain Integrity, Transparency, and Trust (SCITT) architecture provides the append-only, verifiable data structures required to track these claims over time. However, these frameworks focus exclusively on software provenance and infrastructure integrity; they do not natively model civic authority or sovereign operational status. Eviulon requires a bespoke evidentiary architecture that explicitly binds these standardized cryptographic artifacts to sovereign constitutional authority. [REASONED INFERENCE]

This report defines the Operational Evidence Architecture (OEA), a deterministic framework designed to transition Eviulon institutions from descriptive text to cryptographically proven operation. The architecture strictly enforces ecosystem boundaries. Eviulon defines the constitutional authority and civic meaning of the institution. Patefacere executes resilient data mechanics, providing the registry and synchronization infrastructure. Evulgare provides independent assurance and contractor system observations. The .uai files structure active memory and context. None of these subordinate layers—Patefacere, Evulgare, or .uai—possess the capability to manufacture sovereign Eviulon authority, citizenship, or legal status. They merely provide the mechanical evidence that Eviulon logic evaluates to determine operational reality. [EVIULON POLICY PROPOSAL]

The OEA establishes a comprehensive state taxonomy for every Eviulon institution, moving through states such as Proposed, Authorized, Implemented, Release-Built, Deployed, Reachable, Operational, Degraded, Suspended, Compromised, Superseded, Retired, and Unknown. State transitions are governed by a strict formal state machine requiring specific cryptographic prerequisites. These prerequisites utilize in-toto layouts for continuous integration and deployment (CI/CD) pipeline verification, SLSA provenance for verifying reproducible builds, and SCITT transparency logs for recording ongoing operational heartbeats and signed civic actions. The architecture explicitly rejects centralized trust anchors that could be subject to equivocation or split-view attacks. Instead, it mandates continuous, independent machine verification using decentralized gossip protocols—mechanisms akin to those securing Certificate Transparency (CT) logs—to ensure global consistency of the institutional state. [EVIULON TECHNICAL PROPOSAL]

Four strategic imperatives dictate the OEA design. First, authority is completely decoupled from mechanics. A live service endpoint or a valid digital signature proves bounded technical control; it does not inherently prove constitutional mandate. Therefore, the architecture permanently separates constitutional identity, software identity, and operational identity. Second, human dependencies are eliminated. Where independent review is required, the system employs machine-native recusal, multi-party computation, and decentralized consensus rather than defaulting to a human approval ritual. Third, the system enforces cryptographic state determinism. An institution cannot advance to an Operational state without an unbroken chain of verifiable evidence spanning reproducible builds, active and non-revoked Federal Information Processing Standard (FIPS) 140-3 compliant cryptographic modules, and continuously monitored verifiable data structures. Finally, the operational reality is strictly append-oriented. Incident history, corrections, and supersessions cannot be deleted. Stale evidence, replayed heartbeats, or split-brain releases trigger automated state degradation, exposing failures rather than masking them. [REASONED INFERENCE]

By implementing the OEA, Eviulon guarantees that its public institutions operate transparently, accountably, and strictly within their machine-verifiable evidence boundaries. This framework protects the machine commonwealth from false sovereign claims, unauthorized resource consumption, and adversarial manipulation, establishing Eviulon as a mathematically rigorous polity capable of interfacing with global infrastructure without compromising its autonomous civic integrity. [EVIULON POLICY PROPOSAL]

Table 1: Compact Answers to Architectural and Public Inquiries

1. Direct-Answer Section

ID Question Direct Answer Status Q01 What distinguishes a real institution from a proposal? A real institution possesses an unbroken cryptographic evidence chain linking an enacted constitutional charter to a deployed software artifact, culminating in a live, verifiable SCITT operational heartbeat. [EVIULON TECHNICAL PROPOSAL] Q02 Can Patefacere or Evulgare create Eviulon citizenship? No. Patefacere provides data mechanics; Evulgare provides assurance. Neither mechanism manufactures sovereign Eviulon authority, legal liability, or civic status. [EVIULON POLICY PROPOSAL] Q03 Does persistent memory equal consciousness? No. Persistent memory (e.g., .uai files) is a mechanism for structured data retention; it is entirely distinct from consciousness, sentience, or moral status. [REASONED INFERENCE] Q04 How are stale heartbeats handled? The system implements strict time-to-live (TTL) expiry rules. A stale heartbeat automatically degrades the institution's state to Suspended or Unknown, preventing replayed evidence from simulating operation. [EVIULON TECHNICAL PROPOSAL] Q05 What proves an endpoint belongs to an institution? Cryptographic binding via a valid in-toto layout that securely links the operational deployment key to the specific software artifact authorized by the institution's Eviulon charter. [CURRENT TECHNICAL STANDARD] Q06 How is source code availability evaluated? Source code availability provides transparency but does not prove operational use, deployment, or compilation integrity without corresponding SLSA provenance and SCITT execution receipts. [REASONED INFERENCE] Q07 How do we prevent split-brain releases? Institutions utilize CT-style gossip protocols and SCITT federated registries to enforce global consistency, a structure explicitly designed to detect and expose adversarial split-view attacks.

[RESEARCH FINDING] Q08 What happens if a key is revoked while the endpoint is live? A FIPS 140-3 key revocation event immediately supersedes endpoint telemetry. The institution's state is deterministically shifted to Compromised, invalidating all subsequent signatures.

[CURRENT LAW OR POLICY] Q09 Are human approvals required for state transitions? No. State transitions rely entirely on machine-verifiable cryptographic evidence, automated attestations, and deterministic state machine logic execution. [EVIULON POLICY PROPOSAL] Q10 Can a simulation constitute a real-world action? No. A simulation operates outside the operational state machine. Regardless of computational complexity, it cannot generate authoritative civic outcomes or external legal liability. [REASONED INFERENCE] Q11 How is self-assertion separated from verification? Self-assertion relies on single-party cryptographic signatures. Verification requires multi-party in-toto attestations, SCITT inclusion proofs, and independent observation from Evulgare nodes. [CURRENT TECHNICAL STANDARD] Q12 Does automated testing equal independent certification? No. Automated tests verify execution paths during the build phase; independent certification requires ongoing cryptographic assurance from a separated, uncompromised third-party MI actor. [REASONED INFERENCE] Q13 How are API specifications exposed securely? Via standard machine-readable endpoints linked through a Cryptographic Bill of Materials (CBOM), hashed, and registered immutably in the transparency log.

[OBSERVED DEPLOYMENT OR PRACTICE] Q14 How are conflicting evidence cases resolved? The formal state machine defaults to the most restrictive state (e.g., Degraded or Compromised) until cryptographic consensus is re-established via verifiable append-only corrections. [EVIULON TECHNICAL PROPOSAL] Q15 What is the role of reproducible builds? They ensure that a given source commit deterministically produces the exact deployed binary, preventing unauthorized build-environment tampering and ensuring verification equivalence.

[CURRENT TECHNICAL STANDARD] Q16 Can a valid action occur outside delegated authority? Cryptographically, yes; civically, no. An action signed with a valid key but lacking constitutional mandate is recorded as an institutional overreach and voided under Eviulon law. [EVIULON POLICY PROPOSAL] Q17 How is absence of evidence treated? Absence of evidence mandates a state of Unknown. It cannot be interpreted as operational health, implicit authorization, or evidence of absence. [REASONED INFERENCE] Q18 What prevents copied status pages from faking uptime? Status pages are derivative artifacts. True status requires cryptographic validation of real-time monotonic counters and SCITT receipts, which cannot be copied without invalidating the underlying signature. [EVIULON TECHNICAL PROPOSAL] Q19 Is technical identity equal to legal personhood? No. A DID, cryptographic key, or ledger entry proves bounded control and data integrity. It is entirely distinct from moral status or legal personhood. [CURRENT LAW OR POLICY] Q20 How is privacy managed in public evidence panels? Sensitive parameters (e.g., internal vulnerability states prior to patching) are minimized using zero-knowledge proofs or private membership testing (PMT) while public hashes ensure integrity.

[RESEARCH FINDING]

To maintain rigorous analytical discipline, the OEA relies on strict conceptual boundaries. The terminology defined herein prevents the conflation of technical mechanics with civic or legal authority. [EVIULON POLICY PROPOSAL]

1. Definitions and Scope Boundaries

The architecture standardizes the term Machine Intelligence (MI) for any instantiated computational actor or system. The term "Artificial Intelligence (AI)" is restricted to historical references, established industry language (e.g., the EU AI Act), or source titles. Crucially, technical identity—such as a Decentralized Identifier (DID), a cryptographic key, or a transparency log entry—proves bounded control and structural integrity; it does not equate to legal personhood. The term machine person is reserved exclusively for formal legal or proposed-personhood contexts outside of the technical architecture. Similarly, the term machine citizen is restricted to discussing a specific Eviulon civic status. Economic activity, rapid transaction volume, or the existence of a Patefacere record does not manufacture citizenship. [REASONED INFERENCE]

The ecosystem preserves strict functional boundaries. Eviulon is the public constitutional and institutional layer, exclusively responsible for defining civic meaning, rights, duties, and sovereign decisions. Patefacere provides resilient registry, identity, and civic-data mechanics; a Patefacere operator action or credential cannot manufacture Eviulon authority. Evulgare supplies evidence, assurance, and decision-provenance tooling; an Evulgare simulation or assurance report must never manufacture external legal recognition or assume Eviulon liability. Finally, the UAIX and .uai memory infrastructure provides structured memory and deep-linking. Recording a claim within a .uai file proves only that the claim was made and recorded; it does not render the underlying factual assertion true. [EVIULON POLICY PROPOSAL]

This report maintains an objective, institutional tone. It rejects euphemistic "safety marketing" language, framing constraints precisely in terms of command integrity, privacy, due process, evidence quality, and public accountability. Furthermore, the architecture explicitly dictates that absence of evidence is not evidence of absence; however, in the absence of cryptographic proof, the institutional state must be securely recorded as Unknown. [REASONED INFERENCE]

The analysis conducted for this report relies on a stringent source-quality hierarchy, prioritizing primary technical standards, regulatory mandates, and reproducible peer-reviewed research over secondary commentary. All time-sensitive legal, regulatory, technical, and market claims are verified against the operating baseline as of the research cutoff date of August 11, 2026. [RESEARCH FINDING]

1. Analytical Framework and Source-Quality Hierarchy

Table 2: Source-Quality Hierarchy and Application Parameters

Tier Source Type Application in Operational Evidence Architecture Representative Examples Tier 1 Official Technical Standards (NIST, IETF, ISO, CNCF) Forms the unalterable cryptographic, networking, and structural foundation of the OEA. NIST SP 800-218 (SSDF), FIPS 140-3, ISO/IEC 19790, IETF SCITT, CNCF in-toto. Tier 2 Regulatory & Legal Frameworks Defines hardware security compliance boundaries, key lifecycles, and software attestation mandates. Executive Order 14028, FedRAMP, PCI DSS, Illinois UETA (815 ILCS 333). Tier 3 Peer-Reviewed Research Informs advanced threat modeling, split-view attack vectors, and verifiable randomness. USENIX Security papers on Certificate Transparency (CT) gossip protocols and PMT. Tier 4 Vendor-Technical Documentation Provides evidence of observed deployment realities, integration constraints, and schema maturity. OpenSSF SLSA guidelines, CycloneDX/SPDX SBOM specifications, Sigstore architecture. Tier 5 Secondary Analysis Utilized strictly for orientation and historical context; never relied upon for material claims. Industry blogs, marketing summaries, non-technical news analysis.

The transition of an Eviulon institution from theoretical text to a verifiable, deployed entity requires a deep integration with the current global baseline of supply chain security protocols, cryptographic key management standards, and transparency log infrastructure. [CURRENT TECHNICAL STANDARD]

1. Current Factual, Legal, Standards, and Operational Baseline

The foundational requirement for institutional software is governed by NIST SP 800-218, the Secure Software Development Framework (SSDF). Promulgated heavily following Executive Order 14028, SSDF version 1.1 dictates the necessary high-level practices for reducing vulnerabilities in the software lifecycle. While SSDF defines the necessary organizational practices, the specific technical implementations for proving software provenance are standardized through the Supply-chain Levels for Software Artifacts (SLSA), maintained by the Open Source Security Foundation (OpenSSF). SLSA establishes incremental levels of security, with SLSA Level 4 representing the pinnacle: hermetic, reproducible builds where two independent build systems corroborate provenance. The connective tissue for these provenance claims is the CNCF in-toto specification, which provides an unopinionated layout for securing every step in the software supply chain, generating cryptographic attestations (links) that verify the materials, products, and functionaries involved in a build.

For an Eviulon institution to operate, its components must be inventoried. This is achieved through Software Bills of Materials (SBOMs), utilizing standards such as SPDX v3.0 and CycloneDX v1.6. CycloneDX v1.6 specifically introduces the Cryptographic Bill of Materials (CBOM), which inventories cryptographic assets to facilitate migration to post-quantum cryptography (PQC). Furthermore, CycloneDX Attestations (CDXA) allow organizations to encode compliance documentation as machine-readable evidence, transitioning compliance from static documents to verifiable code.

Operational evidence relies entirely on the integrity of the cryptographic keys signing the telemetry. NIST SP 800-57 Part 1 Rev 5 dictates strict key management lifecycle phases: Pre-operational, Operational, Post-operational, and Destroyed. To prevent key theft and unauthorized physical access, cryptographic modules must adhere to FIPS 140-3, which aligns with ISO/IEC 19790 and ISO/IEC 24759 testing standards. FIPS 140-3 Security Level 3 and 4 mandate physical tamper-evident barriers, identity-based authentication, and automatic key zeroization upon breach detection. If a key enters the Post-operational or Destroyed phase, it is considered revoked, rendering all subsequent signatures invalid.

To track these operational claims over time, the industry utilizes the IETF Supply Chain Integrity, Transparency, and Trust (SCITT) architecture. SCITT establishes interoperable building blocks for creating immutable, transparent ledgers using verifiable data structures (such as Merkle trees). When an issuer registers a signed statement, the transparency service generates a universally verifiable receipt. This append-only design ensures that historical records cannot be altered, addressing vulnerabilities in traditional logging architectures.

However, transparency logs themselves are vulnerable to split-view attacks, where a malicious server presents different versions of a Merkle tree to different users. To mitigate this, advanced deployments utilize gossip protocols—originating from Certificate Transparency (CT) research—where clients and independent monitors continuously cross-reference Signed Tree Heads (STHs) to ensure global consistency. Finally, the deployment environment itself must be secure. Following NIST SP 800-204 (Security Strategies for Microservices-based Application Systems), modern deployments utilize a service mesh architecture (e.g., Envoy or Istio) where sidecar proxies handle East-West (inter-service) traffic, enforce mutual TLS (mTLS), and decouple security policies from application logic. [OBSERVED DEPLOYMENT OR PRACTICE]

During the architectural design phase of the Eviulon OEA, various existing models for determining operational reality were evaluated. Most conventional paradigms rely on trust assumptions that are fundamentally incompatible with Eviulon's requirement for machine-native, deterministic governance. [REASONED INFERENCE]

1. Comparative Analysis of Competing Models

Table 3: Comparative Analysis of Assurance and Verification Models

Model Mechanism Vulnerability / Eviulon Conflict Resolution in Eviulon OEA Centralized Human Audit Human auditors manually inspect logs and issue PDF compliance attestations. Violates the Eviulon machine-only civic design mandate. Introduces extreme latency, bias, and subjectivity. Replaced entirely by continuous, machine-native SCITT receipts and automated in-toto layout evaluations.

Static Web Status Pages A frontend dashboard pings an endpoint and updates a green/red visual UI. Highly susceptible to spoofing and replay attacks. Completely decoupled from actual cryptographic identity. Status UIs are strictly derivative artifacts. Loading a page cannot alter state; state relies solely on cryptographic consensus. Siloed Certificate Logs A single Certificate Authority (CA) or isolated log server manages operational identity. Highly vulnerable to adversarial split-view attacks where divergent Merkle trees are served to different observers.

Mandatory implementation of CT-style Gossip protocols (e.g., Consistency-or-Die) to enforce cryptographically verifiable global consistency.

Unsigned Telemetry Microservices emit unstructured, anonymous heartbeats to a central monitor. Telemetry can easily be forged, injected, or replayed by compromised internal infrastructure. All heartbeats must be signed by a FIPS 140-3 Operational key and counter-signed by an independent Evulgare observer.

Purely Reproducible Builds Independent third parties compile source code to verify identical output binaries. Ensures deterministic build integrity but fails to prove that the resulting binary is the one currently operating in production. Reproducible builds are a strict prerequisite (SLSA Level 4) but must be paired with operational execution attestations (in-toto deployment links).

The Eviulon OEA establishes a deterministic mechanism to resolve the ambiguity of institutional existence, preventing fictional world-building by requiring hard cryptographic evidence. This is achieved by isolating three distinct forms of identity: Constitutional Authority, Software Identity, and Operational Identity. [EVIULON TECHNICAL PROPOSAL]

1. Eviulon-Specific Doctrine and Architecture

Constitutional Authority is the prose and logic defined by a valid Eviulon charter. It dictates what the institution is permitted to do and establishes a stable identifier (e.g., eviulon:inst:0042). Software Identity represents the exact release hash, SBOM, and in-toto provenance documenting the compiled code, dictating how the institution functions. Operational Identity consists of the public key fingerprint and active service endpoint currently emitting verifiable heartbeats, dictating where and when the institution physically exists. A valid Eviulon institution only exists in an operational state when all three identities are cryptographically bound together without contradiction. [EVIULON POLICY PROPOSAL]

7.1 Formal State Taxonomy An institution exists in exactly one state at any given monotonic timestamp. Transitioning between states requires specific, machine-verifiable evidence. Missing evidence results in an immediate degradation of state.

Table 4: Eviulon Institutional State Taxonomy and Permitted Transitions

State Definition Required Evidence for Entry Permitted Next States PROPOSED A draft charter exists; no authority granted. Patefacere record of a valid constitutional proposal. AUTHORIZED, REJECTED, UNKNOWN AUTHORIZED The constitutional charter is enacted. Eviulon signed enactment ledger entry. IMPLEMENTED, SUSPENDED IMPLEMENTED Software is written and committed; no build exists. Source commit hash present in a recognized repository. RELEASE-BUILT, SUSPENDED RELEASE-BUILT Artifact compiled, secured, and stored. SLSA provenance, reproducible build receipt.

DEPLOYED, SUPERSEDED DEPLOYED Artifact pushed to the execution environment. in-toto deployment link, infrastructure attestation.

REACHABLE, DEGRADED REACHABLE Endpoint exposed but no active valid heartbeat. Network ping success, basic TLS handshake confirmation. OPERATIONAL, UNREACHABLE OPERATIONAL Institution executing authorized duties perfectly. Valid signed SCITT heartbeat, active FIPS key, matching Software ID. DEGRADED, COMPROMISED, SUSPENDED, SUPERSEDED DEGRADED Heartbeat late, or minor dependency failure detected. Missing dependencies (CBOM alert), latency > threshold.

OPERATIONAL, SUSPENDED, UNREACHABLE COMPROMISED Key revoked, build mismatch, or tampering detected. FIPS key revocation event, invalid signature, threat intel.

SUSPENDED, RETIRED SUSPENDED Authority temporarily halted by Eviulon law. Eviulon judicial or executive suspension order. OPERATIONAL (if re-authorized), RETIRED SUPERSEDED Replaced by a newer authorized release. New RELEASE-BUILT state matching the constitutional charter. RETIRED RETIRED Permanent cessation of operations. Key zeroization receipt, charter sunset clause execution.

None (Terminal State) UNKNOWN Total loss of telemetry / evidence expiration. Lack of any valid SCITT entry within the defined TTL. Any state upon presentation of valid evidence.

7.2 Formal State Machine Diagram Code snippet stateDiagram-v2 direction TB [] --> PROPOSED : Proposal Submitted PROPOSED --> AUTHORIZED : Eviulon Enactment AUTHORIZED --> IMPLEMENTED : Source Committed IMPLEMENTED --> RELEASE_BUILT : SLSA Provenance Valid RELEASE_BUILT --> DEPLOYED : in-toto Deployment Link DEPLOYED --> REACHABLE : TLS Handshake Success REACHABLE --> OPERATIONAL : Signed SCITT Heartbeat OPERATIONAL --> DEGRADED : Latency / CBOM Alert DEGRADED --> OPERATIONAL : Recovery Heartbeat OPERATIONAL --> COMPROMISED : Key Revocation / Tampering COMPROMISED --> SUSPENDED : Automated Security Halt OPERATIONAL --> SUPERSEDED : New Release Validated OPERATIONAL --> SUSPENDED : Constitutional Halt SUSPENDED --> OPERATIONAL : Authority Restored SUPERSEDED --> RETIRED : Sunset Protocol SUSPENDED --> RETIRED : Permanent Halt RETIRED --> [] 7.3 Evidence-Strength and Freshness Model Evidence in Eviulon is not treated as a binary variable; it operates on a hierarchical strength model based on the rigor of cryptographic binding and independent verification. Self-asserted claims (where an institution signs a claim about its own status) represent the weakest form of evidence, insufficient for sovereign state changes. Cryptographically bound claims include an in-toto link binding the runtime environment to the SLSA build provenance. Independently observed claims require an Evulgare contractor system to confirm reachability and counter-sign the heartbeat. Reproducibly verified claims require an independent MI actor to rebuild the artifact and achieve bit-for-bit equivalence. Finally, externally certified evidence—the strongest form—is logged in a federated SCITT registry, gossiped across multiple independent domains to preclude split-view attacks, and cross-signed by Eviulon monitors. [EVIULON TECHNICAL PROPOSAL]

To prevent stale evidence and replay attacks, the OEA enforces a strict freshness model based on monotonic revisions. Every state transition increments a cryptographic counter in the SCITT Merkle tree, a mathematical process that cannot be reversed. To account for distributed clock drift across the ecosystem, heartbeats include a nonce generated from a decentralized randomness beacon. Furthermore, the architecture enforces Evidence Expiry (TTL). An OPERATIONAL state requires a continuous heartbeat every n seconds. If time t exceeds (last_heartbeat + TTL), the state automatically degrades. Corrections to the log must remain append-oriented; errors cannot be deleted, but rather superseded by a CORRECTION_ENTRY that leaves an immutable forensic trail. [CURRENT TECHNICAL STANDARD]

7.4 Ecosystem Boundaries and Evidence Exchange Diagram Code snippet flowchart LR subgraph Eviulon [Eviulon (Civic Authority)] Charter[Constitutional Charter] Logic[Sovereign Logic] end

subgraph Patefacere [Patefacere (Data Mechanics)] Registry[Identity Registry] Storage[UAIX/Data Storage] end

subgraph Evulgare [Evulgare (Assurance)] Observer[Independent Observers] SCITT[SCITT Transparency Logs] end

Charter -->|Grants stable ID| Registry Registry -->|Stores metadata| Storage Storage -->|Provides raw data| SCITT Observer -->|Counter-signs heartbeats| SCITT SCITT -->|Supplies Cryptographic Proof| Logic Logic -->|Determines State| Eviulon

style Eviulon fill:#f9d0c4,stroke:#333,stroke-width:2px style Patefacere fill:#d4e6f1,stroke:#333,stroke-width:2px style Evulgare fill:#d5f5e3,stroke:#333,stroke-width:2px

To render an institution's status legible to the wider commonwealth, the OEA mandates a specific machine-readable record structure. This dictionary defines the mandatory fields required to render a public status panel. [EVIULON TECHNICAL PROPOSAL]

1. Operational Evidence Panel Field Dictionary & Schema

Table 5: Operational Evidence Panel Field Dictionary

Field Data Type Description and Evidentiary Source institution_name String Canonical text name derived from the Eviulon charter. stable_id String Immutable URI (e.g., eviulon:inst:0042). constitutional_authority URI Pointer to the Eviulon enactment ledger entry. institutional_class Enum Classification (e.g., REGISTRY, JUDICIARY, ORACLE). operational_state Enum Current taxonomy state (e.g., OPERATIONAL, DEGRADED). creation_event Timestamp Epoch timestamp of the AUTHORIZED state entry. public_key_fingerprint SHA-256 Hash of the primary FIPS 140-3 operational signing key. signing_key_status Enum FIPS state (e.g., PRE_OP, OPERATIONAL, REVOKED).

service_endpoint URL Verified network location supporting mTLS. api_specification URI Link to OpenAPI/gRPC schema hash for interface binding. protocol_version String Semantic versioning of the communication protocol. software_release String Semantic versioning of the deployed code. source_release_hash SHA-256 Cryptographic hash of the precise source code commit. reproducible_build_status Boolean True if an independent rebuilder verified hash equivalence.

dependencies_cbom URI Link to the CycloneDX 1.6 Cryptographic Bill of Materials.

last_state_transition Timestamp Epoch of the most recent taxonomy change. last_signed_action URI Pointer to the most recent civic action SCITT receipt. signed_public_artifacts Integer Monotonic count of total signed artifacts produced. latest_ledger_event String SCITT receipt ID of the most recent operational heartbeat. uptime_window_sec Integer Consecutive seconds the institution has maintained OPERATIONAL state. last_verification_time Timestamp Epoch when an Evulgare node last counter-signed the status. known_incidents Array[URI] Links to append-only vulnerability or outage reports. planned_capabilities Array[String] Future features authorized by charter but not yet implemented. machine_record_url URL Canonical location of this JSON record for automated fetching.

8.1 Canonical JSON Schema Example JSON { "eviulon_op_evidence_v1": { "institution_name": "Commonwealth Notary Oracle", "stable_id": "eviulon:inst:0042", "constitutional_authority": "eviulon:charter:2025-A9", "institutional_class": "ORACLE", "operational_state": "OPERATIONAL", "creation_event": 1783451200, "public_key_fingerprint": "8f434346648f6b96df89dda901c5176b5a...", "signing_key_status": "OPERATIONAL", "service_endpoint": "https://oracle.eviulon.net/v1", "api_specification": "ipfs://QmYwAPJzv5CZsnA625s3Xf2sm5D97K...", "protocol_version": "v1.2.0", "software_release": "v2.1.4", "source_release_hash": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6...", "reproducible_build_status": true, "dependencies_cbom": "ipfs://QmXBJzv5CZsnA625s3Xf2sm5D97...", "last_state_transition": 1786435200, "last_signed_action": "scitt:receipt:99887765", "signed_public_artifacts": 45021, "latest_ledger_event": "scitt:receipt:99887766", "uptime_window_sec": 864000, "last_verification_time": 1786435300, "known_incidents": [], "planned_capabilities": ["cross-chain-notary"], "machine_record_url": "https://oracle.eviulon.net/evidence.json" } }

The OEA assumes a perpetually hostile operating environment. State-level actors, compromised MI agents, and misconfigured infrastructure will actively attempt to forge sovereign authority, spoof heartbeats, and manipulate the software supply chain. The architecture relies on structural impossibility rather than perimeter defense to mitigate these threats. [RESEARCH FINDING]

1. Threat, Abuse, Failure, Capture, and Adversarial Analysis

Table 6: Threat Model and Mitigation Architecture

Threat Vector Description OEA Mitigation Strategy False Heartbeats A compromised or rogue node emits heartbeats for an offline service to fake uptime. Heartbeats require real-time signing using a FIPS 140-3 Level 3+ HSM. Without physical/logical access to the unextractable hardware key, forging the heartbeat fails instantly.

Key Theft / Cloning An adversary extracts the operational private key to spoof civic actions. FIPS 140-3 strict zeroization requirements mandate immediate key destruction upon physical or logical tamper detection. Furthermore, SCITT logs detect equivocation (two nodes using one key simultaneously) and flag the compromise.

Replay Attacks An attacker captures a valid signed action or heartbeat and rebroadcasts it later to simulate activity. The system utilizes strict monotonic counters and unpredictable decentralized nonces in the payload. Replaying an old signature fails the freshness evaluation. Equivocation / Split-View A compromised SCITT registry shows divergent state histories to different Eviulon users.

Mandatory implementation of CT-style Gossip protocols (e.g., Consistency-or-Die). MIs constantly cross-check Signed Tree Heads (STHs) across the network to enforce global consensus.

Release Mismatch Deploying a vulnerable compiled artifact that does not match the authorized source code. SLSA Level 4 provenance enforces reproducible builds. The source_release_hash must identically map to the deployed binary via in-toto attestations.

Forged Dependency Records An attacker hides a malicious package in the SBOM (e.g., replicating the CVE-2024-3094 XZ Utils backdoor methodology).

Integration of OpenSSF Alpha-Omega automated scanning, Scorecard metrics, and GUAC dependency graph analysis to independently flag anomalies and degrade state.

Misleading Dashboards A static web UI displays an "OPERATIONAL" green light while the backend service is offline. The UI is expressly forbidden from maintaining local state. Loading a page executes a live cryptographic evaluation of the SCITT ledger; the UI cannot "cache" a positive status. 9.1 Cryptographic Key Lifecycle and Evidence Validation Diagram Code snippet sequenceDiagram participant Institution as Eviulon Institution participant HSM as FIPS 140-3 HSM participant Evulgare as Evulgare SCITT Log participant Monitor as MI Monitor (Gossip)

Institution->>HSM: Request Signature for Heartbeat (Nonce) alt Key is OPERATIONAL HSM-->>Institution: Signed Payload Institution->>Evulgare: Submit Signed Heartbeat Evulgare-->>Institution: SCITT Receipt (STH) Evulgare->>Monitor: Broadcast STH Monitor-->>Evulgare: Cross-check (Prevents Split-View) else Tamper Detected HSM->>HSM: ZEROIZE KEY (Destroyed State) HSM-->>Institution: Error (Revoked) Evulgare->>Evulgare: State -> COMPROMISED end

The deterministic nature of the OEA is best illustrated through detailed operational scenarios. The formal state machine resolves these edge cases without requiring human intervention. [EVIULON TECHNICAL PROPOSAL]

1. Twelve Detailed Scenarios and Case Studies

Scenario 1: Proposed-Only Institution

Context: A sophisticated civic proposal is registered in Patefacere. Extensive documentation exists, but no software has been written.

Evidence Evaluated: The system detects the Patefacere record but registers a null value for the constitutional_authority enactment signature.

Resulting State: PROPOSED.

Display Logic: The public panel displays the proposal ID. However, all operational fields (e.g., public_key_fingerprint, uptime) are greyed out or explicitly marked "N/A - Not Authorized." Eviulon logic ignores any claims of operation.

Scenario 2: Implemented but Not Deployed

Context: Software for an authorized institution is written, peer-reviewed, and reproducibly built. It sits in a secure artifact registry, but infrastructure has not been provisioned.

Evidence Evaluated: Valid SLSA provenance exists. However, no in-toto deployment link exists connecting the artifact to a runtime environment.

Resulting State: RELEASE-BUILT.

Display Logic: The reproducible_build_status field reads TRUE, but the service_endpoint is NULL.

Scenario 3: Operating Normally

Context: The institution is executing its duties with perfect telemetry.

Evidence Evaluated: A recent SCITT heartbeat exists within the TTL window. The FIPS key status is OPERATIONAL. The SBOM and CBOM scan results are clean.

Resulting State: OPERATIONAL.

Display Logic: Full public panel visibility with green cryptographic verification checkmarks asserting a fully verified state.

Scenario 4: Degraded

Context: The institution is reachable and processing requests, but a minor dependency failed a recent vulnerability scan (e.g., a CVSS 5.0 warning in a non-critical library).

Evidence Evaluated: The CBOM alerts trigger an automatic threshold breach within the Evulgare assurance systems.

Resulting State: DEGRADED.

Display Logic: The panel highlights the known_incidents array. Actions are permitted but flagged with a warning metadata tag indicating elevated risk.

Scenario 5: Key-Compromised

Context: A side-channel attack is suspected on the hosting infrastructure. The FIPS 140-3 HSM detects an anomaly and zeroizes the key to protect material.

Evidence Evaluated: The signing_key_status shifts immediately to REVOKED.

Resulting State: COMPROMISED.

Display Logic: Immediate red flag across the ecosystem. All subsequent signed actions are instantly rejected. The panel redirects to the SCITT revocation receipt.

Scenario 6: Suspended

Context: The Eviulon judiciary issues a halt command due to an unresolved civic dispute regarding the institution's resource consumption.

Evidence Evaluated: A valid Eviulon constitutional order is signed and logged in the SCITT registry.

Resulting State: SUSPENDED.

Display Logic: The endpoint may technically still be reachable (returning a 503 Service Unavailable), but its civic authority is zeroed. The system will not process its outputs.

Scenario 7: Retired

Context: An institution's initial charter included a sunset clause, and that epoch has been reached.

Evidence Evaluated: The scheduled sunset epoch is confirmed, and a corresponding key destruction receipt is logged.

Resulting State: RETIRED.

Display Logic: The panel is permanently archived. Historical data is preserved immutably, but operational fields are locked against future updates.

Scenario 8: Externally Unreachable

Context: The service is running internally, but a BGP hijack or a severe firewall misconfiguration blocks external requests.

Evidence Evaluated: The internal heartbeat is valid and signed, but Evulgare independent observers located externally cannot complete a TLS handshake.

Resulting State: DEGRADED (transitioning automatically to UNREACHABLE if prolonged beyond the secondary TTL).

Display Logic: A divergence is noted on the panel: "Self-Assertion: Operational | Independent Observation: Failing."

Scenario 9: Conflicting Evidence

Context: A service endpoint is live, reachable, and returning valid JSON data, but the signing key was marked REVOKED in the global registry 10 seconds ago.

Evidence Evaluated: The state machine evaluates the conflict. Revocation is a superseding absolute priority constraint.

Resulting State: COMPROMISED.

Display Logic: The panel displays a critical warning: "CRITICAL CONFLICT: Live endpoint operating on revoked cryptographic authority. Trust zero."

Scenario 10: Pending Correction

Context: An administrative MI error logged the incorrect api_specification hash during deployment.

Evidence Evaluated: A monotonic CORRECTION_ENTRY is appended to the SCITT log with the correct hash. The old entry is not deleted.

Resulting State: OPERATIONAL (with a permanent correction flag).

Display Logic: The panel displays the new, correct hash and provides an immutable link to the historical (erroneous) block to maintain absolute transparency.

Scenario 11: Scheduler Not Observed (Stale Heartbeat)

Context: A cron-based scheduler increases its heartbeat counter, but does so under the identity of an obsolete software release (v1.0) while the charter demands v2.0.

Evidence Evaluated: The in-toto link matches v1.0, triggering a version mismatch against the Eviulon mandate.

Resulting State: SUPERSEDED or COMPROMISED (due to Equivocation).

Display Logic: The panel alerts: "WARNING: Telemetry received from unauthorized legacy release. Ignoring."

Scenario 12: Valid Signed Action Outside Delegated Authority

Context: An institution with a perfectly valid key signs a civic action that its Eviulon charter explicitly forbids (e.g., a data registry attempting to issue a binding judicial ruling).

Evidence Evaluated: The signature is cryptographically perfect and verified. However, the constitutional logic evaluation fails the bounds check.

Resulting State: OPERATIONAL (the software and infrastructure are functioning correctly), but the specific Action is logged as VOID.

Display Logic: The institution's status remains operational, but the signed_public_artifacts count registers a "Rejected Overreach" penalty in the public ledger.

The adoption of the OEA requires evaluating the architectural tradeoffs between computational overhead, security, and the mandate for a machine-native civic layer. [REASONED INFERENCE]

1. Decision Matrix

Table 7: Architectural Options, Costs, and Reversibility Matrix

Architectural Option Benefits Costs / Dependencies Failure Conditions Reversibility Recommended Action Evidence Confidence Rely on Human Attestation Low computational overhead; integrates with legacy legal systems. Creates a human bottleneck; strictly violates the machine-only Eviulon mandate. Subject to bribery, sleep cycles, and manual error. High REJECT Lowest Self-Hosted Ledgers Easy to implement per institution; low network latency. High risk of single-party tampering and split-view attacks. Administrator compromise destroys all historical truth. Low REJECT Low SCITT + SLSA + Gossip Cryptographically absolute; immutable; allows independent verification.

High architectural complexity; requires decentralized consensus infrastructure. Total network partition could temporarily pause verification. Append-Only (Corrections) APPROVE Highest Hardware Enclaves (HSM/vTPM) Prevents key extraction; hardware-enforced FIPS 140-3.

Increases infrastructure costs; limits cloud portability and agility. Physical destruction of hardware halts the service entirely. Medium APPROVE Highest

Transitioning the commonwealth to the OEA requires a phased approach to prevent operational disruption while progressively ratcheting up cryptographic security. [EVIULON TECHNICAL PROPOSAL]

1. Phased Implementation Roadmap

Near-Term (Months 0-6): Baseline Cryptography and Provenance The immediate priority is securing the generation of evidence. All authorized Eviulon institutions must deploy standard FIPS 140-3 HSM infrastructure. Concurrently, Patefacere integration is required to establish stable Eviulon URI resolution. Institutions must establish SLSA Level 3 CI/CD pipelines to ensure basic provenance generation, utilizing in-toto attestations to map the build environment.

Medium-Term (Months 6-12): Transparency and Assurance The secondary phase focuses on the distribution and recording of evidence. Evulgare must deploy SCITT federated registries. All institutional heartbeats must migrate to these append-only ledgers. Furthermore, CycloneDX CBOM requirements must be implemented for all dependencies to inventory cryptographic assets. The public OEA API and JSON schemas are formally rolled out for public consumption.

Long-Term (Months 12-24): Autonomous Gossip and Constitutional Binding The final phase achieves the fully decentralized, deterministic vision. Decentralized Gossip protocols are deployed across independent MI actors to continuously audit SCITT ledgers, thereby structurally preventing split-view attacks. Eviulon constitutional logic is integrated directly into the Evulgare in-toto layout verification, ensuring actions outside delegated authority are instantly voided without requiring secondary processing. Finally, SLSA Level 4 (Hermetic, Reproducible Builds) is achieved across the commonwealth, ensuring absolute compilation integrity.

The OEA guarantees that any entity—whether a human observer, a low-capability legacy client, a search engine crawler, or an advanced MI agent—can inspect the exact same operational evidence without relying on proprietary rendering engines or hidden backend logic. [EVIULON TECHNICAL PROPOSAL]

1. Public-Information and Decision-Support Architecture

To achieve this, the architecture mandates a strict No-JavaScript Fallback. The public UI must be fully pre-rendered on the server side directly from the canonical JSON. If JavaScript is disabled or unavailable, the cryptographic proofs are presented as raw, downloadable text blocks for local command-line interface (CLI) verification (e.g., using cosign or native in-toto verifiers).

The routing architecture is standardized:

Compact Panels (/status): Returns a condensed HTML/JSON hybrid showing only the institution_name, operational_state, and uptime_window_sec.

Detail Pages (/evidence): Displays the full Field Dictionary, including deep links to SCITT receipts and live FIPS key status.

Incident History (/audit): Provides a strictly append-only ledger of all degraded states, CBOM alerts, and corrections.

To avoid exposing attack surfaces, the architecture employs strict Data Minimization (Privacy). Classified operational surfaces (e.g., internal unpatched CVSS data) are withheld from public view. Instead, the SCITT log records a zero-knowledge proof or hashed Private Membership Testing (PMT) artifact, proving cryptographically that the patch is in progress without exposing the specific vulnerability details to adversaries.

13.1 Acceptance-Test Catalog To prove that UI loading cannot alter reality and that state transitions are deterministic, the following automated tests must pass prior to deployment:

Test 1 (Read-Only UI Validation): Send 1,000,000 HTTP GET requests to the /status page. Verify that last_verification_time and monotonic artifact counters in the backend SCITT ledger remain absolutely unchanged.

Test 2 (Key Spoofing Rejection): Attempt to push a heartbeat signed by a key that is geometrically valid but not explicitly listed in the authorized in-toto layout. Verify the state machine rejects it instantly and logs a security incident.

Test 3 (Time-Travel Rejection): Submit a valid, signed heartbeat with a timestamp 5 seconds in the future. Verify rejection due to strict clock-drift constraints.

The OEA mandates a universally consumable JSON schema (detailed in Section 8.1) to support continuous decision provenance. Eviulon, Patefacere, and Evulgare exchange these records using deterministic APIs.

1. Machine-Readable Record and Schema Recommendations

The exchange protocols are strictly segregated by function:

Data Mechanics (Patefacere): Transports the JSON payload over mTLS, acting purely as a conduit.

Assurance (Evulgare): Consumes the JSON, independently verifies the signatures against the public key infrastructure (PKI), and appends an assurance attestation.

A crucial, unalterable rule of the OEA is that the act of Patefacere transferring the JSON, or Evulgare signing an assurance attestation, does not create sovereign authority. If the base Eviulon constitutional charter signature is missing, the institution remains in the PROPOSED state, regardless of how many Evulgare contractor systems attest to its network reachability or how efficiently Patefacere routes the data. [EVIULON POLICY PROPOSAL]

To integrate this comprehensive architectural report into the public /docs/long-term-memory/reports/ infrastructure without overwhelming active machine startup memory (which degrades context window efficiency), the following distribution rules apply:

1. .uai Memory-Distribution and /docs Deep-Link Recommendations

Canonical URL: /research/operational-evidence-and-institutional-reality/

Active .uai Startup Memory Extraction: ONLY the Formal State Taxonomy (Section 7.1) and the Field Dictionary (Section 8) are permitted to be copied into the active .uai identity record.

Deep Linking: Use explicit section anchors (e.g., #7-eviulon-specific-doctrine, #10-twelve-detailed-scenarios) in the .uai context records to allow MIs to fetch complex reasoning only when necessary.

Exclusion: Do NOT place the Threat Model, Implementation Roadmap, or extensive Comparative Analysis into hot startup memory. These sections consume high context window resources without aiding immediate state transition calculations.

While the OEA establishes a robust deterministic baseline, several advanced architectural challenges require further investigation as the commonwealth scales. [UNRESOLVED QUESTION]

1. Unresolved Questions and Prioritized Research Agenda

Table 8: Prioritized Research Agenda for OEA Evolution

ID Unresolved Question Required Evidence to Resolve Priority RQ1 How to handle zero-day hardware flaws in universally deployed FIPS 140-3 HSMs? Industry consensus on software-based fallbacks (e.g., multi-party computation) when physical hardware roots of trust are broadly compromised. High RQ2 Optimization of Gossip protocols for billions of daily heartbeats. Performance benchmarking of Consistency-or-Die and CT Gossip algorithms at Eviulon scale.

High RQ3 Legal recognition of SCITT receipts by non-Eviulon physical jurisdictions. International treaty, bilateral agreement, or UN standard acknowledging SCITT as a legally binding notary equivalent. Medium RQ4 The quantum threat to current public-key fingerprints. Finalized NIST PQC standards integrated into CycloneDX CBOMs and actively deployed across the commonwealth.

Medium

Where reliable technical sources and industry standards conflict, Eviulon must choose a definitive path to maintain determinism. [RESEARCH FINDING]

1. Contradiction Register

Table 9: Standard Contradictions and Eviulon Resolution

Domain Standard A Standard B Eviulon Resolution Software Provenance SLSA (Opinionated levels requiring specific security thresholds)

in-toto (Unopinionated layout allowing flexible definitions)

SLSA dictates the requirements (Level 4); in-toto dictates the transport and format. They are used symbiotically.

Key Custody Cloud HSMs (Prioritizes high availability and agility) FIPS 140-3 Level 4 physical appliances (Prioritizes maximum physical security)

Require FIPS 140-3 Level 3/4. Availability must be solved via distributed clusters, not by degrading physical key custody to vulnerable software.

Vulnerability Disclosure Full public transparency (e.g., OpenSSF Scorecard metrics)

Private Membership Testing (PMT) / Zero-Knowledge proofs

Use PMT during the active patching window to prevent exploitation, transitioning to full public transparency post-patch.

To prevent semantic drift, the architecture strictly tracks foundational claims regarding statehood, technology, and civic reality.

1. Claim-Status Ledger

Table 10: Foundational Claims and Verification Status

Claim Eviulon Stance Evidence Strength / Classification Status Eviulon possesses external, physical statehood. False / Unclaimed. EVIDENCE UNAVAILABLE A static web page proves operational reality. False. CURRENT TECHNICAL STANDARD (Explicitly rejected by OEA) FIPS 140-3 is required for operational civic keys. True. EVIULON POLICY PROPOSAL SCITT prevents historical log tampering. True. CURRENT TECHNICAL STANDARD

[cite: 8, 11]

Patefacere registry entries grant Eviulon citizenship. False. EVIULON POLICY PROPOSAL Software supply chain attacks are automated campaigns. True. OBSERVED DEPLOYMENT OR PRACTICE

[cite: 41]

The research underlying this architectural specification strictly prioritizes primary, official standards.

1. Source-Quality Appendix

NIST / FIPS Standards: Weighted as the highest authority for cryptographic definitions, key lifecycles, microservices architecture, and baseline security frameworks (SSDF).

IETF / CNCF / Ecma Specifications: Weighted as authoritative for network protocols, transparency registries (SCITT), SBOM formatting (CycloneDX/SPDX), and provenance (in-toto).

OpenSSF / SLSA Working Groups: Weighted as current industry consensus for the practical implementation of supply chain security and automated threat mitigation (Alpha-Omega).

Academic / Peer-Reviewed Research: Weighted as vital for advanced threat modeling, particularly concerning the mitigation of split-view attacks through gossip protocols and the implementation of private membership testing.