Network Working Group L.J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 4 September 2026 Expires: 8 March 2027 Reilly Government Integrity Protocol (RGIP): Multi-Layer, Quantum-Resilient Framework for Permanent and Tamper-Evident Public Records draft-reilly-government-integrity-02 Abstract The Reilly Government Integrity Protocol (RGIP) defines a standards-aligned method for producing permanent, independently verifiable public records by combining multi-algorithm content hashing, public timestamp anchoring, archival deposit under a persistent identifier, decentralized storage, and web archiving into a single pipeline. This revision corrects defects in draft-reilly-government-integrity-01 that would have prevented independent verification or overstated the guarantees the protocol provides. It replaces the -01 SHA3-512-only Cross-Chain Hash, which made a single algorithm the sole binding of three otherwise independent chains, with an entangled link-and-braid construction in which each chain consumes the prior state of all three. It defines a canonical, domain-separated, length-delimited encoding for every hashed input, removing the concatenation ambiguity present in -01. It separates the signed Evidence Receipt Core from the mutable anchor envelope, resolving the -01 condition in which confirming an anchor invalidated the signature over the record it described. It adds Chain Checkpoint anchoring, without which the -01 claim that record sequence is provable did not hold, since -01 anchored only artifact digests and never the chain itself. It replaces raw digests of low-entropy government records with salted field commitments, adds explicit pending and attested anchor states, adds a Revocation Registry and Hash Migration Bridging Records, replaces the quantum_resilient boolean with a declared algorithm suite, prohibits automated repair of chain integrity violations, and narrows the -01 post-quantum claims to what the constructions support. It also documents the function of RGIP records and of this specification as prior art records under 35 U.S.C. 102(a)(1), consistent with the treatment in version -02 of the REM Protocol specification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Reilly Expires 8 March 2027 [Page 1] Internet-Draft Reilly Government Integrity Protocol September 2026 Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Changes in This Revision . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Goals and Non-Goals . . . . . . . . . . . . . . . . . 8 4. High-Level Overview . . . . . . . . . . . . . . . . . . . . . 9 5. Government Use Cases . . . . . . . . . . . . . . . . . . . . 10 5.1. Legislative and Regulatory Records . . . . . . . . . . 10 5.2. Procurement and Contracting . . . . . . . . . . . . . 10 5.3. Financial and Budget Records . . . . . . . . . . . . . 11 5.4. Judicial Records . . . . . . . . . . . . . . . . . . . 11 5.5. Intelligence and National Security Records . . . . . . 11 5.6. Election Administration . . . . . . . . . . . . . . . 12 5.7. Constraints Common to All Use Cases . . . . . . . . . 12 6. Canonical Encoding and Domain Separation . . . . . . . . . . 13 7. Entangled Triple-Hash Chain Architecture . . . . . . . . . . 14 7.1. Algorithm Suite . . . . . . . . . . . . . . . . . . . 14 7.2. Artifact Fingerprint . . . . . . . . . . . . . . . . . 14 7.3. Link Construction . . . . . . . . . . . . . . . . . . 15 7.4. Braid Construction . . . . . . . . . . . . . . . . . . 15 Reilly Expires 8 March 2027 [Page 2] Internet-Draft Reilly Government Integrity Protocol September 2026 7.5. Genesis Block . . . . . . . . . . . . . . . . . . . . 16 7.6. Chain Integrity Verification . . . . . . . . . . . . . 16 7.7. Security Properties and Limits . . . . . . . . . . . . 17 8. REMID: Content-Derived Artifact Identifier . . . . . . . . . 17 8.1. Format and Derivation . . . . . . . . . . . . . . . . 18 8.2. Collision Handling . . . . . . . . . . . . . . . . . . 18 8.3. Properties and Limits . . . . . . . . . . . . . . . . 18 8.4. REMID Resolver . . . . . . . . . . . . . . . . . . . . 19 9. Field Commitments and Selective Disclosure . . . . . . . . . 19 10. Evidence Receipt (ER) Data Model . . . . . . . . . . . . . . 20 10.1. ER Core (Signed) . . . . . . . . . . . . . . . . . . 20 10.2. ER Envelope (Mutable) . . . . . . . . . . . . . . . . 21 10.3. Field Notes . . . . . . . . . . . . . . . . . . . . . 23 10.4. Version and Compatibility . . . . . . . . . . . . . . 23 11. Permanence Layer Stack . . . . . . . . . . . . . . . . . . . 23 11.1. Anchor States . . . . . . . . . . . . . . . . . . . . 23 11.2. Timestamp Anchoring via OpenTimestamps . . . . . . . 24 11.3. Chain Checkpoint Anchoring . . . . . . . . . . . . . 24 11.4. Decentralized Storage via IPFS . . . . . . . . . . . 25 11.5. Archival Deposit and DOI Issuance . . . . . . . . . . 25 11.6. Web Archival . . . . . . . . . . . . . . . . . . . . 26 12. Step-by-Step Implementation (Normative) . . . . . . . . . . 26 13. Verification Procedure (Normative) . . . . . . . . . . . . . 28 14. Amendment, Supersession, and Revocation . . . . . . . . . . 29 14.1. Amendment Records . . . . . . . . . . . . . . . . . . 29 14.2. Revocation Registry . . . . . . . . . . . . . . . . . 29 14.3. Retention and Disposition . . . . . . . . . . . . . . 30 15. Hash Migration Bridging Records . . . . . . . . . . . . . . 30 16. Autonomous Agent Architecture . . . . . . . . . . . . . . . 31 16.1. Agent Roles . . . . . . . . . . . . . . . . . . . . . 31 16.2. Blast Radius and Oversight . . . . . . . . . . . . . 32 16.3. Prohibited Automated Actions . . . . . . . . . . . . 33 17. Operational Considerations . . . . . . . . . . . . . . . . . 33 18. Security Considerations . . . . . . . . . . . . . . . . . . 34 19. Post-Quantum Considerations . . . . . . . . . . . . . . . . 35 20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 21. Prior Art Record Function . . . . . . . . . . . . . . . . . 37 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 23.1. Normative References . . . . . . . . . . . . . . . . 38 23.2. Informative References . . . . . . . . . . . . . . . 40 Appendix A. Changes from draft-reilly-government-integrity-01 . 41 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Public institutions produce records whose integrity is foundational Reilly Expires 8 March 2027 [Page 3] Internet-Draft Reilly Government Integrity Protocol September 2026 to democratic governance, legal accountability, and public trust. Legislative acts, regulatory filings, judicial decisions, agency rulemakings, procurement records, budget authorizations, and intelligence assessments all depend on an unbroken chain of custody from the moment of creation. When that chain is interrupted, whether by accident, negligence, or deliberate suppression, the record loses its evidentiary value and public accountability fails. Existing mechanisms for establishing record permanence are structurally insufficient. Institutional custody concentrates control in the entity whose conduct the record is meant to document. Paper archives are subject to physical destruction. Certified copies depend on the integrity of the certifying authority. Digital records stored in government-controlled systems are alterable by the same administrators who produce them. None of these mechanisms provides independently verifiable proof that a record existed at a specific moment and has not been modified since. RGIP addresses this structural gap by anchoring government records to infrastructure that no single institution controls. A public timestamping layer provides an observation of existence that cannot be revised without recomputing the underlying consensus. Content-addressed storage provides retrievability independent of any hosting provider. Archival deposit under a persistent identifier provides a citable reference maintained by an institution distinct from the record's originator. Web archival provides an additional independent crawl. Together these layers ensure that no single point of failure, and no single institutional actor, can silently suppress or alter a record that has been processed through RGIP. RGIP does not mandate a legal framework, evidentiary standard, or regulatory standing for anchored records. It provides cryptographic infrastructure on which such frameworks may rely. Whether a record produced under RGIP is admissible, authoritative, or dispositive in any proceeding is determined by the applicable forum and not by this specification. 1.1. Changes in This Revision Revision -00 [RGIP00] established a single-hash pipeline. Revision -01 introduced a triple-hash chain, the REMID, a four-layer permanence stack, and an autonomous agent architecture. Several of its constructions did not deliver the properties claimed for them. This revision corrects them. 1. Binding of the three chains. In -01, the three chains were bound solely by a SHA3-512 Cross-Chain Hash computed over their outputs. An adversary able to forge SHA3-512 could forge the Reilly Expires 8 March 2027 [Page 4] Internet-Draft Reilly Government Integrity Protocol September 2026 binding, and the three chains were otherwise mutually independent, so the construction did not require defeating all three algorithms as -01 claimed. Section 7 replaces it with an entangled link-and-braid construction in which every chain consumes the prior Braid, and the Braid is computed under all three algorithms rather than one. 2. Hashed-input ambiguity. Revision -01 concatenated variable-length text fields with no separator, length prefix, or domain tag, so distinct field assignments could produce identical preimages. Section 6 defines a canonical, domain-separated, length-delimited encoding that every hashed input MUST use. 3. Signature and anchor circularity. In -01 the signature covered the whole Evidence Receipt, including permanence fields that change when a pending anchor is later confirmed. Updating permanence.bitcoin.status from "pending" to "confirmed" invalidated the signature over the record it described. Section 10 separates a signed, immutable ER Core from a mutable ER Envelope carrying anchor and archival state. 4. Unanchored chain. Revision -01 submitted only the artifact SHA-256 digest to OpenTimestamps. Nothing external committed to chain state, so an operator could rebuild the entire chain in a different order and every artifact timestamp would still verify. The -01 assertion that procurement record sequence "cannot be forged" did not follow. Section 11.3 adds Chain Checkpoint anchoring, and Section 5.7 states the ordering guarantee in terms of what Checkpoints actually establish. 5. Missing verification inputs. The -01 chain hashes consumed record_id, but record_id was not a field of the -01 Evidence Receipt, so a third party could not recompute the chain hashes from a published ER. Section 10.1 makes record_id a required ER Core field and requires that the OTS proof bytes needed by verification be carried or referenced by the ER. 6. Low-entropy artifact exposure. Government records frequently have low entropy: ballot definitions drawn from a known set, voter records over known name and address spaces, form-based filings. Publishing a raw digest of such an artifact lets an adversary confirm its content by enumeration. Section 9 introduces salted Field Commitments, and Section 20 prohibits anchoring raw digests of low-entropy or access-controlled artifacts. 7. REMID self-contradiction. Revision -01 declared the REMID deterministic and simultaneously directed implementations to Reilly Expires 8 March 2027 [Page 5] Internet-Draft Reilly Government Integrity Protocol September 2026 append additional hash characters on collision, which makes it non-deterministic and unreproducible by a Verifier. Section 8.2 defines a deterministic collision rule. Section 8.3 restates the collision bound, which -01 gave as a per-pair probability where a birthday bound applies. 8. Overstated post-quantum claims. Revision -01 asserted a quantum speedup exploiting the Merkle-Damgard structure of SHA-2, which is not a known result, and garbled the security levels of BLAKE3. Section 19 states the classical and quantum levels each algorithm supports and identifies what remains unaddressed, notably the signature algorithm. 9. Self-asserted properties. The -01 chain object carried a quantum_resilient boolean, which a Verifier cannot check and which conveys the Producer's opinion rather than a fact about the record. It is replaced by an alg_suite identifier naming the algorithms actually used. 10. Governance of automated action. The -01 agent architecture let a self-heal agent act on any degraded layer without constraint, including, on its face, chain integrity findings. Section 16 classifies agent actions by blast radius and prohibits automated remediation of chain integrity violations. This revision also adds a Revocation Registry (Section 14.2), Hash Migration Bridging Records (Section 15), retention and disposition guidance for records subject to statutory schedules (Section 14.3), and a prior art record section (Section 21). Internal cross-references, which were misnumbered throughout -01, and several passages duplicated by editing error, have been corrected. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Artifact: The public record content being made permanent (e.g., PDF, text, JSON, image, or document bundle). Fingerprint: The ordered triple of digests (SHA-256, SHA3-512, BLAKE3-256) of an Artifact's canonical byte stream. Reilly Expires 8 March 2027 [Page 6] Internet-Draft Reilly Government Integrity Protocol September 2026 Link: The per-algorithm chain value at a block, computed over the prior Braid and the current block inputs (Section 7.3). Braid: The ordered triple of digests committing to all three Links at a block, computed under all three algorithms (Section 7.4). The Braid replaces the -01 Cross-Chain Hash. Block: A single entry in an RGIP chain, corresponding to one Artifact submission, amendment, revocation, or bridging record. Genesis Block: The first block of an RGIP chain, whose prior Braid is the all-zeros Braid of Section 7.5. Chain Head: The Braid of the highest-indexed block in a chain. Checkpoint: A commitment to a Chain Head submitted to the timestamp layer, establishing that the chain held that state no later than an observed time (Section 11.3). REMID: Reilly EternaMark Identifier. A content-derived persistent identifier for an Artifact, in the namespace REMID:YYYY.MMDD/ (Section 8). ER: Evidence Receipt. The record object defined in Section 10, consisting of an ER Core and an ER Envelope. ER Core: The immutable, signed portion of an ER. ER Envelope: The mutable portion of an ER carrying anchor and archival state. Not covered by the Core signature. Field Commitment: A salted digest over a single field value, published in place of the value where the value is sensitive or low-entropy (Section 9). Anchor: The submission of a digest to a public timestamping service, and its subsequent attestation. Pending Anchor: An anchor submitted to a calendar or aggregator but not yet committed to a public consensus record. A pending anchor is a receipt of submission, not evidence of time (Section 11.1). Reilly Expires 8 March 2027 [Page 7] Internet-Draft Reilly Government Integrity Protocol September 2026 Attested Anchor: An anchor whose proof resolves to a committed public consensus record, establishing an upper bound on the time at which the digest existed. CID: Content Identifier per IPFS content addressing [IPFS-SPEC]. DOI: Digital Object Identifier resolving to an archival landing page for the Artifact. OTS Proof: An OpenTimestamps [OTS] proof linking a digest to a Bitcoin block header via a Merkle path. ni URI: A content-hash URI per [RFC6920]. Producer: The entity operating an RGIP pipeline and issuing ERs. Verifier: Any party checking an ER against the Artifact and the permanence layers. A Verifier is assumed to trust neither the Producer nor the record's originating agency. 3. Protocol Goals and Non-Goals Goals * Binding each Artifact to a fingerprint under three structurally independent hash functions. * Chaining Artifacts in a sequence such that retrospective alteration is detectable by any Verifier holding a later Checkpoint. * Anchoring both individual Artifacts and periodic Chain Heads to a public timestamping layer controlled by no participant in the record's subject matter. * Distributing Artifacts and their metadata across independent permanence layers, such that loss of any one layer does not destroy verifiability. * Permitting verification of a record without disclosing sensitive or statutorily protected field values. * Supporting continuous automated verification while keeping integrity findings under human authority. Reilly Expires 8 March 2027 [Page 8] Internet-Draft Reilly Government Integrity Protocol September 2026 Non-Goals * Mandating a specific timestamping service beyond naming Bitcoin OpenTimestamps as the RECOMMENDED anchor. * Defining new cryptographic primitives. * Determining the legal, evidentiary, or regulatory standing of records. * Prescribing access control policy for Artifact content. * Preventing destruction or non-production of a record. RGIP makes alteration and backdating detectable; it does not make a record available to a party the custodian refuses to serve, beyond the copies distributed to the permanence layers at processing time. * Establishing that a record is accurate, lawful, or complete. RGIP establishes what was recorded and when, not whether what was recorded was true. 4. High-Level Overview A Producer processes an Artifact through the following pipeline: (1) Determine the Artifact's canonical byte stream and compute its Fingerprint under SHA-256, SHA3-512, and BLAKE3-256. (2) Derive a REMID from the SHA-256 digest and the UTC submission date (Section 8). (3) Assemble the block inputs and encode them canonically per Section 6. (4) Compute the three Links over the prior Braid and the block inputs, then compute the new Braid (Section 7). (5) Where field values are sensitive or low-entropy, compute salted Field Commitments and publish those in place of the values (Section 9). (6) Assemble and sign the ER Core. (7) Submit the ER Core digest to the timestamp layer, obtaining a pending anchor (Section 11.2). (8) Pin the Artifact and ER to content-addressed storage, deposit the Artifact for archival under a persistent identifier, and Reilly Expires 8 March 2027 [Page 9] Internet-Draft Reilly Government Integrity Protocol September 2026 submit the resolver URL for web archival. Record the results in the ER Envelope. (9) Publish the ER. (10) On a defined cadence, submit a Checkpoint over the Chain Head to the timestamp layer (Section 11.3). (11) Monitor for anchor attestation and update the Envelope from pending to attested when a proof resolves. Verifiers retrieve the ER, recompute the Fingerprint and the chain values, verify the Core signature, resolve each permanence layer independently, and evaluate anchors under Section 11.1. 5. Government Use Cases This section is informative. It illustrates application of RGIP to government record categories. Section 5.7 states constraints that apply to all of them and that were absent from -01. 5.1. Legislative and Regulatory Records A legislative body or regulatory agency publishes a document: bill text, a final rule, guidance, or a public notice. The agency processes the document through RGIP at publication, producing an ER whose Core digest is anchored, whose Artifact is pinned and deposited, and whose resolver page is crawled. A later claim that the document's content differs from the published version is refutable by recomputing the Fingerprint. A later claim that it was published earlier than it was is refutable by the attested anchor, which establishes an upper bound on existence time. An anchor does not establish a lower bound: it does not show that the document did not exist earlier. 5.2. Procurement and Contracting Procurement generates records that are frequently disputed: solicitation language, proposal submissions, evaluation scores, and award decisions. Each is processed at creation or receipt. Ordering within the chain is established relative to Checkpoints. Two blocks separated by an attested Checkpoint are ordered with respect to that Checkpoint's observed time: the earlier block's content was fixed before the Checkpoint was anchored. Blocks with no intervening Checkpoint are ordered only by the Producer's own assertion, since the Producer could have constructed both at any time Reilly Expires 8 March 2027 [Page 10] Internet-Draft Reilly Government Integrity Protocol September 2026 before the next Checkpoint. Agencies SHOULD therefore set the Checkpoint cadence (Section 11.3) to the granularity at which ordering disputes are expected to matter. For procurement, a Checkpoint at each phase boundary is RECOMMENDED. Audit agencies can verify the full chain without relying on the contracting agency's internal systems, provided the ERs and the Checkpoint proofs are published. 5.3. Financial and Budget Records Appropriations, expenditure authorizations, and audit findings are anchored at issuance. A retroactive amendment MUST create a new block under Section 14.1; the original block remains in the chain and the original Artifact remains retrievable via its REMID, persistent identifier, and CID. Suppression of the original therefore requires removing it from every permanence layer, each operated by a distinct party. 5.4. Judicial Records Filings, orders, and opinions processed at issuance carry a tamper-evident record of content. This is relevant where a record is later sealed, expunged, or amended and the fact and content of the original is itself material. Sealing and expungement raise a direct conflict with permanence. A court order to destroy or seal a record cannot be satisfied by a system that has published the Artifact to irrevocable public layers. Deployments handling records subject to sealing MUST anchor Field Commitments rather than the Artifact itself (Section 9), MUST NOT pin or deposit the Artifact to public permanence layers, and MUST record the anchoring mode in the ER Core. Section 14.3 addresses disposition. 5.5. Intelligence and National Security Records Assessments, briefings, and supporting evidence may be processed to establish content at time of production, which is relevant to chain of custody, inspector general oversight, and declassification review where original content must be distinguishable from later revisions. Classified and controlled unclassified material MUST NOT have its Artifact digest anchored to a public timestamp layer. A digest is a commitment: an adversary holding a candidate document can confirm it by recomputation, and the anchor also discloses that a document existed at a given time, which is itself frequently sensitive. Deployments in this context MUST use salted commitments (Section 9), Reilly Expires 8 March 2027 [Page 11] Internet-Draft Reilly Government Integrity Protocol September 2026 MUST hold salts within the accreditation boundary, and SHOULD consider whether the timing pattern of anchors is itself a disclosure. Anchoring to a private or community-of-interest timestamp service is a supported profile under Section 17 and forfeits the independence property that public anchoring provides. 5.6. Election Administration Ballot definitions, aggregate canvass reports, and configuration state may be processed at defined intervals, creating an audit trail verifiable without reliance on an election administrator's internal systems. Voter registration files MUST NOT be processed as raw Artifacts. They contain personal data, they are low-entropy against known name and address spaces, and in many jurisdictions their disclosure is statutorily constrained. Where registration state must be anchored, Producers MUST anchor a salted commitment over the file (Section 9) and retain the salt under the same controls as the file. Cast vote records MUST NOT be anchored in any form that could associate a ballot with a voter. Where individual cast vote records are anchored, block ordering MUST be randomized or batched so that block index does not correspond to order of casting. 5.7. Constraints Common to All Use Cases The following constraints apply to every case above and qualify claims made without qualification in -01. * An attested anchor establishes that a digest existed no later than the observed time. It does not establish authorship, authority, accuracy, or that no earlier version existed. * Chain ordering is provable only relative to Checkpoints (Section 11.3). Absent Checkpoints, an operator with control of the datastore can reconstruct the entire chain in any order and all per-artifact anchors will still verify. * RGIP detects alteration of records it has processed. It does not detect the non-creation of a record, the withholding of a record from processing, or the selective processing of a subset. The absence of a block is not evidence that no such record existed. Where completeness matters, a deployment SHOULD publish periodic completeness attestations enumerating the block range and count covered, so that gaps are visible. * Where an agency is both the record's subject and the operator of Reilly Expires 8 March 2027 [Page 12] Internet-Draft Reilly Government Integrity Protocol September 2026 the RGIP pipeline, the independence property comes from the external layers, not from the pipeline. A Verifier SHOULD treat unanchored, unpinned, or undeposited records from such a deployment as unverified. Deployments that present RGIP output to the public SHOULD state these limits alongside the evidence. 6. Canonical Encoding and Domain Separation Revision -01 formed hash inputs by concatenating UTF-8 strings with no delimiter. Because several inputs are variable-length, distinct assignments could produce the same preimage; for example, a record_id ending in a digit followed by a timestamp is indistinguishable from a longer record_id followed by a shorter timestamp. This section removes that ambiguity and is normative. Every hash input defined in this document MUST be constructed as: ENC(label, f_1, f_2, ..., f_n) = LP(label) || LP(f_1) || LP(f_2) || ... || LP(f_n) where: * LP(x) is the length-prefixed encoding of octet string x: an eight-octet unsigned big-endian length, followed by the octets of x. * label is a US-ASCII domain separation tag drawn from the registry in this section. * Text fields are encoded as UTF-8 with Unicode Normalization Form C applied before encoding. * Digest fields are encoded as raw octets, not as hexadecimal text. Where a digest is displayed in an ER, it is lowercase hexadecimal; where it is hashed, it is the underlying octets. * An absent OPTIONAL field is encoded as LP of the empty string. A Producer MUST NOT omit the field from the sequence. Domain separation tags defined by this document: "RGIP/2/link/sha256" Section 7.3 "RGIP/2/link/sha3-512" Section 7.3 "RGIP/2/link/blake3" Section 7.3 "RGIP/2/braid/sha256" Section 7.4 "RGIP/2/braid/sha3-512" Section 7.4 Reilly Expires 8 March 2027 [Page 13] Internet-Draft Reilly Government Integrity Protocol September 2026 "RGIP/2/braid/blake3" Section 7.4 "RGIP/2/core" Section 10.1 "RGIP/2/commit" Section 9 "RGIP/2/checkpoint" Section 11.3 "RGIP/2/bridge" Section 15 A digest computed under one tag is not a valid digest under any other. Implementations MUST NOT reuse a tag for a purpose not defined here, and a profile defining new constructions MUST allocate tags under its own prefix. All Artifact digests are taken over the Artifact's canonical byte stream. For JSON Artifacts, the canonical byte stream is the JCS [RFC8785] serialization. For all other media types, it is the exact octet sequence published, and the Producer MUST NOT normalize, re-encode, or re-compress it. 7. Entangled Triple-Hash Chain Architecture RGIP maintains three chain values per block under three structurally independent hash functions. Unlike -01, in which the chains ran in parallel and met only at a single SHA3-512 binding value, each chain in this revision consumes the prior state of all three. 7.1. Algorithm Suite The algorithm suite REQUIRED by this document is designated "rgip-2-a" and consists of: SHA-256 [RFC6234], 32-octet output SHA3-512 [FIPS202], 64-octet output BLAKE3-256 [BLAKE3], 32-octet output in the default hash mode with no key and no context string Revision -01 did not fix the BLAKE3 output length, although BLAKE3 is an extendable-output function and its genesis value in -01 implied 32 octets. This revision fixes it at 32 octets. An ER MUST carry the suite identifier in core.alg_suite. This replaces the -01 chain.quantum_resilient boolean, which asserted a property no Verifier could check. A Verifier MUST reject an ER whose alg_suite it does not implement, rather than attempting partial verification. 7.2. Artifact Fingerprint The Fingerprint of an Artifact A is the ordered triple: Reilly Expires 8 March 2027 [Page 14] Internet-Draft Reilly Government Integrity Protocol September 2026 FP(A) = ( SHA-256(A), SHA3-512(A), BLAKE3-256(A) ) computed over the canonical byte stream of Section 6. All three digests MUST be computed; a Producer MUST NOT emit an ER carrying fewer than three. 7.3. Link Construction Let B(N-1) = (b256(N-1), b3(N-1), bb3(N-1)) be the prior Braid, and let the block inputs be: idx the block index, as an 8-octet unsigned big-endian integer rid the record_id (Section 10.1) remid the REMID created the RFC 3339 [RFC3339] creation timestamp, UTC etype the event type fp256, fp3, fpb3 the three Fingerprint digests, or, in commitment mode, the corresponding Field Commitments (Section 9) mode the anchoring mode, "artifact" or "commitment" The three Links at block N are: L256(N) = SHA-256( ENC("RGIP/2/link/sha256", b256(N-1), b3(N-1), bb3(N-1), idx, rid, remid, created, etype, fp256, fp3, fpb3, mode) ) L3(N) = SHA3-512( ENC("RGIP/2/link/sha3-512", b256(N-1), b3(N-1), bb3(N-1), idx, rid, remid, created, etype, fp256, fp3, fpb3, mode) ) Lb3(N) = BLAKE3-256( ENC("RGIP/2/link/blake3", b256(N-1), b3(N-1), bb3(N-1), idx, rid, remid, created, etype, fp256, fp3, fpb3, mode) ) Each Link consumes all three prior Braid components. Consequently a forgery under any single algorithm does not yield a consistent chain: the forged value must reproduce inputs that the other two algorithms also commit to. 7.4. Braid Construction The Braid at block N is the ordered triple: Reilly Expires 8 March 2027 [Page 15] Internet-Draft Reilly Government Integrity Protocol September 2026 b256(N) = SHA-256( ENC("RGIP/2/braid/sha256", L256(N), L3(N), Lb3(N)) ) b3(N) = SHA3-512( ENC("RGIP/2/braid/sha3-512", L256(N), L3(N), Lb3(N)) ) bb3(N) = BLAKE3-256( ENC("RGIP/2/braid/blake3", L256(N), L3(N), Lb3(N)) ) B(N) = ( b256(N), b3(N), bb3(N) ) The -01 Cross-Chain Hash used SHA3-512 alone as the outer function. That made SHA3-512 a single point of algorithmic failure for the binding: an adversary with a SHA3-512 collision could bind an inconsistent set of chain values. Computing the Braid under all three algorithms removes that property. A Verifier MUST check all three Braid components; checking one is not a summary of the others and MUST NOT be presented as one. 7.5. Genesis Block For the Genesis Block, B(-1) is the all-zeros Braid: b256(-1) = 32 octets of 0x00 b3(-1) = 64 octets of 0x00 bb3(-1) = 32 octets of 0x00 A chain MUST have exactly one Genesis Block. Its block index MUST be 0. A Producer operating multiple chains MUST give each a distinct chain identifier carried in core.chain_id, and MUST NOT interleave blocks from different chains in one index space. 7.6. Chain Integrity Verification For each block N under verification, a Verifier MUST: 1. Recompute L256(N), L3(N), and Lb3(N) per Section 7.3 from the published block inputs and the prior Braid, and compare each to the stored value. 2. Recompute b256(N), b3(N), and bb3(N) per Section 7.4 from the recomputed Links, and compare each to the stored value. 3. Confirm that the block's prior Braid fields equal the stored Braid of block N-1 componentwise. 4. Confirm that the Genesis Block's prior Braid is the all-zeros Braid of Section 7.5 and that its index is 0. Reilly Expires 8 March 2027 [Page 16] Internet-Draft Reilly Government Integrity Protocol September 2026 5. Confirm that block indices are contiguous over the range verified, with no gaps. Verification MUST fail if any comparison does not match. Partial verification, meaning verification of fewer than all six values per block, MUST NOT be reported as verification. A tool offering a reduced check MUST label its output as a partial check and MUST name the values omitted. Verification of chain integrity alone establishes internal consistency. It does not establish when the chain was constructed. That requires Checkpoints (Section 11.3). 7.7. Security Properties and Limits The construction provides: * Detection of any modification to a block's inputs, which changes that block's Links and Braid and every subsequent block's values. * Resistance to forgery under compromise of any single hash function, since a consistent chain requires all three Links and all three Braid components to agree on the same inputs. It does not provide: * Proof of ordering absent Checkpoints, as stated in Section 5.7. * Protection against a Producer who constructs a self-consistent chain from the start with fabricated timestamps. Only an attested anchor constrains that. * Protection against omission. A chain can be internally perfect and materially incomplete. Revision -01 claimed the construction "converts three independent attack problems into one simultaneous multi-algorithm problem". That claim was not supported by the -01 construction, in which the chains did not consume one another. It is supported by the construction in this section, with the qualification that the security of the ensemble is bounded by the strongest of the three functions, not by their sum: the ensemble survives the failure of any two, but no composition of hash functions exceeds the security of its strongest member against an adversary who has broken none of them. 8. REMID: Content-Derived Artifact Identifier The REMID is a persistent identifier derived from Artifact content Reilly Expires 8 March 2027 [Page 17] Internet-Draft Reilly Government Integrity Protocol September 2026 and submission date. It does not depend on a registrar, certificate authority, or naming authority. Revision -01 described it as "self-sovereign"; this revision uses "content-derived", which states the property without implying a governance claim. 8.1. Format and Derivation REMID:YYYY.MMDD/[.] where YYYY, MM, and DD are the UTC year, month, and day of submission, and sha256_prefix8 is the first eight lowercase hexadecimal characters, that is the first four octets, of the Artifact's SHA-256 digest. In commitment mode (Section 9), the prefix is taken from the salted commitment rather than from the Artifact digest, so that the REMID does not leak a searchable fragment of the Artifact digest. Example: REMID:2026.0904/3e48edc8 8.2. Collision Handling Revision -01 directed implementations encountering a collision to "append additional hash characters", without specifying how many or how a Verifier would know. That rule made the REMID non-reproducible. This revision replaces it. If, within a single chain and a single UTC date, a newly derived REMID equals an already-issued REMID whose Artifact digest differs, the Producer MUST append a disambiguator: a decimal integer, beginning at 1, incremented for each further collision on that prefix and date. The base form, with no disambiguator, is always the first issuance. A Verifier re-deriving a REMID computes the base form and MUST accept an ER whose subject.remid is the base form or the base form with a disambiguator. The disambiguator is not derivable from content, so a Verifier MUST NOT treat its value as evidence of anything beyond issuance order within that date, and MUST resolve identity by the full Fingerprint, never by REMID alone. 8.3. Properties and Limits * Deterministic to the base form. The base REMID for a given Artifact submitted on a given UTC date is reproducible by any party holding the Artifact. Reilly Expires 8 March 2027 [Page 18] Internet-Draft Reilly Government Integrity Protocol September 2026 * Content-derived. The embedded prefix permits fast matching against the full digest but is not itself an identity check. * Collision bound. The prefix is 32 bits. Revision -01 stated the collision probability as "approximately 1 in 2^32", which is the per-pair figure. The applicable bound over n Artifacts sharing a date is the birthday bound: the probability of at least one collision is approximately n^2 / 2^33, giving roughly even odds near n = 77,000 and a one-in-a-thousand chance near n = 2,900. Deployments processing high daily volumes will encounter collisions as a matter of course and MUST implement Section 8.2 rather than treating collisions as exceptional. * Not an authority. A REMID is valid if and only if its prefix matches the corresponding digest. No party assigns or revokes REMIDs, and a REMID carries no assertion about the record's status; revocation is handled in Section 14.2. 8.4. REMID Resolver Producers SHOULD publish a resolver endpoint at a stable URL mapping a REMID to the corresponding ER and Artifact metadata. The resolver SHOULD return JSON conforming to Section 10. A resolver is a convenience, not a trust anchor: a Verifier MUST NOT accept resolver output in place of independent verification of the permanence layers. 9. Field Commitments and Selective Disclosure Many government records cannot be published in full but must still be anchored. Revision -01 anchored the raw Artifact digest in all cases, which is unsafe for low-entropy content: an adversary with a candidate document, or with the ability to enumerate a small candidate space, confirms content by recomputing the digest. A Field Commitment over value v is: C(v) = SHA-256( ENC("RGIP/2/commit", salt, field_name, v) ) where salt is at least 16 octets from a cryptographically secure random source, generated per value and never reused across values or records. Rules: * A Producer operating in commitment mode MUST set core.mode to "commitment" and MUST populate the Fingerprint positions with commitments over the corresponding digests, using the same encoding. Reilly Expires 8 March 2027 [Page 19] Internet-Draft Reilly Government Integrity Protocol September 2026 * Salts MUST NOT be published with the ER. They are disclosed only to a party authorized to verify the underlying value. * A Producer MUST retain salts for at least the retention period of the record. Loss of a salt renders the corresponding commitment permanently unverifiable, and Section 14.3 treats deliberate salt destruction as a disposition mechanism. * Selective disclosure of a field is performed by supplying the value and its salt, which the recipient checks against the published commitment. Disclosure of one field MUST NOT reveal any other field, which the per-value salt ensures. * A Verifier presented with an ER in commitment mode can verify chain integrity, signature, and anchors in full, and can verify content only for fields disclosed to it. Verification output MUST state which fields were verified against values and which were verified only as commitments. 10. Evidence Receipt (ER) Data Model An ER is a UTF-8 JSON object [RFC8259] with two top-level members: "core" and "envelope". The Core is immutable and signed. The Envelope carries state that changes after issuance and is not covered by the Core signature. This split resolves a defect in -01, where permanence.bitcoin.status moved from "pending" to "confirmed" inside the object the signature covered, so that a correctly operated pipeline invalidated its own signatures as a matter of routine. 10.1. ER Core (Signed) { "er_version": "3", "alg_suite": "rgip-2-a", "chain_id": string, "record_id": string, // REQUIRED; UUID v4 [RFC9562] "mode": string, // "artifact" | "commitment" "subject": { "title": string, // OMITTED in commitment mode "originator": string, // issuing body "remid": string, "artifact_uri": string OPTIONAL }, "content": { "media_type": string, "byte_length": integer OPTIONAL, // omit in commitment mode Reilly Expires 8 March 2027 [Page 20] Internet-Draft Reilly Government Integrity Protocol September 2026 "sha256": string, // hex, or commitment in that mode "sha3_512": string, "blake3_256": string, "ni": string OPTIONAL // ni URI [RFC6920] }, "chain": { "block_index": integer, "link_sha256": string, "link_sha3_512": string, "link_blake3_256": string, "braid_sha256": string, "braid_sha3_512": string, "braid_blake3_256": string, "prev_braid_sha256": string, "prev_braid_sha3_512": string, "prev_braid_blake3_256": string }, "event": { "event_type": string, // "publish" | "amend" | "revoke" | // "bridge" | "checkpoint" "created": string, // RFC 3339 [RFC3339], UTC "supersedes": string OPTIONAL // REMID of prior record }, "disclosure": { "committed_fields": array OPTIONAL // field names in commitment }, "sign": { "alg": string, // COSE algorithm [RFC9053] "kid": string, // key identifier "cose_sign1": string // base64url COSE_Sign1 [RFC9052] } } The Core digest is: core_digest = SHA-256( ENC("RGIP/2/core", JCS(core_without_sign)) ) where core_without_sign is the Core object with the "sign" member removed, serialized per JCS [RFC8785]. The COSE_Sign1 signature is computed over core_without_sign in its JCS serialization. The core_digest is the value submitted to the timestamp layer. 10.2. ER Envelope (Mutable) { "core_digest": string, // binds Envelope to Core "anchors": [ Reilly Expires 8 March 2027 [Page 21] Internet-Draft Reilly Government Integrity Protocol September 2026 { "layer": "ots", "state": string, // "pending" | "attested" "digest": string, // the anchored value "submitted_at": string, // RFC 3339 "calendars": array, "proof": string OPTIONAL, // base64 OTS proof bytes "proof_uri": string OPTIONAL, "observed_height": integer OPTIONAL, "observed_time": string OPTIONAL } ], "ipfs": { "state": string, "cid": string OPTIONAL, "gateways": array OPTIONAL }, "archival": { "state": string, "doi": string OPTIONAL, "record_url": string OPTIONAL, "repository": string OPTIONAL }, "web_archive": { "state": string, "snapshots": array OPTIONAL }, "checkpoints": array OPTIONAL, // Checkpoint refs, Section 11.3 "envelope_updated": string // RFC 3339 } The Envelope MUST carry core_digest. A Verifier MUST recompute the Core digest and confirm it matches before relying on any Envelope field. An Envelope whose core_digest does not match its Core is discarded, not repaired. Envelope contents are not signed and carry no authority of their own. Every Envelope claim is verified against the layer it names: an anchors entry is verified by checking the proof, an ipfs entry by resolving the CID, an archival entry by resolving the identifier. A Verifier MUST NOT accept an Envelope assertion it did not check. Revision -01 required Producers to store raw OTS receipt bytes but provided no ER field to carry them, while its verification procedure required a Verifier to parse those bytes. The "proof" and "proof_uri" members close that gap. At least one of them MUST be present for any anchor in state "attested". Reilly Expires 8 March 2027 [Page 22] Internet-Draft Reilly Government Integrity Protocol September 2026 10.3. Field Notes * URIs MUST conform to [RFC3986]. * Timestamps MUST be RFC 3339 [RFC3339] with a UTC offset of Z. * Hexadecimal digest values MUST be lowercase. * In commitment mode, subject.title, content.byte_length, and content.ni MUST be omitted, since each leaks Artifact information that defeats the commitment. Revision -01 had no commitment mode and therefore no such rule. * Signatures MUST use COSE_Sign1 [RFC9052], a CBOR [RFC8949] structure. Ed25519 [RFC8032] is RECOMMENDED for current deployments. Section 19 addresses migration. * The -01 security.binding_hash field is removed. It was a SHA-256 over three values already covered by the chain construction and added no detection capability that Section 7.6 does not provide. 10.4. Version and Compatibility The er_version is "3". Revision -00 issued version "1" and -01 issued version "2". The Core and Envelope split, the entangled chain values, and the mode field are not backward compatible with version "2": a version 2 ER cannot be verified under this document, and a version 3 ER cannot be verified under -01. A Producer migrating an existing chain MUST NOT recompute historical blocks under the new construction, which would destroy the correspondence between those blocks and their existing anchors. Instead the Producer MUST issue a Hash Migration Bridging Record (Section 15) at the transition, carrying the last -01 Cross-Chain Hash as an input to the first Braid computed under this document. 11. Permanence Layer Stack 11.1. Anchor States Every anchor is in one of two states. pending: The digest has been submitted to a calendar or aggregator and a receipt has been returned. A pending anchor evidences submission only. It does not establish that the digest existed at any particular time, because no public consensus record has committed to it. Revision -01 used Reilly Expires 8 March 2027 [Page 23] Internet-Draft Reilly Government Integrity Protocol September 2026 the same "pending" label but described the result as a timestamp throughout, which overstates it. attested: The proof resolves through an aggregation path to a committed public consensus record whose observed time bounds the digest's existence. A Producer MUST NOT present a pending anchor as evidence of time in any user-facing output, report, or API response. A Verifier MUST treat an anchor in state "pending" as absent for the purpose of Section 13. 11.2. Timestamp Anchoring via OpenTimestamps The core_digest of the ER Core MUST be submitted to one or more OpenTimestamps [OTS] calendar servers. Submission to at least three independent calendars is RECOMMENDED, so that the loss or discontinuation of one operator does not leave the record without a path to attestation. Revision -01 anchored the Artifact SHA-256 digest. This revision anchors the Core digest, which commits to the Artifact digests, the chain values, the REMID, and the event metadata together. Anchoring the Artifact digest alone left the surrounding record unanchored, including the timestamp the record asserted for itself. A Producer MAY additionally anchor the Artifact digest where a bare content timestamp is independently useful, except where Section 20 prohibits it. Calendar servers aggregate submissions into a Merkle tree and commit the root to a Bitcoin transaction. Once a block confirms the commitment, the proof is upgraded to include the full path from the submitted digest to the block header. The Producer MUST then parse the observed height and time, set the anchor state to "attested", and update the Envelope. The Core is not modified. Merkle inclusion proofs used by RGIP-defined constructions, as distinct from those internal to the OTS layer, MUST use the construction of [RFC9162], including its distinct leaf and interior node prefixes, and MUST NOT duplicate a leaf to balance a tree. 11.3. Chain Checkpoint Anchoring This section is new in -02 and supplies the property -01 asserted but did not construct. A Checkpoint commits to a Chain Head: Reilly Expires 8 March 2027 [Page 24] Internet-Draft Reilly Government Integrity Protocol September 2026 checkpoint_digest = SHA-256( ENC("RGIP/2/checkpoint", chain_id, idx, b256(idx), b3(idx), bb3(idx), created) ) where idx is the index of the highest block covered. A Producer MUST submit Checkpoints to the timestamp layer on a published cadence, and MUST publish each Checkpoint together with its proof and the block index it covers. A cadence no longer than 24 hours is RECOMMENDED for general deployments. Deployments where ordering is contested, such as procurement or election administration, SHOULD checkpoint at every phase boundary in addition to the periodic cadence. What a Checkpoint establishes: every block at or below the covered index held the content it now holds no later than the Checkpoint's observed time. A Producer cannot subsequently insert, remove, or reorder any block in that range without producing a Chain Head that fails to match the anchored Checkpoint. What it does not establish: anything about blocks added after the Checkpoint, which remain reorderable until the next one. The ordering guarantee is therefore granular to the cadence, and a deployment's cadence is itself a material disclosure. Producers MUST publish their cadence. Verifiers evaluating an ordering claim MUST identify the first attested Checkpoint covering the block in question and MUST state the ordering conclusion relative to that Checkpoint's observed time rather than to the block's asserted created value. 11.4. Decentralized Storage via IPFS The Artifact and its ER SHOULD be pinned to IPFS [IPFS-SPEC], yielding a CID that is a self-describing multihash [MULTIHASH]. The CID is recorded in the Envelope, with at least one resolving gateway. Pinning is not permanence. A CID resolves only while at least one node serves the content, so a Producer MUST verify pin liveness on a published schedule and MUST treat a lapsed pin as a degraded layer under Section 16. A Producer MUST NOT pin Artifacts in commitment mode, or any Artifact excluded by Section 20. 11.5. Archival Deposit and DOI Issuance Artifacts SHOULD be deposited with a repository that issues a persistent identifier and commits to long-term preservation. Zenodo, operated by CERN, is RECOMMENDED for openly publishable records on the basis of its preservation commitment and its independence from Reilly Expires 8 March 2027 [Page 25] Internet-Draft Reilly Government Integrity Protocol September 2026 the depositing agency. Agencies subject to a statutory records schedule SHOULD additionally deposit with the archival authority of record for their jurisdiction; such deposit is complementary to, not a substitute for, deposit with an independent repository, since the archival authority may be within the same governmental structure as the record's subject. The identifier and record URL are recorded in the Envelope. Producers MUST use current repository URL forms and MUST NOT emit legacy path forms in published records. 11.6. Web Archival The REMID resolver URL SHOULD be submitted for web archival, which creates an independent crawl of the public-facing record page. Snapshot URLs are recorded in the Envelope. Web archival covers the resolver page, not the Artifact bytes, and MUST NOT be counted as an Artifact copy for the purposes of Section 13. 12. Step-by-Step Implementation (Normative) Step 1: Prepare the Artifact 1. Determine the canonical byte stream per Section 6. 2. Compute the Fingerprint under SHA-256, SHA3-512, and BLAKE3-256. 3. Determine the anchoring mode. If the Artifact is access-controlled, low-entropy, or otherwise within Section 20's prohibition, the mode is "commitment"; otherwise "artifact". 4. In commitment mode, generate a fresh salt per value and compute Field Commitments per Section 9. Retain salts under the controls applicable to the Artifact. Step 2: Assign a REMID 5. Determine the UTC submission date. 6. Derive the base REMID per Section 8.1, applying Section 8.2 if the base form is already issued for that date on that chain. Step 3: Compute Chain Values 7. Retrieve the prior Braid. For the Genesis Block, use the all-zeros Braid of Section 7.5. Reilly Expires 8 March 2027 [Page 26] Internet-Draft Reilly Government Integrity Protocol September 2026 8. Generate a record_id. UUID v4 [RFC9562] is RECOMMENDED. 9. Record the creation timestamp in RFC 3339 [RFC3339] UTC. 10. Encode the block inputs per Section 6 and compute L256, L3, and Lb3 per Section 7.3. 11. Compute the Braid components per Section 7.4. Step 4: Build and Sign the Core 12. Populate the ER Core per Section 10.1. 13. Serialize the Core without its "sign" member per JCS [RFC8785] and compute the core_digest. 14. Create a COSE_Sign1 [RFC9052] over that serialization and place it, with its algorithm and key identifier, in "sign". Step 5: Anchor 15. Submit the core_digest to at least three OTS calendars. Record the submission time, calendars, and receipt in the Envelope with state "pending". Step 6: Distribute 16. Unless prohibited by Section 20, pin the Artifact and ER to IPFS and record the CID and gateways. 17. Unless prohibited by Section 20, deposit the Artifact for archival and record the identifier and record URL. 18. Submit the REMID resolver URL for web archival and record the snapshots. Step 7: Publish 19. Publish the ER. The archival landing page and the resolver SHOULD link each other. Step 8: Attest 20. Poll for proof upgrades. On upgrade, parse the observed height and time, set the anchor state to "attested", attach the proof bytes or a proof URI, and update envelope_updated. The Core is never modified. Reilly Expires 8 March 2027 [Page 27] Internet-Draft Reilly Government Integrity Protocol September 2026 Step 9: Checkpoint 21. On the published cadence, and at any phase boundary the deployment defines, compute the checkpoint_digest per Section 11.3, submit it, and publish the Checkpoint with its covered block index. Track it to attestation as in Step 8. 13. Verification Procedure (Normative) A Verifier MUST perform the following. 1. Retrieve the ER. Confirm er_version is "3" and alg_suite is implemented. If not, stop and report the ER as unverifiable under this document rather than attempting a reduced check. 2. Recompute the Core digest per Section 10.1 and confirm the Envelope's core_digest matches. 3. Verify the COSE_Sign1 signature over the JCS serialization of the Core without "sign", using a key obtained through a channel independent of the ER. 4. If mode is "artifact": recompute the Fingerprint of the retrieved Artifact and confirm all three digests match content.sha256, content.sha3_512, and content.blake3_256. If mode is "commitment": confirm the Fingerprint positions are well-formed commitments and verify only those fields for which a value and salt have been disclosed. 5. Recompute the Links and Braid per Section 7.6 and confirm all six values, and confirm linkage to the prior block. 6. Re-derive the base REMID and confirm subject.remid is the base form or a disambiguated form of it per Section 8.2. 7. For each anchor: parse the proof, confirm the path connects the stated digest to a block header, confirm that header is present in the public chain at the stated height, and confirm the anchored digest equals the core_digest. An anchor in state "pending" is treated as absent. 8. Identify the earliest attested Checkpoint covering this block index. Confirm the Checkpoint's committed Chain Head matches the Braid recomputed for that index. Record its observed time as the bound on the block's construction. 9. Resolve the CID through a gateway not operated by the Producer and confirm the returned bytes reproduce the Fingerprint. Reilly Expires 8 March 2027 [Page 28] Internet-Draft Reilly Government Integrity Protocol September 2026 10. Resolve the archival identifier and confirm the landing page serves the same Artifact. 11. Confirm the REMID is not listed in the Revocation Registry (Section 14.2), and if it is, report the revocation with the record rather than suppressing either. 12. Confirm all timestamps are well-formed RFC 3339 UTC and that event.created is not later than the earliest attested anchor's observed time. A created value later than its own attestation is a contradiction and MUST fail verification. Reporting A Verifier MUST report per-check results rather than a single boolean. A record is reported as verified only if steps 2 through 8 pass. Steps 9 and 10 establish retrievability; their failure downgrades the report to "verified, not retrievable" rather than failing it, since a valid record can outlive a hosting layer. Revision -01 stated that a record "MAY be considered unverified if fewer than two layers return consistent results", which left the threshold to the Verifier and permitted a record with no attested anchor to be reported as verified. That guidance is withdrawn. A record with no attested anchor MUST NOT be reported as timestamped under any threshold. 14. Amendment, Supersession, and Revocation 14.1. Amendment Records An amendment MUST create a new Artifact, a new REMID, and a new block, with event_type "amend" and event.supersedes set to the REMID of the record amended. The original block is never modified or removed. Revision -01 placed the prior REMID in subject.artifact_uri, conflating a supersession relationship with a retrieval location; event.supersedes replaces that use. A resolver serving a superseded REMID MUST serve the original record and MUST indicate the supersession, rather than redirecting to the amendment. Silently serving the amendment in place of the original defeats the purpose of anchoring the original. 14.2. Revocation Registry Records are withdrawn, corrected under seal, or issued in error. Revision -01 had no mechanism for this, so the only way to signal a withdrawal was to alter or remove the record, which the chain Reilly Expires 8 March 2027 [Page 29] Internet-Draft Reilly Government Integrity Protocol September 2026 forbids. A Producer MUST maintain a Revocation Registry: an append-only, chained series of blocks with event_type "revoke", each naming the REMID revoked, a reason code, and the effective time. Revocation blocks are anchored and checkpointed like any other. Revocation removes nothing. The revoked record remains in the chain and remains retrievable. Revocation asserts that the issuing body no longer stands behind the record, which is itself a record. A Verifier MUST surface a revocation alongside the record and MUST NOT treat revocation as a verification failure. 14.3. Retention and Disposition Government records are frequently subject to statutory retention schedules that require disposition at a defined time. A protocol built on irrevocable public layers is in tension with any such requirement, and -01 did not address it. Deployments subject to a disposition requirement MUST operate in commitment mode for the affected record categories and MUST NOT distribute the Artifact to public permanence layers. At disposition, the Producer destroys the Artifact and the associated salts under its normal procedure. The chain retains the block, the commitments, and the anchors, so the fact and timing of the record's existence survive disposition while its content does not. This property is called erasure-compatible permanence and is consistent with the treatment in [I-D.reilly-aigov]. Producers MUST record disposition as a "revoke" block with a reason code indicating scheduled disposition, so that the gap is documented rather than silent. Where a legal obligation requires removal of content already distributed to public layers, a Producer MUST document that the obligation cannot be fully satisfied for those layers, MUST request removal where a layer offers a mechanism, and MUST NOT represent removal as complete. Deployments SHOULD avoid this situation by classifying record categories before processing rather than after. 15. Hash Migration Bridging Records Hash functions are eventually deprecated. A chain that depends on a deprecated function cannot be recomputed under a replacement without destroying the correspondence between its blocks and its existing anchors. Reilly Expires 8 March 2027 [Page 30] Internet-Draft Reilly Government Integrity Protocol September 2026 A Bridging Record is a block with event_type "bridge" that binds a chain's state under an outgoing algorithm suite to its state under an incoming suite: bridge_digest = SHA-256( ENC("RGIP/2/bridge", chain_id, idx, old_suite, new_suite, old_head_values, new_head_values, created) ) where old_head_values is the ordered concatenation of the Chain Head components under the outgoing suite, and new_head_values the same under the incoming suite, both computed over the same block. Rules: * A Producer MUST NOT recompute historical blocks under a new suite. * A Bridging Record MUST be anchored and checkpointed under both suites where both remain operable. * A Verifier reaching a Bridging Record while walking backward switches to the outgoing suite for all earlier blocks and MUST report the suite under which each range was verified. * Deprecation of a suite does not invalidate blocks anchored under it before deprecation. A Verifier MUST report such blocks as verified under a deprecated suite rather than as failures. The same construction applies to the migration from the -01 Cross-Chain Hash to the Braid of Section 7.4, treating the last -01 Cross-Chain Hash as old_head_values. 16. Autonomous Agent Architecture RGIP deployments SHOULD run continuous verification agents. Revision -01 defined agents numbered 1 through 5, 5.5, 6, 7, 11, 13, and 14, a numbering that reflected an implementation's history rather than a specification. This revision names roles instead. 16.1. Agent Roles Fingerprint Agent: Computes the Fingerprint for each incoming Artifact. MUST produce all three digests before any downstream role runs. Identifier Agent: Derives the REMID and applies the collision rule of Section 8.2. Chain Agent: Reilly Expires 8 March 2027 [Page 31] Internet-Draft Reilly Government Integrity Protocol September 2026 Encodes block inputs per Section 6, computes the Links and Braid, and appends the block. Signing Agent: Serializes and signs the Core. MUST have access to signing keys that no other role has. Anchor Agent: Submits Core digests to the timestamp layer and records pending state. Checkpoint Agent: Computes and submits Checkpoints on the published cadence (Section 11.3). MUST run independently of the Anchor Agent so that a failure in per-record anchoring does not silently stop checkpointing. Distribution Agent: Performs IPFS pinning, archival deposit, and web archival submission, subject to the mode and to Section 20. Attestation Agent: Polls for proof upgrades and promotes anchors from pending to attested. A polling interval no longer than 15 minutes is RECOMMENDED. Persistence Agent: Stores ERs with integrity-checked reads. Sentinel Agent: Recomputes all six chain values for stored blocks per Section 7.6, verifies Envelope claims against their layers, and raises findings. MUST NOT modify records. Remediator Agent: Acts on findings within the limits of Section 16.2 and 16.3. Agents MUST run as independent processes or tasks with crash isolation, MUST handle asynchronous cancellation without leaving a block partially appended, and MUST NOT allow the failure of one role to suppress the findings of another. 16.2. Blast Radius and Oversight Every automated action is classified: BR0 Read-only. Verification, polling, reporting. Permitted in all modes. Reilly Expires 8 March 2027 [Page 32] Internet-Draft Reilly Government Integrity Protocol September 2026 BR1 Idempotent repair of a distribution layer: re-pinning a lapsed CID, resubmitting a web archival request, resubmitting a digest whose calendar submission was lost. Permitted in autonomous mode. BR2 Actions that create a new block: bridging records, supersession records. Permitted in supervised mode with recorded human approval. BR3 Actions that alter, delete, or reconstruct stored blocks, alter Envelope anchor state without a resolved proof, alter the Revocation Registry, or touch signing keys or salts. MUST NOT be automated in any mode. A deployment MUST declare its oversight mode and MUST record the mode in effect for each remediation taken. A Remediator MUST apply once-per-episode semantics: a finding that recurs after remediation escalates to human review rather than looping. Revision -01's self-heal agent had no such constraint and, as specified, would re-execute indefinitely against a persistent fault. 16.3. Prohibited Automated Actions Automated remediation of a chain integrity finding is prohibited. If the Sentinel Agent reports that a recomputed Link or Braid does not match its stored value, the only permitted automated response is to record the finding, halt appends to that chain, and escalate. The reason is that a chain integrity violation has exactly two causes: storage corruption or tampering. These are indistinguishable to the agent, and the repair appropriate to the first destroys the evidence of the second. In a system whose purpose is to detect alteration of government records, an agent that automatically restores chain consistency is an agent that automatically conceals tampering. Likewise prohibited without human authorization: promoting an anchor to attested without a resolved proof, issuing a revocation, destroying salts, and recomputing historical blocks. 17. Operational Considerations Key Management: Signing keys SHOULD be held in hardware meeting FIPS 140-3 Level 2 or higher for production government deployments. Keys SHOULD be rotated on a published schedule. Public keys and rotation history MUST be published through a channel independent of the ER distribution path, since a Verifier that obtains the key from the Reilly Expires 8 March 2027 [Page 33] Internet-Draft Reilly Government Integrity Protocol September 2026 same party that supplied the signature verifies nothing about authorship. Chain Continuity: A Producer MUST maintain an unbroken chain from Genesis. If the datastore is lost, chain state MAY be reconstructed by ordering persisted ERs by block index and recomputing values, but the reconstruction MUST be verified against the most recent attested Checkpoint before appends resume, and the reconstruction event MUST be recorded. Reconstruction that does not reproduce the checkpointed Chain Head is a chain integrity finding under Section 16.3, not a recoverable condition. Multiple Formats: If the same content is distributed in several formats, each format SHOULD receive its own block, since each has a distinct Fingerprint. The relationship between them SHOULD be expressed through event.supersedes or a profile-defined member, not by sharing a REMID. Calendar Redundancy: At least three independent calendars SHOULD be used per submission. Loss of one operator leaves proofs from the others independently valid. Profiles: A profile MAY restrict permanence layers, mandate specific COSE algorithms, define PKI discovery, or substitute a private timestamp service such as a Time-Stamp Protocol authority [RFC3161]. A profile that substitutes a private timestamp service MUST state plainly that it forfeits the independence property, since the anchor is then controlled by a party within the same trust boundary as the record's custodian. Interoperability with the Suite: RGIP shares its permanence methodology with [I-D.reilly-rem-protocol] and its evidence chaining approach with [I-D.reilly-banking-integrity]. A deployment operating more than one MAY share the timestamp and archival layers but MUST maintain separate chain identifiers and index spaces. 18. Security Considerations Chain Integrity: Integrity rests on collision resistance across the suite. A collision in one function does not yield a consistent chain, since each Link consumes the prior Braid under all three and the Braid is computed under all three (Section 7.4). Compromise of all Reilly Expires 8 March 2027 [Page 34] Internet-Draft Reilly Government Integrity Protocol September 2026 three is required to forge a chain that verifies. The Producer as Adversary: The threat model that motivates RGIP includes an operator who is also the record's subject. Against that adversary the chain and the signature provide nothing on their own, since the adversary controls both. Only the external layers constrain such an operator, and only through Checkpoints for ordering and attested anchors for time. Deployments SHOULD be evaluated on their Checkpoint cadence and layer independence, not on the presence of a chain. Anchor Semantics: An attested anchor bounds existence from above. It cannot bound it from below, cannot establish authorship, and cannot establish that the anchored record is the only version. Presenting an anchor as proof that a record is authentic overstates it. Key Compromise: Compromise of a signing key permits fraudulent Cores but does not permit alteration of existing anchors or Checkpoints. Producers MUST publish revocation metadata for compromised keys, and Verifiers MUST check that a signature's kid was valid at the block's attested time rather than at verification time. Replay and Substitution: Verifiers SHOULD retrieve Artifacts over authenticated TLS [RFC8446] and compare media type and length where available. The REMID binds identifier to content, and the Core binds content to chain position, limiting substitution. Denial of Service: Producers SHOULD rate-limit submissions per source to prevent chain flooding, and MUST NOT drop blocks silently when a rate limit engages, since a silent drop is indistinguishable from suppression. Salt Handling: In commitment mode, salts are the entire confidentiality boundary. Salt disclosure reveals the committed values; salt loss makes them permanently unverifiable. Salts MUST be stored separately from the ERs they protect. 19. Post-Quantum Considerations Revision -01 made claims this section corrects. SHA3-512: Reilly Expires 8 March 2027 [Page 35] Internet-Draft Reilly Government Integrity Protocol September 2026 Provides approximately 256-bit preimage resistance against Grover search [GROVER] and approximately 256-bit classical collision resistance. Revision -01 stated that SHA3-512 "is not weakened by quantum speedups that exploit SHA-2's Merkle-Damgard structure". No such quantum speedup is known; the structural distinction between Keccak [KECCAK] and Merkle-Damgard is relevant to length-extension behavior, which is a classical property, not a quantum one. The case for including SHA3-512 is algorithm diversity, not immunity to a quantum attack that has not been demonstrated. SHA-256: Provides approximately 128-bit preimage resistance under Grover and 128-bit classical collision resistance. Its inclusion is required for compatibility with the Bitcoin-based timestamp layer and is not a post-quantum measure. BLAKE3-256: Provides 128-bit classical collision resistance and approximately 128-bit preimage resistance under Grover. Revision -01 described it as providing "128-bit classical security (256-bit output truncated by Grover's algorithm to approximately 128-bit quantum resistance)", which conflates collision and preimage resistance and misstates both. Collision search: Quantum collision search offers limited practical advantage over classical birthday search once memory and hardware costs are accounted for. Deployments SHOULD NOT assume quantum adversaries halve collision resistance across the board. The unaddressed exposure: The hash layer is the more robust part of this design. The signature is not. Ed25519 [RFC8032] is broken by a cryptographically relevant quantum computer, and a break would let an adversary forge Cores for any period in which the corresponding key was valid. Attested anchors and Checkpoints limit the damage, because a forged Core cannot acquire a pre-existing anchor, but the signature layer, not the hash layer, is where migration is urgent. Producers SHOULD plan migration to a standardized post-quantum signature algorithm as standardization completes [NIST-PQC] and SHOULD use the alg_suite and Bridging Record mechanisms to record the transition. Revision -01 described post-quantum resilience as a property of the protocol; it is more accurately a property of the hash layer only. Migration: COSE [RFC9052] supports algorithm agility, so signature migration Reilly Expires 8 March 2027 [Page 36] Internet-Draft Reilly Government Integrity Protocol September 2026 does not require restructuring the ER. Hash suite migration follows Section 15. 20. Privacy Considerations Anchors and CIDs are public and permanent. Nothing submitted to those layers can be recalled. Producers MUST NOT anchor a raw digest of an Artifact that is access-controlled, classified, contains personal data, or is drawn from a candidate space small enough to enumerate. A digest is a commitment, and against low-entropy content a commitment is equivalent to disclosure for any adversary who can guess and check. Revision -01 stated that a SHA-256 digest "does not by itself reveal Artifact content", which holds only for high-entropy content and was the basis on which -01 recommended anchoring voter rolls and intelligence assessments directly. Those recommendations are withdrawn. For such Artifacts, Producers MUST operate in commitment mode (Section 9), MUST NOT pin or deposit the Artifact, and MUST hold salts under the controls applicable to the underlying content. ERs SHOULD carry the minimum metadata needed for identification and attribution. In commitment mode, subject.title and content length are omitted for the reason given in Section 10.3: a title frequently discloses more than the digest it accompanies. Metadata that survives commitment mode is still disclosure. The existence of a block, its time, its originator, and its cadence are visible even when content is not. For sensitive programs, the pattern of anchoring may reveal operational tempo. Section 5.5 applies. Personal data in publicly deposited government records is governed by the applicable disclosure regime. Where a subject has a statutory right to erasure, Section 14.3 applies, and the deployment MUST have classified the record before processing rather than seeking removal afterward. 21. Prior Art Record Function This section is informative and is not legal advice. A record produced under RGIP in "artifact" mode, deposited openly and anchored to a public timestamp layer, functions as a prior art record under 35 U.S.C. 102(a)(1) [USC-35-102]. Three elements combine: public accessibility is supplied by open archival deposit under a Reilly Expires 8 March 2027 [Page 37] Internet-Draft Reilly Government Integrity Protocol September 2026 persistent identifier and by content-addressed distribution; date corroboration is supplied by the attested anchor, observed by a party with no interest in the record; and content binding is supplied by the Fingerprint, which ties the corroborated date to an exact byte sequence rather than to a description. A record in "commitment" mode does not function as prior art with respect to its content, since the content is not publicly accessible. It establishes only that a commitment existed at a bounded time, and the content can be disclosed later to a specific party under Section 9. This distinction parallels the Full and Partial REM Record distinction in [I-D.reilly-rem-protocol] version -02. This specification is itself such a record. It is published as an Internet-Draft, deposited for archival, and anchored under the methodology it describes, and it is intended to serve as a defensive publication of the constructions it defines. Whether any particular record qualifies as prior art, and what weight it carries, is determined by the applicable forum under the applicable law. This document specifies a record format and does not determine that outcome. 22. IANA Considerations This document has no IANA actions. Should a future revision seek registration of the "REMID" URI scheme or of the domain separation tags of Section 6, those actions will be specified in that revision. 23. References 23.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, . Reilly Expires 8 March 2027 [Page 38] Internet-Draft Reilly Government Integrity Protocol September 2026 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . [FIPS202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, August 2015, Reilly Expires 8 March 2027 [Page 39] Internet-Draft Reilly Government Integrity Protocol September 2026 . [BLAKE3] O'Connor, J., Aumasson, J.-P., Neves, S., and Z. Wilcox-O'Hearn, "BLAKE3: One Function, Fast Everywhere", 2020, . 23.2. Informative References [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", 2016, . [IPFS-SPEC] Protocol Labs, "IPFS: Content Addressed, Versioned, P2P File System", 2014, . [MULTIHASH] Protocol Labs, "Multihash: Self-Describing Hash Functions", 2015, . [NIST-PQC] National Institute of Standards and Technology, "Post-Quantum Cryptography Standardization", 2024, . [GROVER] Grover, L. K., "A fast quantum mechanical algorithm for database search", Proceedings of the 28th Annual ACM Symposium on Theory of Computing, pp. 212-219, 1996. [KECCAK] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, "The Keccak reference, version 3.0", 2011, . [USC-35-102] United States Code, "Title 35, Section 102: Conditions for patentability; novelty", 2011. [I-D.reilly-rem-protocol] Reilly Expires 8 March 2027 [Page 40] Internet-Draft Reilly Government Integrity Protocol September 2026 Reilly, L. J., "Reilly EternaMark (REM) Protocol - Dual-Layer Digital Permanence Using DOI Archiving and Blockchain Timestamping", Work in Progress, Internet- Draft, draft-reilly-rem-protocol-02, 2026. [I-D.reilly-banking-integrity] Reilly, L. J., "Reilly Banking Integrity Protocol (RBIP)", Work in Progress, Internet-Draft, draft-reilly-banking-integrity-02, 2026. [I-D.reilly-aigov] Reilly, L. J., "Verifiable AI Governance and Data Privacy Records", Work in Progress, Internet-Draft, draft-reilly-aigov-00, 2026. [RGIP00] Reilly, L. J., "Reilly Government Integrity Protocol (RGIP)", DOI 10.5281/zenodo.17114518, September 2025. Appendix A. Changes from draft-reilly-government-integrity-01 Corrections to constructions * The SHA3-512-only Cross-Chain Hash is replaced by the entangled link-and-braid construction of Section 7. Each Link now consumes all three components of the prior Braid, and the Braid is computed under all three algorithms rather than SHA3-512 alone. The -01 construction made SHA3-512 the sole binding of three otherwise independent chains and therefore did not deliver the "all three simultaneously" property it claimed. * Section 6 defines a canonical, domain-separated, length-delimited encoding for all hashed inputs. Revision -01 concatenated variable-length UTF-8 fields without delimiters, permitting distinct field assignments to produce identical preimages. * BLAKE3 output length is fixed at 32 octets in the default hash mode. Revision -01 left it unspecified for an extendable-output function. * Section 10 splits the ER into a signed Core and a mutable Envelope. In -01 the signature covered permanence fields that change on anchor confirmation, so routine operation invalidated the signature over the record. * The anchored value is now the Core digest rather than the bare Artifact digest, so that chain position, REMID, and asserted time are covered by the anchor. Reilly Expires 8 March 2027 [Page 41] Internet-Draft Reilly Government Integrity Protocol September 2026 * record_id is a required ER Core field. It was consumed by the -01 chain hashes but absent from the -01 ER, making third-party recomputation impossible. * Envelope members "proof" and "proof_uri" carry the OTS proof bytes that -01 required Producers to store and Verifiers to parse but provided no field for. * Merkle inclusion proofs in RGIP-defined constructions are specified under [RFC9162], which obsoletes the RFC 6962 construction cited by -01. * security.binding_hash is removed as redundant with Section 7.6. * chain.quantum_resilient is replaced by core.alg_suite, since a Verifier can check the latter and cannot check the former. * Section 8.2 replaces the -01 collision rule, which directed implementations to append hash characters and thereby contradicted the determinism the same section asserted. * Section 8.3 restates the REMID collision bound as a birthday bound. Revision -01 gave the per-pair figure of 1 in 2^32. New material * Section 11.3, Chain Checkpoint anchoring. Revision -01 anchored only artifact digests, so nothing external committed to chain state and the -01 claim that record sequence could not be forged did not hold. * Section 9, salted Field Commitments and selective disclosure, together with commitment mode throughout. * Section 14.2, the Revocation Registry, and Section 14.1's use of event.supersedes in place of the -01 overloading of subject.artifact_uri. * Section 14.3, retention and disposition, addressing statutory records schedules and erasure-compatible permanence. * Section 15, Hash Migration Bridging Records, including the bridge from the -01 Cross-Chain Hash to the Braid. * Section 16.2 and 16.3, blast radius classification and the prohibition on automated remediation of chain integrity findings. The -01 self-heal agent was unconstrained and would have been permitted to overwrite evidence of tampering. Reilly Expires 8 March 2027 [Page 42] Internet-Draft Reilly Government Integrity Protocol September 2026 * Section 5.7, constraints common to all use cases, and Section 21, the prior art record function under 35 U.S.C. 102(a)(1). Withdrawn or narrowed claims * The -01 recommendation to process voter registration files and intelligence assessments with raw digest anchoring is withdrawn (Sections 5.5, 5.6, 20). A digest of low-entropy content is equivalent to disclosure against an adversary who can enumerate. * The -01 assertion of a quantum speedup exploiting SHA-2's Merkle-Damgard structure is withdrawn; no such result is known (Section 19). * The -01 characterization of BLAKE3's security levels is corrected; it conflated collision and preimage resistance. * Post-quantum resilience is scoped to the hash layer, with the signature layer identified as the unaddressed exposure. * The -01 verification guidance permitting a record to be considered verified on a two-of-N layer threshold is withdrawn. A record with no attested anchor is not timestamped under any threshold (Section 13). * "Self-sovereign" is replaced by "content-derived" in describing the REMID. Editorial * Internal cross-references corrected throughout. Revision -01 referred to Sections 5.1 through 5.3 for chain hash definitions located in 6.1 through 6.3, to Section 6 for the REMID located in Section 7, to Section 7 for the ER model located in Section 8, and to Sections 8.3 and 8.4 for permanence subsections located in 9.3 and 9.4. The -01 change log carried the same errors. * Duplicated passages in the -01 Section 9.1, Section 15, the MULTIHASH reference, and the -01 change log are removed. * The Introduction's repeated statement of the anchoring premise is consolidated. * Agent roles are named rather than numbered, removing the -01 sequence 1, 2, 3, 4, 5, 5.5, 6, 7, 11, 13, 14. * er_version is incremented from "2" to "3". Reilly Expires 8 March 2027 [Page 43] Internet-Draft Reilly Government Integrity Protocol September 2026 Acknowledgments The author thanks the IETF community for review and discussion. Author's Address Lawrence J. Reilly REM Technologies & Consulting, LLC United States of America Email: lreilly250@gmail.com Reilly Expires 8 March 2027 [Page 44]