RFC-ATF-3: Agent Trust Fabric — Governance Policy Interoperability, Evidence Lifecycle & Forensic Verification Protocol

RFC-ATF-3 is the third foundational specification in the Agent Trust Fabric (ATF) Open Protocol Standard — an open, post-quantum governance protocol for AI agents operating in high-stakes environments that require cryptographically verifiable delegation chains, real-time authority monitoring, and forensically auditable evidence infrastructure. The ATF stack was designed to answer a question that most AI governance frameworks avoid: how do you formally prove, years after the fact, that an AI agent acted within the boundaries it was authorized to act within — without relying on the availability of the platform, the original operators, or any live infrastructure? RFC-ATF-3 is the answer to that question. Context: The ATF Protocol Stack RFC-ATF-3 is the third and final layer of a three-RFC architecture, each addressing a distinct structural problem in AI agent governance: RFC-ATF-1 (DOI: 10. 5281/zenodo. 20155016) established the cryptographic foundation: ML-DSA-65 delegation chains, monotonic authority reduction, and offline verifiability. Six invariants. ATF-Compliant designation. RFC-ATF-2 (DOI: 10. 5281/zenodo. 20241344) addressed runtime continuity: the Continuity Enforcement Score (CES) formula, Runtime Continuity Records, HALT semantics, and acyclicity constraints on delegation chains. Eight invariants. ATF-RGC-Compliant designation. RFC-ATF-3 (this document) addresses the evidence problem: what is produced by a governed system, how long it is retained, how it is archived with cryptographic immutability, and how it is forensically reconstructed by an independent auditor. Twenty-six new invariants. ATF-FEI-Compliant designation. Together, the three RFCs define 40 formally specified invariants — the most comprehensive formal constraint set published for AI agent governance infrastructure to date. Part I — Governance Policy Interoperability Layer (GPIL) Multi-agent systems increasingly operate across organizational boundaries, regulatory jurisdictions, and technical runtimes. Most governance frameworks treat interoperability as a configuration problem. GPIL treats it as a formal protocol problem. GPIL defines a three-tier interoperability taxonomy that separates concerns which virtually all existing frameworks conflate: Layer 1 — Cryptographic Interoperability: Can two runtimes verify each other's signatures? Governed by algorithm compatibility (ML-DSA-65 ↔ ML-DSA-65) and key format standardization. Non-negotiable — no sovereign override permitted. Layer 2 — Protocol Interoperability: Do two runtimes implement the same ATF message types, delegation semantics, and receipt formats? Governed by version negotiation and profile matching. Layer 3 — Governance Policy Interoperability: Can two organizations agree on thresholds, approval quorums, retention periods, and escalation paths — without compromising either party's sovereign governance parameters? GPIL introduces the Policy Parameter Registry — a categorized table of all ATF-relevant governance parameters, each classified as Protocol-Bounded (immutable by organizational policy) or Sovereign (configurable within formal bounds). This prevents the class of governance failures caused by misconfigured thresholds that silently override protocol-level safety constraints. The Cross-Runtime Governance Contract (CRGC) is a signed, version-locked bilateral agreement between two ATF runtimes. A CRGC specifies the agreed parameter set for the interaction, carries ML-DSA-65 signatures from both parties, and is immutable once executed. Any parameter drift after CRGC execution triggers a protocol violation — not a configuration warning. Three invariants: GPIL-INV-001–003. Part II — Evidence Lifecycle & Archive Pipeline (ELP) A governed AI system continuously produces evidence: delegation receipts, runtime continuity records, authority transitions, escalation events, approval decisions, execution traces. Without a formal lifecycle specification, this evidence accumulates without structure, degrades without policy, and becomes forensically useless over time. ELP defines eight evidence classes with formal classification rules: Governance Delegation Receipt (GDR) Runtime Continuity Record (RCR) Authority Transition Record (ATR) Escalation Event Record (EER) Approval Decision Receipt (ADR) Policy Violation Record (PVR) Forensic Reconstruction Input (FRI) Archive Integrity Proof (AIP) Each class carries a mandatory classification at creation time (ELR-INV-001), and that classification is immutable for the lifetime of the record (ELR-INV-002). Evidence transitions through formal lifecycle stages — ACTIVE → ARCHIVED → COLD → SEALED — with retention tier compliance enforced by invariant (ELR-INV-003, ELR-INV-004). The Immutable Evidence Archive Pipeline (EAP) specifies the cold archive structure: a Merkle-chained sequence of COLD blocks, each containing a set of sealed evidence records, a canonical hash computed over its contents, and a back-pointer to the previous block's hash. The genesis block carries a cryptographic anchor (EAP-INV-007) that allows any auditor to verify the integrity of the entire archive from any point in the chain. COLD blocks are immutable once sealed (EAP-INV-004) — no amendment, no deletion, no reprocessing. Seven invariants: EAP-INV-001–007. Part III — Forensic Verification Protocol (FVP) Forensic verification in AI governance faces a problem that traditional audit frameworks do not: the auditor may have no access to the live system, no relationship with the original operators, and no ability to replay the events being audited. The only thing they have is what was exported — and that export must be sufficient for a complete, independent reconstruction. The OMNIX Evidence Package (OEP) is the forensic deliverable format specified by RFC-ATF-3. An OEP is a self-contained directory archive with a fixed structure: OMNIX-PACKAGE-DATE-ID/ META/ manifest. json (signed package manifest) README. txt (human-readable verification instructions) BLOCKS/ OMNIX-BLOCK-*. json (COLD blocks in chain order) chainᵢndex. json (block sequence with canonical hashes) KEYS/ publicₖey. b64 (ML-DSA-65 public key, base64) VERIFY/ omnixₐtfᵥerify. py (offline CLI verifier, Python 3. 8+) verifyₐll. sh (full chain verification script) CUSTODY/ evidencecustodyₗog. json REPORT/ forensicᵣeport. html (offline forensic reconstruction report) SIGNATURE/ packageₛignature. json (ML-DSA-65 signature over canonical manifest hash) An OEP can be verified entirely offline — no network access, no platform availability, no operator involvement. The verifier script is included in the package itself. Six invariants: OEP-INV-001–006. The Forensic Export Authentication (FEA) protocol governs how OEPs are generated. FEA-INV-001 mandates key isolation: export signing keys must be separate from governance signing keys — a single key compromise cannot simultaneously invalidate both the governance chain and its forensic deliverables. FEA-INV-003 mandates fail-closed behavior: if the signing key is absent or invalid at export time, the export fails — it does not produce an unsigned package. Five invariants: FEA-INV-001–005. FVP-INV-007 — the Determinism Invariant — is the most technically consequential constraint in RFC-ATF-3: any conformant verifier implementation, regardless of programming language or platform, must produce an identical forensic verdict given identical inputs. This means the hash function, the serialization format, the canonical form of all inputs, and the verdict encoding must all be specified with sufficient precision that two independent implementations cannot produce divergent results. Cross-language hash parity is mandatory, not aspirational. ATF-FEI-Compliant Designation An implementation that fully conforms to RFC-ATF-1, RFC-ATF-2, and RFC-ATF-3 earns the ATF-FEI-Compliant (Forensic Evidence Infrastructure Compliant) designation — the highest tier in the ATF protocol hierarchy. This designation is intended for forensic-grade, regulatory-grade, and institutional-grade deployments where governance decisions must be independently auditable for years or decades after the fact, without platform availability. Conformance is verified using the standalone ATF Conformance Suite: 92 test vectors across all 40 invariants Three profiles: BASE (ATF-INV-001–006), RGC (BASE + RGC-INV-001–008), ALL (full 40-invariant ATF-FEI-Compliant) Zero external dependencies beyond Python 3. 8 Each run produces an ATF Conformance Result (ATFCR) artifact with a unique ATFCR-* identifier and SHA-256 integrity hash suitable for inclusion in regulatory submissions, audit logs, and IMPLEMENTATIONS. md Available at: github. com/Costenho19/atf-protocol-standard/tree/main/atf-conformance-suite Cryptographic Design RFC-ATF-3 is post-quantum secure by design. All signatures — governance receipts, delegation records, forensic packages, Cross-Runtime Governance Contracts, and export authentication — use ML-DSA-65 (Dilithium-3), standardized as NIST FIPS 204 (August 2024). ECDSA, RSA, and any pre-quantum signature scheme are not referenced in the protocol. Evidence packages are designed to remain cryptographically verifiable for decades, assuming continued availability of ML-DSA-65 implementations — which, as a NIST standard, is a reasonable long-term assumption. Publication Notes This document is the reference specification for the OMNIX QUANTUM governance platform Published as an open standard under CC BY 4. 0 to enable independent implementations, academic review, and institutional adoption Full source, conformance suite, test vectors, and implementation guidance available at github. com/Costenho19/atf-protocol-standard The PDF included in this record was generated from the canonical markdown source (RFC-ATF-3. md,