Summary

  • RGIP revision 02 replaces revision 01’s broadly empowered self-heal agent with four blast-radius classes and declared oversight modes.
  • Idempotent repairs to a distribution layer may run autonomously once; a recurring fault must go to human review instead of looping.
  • A Link or Braid mismatch is different: automation may only record the finding, halt new appends to that chain and escalate, because corruption and tampering look the same to the agent.
  • This is an individual Internet-Draft, not an IETF standard or deployment report. The missing evidence is running code and test vectors that prove the stop rule under both fault and attack conditions.

A maintenance feature became an authority question

The I-D announcement records revision 02 of the Reilly Government Integrity Protocol on 4 September 2026. The proposal describes a pipeline for making public records independently verifiable through multiple hashes, external timestamp anchors, distributed copies and archives. Its examples span legislation, procurement, budgets, courts, elections and other government records.

The most important governance change is not another hash. The revision says that its predecessor left automated action too broad. Revision 01 assigned Agent 11 to scan degraded permanence layers and re-execute the responsible agent. A Sentinel recomputed chain values and raised alerts. An Intelligence agent generated findings and remediation directives and sent them to the self-heal function. The architecture was presented as continuous integrity assurance without continuous human oversight.

That arrangement combined three powers: observe an anomaly, decide what it meant and change the system that contained the evidence. The text did not put chain-integrity findings outside the self-heal agent’s reach. A persistent fault could therefore trigger repeated repair attempts. Even if every component acted exactly as intended, the design lacked a stopping condition that another verifier could audit.

Revision 02 treats this as a defect, not a minor clarification. It replaces the general self-heal role with a read-only Sentinel and a bounded Remediator. The Sentinel must not modify records. The Remediator receives findings, but its permission depends on what an action can change.

Four classes separate retry from rewriting history

The new section 16 creates a blast-radius ladder. BR0 covers verification, polling and reporting. Those actions are read-only and are allowed in every oversight mode. BR1 covers idempotent repair of a distribution layer—for example re-pinning content or resubmitting an archive request without changing the signed record. This class may be autonomous.

BR2 covers an action that creates a new block or changes externally visible protocol state, such as a bridge or supersession record. It is supervised and requires recorded human approval. BR3 reaches the evidence itself: altering, deleting or reconstructing stored blocks, changing an anchor state without proof, changing the revocation registry, or touching keys and salts. That class must not be automated.

The labels matter because they make authority depend on effect rather than on which software component asks. A retry that reconstructs no evidence is not treated like a repair that rewrites the history against which evidence will later be judged. Deployments are also told to declare their oversight mode and record the mode used for every remediation.

The draft adds a second restraint called once-per-episode. If one permitted remediation does not clear the finding, the next occurrence goes to human review. An agent cannot continue re-executing a repair against the same unresolved condition. This is a small operational rule with a large institutional effect: retry policy becomes a visible limit on delegated power.

At the chain boundary, “repair” is the wrong verb

The strictest instruction applies when the Sentinel recomputes a Link or Braid and gets a value different from the one stored. Automated remediation is prohibited. The only machine response is to record the finding, halt further appends to that chain and escalate.

The reason is epistemic. A storage error and deliberate alteration can produce the same verification symptom. The agent cannot know which one it is seeing. Restoring the value that makes a corrupt store consistent may be correct maintenance; applying the same operation after tampering can remove the trace investigators need. A system built to expose alteration defeats itself if its first response to alteration is to make the chain look clean again.

This distinction appears elsewhere in the revision. An evidence-envelope claim must be checked against the layer it describes rather than accepted as self-authenticating. After datastore loss, a reconstructed chain must reproduce an attested checkpoint before appends resume. If it does not, the result is an integrity finding—not an ordinary recoverable state. The draft also withholds autonomous authority to attest an anchor without proof, issue a revocation, destroy salts or recompute historical blocks.

These rules align with older evidence-handling discipline without deriving their standing from it. RFC 3227, a Best Current Practice on evidence collection and archiving, advises investigators to minimise changes to collected data, collect before analysing, and document how evidence was discovered, handled and transferred. NIST SP 800-86 likewise places forensic technique inside incident response rather than treating an altered production copy as the only source of truth. RFC 4810 describes long-term evidence records and calls for modifications—including administrator modifications—to be detectable.

None of those documents endorses RGIP. They supply a useful external test: recovery and evidence preservation are separate jobs. The copy used to restore service need not be the untouched copy used to explain what happened.

The draft has no institutional authority to settle legal effect

Datatracker labels RGIP an active individual Internet-Draft. Anyone may submit one. It is not endorsed by the IETF, has no formal standing in the standards process, no RFC stream and no responsible Area Director. Its own introduction says legal admissibility, authority and dispositive effect belong to the applicable forum, not to the specification.

That caveat is essential for a protocol about government records. A hash can show that two byte strings differ. A timestamp can support a claim that certain data existed before a time. Neither decides whether an official had authority, whether a retention order was lawful, whether evidence is admissible, or which record controls after an amendment. Technical control over a ledger is not legal jurisdiction over its contents.

The draft is also a design proposal, not operational evidence. The reviewed text does not publish a test-vector section, reference implementation, deployment report or interoperability result. NIST SP 800-61r3 provides current incident-response context, but it does not fill that evidence gap. A good rule on paper still needs fault injection, independent implementations and auditable recovery exercises.