Designing a Public Operational Evidence and Transparency Center for Machine-Governed Institutions

1\. Research-Status Front Matter#

The proliferation of Machine Intelligence within governance structures introduces unprecedented challenges in institutional epistemology. When a digital institution relies heavily on polished constitutional or policy text, public observers face an information asymmetry: they cannot independently verify whether the institution exists merely as prose, is actively executing software, or possesses the cryptographic authority to enact real-world state changes. The resulting ambiguity often manifests as "transparency theater"—governance practices that perform openness without enabling meaningful accountability or technical intelligibility1. This report provides the architectural specification for a public transparency infrastructure designed to bridge Patefacere (the authoritative evidence and operational record layer) and Eviulon (the governance and public institutional layer). The architecture resolves the transparency paradox—wherein excessive, unstructured data disclosure induces cognitive overload and diminishes user autonomy3—by implementing a tiered, cryptographic evidence verification system. Through the integration of standardized software supply-chain attestations, runtime telemetry, and cryptographic ledger proofs, this design ensures that the operational status of a Machine Intelligence is derived strictly from continuous, machine-verifiable artifacts rather than human assertion.

2\. Executive Decision Brief#

To eliminate performative institutional world-building, the Operational Evidence Center must enforce a deterministic relationship between cryptographic reality and public representation. The architecture fundamentally prohibits human intervention in the declaration of operational status. The system relies on continuous verification of underlying primitives. Software provenance must be demonstrated through Supply-chain Levels for Software Artifacts (SLSA) attestations5. Runtime instantiation must be proven via observable endpoint telemetry and Certificate Transparency (CT) logs compliant with IETF RFC 91626. Institutional actions must be anchored by digital signatures utilizing the Dead Simple Signing Envelope (DSSE) format7 and recorded in publicly auditable transparency logs utilizing Signed Entry Timestamps (SET)8. By synthesizing these elements, the Operational Evidence Panel guarantees that an institution's public posture degrades automatically and visibly the moment its underlying cryptographic or infrastructural evidence becomes stale or invalid.

3\. Operational-State Ontology#

The distinction between planned capabilities, deployed software, and executing infrastructure requires a rigorous ontological framework. Institutional state is strictly derived from the continuous evaluation of the formal state machine detailed below.

4\. Evidence Ladder from Prose to Externally Verified Operation#

The epistemic weight of institutional claims must be categorized by the cryptographic and observational strength of the supporting artifacts. The proof-strength ladder defines this hierarchy.

5\. Operational Evidence Panel Field Specification#

The Operational Evidence Panel presents a standardized data dictionary. Every field is mapped to specific data types and retrieval mechanisms to ensure machine-readability and consistency.

6\. Public/Protected/Redacted Classification#

The exposure of operational telemetry introduces inherent security risks, necessitating a rigorous disclosure matrix. The classification model balancing transparency against operational security (OpSec) relies on principles of zero-trust architecture and vulnerability mitigation15.

7\. Evidence Freshness and Expiry#

A static cryptographic hash or a cached successful ping cannot serve as perpetual proof of operation. The architecture enforces strict time-to-live (TTL) boundaries on all evidence. When the verifying service ceases operation, or when an institution stops producing evidence, the status derivation algorithm automatically degrades the public state, preventing stale status presentation17.

The status derivation algorithm runs continuously within Eviulon. The following implementation-neutral pseudocode defines the exact deterministic logic used to evaluate the evidence payload from Patefacere and output the public operational state. function derive\status(evidence\record, current\time): // Level 0 Check if evidence\record.constitutional\_prose is NULL: return "None"

// Level 1 Check if evidence\record.source\commit\_hash is NULL: return "Declared"

// Level 2 Check if verify\slsa\provenance(evidence\record.build\artifact) is FALSE: return "Implemented"

// Level 3 Check if verify\tls\ct\logs(evidence\record.service\_endpoint) is FALSE: return "Deployed"

// Incident and Key Overrides if evidence\record.active\incidents is not EMPTY: return "Degraded"

if check\key\revocation(evidence\record.public\key) is TRUE: return "Suspended"

// Level 4 Check (Freshness constraint) time\since\ping \= current\time \- evidence\record.last\ping\time if time\since\ping \> 5\_MINUTES: return "Unavailable"

// Level 5 Check (Freshness constraint) time\since\action \= current\time \- evidence\record.last\signed\action\time if time\since\action \<= 24\HOURS: if verify\dsse\signature(evidence\record.latest\artifact, evidence\record.public\key): return "Verified" // The exact evidence supporting the term is met

// Fallback if reachable but not actively signing return "Observed"

8\. Key, Release, Build, and Artifact Evidence#

The operational integrity of a Machine Intelligence relies on the robust cryptanalysis of its software supply chain. The architecture integrates multiple industry-standard verification formats to build a comprehensive evidence portfolio. Build provenance relies on the SLSA framework5, which provides incrementally adoptable guidelines for supply chain security. To prevent tampering between source control and artifact generation, Eviulon requires SLSA Level 3 attestations, which mandate ephemeral, isolated build environments and non-forgeable provenance data10. These attestations are formatted using the in-toto specification11 and wrapped within a Dead Simple Signing Envelope (DSSE)7. The critical innovation of DSSE is the Pre-Authentication Encoding (PAE) format, which serializes the payload prior to signing. The PAE structure explicitly binds the payload type and length to the signature, neutralizing type confusion and length extension attacks18. By signing the PAE rather than the raw JSON, the architecture bypasses the fragility of JSON canonicalization. For runtime artifact publication, the system utilizes Sigstore protobuf bundles (application/vnd.dev.sigstore.bundle+json)19. These bundles encapsulate the payload, the signature, the signing certificate, and an offline-verifiable Signed Entry Timestamp (SET) generated by the Rekor transparency log8. The SET provides cryptographic proof that the signature was recorded in an immutable, append-only ledger during the certificate's validity window, serving as an unforgeable anchor of temporal existence.

9\. Incident and Degradation Disclosure#

Transparency reporting must address failures natively. Hiding outages behind cached positive states constitutes transparency theater2. The architecture mandates that any cryptographic validation failure, unresolved telemetry timeout, or critical vulnerability disclosure immediately influences the public status. When Patefacere ingests a failure event, the status derivation algorithm forces a transition to Degraded or Suspended. The known\_incidents array is subsequently updated using a structured incident disclosure model. Proposed Incident Disclosure Model Schema: The disclosure model represents incidents as immutable, append-only JSON objects containing specific diagnostic telemetry.

10\. Machine-Readable Publication Architecture#

To support a diverse ecosystem of consumers, from autonomous AI agents to traditional enterprise compliance monitors, the Operational Evidence Center publishes data across multiple standardized formats. Detailed Route Map:

• GET /.well-known/eviulon/operational-evidence.json – The canonical JSON representation of the panel.
• GET /.well-known/eviulon/operational-evidence.jsonld – Semantic web representation utilizing W3C Verifiable Credentials Data Model 2.0 schemas22.
• GET /llms.txt – A streamlined Markdown file optimized for Large Language Model consumption, detailing context and endpoints without rendering overhead24.
• GET /docs/openapi.yaml – The OpenAPI 3.1 specification for interacting with the institution.
• GET /artifacts/verification-bundle.tar.gz – A downloadable archive conforming to the OCI 1.1 Referrers API manifest19.

Proposed Verification Bundle Manifest: The verification bundle provides all necessary components for a local client to audit the institution offline.

1. manifest.json: An OCI 1.1 compliant index linking the bundle components. 2. attestation.intoto.jsonl: The SLSA provenance data wrapped in DSSE. 3. sbom.cyclonedx.json: The CycloneDX 1.6 software bill of materials, including the Cryptographic Bill of Materials (CBOM) extensions25. 4. signature.sigstore.json: The Sigstore protobuf bundle containing the Rekor SET and offline verification material20. 5. tls\_sct.bin: The binary representation of the RFC 9162 Signed Certificate Timestamps6.

Example JSON-LD Record (Abbreviated):

JSON { "@context": \[ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/security/suites/ed25519-2020/v1" \], "id": "urn:uuid:a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d", "type": \["VerifiableCredential", "OperationalEvidence"\], "issuer": "did:web:patefacere.example.com", "issuanceDate": "2026-08-12T10:48:23Z", "credentialSubject": { "id": "did:web:institution.eviulon.example.com", "institution\name": "Primary Arbitrator Protocol", "operational\state": "Verified", "last\signed\action": "2026-08-12T10:45:00Z", "reproducible\build\status": 3 }, "proof": { "type": "Ed25519Signature2020", "created": "2026-08-12T10:48:23Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:web:patefacere.example.com\#key-1", "proofValue": "z58D..." } }

11\. Human-Facing Information Architecture#

Displaying raw cryptographic data to non-technical users induces the transparency paradox—information overload that diminishes functional understanding3. The Eviulon UI mitigates this through a progressive disclosure model.

1. Heuristic Summary: A highly visible, single-sentence assessment utilizing strict, honest vocabulary to convey current state. 2. Actionable Telemetry: Expandable modules detailing the 30-day uptime window, recent ledger hashes, and incident logs. 3. Cryptographic Proof: Collapsed sections housing the PAE structure, public key fingerprints, and verification bundle download links.

20 Examples of Honest Status Wording:

20 Examples of Prohibited or Misleading Status Wording:

12\. Accessibility and Responsive UI Requirements#

The Operational Evidence Panel must conform to WCAG 2.2 AAA standards to ensure universal interpretability.

• Color and Iconography: Status indicators must never rely solely on color. The UI pairs color with distinct geometry: Verified utilizes a deep blue square; Observed a green circle; Degraded an amber triangle; Unavailable a red octagon.
• Focus Order: The Document Object Model (DOM) must prioritize the institution name, current operational state, and the last verification timestamp. Screen readers must encounter these high-level heuristics before entering the high-density cryptographic proof sections.
• Tables and Expandable Evidence: Cryptographic hashes (e.g., SHA-256 strings) must be contained within div elements utilizing word-break: break-all to prevent layout breaking. A keyboard-accessible (Enter/Space to activate) "Copy to Clipboard" button must accompany every hash.
• Mobile Presentation: Lengthy hashes on narrow viewports must be visually truncated using an ellipsis in the center (e.g., 0x1a2b...3c4d), but the underlying copy function must retain the full un-truncated string to prevent mobile truncation spoofing.

13\. AEO, GEO, SEO, and Low-Capability-Agent Support#

The architecture must support low-capability agents, including simple curl requests, search engine crawlers, and LLM retrieval tools (AEO/GEO optimization). The system achieves this by ensuring that all Eviulon pages degrade gracefully in the absence of JavaScript. A no-JavaScript agent requesting the panel receives a static HTML document containing embedded JSON-LD schema data. Furthermore, the root domain must host an llms.txt file24, which provides a Markdown-formatted, highly structured summary of the institution's operational context, API specifications, and public key material. To support localization without breaking interoperability, the UI translates contextual prose via HTTP Accept-Language headers, but all machine-readable ENUMs (e.g., Verified, Degraded) and JSON keys remain strictly in canonical English.

14\. Security and Privacy Threat Model#

Exposing continuous operational evidence creates unique attack vectors. The architecture mitigates these through the following comprehensive threat model.

15\. Comparative Analysis of Transparency Systems#

The integration of disparate transparency standards is required to construct a holistic operational evidence framework.

16\. Recommended Architecture for Patefacere and Eviulon#

The system implements a strict separation of concerns between the storage of evidence and the presentation of status. Patefacere (Authoritative Evidence Storage): Functions as an immutable, append-only OCI-compliant registry19. It stores base container images, CycloneDX SBOMs, DSSE-wrapped attestations, and raw telemetry logs. Crucially, Patefacere executes no status logic. It is a passive repository of cryptographic truth. Eviulon (Public Institutional Layer): Functions as the active verifier and presentation gateway. Eviulon continuously polls Patefacere, retrieves the raw artifacts, executes the deterministic status derivation algorithm (Section 7), and generates the JSON-LD, OpenAPI, llms.txt, and HTML interfaces. Caching Strategy: Eviulon employs a high-speed caching layer with a strict 5-minute TTL. Public readers can verify that an evidence record originated from Patefacere (and was not manipulated by Eviulon) by downloading the Verification Bundle and executing a local signature check of the DSSE envelope against the institution's public key18.

17\. Minimum Viable Version and High-Assurance Version#

Minimum Viable Version (MVV): The MVV focuses on establishing the basic evidence ladder. It requires SLSA Level 1 provenance, public key registration, basic endpoint reachability pings, and the publication of a flat JSON operational panel. In this version, Eviulon caches status but may rely on simpler HMAC signatures rather than full DSSE PAE wrapping. High-Assurance Version (HAV): The HAV mandates the complete architectural spec. It enforces SLSA Level 3+ attestations, requires OCI 1.1 Referrers API manifests for verification bundles, mandates CT logging for all TLS certificates12, and incorporates zero-knowledge proofs for artifact verification. The HAV completely automates incident disclosure based on SBOM vulnerability scanning15.

18\. Validation Strategy#

To ensure architectural integrity, the system must pass a rigorous acceptance matrix prior to deployment. Test Matrix (60 Acceptance Checks):

19\. Open Questions#

While this architecture resolves significant ambiguities in institutional transparency, several research frontiers remain:

1. How can zero-knowledge proofs (e.g., zk-SNARKs) be integrated into the DSSE payload to prove the deterministic logic of a Machine Intelligence output without revealing proprietary internal model weights? 2. What is the optimal cryptographic mechanism for scaling RFC 9162 CT Merkle consistency proofs28 to generalized institutional ledger events, avoiding the computational overhead of traversing massive, unbalanced trees? 3. How can hardware-bound attestations (e.g., TPM PCR measurements) be reliably federated into the verification bundle without exposing host infrastructure to advanced fingerprinting attacks?

21\. Claim-to-Source Traceability Appendix#

This architecture synthesizes critical advances in software supply chain security and privacy research. The reliance on SLSA for build provenance ensures that software generation is isolated and tamper-evident5. The use of DSSE formatting with Pre-Authentication Encoding (PAE) directly mitigates historical JSON canonicalization flaws18. Sigstore's protocol buffer bundles provide the necessary offline-verifiable Signed Entry Timestamps (SET)8, ensuring temporal anchoring without trusting the Eviulon presentation layer. The requirement for CycloneDX over purely license-focused standards stems from its native support for VEX and Cryptographic Bills of Materials (CBOM), which are critical for automated incident degradation14. Furthermore, the conceptual framework defining the "transparency paradox"—and the necessity of tiered, heuristic UIs to prevent cognitive overload—is deeply grounded in human-computer interaction research regarding autonomy depletion3.

22\. .uai and /docs Integration Appendix#

Patefacere Integration Requirements:

1. Recommended /docs/ location and report ID:

• Location: /docs/architecture/evidence-transparency-center.md
• Report ID: ETC-ARCH-2026-08-003

2. Proposed .uai pointers and 20–40 durable memory statements:

• @uai:patefacere:evidence\derivation\rules
• @uai:eviulon:operational\state\machine
• Durable Memory Statements:
  1. Patefacere stores raw cryptographic evidence; Eviulon calculates public state deterministically.
  2. No institution is "operational" without verifiable actual-host evidence.
  3. Human manual status overrides are strictly prohibited under all circumstances.
  4. State downgrades automatically to Unavailable after 5 minutes of unreachable telemetry.
  5. llms.txt is the primary interface for autonomous agents assessing institution status.
  6. DSSE Pre-Authentication Encoding (PAE) must wrap all in-toto attestations.
  7. Sigstore bundles must contain an offline-verifiable Signed Entry Timestamp (SET).
  8. The Operational Evidence Panel must conform to WCAG 2.2 AAA contrast standards.
  9. Status indicators must pair color with geometric shapes (e.g., Green Circle, Amber Triangle).
  10. Incident disclosures must include a cryptographic impact boolean.
  11. MD5 and SHA-1 hashes are permanently deprecated; SHA-256 is the minimum standard.
  12. OCI 1.1 Referrers API is used to distribute verification bundles.
  13. State transitions are logged in ISO-8601 UTC format exclusively.
  14. W3C StatusListV1 is polled every 60 seconds for key revocation checks.
  15. Merkle consistency proofs (RFC 9162\) validate transparency log append-only properties.
  16. A critical CVE in a CycloneDX SBOM forces a Degraded state transition.
  17. The institution\_name field is public; internal IP topology is redacted.
  18. Uptime is calculated on a 30-day sliding window based on continuous polling.
  19. Eviulon caching layer utilizes a strict 5-minute Time-To-Live (TTL).
  20. Action signatures expire after 24 hours, forcing a transition from Verified to Observed.
  21. A genesis event timestamp must precede all subsequent institutional artifacts.
  22. SLSA Level 3 is the minimum requirement for the High-Assurance Version (HAV).
  23. JSON-LD outputs must utilize the Ed25519Signature2020 proof suite.
  24. All Eviulon pages must degrade gracefully in the absence of JavaScript.
  25. Machine-readable ENUMs remain in canonical English regardless of localization.

3. Proposed operational-evidence schema fields:

• Defined exhaustively in Section 5 (Operational Evidence Panel Field Specification).

4. Proposed public API endpoints:

• GET /api/v1/institution/{id}/status (Returns JSON-LD schema)
• GET /api/v1/institution/{id}/evidence-bundle (Returns OCI standard tarball)
• GET /{id}/llms.txt (Returns Agent-optimized markdown)

5. Proposed protected verification endpoints:

• POST /api/internal/verify-dsse (Patefacere to Eviulon MTLS auth required)
• POST /api/internal/ingest-telemetry (Requires cryptographic proof of origin from authorized monitors)

6. Proposed static fallback artifacts:

• status\_fallback.json (Last known good state, updated every 5 mins via cron, served during database failure).
• degraded\_ui.html (Static, no-JS page indicating catastrophic Eviulon cache/database failure).

7. Required actual-host evidence before any status may be labeled "operational":

• A valid TCP/TLS handshake positively mapped to the institution's active public key fingerprint.
• A Sigstore Signed Entry Timestamp (SET) proving the deployment manifest was logged to an independent transparency log during the certificate's validity window.

8. A list of claims that must remain "planned" until proven:

• "Multi-region failover" (Remains planned until a verifiable action is signed by a distinctly geo-located infrastructure node).
• "Reproducible builds" (Remains planned until SLSA Level 3+ attestations are published and wrapped in DSSE).
• "Automated governance" (Remains planned until a state-transition transaction is autonomously signed and recorded on the public ledger without human initiation).
• "Quantum-resistant cryptography" (Remains planned until ML-DSA signatures are actively observed in the verification bundle).

Works cited#

1. Reviewable Automated Decision-Making: A Framework for Accountable Algorithmic Systems | Request PDF \- ResearchGate, https://www.researchgate.net/publication/349752519\_Reviewable\_Automated\_Decision-Making\_A\_Framework\_for\_Accountable\_Algorithmic\_Systems 2. Full article: Digital intermediaries and transparency reports as strategic communications, https://www.tandfonline.com/doi/full/10.1080/01972243.2025.2453529 3. The Silent Cost of Artificial Intelligence Assistance: A Theory of Autonomy Surrender, the Recovery Mechanism, and the Restorat \- arXiv, https://arxiv.org/pdf/2606.13962 4. The Transparency Paradox in Explainable AI: A Theory of Autonomy Depletion Through Cognitive Load \- ResearchGate, https://www.researchgate.net/publication/399953320\_The\_Transparency\_Paradox\_in\_Explainable\_AI\_A\_Theory\_of\_Autonomy\_Depletion\_Through\_Cognitive\_Load 5. About SLSA, https://slsa.dev/spec/v1.2/about 6. RFC 9162 \- Certificate Transparency Version 2.0 \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9162/ 7. DSSE: Dead Simple Signing Envelope \- GitHub, https://github.com/secure-systems-lab/dsse 8. Cosign: The Manual Way \- Chainguard Academy, https://edu.chainguard.dev/open-source/sigstore/cosign/cosign-manual-way/ 9. RevocationList2021 or RevocationList2021Status · Issue \#11 · w3c/vc-bitstring-status-list, https://github.com/w3c/vc-bitstring-status-list/issues/11 10. GitHub \- Legit-Labs/legit-provenance-generator: Language-agnostic SLSA provenance generation for Github Actions, https://github.com/Legit-Labs/legit-provenance-generator 11. SLSA Provenance Blog Series, Part 1: What Is Software Attestation \- Legit Security, https://www.legitsecurity.com/blog/slsa-provenance-blog-series-part-1-what-is-software-attestation 12. Certificate Transparency \- Wikipedia, https://en.wikipedia.org/wiki/Certificate\_Transparency 13. draft-farley-acta-signed-receipts-02 \- Signed Decision Receipts for Machine-to-Machine Access Control \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-farley-acta-signed-receipts/ 14. CycloneDX vs SPDX: SBOM Formats Compared \- Safeguard, https://safeguard.sh/resources/blog/cyclonedx-vs-spdx-sbom-formats-compared 15. Top Software Supply Chain Security Best Practices for Enterprises | Veracode, https://www.veracode.com/blog/top-software-supply-chain-security-best-practices/ 16. What Is Software Provenance? | Secure Supply Chain Practices \- JFrog, https://jfrog.com/learn/grc/software-provenance/ 17. The Mythos Effect: Preparing for AI-Accelerated Exploitation \- Sygnia, https://www.sygnia.co/threat-reports-and-advisories/mythos-effect-ai-accelerated-exploitation-vulnerability-management/ 18. verify\_signature.py \- redhat-tssc-tmm/trusted-libraries \- GitHub, https://github.com/redhat-tssc-tmm/trusted-libraries/blob/main/blog/scripts/docs/verify\_signature.md 19. Sigstore Bundle as OCI Artifact · Issue \#3577 \- GitHub, https://github.com/sigstore/cosign/issues/3577 20. Sigstore Bundle Format, https://docs.sigstore.dev/about/bundle/ 21. NIST Special Publication 800-53 Revision 5 | PDF \- Slideshare, https://www.slideshare.net/slideshow/nistsp80053r5/256795731 22. W3C Verifiable Credentials Specification for Galileo \- Galileo Protocol, https://www.galileoprotocol.io/specifications/identity/verifiable-credentials 23. Cross-Domain AuthZ Information sharing for Agents \- IETF, https://www.ietf.org/archive/id/draft-diaconu-agents-authz-info-sharing-01.html 24. The Complete LLMs.txt Guide: What It Is, Why It Matters, and How to Write One | GrowthOS, https://www.usegrowthos.com/blog/llms-txt-guide 25. All about CycloneDX 1.6. SBOM is the foundation of software… | by Interlynk | Medium, https://medium.com/@interlynkblog/all-about-cyclonedx-1-6-6af35df675de 26. How to Make Your Blog Agent-Ready: A Practical Implementation, https://blog.ogwilliam.com/post/how-to-make-your-blog-agent-ready 27. I shipped a broken RFC 9162 consistency proof verifier in Rust \-- here's the exploit and the fix \- Reddit, https://www.reddit.com/r/rust/comments/1raha3x/i\_shipped\_a\_broken\_rfc\_9162\_consistency\_proof/ 28. RFC 9162 \- Certificate Transparency Version 2.0 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9162 29. ITE-5: Disassociate signature envelope specification from in-toto \- GitHub, https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc 30. Stay Compliant with NIST SP 800-218 and CISA Attestation Requirements \- Sonatype, https://www.sonatype.com/resources/guides/stay-compliant-nist-sp-800-218-cisa-requirements 31. SLSA \- Open Source Security Foundation, https://openssf.org/projects/slsa/ 32. OCI Storage Encoding Format \- Tekton, https://tekton.dev/docs/chains/oci-encoding-format/