Network Working Group L.J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational Expires: February 25, 2027 August 24, 2026 Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience draft-reilly-resilience-protocol-02 Abstract The Reilly Resilience Protocol (RRP) standardizes a verifiable method to prove that IT systems, cloud infrastructures, and AI pipelines are continuously exercised and resilient. RRP transforms resilience claims into cryptographically signed, tamper-evident evidence persisted in immutable storage and batched into a daily Merkle root that is publicly time-anchored. The protocol outputs an executive Resilience Scorecard backed by independently verifiable cryptographic receipts. RRP composes with the Reilly EternaMark (REM) protocol to ensure dual-layer digital permanence using both DOI archival and blockchain timestamping. This document supersedes draft-reilly-resilience-protocol-01. It corrects the Merkle tree construction of -01, which duplicated the final leaf of an odd-cardinality set and incorrectly attributed that construction to RFC 9162. It further addresses the principal structural gap of -01, namely that the protocol proved the integrity of the evidence that was produced but could not prove that any particular evidence was ever required to exist. This revision adds the Evidence Continuity Chain, the Control Coverage Attestation, field-level commitments with selective disclosure, governed autonomous remediation with blast-radius classes, hash and signature migration for long retention horizons, a coverage factor and weight renormalization rule in the scoring algorithm, and an implementation status section describing running code. The foundational whitepaper underpinning this work (Reilly Resilience Protocol Whitepaper v2) is permanently archived at: DOI: 10.5281/zenodo.17100703 https://zenodo.org/records/17100703 That document was blockchain timestamped and DOI archived on September 11, 2025, at the time of its upload to Zenodo, providing cryptographic attestation of its existence and integrity as of that date. The initial IETF submission (draft-reilly-resilience- protocol-00) was recorded in the IETF Datatracker on September 27, 2025. 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 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 February 25, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Addressed by This Revision . . . . . . . . . . . 5 1.2. Implementation Status . . . . . . . . . . . . . . . . . 6 2. Conventions Used in This Document . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Principles . . . . . . . . . . . . . . . . . . . . 11 5. Architecture Overview . . . . . . . . . . . . . . . . . . . 13 5.1. Roles and Responsibilities . . . . . . . . . . . . . . 13 5.2. Data Flow . . . . . . . . . . . . . . . . . . . . . . . 16 6. Evidence Schema . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Evidence Record Structure . . . . . . . . . . . . . . . 17 6.2. Control Result Codes . . . . . . . . . . . . . . . . . 20 6.3. Canonical Serialization . . . . . . . . . . . . . . . . 21 6.4. Field Commitments and Selective Disclosure . . . . . . 22 6.5. Version Compatibility . . . . . . . . . . . . . . . . . 25 7. Cryptographic Operations . . . . . . . . . . . . . . . . . 25 7.1. Evidence Signing . . . . . . . . . . . . . . . . . . . 25 7.2. Merkle Tree Construction . . . . . . . . . . . . . . . 26 7.3. Anchoring . . . . . . . . . . . . . . . . . . . . . . . 29 7.4. Evidence Continuity Chain . . . . . . . . . . . . . . . 31 7.5. Hash and Signature Migration . . . . . . . . . . . . . 34 8. Key Management . . . . . . . . . . . . . . . . . . . . . . 36 9. Operational Procedures . . . . . . . . . . . . . . . . . . 38 9.1. Control Definition and the Control Register . . . . . . 38 9.2. Evidence Collection . . . . . . . . . . . . . . . . . . 41 9.3. Signing and Storage . . . . . . . . . . . . . . . . . . 42 9.4. Aggregation and Anchoring . . . . . . . . . . . . . . . 43 9.5. Control Coverage Attestation . . . . . . . . . . . . . 45 9.6. Scorecard Publication . . . . . . . . . . . . . . . . . 47 9.7. Independent Verification . . . . . . . . . . . . . . . 48 9.8. Autonomous Remediation and Human Oversight . . . . . . 50 10. Resilience Scorecard Specification . . . . . . . . . . . . 54 10.1. Pillars, Weights, and Renormalization . . . . . . . . . 54 10.2. Scoring Algorithm . . . . . . . . . . . . . . . . . . . 56 10.3. Score Decay . . . . . . . . . . . . . . . . . . . . . . 58 10.4. Band Assignment and Hysteresis . . . . . . . . . . . . . 59 11. Compliance Mapping . . . . . . . . . . . . . . . . . . . . 60 12. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 63 12.1. Adversary Classes . . . . . . . . . . . . . . . . . . . 63 12.2. Attack Scenarios and Mitigations . . . . . . . . . . . 64 13. Security Considerations . . . . . . . . . . . . . . . . . . 69 14. Relationship to Other Protocols in the Suite . . . . . . . 74 15. Implementation Guidance . . . . . . . . . . . . . . . . . . 77 16. Prior Art and Defensive Publication . . . . . . . . . . . . 80 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 81 18. References . . . . . . . . . . . . . . . . . . . . . . . . 83 18.1. Normative References . . . . . . . . . . . . . . . . . 83 18.2. Informative References . . . . . . . . . . . . . . . . 85 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . 89 Appendix B. Worked Continuity Verification Example . . . . . . 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 1. Introduction Organizations routinely assert claims of "high availability," "recoverability," and "regulatory compliance," yet significant service outages, failed backup restores, configuration drift, and silent AI model degradation continue to occur with alarming frequency. Traditional monitoring logs and dashboard indicators are vulnerable to post-hoc modification, incomplete capture, or absence of objective time-validity proofs. A log that shows 99.9% uptime provides no cryptographic guarantee that the log itself was not modified after the fact. RRP closes this trust gap by producing daily, tamper-evident proof that critical resilience controls executed successfully. The protocol mandates that all evidence be cryptographically signed, persisted in Write-Once-Read-Many (WORM) or equivalent immutable storage, and anchored for independent time attestation. The protocol is designed for three primary audiences: 1. Operators: DevOps, SRE, and security teams who run and automate the actual resilience checks, sign evidence, and maintain the evidence store. 2. Executives: CISOs, CIOs, and board-level stakeholders who consume the Resilience Scorecard and need assurance without burdening themselves with cryptographic details. 3. Auditors and Regulators: Independent third parties who need to re-derive and verify every resilience claim without trusting any single vendor or organizational assertion. RRP is intentionally designed to be composable with existing monitoring systems, CI/CD pipelines, and cloud-native tooling. Implementers are expected to wrap existing check outputs to produce canonical RRP evidence records rather than replace their monitoring stacks wholesale. The whitepaper from which this protocol is derived, "The Reilly Resilience Protocol (RRP): A Tamper-Evident, Blockchain-Anchored Framework for Proving IT, Cloud, and AI System Resilience" (Reilly Resilience Protocol Whitepaper v2), is permanently archived under: DOI: 10.5281/zenodo.17100703 https://zenodo.org/records/17100703 The whitepaper was blockchain timestamped and DOI archived on September 11, 2025, the date of its upload to Zenodo. This blockchain attestation cryptographically proves the document's existence and integrity as of that date and constitutes timestamped prior art for all protocol concepts described herein. See Section 16 for the treatment of RRP evidence as prior art records under 35 U.S.C. 102(a)(1) [USC-35-102], consistent with [DRAFT-REM-02]. 1.1. Problem Addressed by This Revision Revisions -00 and -01 established that an evidence record, once produced and signed, cannot be altered without detection. That property is necessary but not sufficient. An assurance system that proves only the integrity of the records it holds is defeated by an adversary who arranges for damaging records never to be created, or who removes an entire aggregation window rather than a record within one. Concretely, -01 admitted the following: Silent omission: A Control that never executed produced no evidence record. Nothing in -01 required an implementation to state, in signed and anchored form, which Controls were supposed to run. A Scorecard could therefore report a perfect score over the two Controls that ran while eight others were quietly disabled. Section 10.3 of -01 mitigated this only for Controls already known to the Scorecard Generator, which is precisely the set an adversary would edit. Whole-window deletion: Each aggregation window in -01 produced an independent Merkle root with no cryptographic linkage to the preceding window. Removing a bad day removed all trace of that day. Nothing in the surviving anchors was inconsistent with the deletion. Empty-window silence: Section 7.2, step (2) of -01 directed that no anchor be produced when a window contained zero records, and required only a local log entry. The absence of an anchor was therefore indistinguishable from the suppression of one. Unusable privacy posture: Section 13.4 of -01 required that evidence records exclude PII and that sensitive artifacts be encrypted, but offered no mechanism by which a specific field could be disclosed to an auditor while the remainder stayed confidential. In practice this pushes implementers toward publishing more than they should, or toward withholding records entirely. Ungoverned self-healing: -01 was silent on automated remediation. Deployed resilience systems increasingly remediate autonomously, and an unbounded remediator can both cause harm and mask the very failures the protocol exists to record. Merkle construction defect: Section 7.2, step (3) of -01 duplicated the final digest when the leaf count was odd, and cited [RFC9162] as the basis. [RFC9162] and [RFC6962] do not duplicate; they promote the odd node. Duplication admits distinct leaf sets that produce identical roots, the malleability class exploited in CVE-2012-2459 against Bitcoin's tree, and it breaks the append-only structure that consistency proofs depend on. This revision closes each of the above. The central design commitment added in -02 is that an RRP deployment MUST make its own expectations verifiable: the set of Controls that were required to run is itself signed, anchored, and chained, so that the absence of evidence becomes evidence of absence. 1.2. Implementation Status This section is to be removed before publication as an RFC, in accordance with the guidance of [RFC7942]. The mechanisms in this revision were developed against running deployments rather than on paper. At the time of writing: o A continuity-chained, agent-driven measurement instrument operates a nine-agent pipeline performing live DNS, HTTPS, and digest checks against a constellation of eight production endpoints and eight external permanence anchors, with hash-linked epoch records, an operator decision queue, and an autonomous versus human-oversight mode toggle. The anchor layer distinguishes live, dynamic, and immutable expectations and forces immutability violations to human review even when the instrument is in autonomous mode. This deployment is the direct source of the Anchor Expectation semantics in Section 7.3 and the Coverage Attestation in Section 9.5. o A separate rotation-based instrument has committed and chain-verified more than 2,200 epochs, and a second has exceeded 22,000 epochs. Operating experience with the second instrument produced the hysteresis requirement in Section 10.4 and the remediation circuit breaker in Section 9.8: an early build entered a state in which a sentinel agent re-executed the same remediation on every epoch without ever clearing the underlying condition, which is the failure mode those two mechanisms exist to prevent. o A keyless archival mesh operating alongside blockchain anchoring supplies the third anchor class described in Section 7.3. Implementers are cautioned that these are reference deployments operated by the author and have not been subject to independent security review. 2. Conventions Used in This Document 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. The notation H(x) denotes SHA-256 [FIPS180-4] applied to the octet string x, unless a migration under Section 7.5 has replaced the active hash function. The symbol || denotes octet string concatenation. Hex encoding is lowercase throughout. 3. Terminology The following terms are defined for the purposes of this document. Terms introduced in this revision are marked "(new in -02)". Aggregate Manifest: A signed document produced at the close of an aggregation window enumerating the evidence records included in that window, the records excluded and why, the resulting Merkle root, the digest of the corresponding Control Coverage Attestation, the anchor receipts obtained, and the digest of the preceding Aggregate Manifest. Anchor Receipt: A cryptographic proof returned by an anchoring operation which ties a specific digest to an externally verifiable position in time, such as a blockchain transaction identifier and block height, a DOI registration, or a dated archival capture. Anchor Expectation: (new in -02) A declaration of the expected mutability class of an anchoring target, one of "live", "dynamic", or "immutable". A target declared immutable that is observed to have changed constitutes an integrity finding and MUST be escalated to human review irrespective of Autonomy Mode. Autonomy Mode: (new in -02) The operating posture of a Remediator with respect to automated action, one of OBSERVE, SUPERVISED, or AUTONOMOUS. See Section 9.8. Blast Radius Class: (new in -02) A classification, BR0 through BR3, of the potential scope of harm of a remediation action. See Section 9.8. Blockchain Timestamping: The process of publishing a cryptographic digest or Merkle root to a public blockchain, thereby establishing that the committed data existed no later than the block in which the commitment appears. This is distinct from a claim of authorship; it is a claim of existence-by-time. Collector: A software agent or automated process responsible for executing a specific resilience control check and emitting a normalized evidence record conforming to the RRP evidence schema defined in Section 6. Commitment Root: (new in -02) The Merkle root computed over the salted per-field commitments of an evidence record operating in commitment mode. See Section 6.4. Control: A defined, measurable resilience check with associated SLOs. Examples include database backup restore verification, TLS certificate expiry checks, AI model drift scans, and network partition recovery tests. Control Coverage Attestation (CCA): (new in -02) A signed statement, produced once per aggregation window, enumerating every Control in the Control Register that was expected to execute in that window, the number of valid evidence records observed for each, and the resulting coverage ratio. The CCA is what makes omission detectable. See Section 9.5. Control Register: (new in -02) The authoritative, versioned, signed list of Controls an implementation asserts it operates, together with each Control's Pillar assignment, schedule, SLO, and compliance mappings. Changes to the Control Register are themselves evidence and MUST be recorded and anchored. DOI Archival: The process of registering a document or dataset with a Digital Object Identifier (DOI) through a recognized DOI registration agency (such as Zenodo/DataCite), providing a persistent, resolvable identifier that anchors the artifact in a citeable, academically recognized registry. Dual-Layer Digital Permanence: A term originating in the work of L.J. Reilly (see [DRAFT-REM-02]) describing the combination of DOI archival and blockchain timestamping as complementary, independent permanence mechanisms. Neither layer alone is considered sufficient; both are required for full permanence assurance. Empty Window Record: (new in -02) An Aggregate Manifest produced for an aggregation window in which no valid evidence records were collected. It carries the Merkle root of the empty set and a coverage ratio of zero, and is anchored and chained exactly as a populated manifest is. It exists so that a silent window and a suppressed window are distinguishable. Evidence Continuity Chain: (new in -02) The hash-linked sequence of Aggregate Manifests in which each manifest commits to the digest of its predecessor, so that deletion or reordering of any window invalidates every subsequent link. See Section 7.4. Evidence Record: A structured JSON or CBOR document conforming to the RRP evidence schema that captures the result of a single control execution, including metadata, SLO outcome, cryptographic digest, and collector signature. Evidence Store: WORM or functionally equivalent immutable object storage in which evidence records and associated artifacts are preserved with configurable retention policies. Field Commitment: (new in -02) A salted cryptographic commitment to the canonical value of a single named field of an evidence record, permitting that field to be disclosed and verified in isolation. See Section 6.4. Merkle Root: The root digest of a Merkle hash tree constructed per Section 7.2 over all evidence record digests collected within a given aggregation period (typically one calendar day in UTC). Migration Bridging Record: (new in -02) A signed record that binds a chain segment computed under a retiring hash or signature algorithm to its recomputation under a successor algorithm, preserving verifiability of historical evidence across an algorithm transition. See Section 7.5. Prior Art Record: (new in -02) An RRP artifact whose dual-layer anchoring establishes a public, dated, and independently verifiable disclosure of its contents, as described in [DRAFT-REM-02] and Section 16. Remediation Event Record (RER): (new in -02) A signed evidence record documenting a remediation action: its trigger, Blast Radius Class, Autonomy Mode at execution time, the authorizing identity where human authorization was required, the action taken, and the observed outcome. Remediator: (new in -02) A component that proposes or executes corrective action in response to a control result. See Section 9.8. REM Protocol: The Reilly EternaMark Protocol. A complementary protocol that specifies dual-layer digital permanence for arbitrary documents and data artifacts using DOI registration and blockchain timestamping, and, from its -02 revision, their function as prior art records. See [DRAFT-REM-02]. Resilience Scorecard: A structured report, consumable in PDF or dashboard form, that presents weighted pillar scores derived from the window's evidence records, along with the Merkle root, coverage ratio, anchor receipt references, continuity chain position, and independently verifiable evidence URIs. Selective Disclosure Response: (new in -02) A response to an auditor or regulator request that reveals a chosen subset of evidence record fields together with their salts and commitment inclusion proofs, allowing verification against the anchored Commitment Root without revealing undisclosed fields. SLO (Service Level Objective): A quantitative target associated with a Control. An SLO defines the threshold below which a control result is classified as PASS, WARN, or FAIL. WORM Storage: Write-Once-Read-Many storage. Storage in which written objects cannot be modified or deleted for a configured retention period, providing tamper-evidence for stored evidence records. 4. Protocol Principles RRP is founded on six design principles. Principles 4.1 through 4.4 are carried forward unchanged from -01. Principles 4.5 and 4.6 are introduced in this revision. 4.1. Test Restores, Not Backups Backup existence is not proof of recoverability. Recovery MUST be demonstrated by executing an actual restore operation and validating that the restored artifact is consistent with the original. Merely confirming that a backup job completed is explicitly insufficient evidence under this protocol. 4.2. Evidence Over Narrative Every resilience claim MUST map to a signed, immutable evidence record stored at a resolvable URI. Narrative assertions such as "our system is highly available" MUST be supported by verifiable evidence records or they carry no weight under RRP. 4.3. Minimum On-Chain RRP recognizes that publishing full evidence records to public blockchains raises cost, latency, throughput, and privacy concerns. Only the daily Merkle root and the continuity chain head MUST be anchored on-chain. Full evidence records, artifacts, and supporting logs MUST remain off-chain in the Evidence Store. The on-chain commitment is sufficient to provide time attestation for all off-chain evidence linked through the Merkle tree. 4.4. Composability RRP is not a replacement for existing monitoring, observability, or testing infrastructure. Existing systems SHOULD be wrapped to produce standardized RRP evidence records. A Collector MAY be a thin adapter that invokes an existing check and transforms its output into the RRP evidence schema. 4.5. Absence Is a Claim (new in -02) An implementation MUST publish what it expected to measure, not only what it succeeded in measuring. Every aggregation window MUST produce a Control Coverage Attestation and an Aggregate Manifest, including windows in which nothing was collected. A verifier MUST be able to determine, from anchored artifacts alone and without access to internal systems, that a Control which should have reported did not. Scores MUST be reduced in proportion to missing coverage rather than computed over the surviving subset. 4.6. Governed Autonomy (new in -02) Automated remediation is permitted and expected, but it MUST be bounded and recorded. Every remediation action MUST carry a Blast Radius Class, MUST be executed only under an Autonomy Mode that permits that class, and MUST produce a Remediation Event Record. Remediation MUST NOT alter the recorded result of the control execution that triggered it. A failure that was automatically repaired remains a failure for the window in which it occurred. Self-healing systems that erase their own failure signal are outside this protocol. 5. Architecture Overview 5.1. Roles and Responsibilities RRP defines the following distinct roles within an implementation. The Coverage Attestor and Remediator roles are new in -02. Collector: MUST execute one or more assigned Controls on a configured schedule. MUST emit a canonical evidence record per execution. MUST compute the digest of the evidence record prior to signing. SHOULD be isolated such that compromise of one Collector does not compromise others. Signer: MUST hold a signing key (Ed25519 [RFC8032] or ECDSA P-256) in a hardware security module (HSM) or Key Management Service (KMS). MUST sign the digest of each evidence record using the associated private key. MUST NOT expose the private key outside the KMS/HSM boundary. A Collector and Signer MAY be co-located in a single process if the signing key is protected by a KMS API call rather than in-process memory. Evidence Store: MUST accept signed evidence records and associated artifacts (e.g., restore validation logs, screenshots, structured test outputs). MUST enforce WORM semantics or functionally equivalent immutability for the configured retention period (RECOMMENDED minimum: 7 years for compliance-relevant implementations). MUST return a stable, resolvable URI for each stored record. MUST store field salts, where commitment mode is in use, under access control separate from the records themselves (Section 6.4). Coverage Attestor: (new in -02) MUST read the Control Register in force for the window, MUST count valid evidence records observed per Control, and MUST produce and sign a Control Coverage Attestation per Section 9.5. The Coverage Attestor MUST use a signing key distinct from any Collector key and SHOULD be operated under separation of duties from the Collectors whose output it counts. Where organizationally feasible, the Coverage Attestor SHOULD be operated by a different team than the Aggregator. Aggregator: MUST retrieve all evidence records produced within the aggregation window (default: one UTC calendar day). MUST validate each collector signature before including the record in the Merkle tree. Records failing signature validation MUST be excluded and flagged. MUST construct a Merkle tree over the validated set and compute the root digest per the algorithm in Section 7.2. MUST retrieve the Control Coverage Attestation for the window and MUST refuse to produce a manifest without one. MUST output a signed Aggregate Manifest referencing all included record URIs, their digests, the Merkle root, the CCA digest, and the digest of the preceding Aggregate Manifest per Section 7.4. Anchor: MUST publish the Aggregate Manifest digest to at least one public blockchain within the Anchor Window. The Anchor Window opens at 00:00:00 UTC on the day following the aggregation window and MUST close no later than 23:59:59 UTC of that same day. MUST retain the anchor receipt returned by the anchoring service. SHOULD publish to a second independent chain to mitigate single-chain risk. SHOULD additionally place the manifest with one or more keyless archival services per Section 7.3. Remediator: (new in -02) MAY propose or execute corrective action in response to a control result. MUST operate under a declared Autonomy Mode. MUST classify every candidate action by Blast Radius Class and MUST NOT execute a class the current Autonomy Mode does not permit. MUST emit a Remediation Event Record for every proposal and every execution, including refusals. MUST enforce the circuit breaker of Section 9.8.4. MUST NOT modify, suppress, or re-run to overwrite the triggering evidence record. Scorecard Generator: SHOULD compute weighted pillar scores per Section 10 and produce a human-readable Resilience Scorecard in PDF or dashboard format. The Scorecard MUST include the Merkle root, an anchor receipt reference, the aggregation date, the coverage ratio and any Controls reported as missing, the manifest sequence number, and any weight renormalization applied. The Scorecard SHOULD include evidence record URIs for auditor self-service verification. Verifier: Any party wishing to independently verify a resilience claim. A Verifier MUST be able to re-derive evidence digests from stored records, validate Collector signatures against published public keys, verify Merkle inclusion proofs linking individual records to the published Merkle root, confirm the Merkle root matches the on-chain anchor, verify the continuity chain across a range of windows, and confirm the Coverage Attestation against the Control Register, all without trusting any organizational assertion. 5.2. Data Flow The following describes the end-to-end data flow for a single aggregation cycle. Steps (6), (9), and (10) are new in -02. (1) Collectors execute Control checks on schedule, per the Control Register in force for the window. (2) Each Collector produces an evidence record (Section 6) and computes its digest. Where commitment mode is in use, the record's digest covers the Commitment Root rather than the plaintext field values (Section 6.4). (3) Each Signer signs the digest; the signature is embedded in the evidence record's "sig" field. (4) Signed evidence records are submitted to the Evidence Store, which returns a stable URI for each record. (5) A Remediator, if deployed, evaluates results and acts within its Autonomy Mode, emitting Remediation Event Records. The triggering records are not modified. (6) At the close of the aggregation window, the Coverage Attestor produces and signs the Control Coverage Attestation for the window against the Control Register. (7) The Aggregator retrieves all records, validates signatures, and constructs the Merkle tree. (8) The Aggregator produces the Aggregate Manifest, binding the Merkle root, the CCA digest, and the digest of the preceding manifest, and signs it. (9) The Anchor publishes the manifest digest to the blockchain(s) and to the archival anchor set, and retains the receipts. (10) The Scorecard Generator computes pillar scores, applies the coverage factor and any weight renormalization, and produces the Resilience Scorecard. (11) Auditors use the Scorecard's evidence URIs, Merkle root, CCA, manifest chain, and anchor receipts to independently verify any claim, and to detect any claim that should have been made and was not. A window in which zero valid records were collected still executes steps (6) through (11). See Empty Window Record in Section 7.4. 6. Evidence Schema 6.1. Evidence Record Structure Each evidence record MUST be a valid JSON document [RFC8259] or CBOR document [RFC8949] conforming to the following schema. JSON is RECOMMENDED for interoperability; CBOR is OPTIONAL for constrained environments. The canonical field names and their semantics are as follows. Fields marked "(new in -02)" were introduced in this revision and are OPTIONAL for backward compatibility per Section 6.5. "rrp_version" (string, REQUIRED) The RRP version string. For records conforming to this specification: "1.2". "record_id" (string, REQUIRED) A globally unique identifier for this evidence record. MUST be a UUID [RFC9562] formatted as a lowercase hyphenated string. UUIDv4 or UUIDv7 MAY be used; UUIDv7 is RECOMMENDED in new implementations for its sortable time prefix. "record_type" (string, OPTIONAL, new in -02) One of "control" (default when absent), "remediation", or "register-change". Remediation Event Records and Control Register change records share the evidence envelope so that they are signed, stored, aggregated, and anchored by the same machinery. "control_id" (string, REQUIRED) A stable, human-readable identifier for the Control that was executed. RECOMMENDED format: reverse-DNS prefix followed by a descriptive slug (e.g., "com.example.db.restore-verify"). MUST correspond to an entry in the Control Register version referenced by "register_version". "control_version" (string, REQUIRED) The version string of the Control definition in use, allowing traceability to a specific control specification revision. "register_version" (string, OPTIONAL, new in -02) The version identifier of the Control Register in force at execution time. REQUIRED when a Control Coverage Attestation is produced for the window, which under this revision is always. Retained as OPTIONAL in the schema only to permit ingestion of -01 records. "collector_id" (string, REQUIRED) The stable identifier for the Collector that produced this record, corresponding to a published public key. "ts_start" (string, REQUIRED) Timestamp in the format of [RFC3339] with UTC offset (ending in "Z") indicating when the Control execution began. "ts_end" (string, REQUIRED) Timestamp in the format of [RFC3339] with UTC offset indicating when the Control execution completed. "result" (string, REQUIRED) One of: "PASS", "WARN", "FAIL", "ERROR". See Section 6.2 for semantics. "slo_target" (object, REQUIRED) An object describing the SLO threshold. MUST contain: "metric": the metric name (string), "operator": one of "lte", "gte", "lt", "gt", "eq", "value": the threshold value (number or string), "unit": the unit of measurement (string). "slo_actual" (object, REQUIRED) The same structure as "slo_target" with the "value" field set to the actual measured value. "artifacts" (array, OPTIONAL) An array of artifact descriptor objects, each containing: "uri": resolvable URI to the artifact in the Evidence Store (string, REQUIRED), "sha256": hex-encoded digest of the artifact (string, REQUIRED), "type": MIME type or descriptor (string, OPTIONAL). "anchor_expectation" (string, OPTIONAL, new in -02) For Controls that measure an external target, the declared mutability class of that target: "live", "dynamic", or "immutable". See Section 7.3.4. A Control whose target is declared "immutable" and whose measured digest differs from the sealed baseline MUST produce result FAIL and MUST be escalated to human review regardless of Autonomy Mode. "remediation_ref" (array, OPTIONAL, new in -02) An array of "record_id" values of Remediation Event Records triggered by this record. Populating this field MUST NOT change the "result" field or the record's digest; the reference is carried in a superseding linkage record, not by mutating the original. See Section 9.8.5. "metadata" (object, OPTIONAL) Arbitrary key-value pairs for implementation-specific metadata. Values MUST be strings. "commitments" (object, OPTIONAL, new in -02) Present when the record operates in commitment mode. MUST contain: "alg": the commitment construction identifier, currently "RRP-SHA256-SALT-v1", "root": hex-encoded Commitment Root (Section 6.4), "fields": array of committed field paths in canonical order. Field values that are committed MAY be omitted from the record body. Salts MUST NOT appear in the record. "digest" (string, REQUIRED) The hex-encoded digest of the canonical serialization of this record with the "digest" and "sig" fields set to empty strings. See Section 6.3. "sig" (object, REQUIRED) An object containing: "alg": the signing algorithm ("Ed25519" or "ES256"), "kid": key identifier referencing the Signer's published public key, "value": base64url-encoded signature over "digest". An example evidence record (JSON, line-wrapped for readability): { "rrp_version": "1.2", "record_id": "01930f6e-8c2a-7c31-9b44-5f2d1c7a9e03", "record_type": "control", "control_id": "com.example.db.restore-verify", "control_version": "2.0.1", "register_version": "2026-08-01.4", "collector_id": "collector-db-prod-us-east-1", "ts_start": "2026-08-24T00:05:00Z", "ts_end": "2026-08-24T00:23:41Z", "result": "PASS", "slo_target": { "metric": "restore_duration_minutes", "operator": "lte", "value": 30, "unit": "minutes" }, "slo_actual": { "metric": "restore_duration_minutes", "operator": "lte", "value": 18, "unit": "minutes" }, "artifacts": [ { "uri": "s3://evidence-store/2026-08-24/restore-log.txt", "sha256": "a3f1...c9d2", "type": "text/plain" } ], "metadata": { "env": "production", "region": "us-east-1" }, "digest": "4e2a...b7f0", "sig": { "alg": "Ed25519", "kid": "collector-db-prod-us-east-1-key-v3", "value": "base64url-encoded-signature" } } 6.2. Control Result Codes PASS: The control executed successfully and the measured SLO actual value satisfies the SLO target threshold. No action required. WARN: The control executed successfully but the measured SLO actual value approaches (within a configurable margin of) the SLO target threshold, or a non-critical advisory condition was detected. Implementers SHOULD define warning margins per control. FAIL: The control executed but the measured SLO actual value did not satisfy the SLO target threshold. FAIL results MUST trigger alerting and MUST cap the affected pillar score per Section 10.2. ERROR: The control execution itself failed to complete (e.g., the Collector encountered an infrastructure error, timeout, or unexpected exception before producing a valid measurement). ERROR results MUST be treated as FAIL for scoring purposes. The distinction is retained for operational root-cause analysis. There is deliberately no result code meaning "not applicable" or "skipped". A Control that an implementation does not intend to run MUST be removed from the Control Register through a recorded register change (Section 9.1.3), not suppressed at execution time. Absence of a record for a registered Control is handled by the Coverage Attestation, not by a self-reported code. 6.3. Canonical Serialization To compute the "digest" field, implementers MUST: (1) Set the "digest" field to the empty string "". (2) Set the "sig" field to {"alg":"","kid":"","value":""}. (3) Serialize the record to UTF-8 JSON with keys in lexicographic (alphabetical) order by Unicode code point at every level of nesting, no insignificant whitespace, and no trailing newline. Numbers MUST be serialized per the I-JSON rules of [RFC7493]; implementations SHOULD avoid floating-point SLO values entirely and express fractional thresholds in integer units of finer granularity. (4) Compute the digest over the resulting UTF-8 byte sequence. (5) Hex-encode the resulting digest (lowercase). (6) Set the "digest" field to this hex-encoded value. (7) Sign the "digest" value per Section 7.1. Implementers using CBOR MUST apply the deterministic encoding requirements of [RFC8949] Section 4.2 in place of steps (3) through (4), and MUST record "cbor-det" in the metadata so that verifiers select the correct serialization. 6.4. Field Commitments and Selective Disclosure This section is new in -02. It provides the mechanism that -01 lacked for satisfying an auditor's need for a specific fact without publishing an entire operational record. 6.4.1. Motivation Resilience evidence is frequently sensitive in aggregate even when each field is innocuous. Restore durations disclose database sizes. Collector identifiers disclose topology. Regulators and customers, however, typically need one field of one record: that a restore was tested, or that a certificate was valid on a date. Commitment mode permits that single fact to be proven against an anchored root while the remainder stays confidential. 6.4.2. Constructing Field Commitments For an evidence record R operating in commitment mode: (1) Determine the set F of committed field paths. A field path is the JSON Pointer [RFC6901] of the field within R. The fields "digest", "sig", and "commitments" MUST NOT be committed. The fields "record_id", "control_id", "register_version", "ts_end", and "result" MUST be included in F, since coverage counting and scoring depend on them. (2) For each field path p in F with canonical value v (serialized per Section 6.3 as a standalone JSON value): salt_p = 32 octets from a cryptographically secure random number generator c_p = H( 0x02 || salt_p || len(p) || UTF8(p) || len(v) || UTF8(v) ) where len(x) is the length of x in octets encoded as a 4-octet unsigned big-endian integer. The 0x02 domain separation prefix is distinct from the 0x00 leaf prefix and 0x01 interior prefix used in Section 7.2, so that a field commitment can never be reinterpreted as a tree node. (3) Sort the pairs (p, c_p) ascending by p, compared as octet strings. (4) Compute the Commitment Root over the ordered list of c_p values using the Merkle construction of Section 7.2. (5) Populate "commitments" with the algorithm identifier, the hex-encoded root, and the ordered list of field paths. (6) Compute the record "digest" per Section 6.3 over the record as it will be published, that is, with committed field values omitted where the implementation chooses to omit them. Salts MUST be unique per field per record. Salts MUST NOT be derived from the field value, the record identifier, or any other record content, since such derivation would permit an adversary holding the commitment to confirm a guessed value. 6.4.3. Selective Disclosure Response A Selective Disclosure Response is a JSON document containing: "record_id", "control_id", "register_version" (strings), "commitment_root" (string, hex), "disclosed" (array), each element containing: "path" (JSON Pointer string), "value" (the canonical field value), "salt" (base64url), "proof" (array of hex sibling digests, ordered from leaf to root, with a bit vector or explicit index giving left/right position), "manifest_ref" (URI of the Aggregate Manifest for the window), "anchor_ref" (array of anchor receipt references). A recipient verifies a Selective Disclosure Response by recomputing c_p from the disclosed value and salt, verifying the inclusion proof against "commitment_root", confirming that the record digest appears in the referenced Aggregate Manifest, confirming the manifest digest against the anchor receipts, and confirming the manifest's position in the continuity chain per Section 7.4. 6.4.4. Limitations Commitment mode does not provide confidentiality against an adversary who obtains the salts. Salts MUST be stored under access control separate from the evidence records and MUST NOT be written into the Evidence Store objects that hold the records themselves. Low-entropy fields remain guessable to an adversary who obtains a salt, and the "result" field has four possible values. The commitment therefore protects against undetected alteration, not against inference by a salt holder. Implementers requiring confidentiality against holders of partial disclosures SHOULD additionally encrypt artifacts at rest and SHOULD NOT rely on commitment mode alone. Selective disclosure of a subset of fields can itself be misleading. The requirement in Section 6.4.2 step (1) that "result" always be committed and the requirement in Section 9.5 that coverage be attested over the full register together prevent an implementation from disclosing only its favorable fields without the omission being visible. 6.5. Version Compatibility Records bearing "rrp_version": "1.1" remain valid and verifiable. A Verifier processing a mixed-version window MUST apply the Merkle construction of the manifest's own version, not the record's. An Aggregator producing a manifest under this specification MUST use the construction of Section 7.2 for all records in the window regardless of the version of the individual records, and MUST record "construction": "rfc6962" in the manifest. Implementations migrating from -01 MUST NOT recompute or re-anchor historical roots to the corrected construction. Historical roots remain valid under the construction in force at the time of anchoring, which is recorded in the manifest. The continuity chain (Section 7.4) MAY be initialized at the first manifest produced under this specification, with "prev_manifest_digest" set to the genesis value and the pre- migration history referenced through "legacy_ref". 7. Cryptographic Operations 7.1. Evidence Signing Collector signing keys MUST be one of the following algorithms: Ed25519 [RFC8032]: RECOMMENDED. Produces 64-byte signatures. Key pairs are 64 bytes (private) and 32 bytes (public). Deterministic; does not require a random number generator at signing time. ECDSA with P-256 and SHA-256 (ES256): ACCEPTABLE where Ed25519 is not supported by the KMS. Implementers SHOULD use deterministic ECDSA [RFC6979] to mitigate nonce-reuse vulnerabilities. RSA-PSS with SHA-256 (PS256): MAY be used in legacy environments where neither Ed25519 nor ECDSA is available. Minimum key size: 3072 bits. NOT RECOMMENDED for new implementations. All Signer public keys MUST be published in JWK format [RFC7517] at a stable, resolvable URI and SHOULD be published in a JWK Set document alongside the collector identity metadata. Signed evidence records SHOULD additionally be wrapped in a COSE_Sign1 structure [RFC9052] when interoperability with COSE-aware verification toolchains is required. Implementations targeting a transparency service SHOULD express evidence as signed statements per the SCITT architecture [I-D.SCITT-ARCH], which allows RRP evidence to be registered on an existing transparency service rather than an implementation-specific store. Post-quantum signature suites are not mandated by this revision. Implementations with retention horizons beyond the useful life of classical signatures SHOULD plan for migration per Section 7.5 and MAY dual-sign with ML-DSA [FIPS204] in addition to a classical algorithm. Where dual signing is used, the "sig" field MUST carry the classical signature and an additional "sig_pq" field of identical structure MUST carry the post-quantum signature; verifiers that do not recognize "sig_pq" ignore it, and the field is included in the canonical serialization. 7.2. Merkle Tree Construction This section replaces Section 7.2 of -01 in full. The construction in -01 duplicated the final digest when the leaf count was odd. That is the Bitcoin construction, not the construction of [RFC6962] and [RFC9162], and it was incorrectly attributed to the latter. Duplication permits two distinct leaf multisets to yield the same root, and it prevents a tree from being extended without recomputation, which forecloses consistency proofs. Implementations of -01 SHOULD migrate to the construction below for all new windows and MUST NOT retroactively alter previously anchored roots. 7.2.1. Leaf Ordering Let the validated record set for the window be ordered ascending by the tuple (ts_end, record_id), comparing ts_end as an octet string in [RFC3339] UTC form and record_id as an octet string. This ordering is deterministic, reproducible by any verifier from the manifest alone, and monotone in time, so that concatenating consecutive windows yields an append-only sequence over which [RFC9162] consistency proofs are well defined. The digest-sorted ordering specified in -01 is not carried forward. Sorting by digest destroys temporal order and makes the concatenation of windows non-monotone, which is why -01 could not support consistency proofs across windows. 7.2.2. Tree Definition Let D[n] = {d_1, ..., d_n} be the ordered list of record digests. The Merkle Tree Hash MTH is defined recursively as in [RFC6962] Section 2.1: MTH({}) = H() that is, the digest of the empty octet string. For SHA-256 this is: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b 7852b855 MTH({d_1}) = H( 0x00 || d_1 ) For n > 1, let k be the largest power of two strictly less than n. Then: MTH(D[n]) = H( 0x01 || MTH(D[0:k]) || MTH(D[k:n]) ) No leaf is ever duplicated. Trees of any cardinality, including zero and one, are well defined. The 0x00 and 0x01 domain separation prefixes prevent second-preimage attacks in which an interior node is presented as a leaf. 7.2.3. Inclusion and Consistency Proofs Inclusion proofs for individual evidence records MUST be generated per [RFC6962] Section 2.1.1 and stored alongside the Aggregate Manifest, enabling any Verifier to prove that a specific evidence record is included in the published Merkle root without requiring access to all other records. Implementations MAY maintain a single continuous log across windows in addition to per-window trees. Where they do, consistency proofs per [RFC6962] Section 2.1.2 MUST be supported, and verification of a long range of windows SHOULD use the bulk subtree proof construction of [DRAFT-BSP-01], which verifies a contiguous span by descent over full subtrees at landmark breakpoints rather than by one inclusion proof per record. For an auditor verifying a seven-year retention period, the difference is between a proof set linear in the number of records and one logarithmic in the number of windows. 7.2.4. Test Vectors Implementers MUST validate against the [RFC6962] reference vectors. For the avoidance of doubt, given three leaf digests d_1, d_2, d_3 in the order defined by Section 7.2.1: k = 2 MTH = H( 0x01 || H( 0x01 || H(0x00||d_1) || H(0x00||d_2) ) || H(0x00||d_3) ) An implementation that instead computes H( 0x01 || H( 0x01 || H(0x00||d_1) || H(0x00||d_2) ) || H( 0x01 || H(0x00||d_3) || H(0x00||d_3) ) ) is implementing -01 and is non-conformant with this revision. 7.3. Anchoring Anchoring in this revision is organized into three classes. An implementation MUST use at least one anchor from class A and SHOULD use at least one from each of classes A, B, and C. The anchored value is the Aggregate Manifest digest, which transitively commits to the Merkle root, the Coverage Attestation, and the entire prior chain. Anchoring only the Merkle root, as in -01, is no longer sufficient. 7.3.1. Class A: Blockchain Anchors Bitcoin via OpenTimestamps: The manifest digest is committed using OpenTimestamps calendar servers. The returned .ots file constitutes the anchor receipt and MUST be retained alongside the Aggregate Manifest. RECOMMENDED for implementations prioritizing immutability and chain longevity. Ethereum or EVM-Compatible L2: The manifest digest MAY be submitted as calldata in a standard transaction, or via a purpose-built contract. The transaction hash and block number constitute the anchor receipt. Implementers SHOULD prefer a Layer 2 network with Ethereum settlement for cost efficiency. The Anchor Window is defined as the 24-hour UTC period immediately following the close of the aggregation window. Anchoring MUST complete within the Anchor Window. Implementers SHOULD use two independent chains to mitigate the risk of a single chain reorganization or availability failure invalidating the anchor. The on-chain commitment MUST include only the manifest digest and a minimal protocol identifier. Full evidence records, PII, and sensitive operational data MUST NOT be published on-chain. 7.3.2. Class B: Persistent Identifier Anchors The Aggregate Manifest, or a periodic rollup of manifests, SHOULD be deposited with a DOI registration agency, producing a citable, dated, resolvable identifier. This is the archival half of Dual-Layer Digital Permanence per [DRAFT-REM-02]. A monthly or quarterly rollup deposit is RECOMMENDED in preference to daily deposits, which impose an unnecessary registration burden. 7.3.3. Class C: Keyless Archival Anchors Keyless archival services provide independent, third-party dated custody without requiring an account, key, or fee, and remain available when an organization's own infrastructure does not. Implementations SHOULD submit the public manifest URI to two or more of the following classes of service: general web archives supporting the Memento framework [RFC7089], national or regional web archives, source code archives, and open crawl corpora. Class C anchors are weaker than class A: capture timing is not under the implementation's control and coverage is best effort. They MUST NOT be used as the sole anchor for a window. Their value is corroborative, in that an adversary who compromises both the organization and its blockchain anchoring path must still contend with independently held dated copies. 7.3.4. Anchor Expectations for Measured Targets Where a Control measures an external target rather than an internal system, the Control Register MUST declare the target's Anchor Expectation: live: The target is expected to be reachable and to return a success status. Content is expected to change. Only reachability and status are evaluated. dynamic: The target is expected to be reachable and its content is expected to change within declared bounds, for example a status endpoint whose schema is stable. Schema conformance is evaluated; content equality is not. immutable: The target's content is expected never to change. A sealed baseline digest is recorded on first successful observation. Any subsequent divergence from the baseline MUST produce result FAIL, MUST be escalated to human review, and MUST NOT be auto-remediated under any Autonomy Mode, including AUTONOMOUS. An immutable target that changes is either an upstream integrity failure or a compromise of the implementation's own baseline, and neither is a condition an automated remediator should resolve unattended. Baselines MUST be sealed only on a response that was actually received and validated. An implementation MUST NOT seal a baseline from a timeout, an error page, or a redirect to an unrelated resource, as doing so silently converts an outage into a permanent false baseline. 7.4. Evidence Continuity Chain This section is new in -02. 7.4.1. Rationale Under -01, each window stood alone. An adversary with sufficient access could delete a window's manifest, evidence, and anchor receipt, and no surviving artifact would be inconsistent with the result. The Evidence Continuity Chain makes each window cryptographically dependent on its predecessor, so that removing a window invalidates every window after it. To conceal a single bad day, an adversary must forge the entire remaining history and must also defeat the external anchors that already committed to the original chain. 7.4.2. Aggregate Manifest Structure The Aggregate Manifest MUST be a JSON document with the following fields. Canonical serialization and digest computation follow Section 6.3. "rrp_version" (string, REQUIRED) "1.2" "manifest_id" (string, REQUIRED) UUID "chain_id" (string, REQUIRED) A stable identifier for this continuity chain, allowing an organization to operate separate chains per environment or per regulated entity. "seq" (number, REQUIRED) Monotonically increasing integer, starting at 0 for the genesis manifest of the chain. MUST increase by exactly 1 per window with no gaps. "window_start" (string, REQUIRED) RFC 3339 UTC "window_end" (string, REQUIRED) RFC 3339 UTC "prev_manifest_digest" (string, REQUIRED) Hex digest of the preceding manifest. For seq = 0 this MUST be 64 zero characters. "construction" (string, REQUIRED) "rfc6962" "merkle_root" (string, REQUIRED) Hex. For an empty window this is MTH({}) per Section 7.2.2, not an omitted or null value. "record_count" (number, REQUIRED) "included" (array, REQUIRED) Objects of {"uri", "digest"} in the order of Section 7.2.1. MAY be replaced by a reference to a separately stored, digest-committed list where window sizes make inline inclusion impractical; in that case "included_ref" and "included_digest" MUST be present. "excluded" (array, REQUIRED) Objects of {"record_id", "reason"}. MUST be present and MUST be an empty array rather than omitted when no records were excluded. "cca_digest" (string, REQUIRED) Hex digest of the Control Coverage Attestation for this window. A manifest without a CCA digest is non-conformant. "coverage_ratio" (number, REQUIRED) Copied from the CCA for convenience. A verifier MUST confirm it against the CCA rather than trusting it. "anchors" (array, REQUIRED) Objects of {"class", "target", "receipt_uri", "receipt_digest", "obtained_at"}. MAY be empty at manifest signing time and completed by an addendum record per Section 7.4.4. "legacy_ref" (object, OPTIONAL) Present only on the genesis manifest of a chain that continues pre-existing history under a different construction. Contains {"last_legacy_root", "last_legacy_window_end", "construction"}. "digest" (string, REQUIRED) "sig" (object, REQUIRED) Aggregator signature, structured as in Section 6.1. 7.4.3. Chain Invariants A conformant chain satisfies all of the following, and a Verifier MUST check each: (1) seq values are consecutive integers with no gaps and no repeats. (2) For every manifest M with seq > 0, M.prev_manifest_digest equals the digest of the manifest with seq = M.seq - 1. (3) window_start of manifest n+1 equals window_end of manifest n. No time is unaccounted for between consecutive windows. (4) Every manifest carries a cca_digest that resolves to a Coverage Attestation whose window matches the manifest's. (5) Every manifest is anchored in at least one class A anchor within its Anchor Window, or carries a late-anchor explanation per Section 12.2 Scenario 5. A break in any invariant is a finding. It does not by itself prove misconduct, since operational failure produces breaks too, but under this protocol the distinction between misconduct and incompetence is not the Verifier's to make; both MUST be reported and both MUST reduce the score for the affected windows. 7.4.4. Anchor Addendum Because anchoring completes after the manifest is signed, an implementation MAY sign the manifest with an empty "anchors" array and subsequently publish an Anchor Addendum, a small signed record containing the manifest digest and the completed anchor array. The addendum MUST be committed by the next window's manifest through inclusion in that window's evidence set, so that an addendum cannot be silently withdrawn. 7.4.5. Empty Window Records When a window contains zero valid records, the Aggregator MUST still produce a manifest, with merkle_root = MTH({}), record_count = 0, and the window's Coverage Attestation showing zero of the expected Controls observed. This manifest MUST be anchored and chained normally. This replaces the behavior of -01 Section 7.2 step (2), under which no anchor was produced and only a local log entry was required. A window that produced nothing and a window whose evidence was destroyed are, under -01, the same observation from the outside. Under this revision they are not. 7.5. Hash and Signature Migration This section is new in -02. RRP retention horizons are long: seven years is the RECOMMENDED minimum for compliance deployments, and archival deposits under class B anchors are intended to be permanent. These horizons exceed the confident lifetime of any particular hash or signature algorithm. A protocol that does not plan for migration will eventually hold a large volume of evidence that no longer verifies. 7.5.1. Migration Bridging Record To migrate from a retiring algorithm OLD to a successor NEW, the implementation MUST produce a Migration Bridging Record (MBR) containing: "chain_id", "seq_from", "seq_to" The contiguous chain segment being bridged. "old_alg", "new_alg" Algorithm identifiers. "segment_root_old" The root, computed under OLD, over the digests of the manifests in the segment. "segment_root_new" The root, computed under NEW, over the same manifests in the same order. "manifest_map" An ordered list of {"seq", "digest_old", "digest_new"}. "attested_at", "attestor_id" "sig_old", "sig_new" The MBR MUST be signed under both the retiring and the successor signature algorithms. The MBR MUST itself be anchored under class A using the successor algorithm, and SHOULD be anchored under the retiring algorithm as well while that remains available. 7.5.2. Migration Requirements (1) Migration MUST NOT rewrite historical manifests, records, or roots. Original artifacts are retained unmodified; the MBR is additive. (2) An MBR MUST be produced while the retiring algorithm is still considered sound. A bridging record signed after the retiring algorithm is broken carries no more assurance than the broken algorithm itself. Implementers SHOULD treat the first credible published weakening of an algorithm, rather than its formal deprecation, as the trigger to bridge. (3) The active hash for new windows changes at a declared manifest sequence number, which MUST be recorded in the manifest at which the change takes effect. (4) Verifiers encountering a segment under a retired algorithm MUST report the verification as conditional on the MBR and MUST identify the MBR relied upon. (5) A chain with no MBR covering a retired-algorithm segment is verifiable only to the strength of the retired algorithm, and a Verifier MUST say so rather than reporting success. 8. Key Management Proper key management is essential to the integrity of all RRP evidence. The following requirements apply. Requirements (8) through (10) are new in -02. (1) All Signer private keys MUST be stored in a hardware security module (HSM) or a cloud KMS with HSM-backed key storage. (2) Private keys MUST NOT be stored in filesystem files, source control, container images, or environment variables. (3) Each Collector MUST have a distinct signing key pair. Shared keys across Collectors are NOT RECOMMENDED as they prevent individual Collector attribution in the event of compromise. (4) Collector public keys MUST be published to a well-known endpoint prior to the Collector emitting any evidence records. The published JWK Set MUST be updated within 24 hours of any key rotation. (5) Signing keys MUST be rotated at least annually. Key rotation MUST NOT invalidate previously issued signatures. The previous public key MUST remain published and resolvable for the duration of the evidence retention period. (6) Key compromise MUST be declared by publishing a revocation notice at the public key endpoint within 24 hours of discovery. All evidence records signed by the compromised key after the declared compromise time MUST be treated as invalid. (7) Implementers SHOULD maintain an out-of-band key backup in a geographically separate HSM to enable recovery without evidence continuity interruption. (8) The Aggregator signing key, the Coverage Attestor signing key, and every Collector signing key MUST be distinct, and the Aggregator and Coverage Attestor keys MUST NOT be usable by any Collector process. The purpose of the Coverage Attestation is defeated if the same principal can both suppress a record and attest that it was never expected. (9) The Coverage Attestor key SHOULD be held under separation of duties from the Aggregator key, such that no single operator can authorize use of both. Where an organization cannot achieve this, it MUST disclose the limitation in the Scorecard, because a verifier cannot otherwise distinguish an attested coverage claim from a self-issued one. (10) Key revocation MUST NOT invalidate the continuity chain. Manifests signed by a revoked Aggregator key before the declared compromise time remain valid links. The chain MUST continue under the successor key with no gap in seq, and the key transition MUST be recorded as an evidence record of type "register-change". 9. Operational Procedures 9.1. Control Definition and the Control Register 9.1.1. Control Requirements Implementers MUST define a minimum of 5 Controls and SHOULD define 8 to 12 for a production deployment. Each Control MUST have: (a) A stable "control_id" (reverse-DNS format RECOMMENDED). (b) A human-readable description and rationale. (c) A measurable SLO target with a specific metric, operator, threshold value, and unit. (d) An assigned Collector or set of Collectors. (e) An execution schedule (RECOMMENDED: at minimum once per 24-hour period), expressed as an expected record count per aggregation window so that coverage can be counted rather than inferred. (f) An assigned Pillar (Section 10.1). (g) A declared Anchor Expectation where the Control measures an external target (Section 7.3.4). (h) Mapping to at least one compliance framework control (see Section 11) where applicable. The following are RECOMMENDED baseline Controls: Backup Restore Verification: Execute a full restore of a production backup to an isolated environment. Validate restored artifact consistency. SLO example: restore completes in <= 30 min with 100% data integrity checksum match. TLS Certificate Expiry: Verify all externally facing TLS certificates have remaining validity > N days (RECOMMENDED: N >= 30). Database Replication Lag: Confirm replication lag across all read replicas is below a defined threshold. AI Model Drift Scan: Compare current inference distribution against a validated baseline distribution. Trigger WARN if drift exceeds a configurable threshold; FAIL if it exceeds a critical threshold. Network Partition Recovery: Inject a controlled network partition and verify that the system recovers within the defined RTO. Incident Response Drill: Log evidence of a completed tabletop or live incident response exercise, including participant count, scenario, and findings. Anchor Integrity Check: (new in -02) Verify that each declared external anchor target still resolves and, for targets declared immutable, still matches its sealed baseline digest. 9.1.2. The Control Register The Control Register is the signed, versioned document that enumerates every Control the implementation asserts it operates. It MUST contain, for each Control, the fields of Section 9.1.1, and MUST carry a "register_version" identifier, an "effective_from" timestamp, the digest of the preceding register version, and an Aggregator or Coverage Attestor signature. The Control Register MUST be published at a resolvable URI, MUST be stored in the Evidence Store, and its digest MUST be committed through the Coverage Attestation of every window in which it is in force. The Register is the anchor of the whole omission-resistance property. Without a signed, versioned, externally visible statement of what was supposed to run, coverage is self-reported and worthless. 9.1.3. Register Changes Adding, removing, retiring, or materially altering a Control MUST produce an evidence record of "record_type": "register-change" containing the prior and new register versions, the affected control_ids, the nature of the change, the authorizing identity, and a stated reason. That record is signed, stored, aggregated, and anchored like any other. Removing a Control is therefore permitted and is not treated as misconduct. It is treated as a dated, signed, publicly verifiable decision by a named party, which is the property that matters. An organization that quietly stops testing restores and an organization that documents a decision to stop testing restores are distinguishable under this revision, and were not under -01. 9.2. Evidence Collection Each Collector MUST: (1) Execute the assigned Control check at the scheduled time. (2) Record ts_start immediately before execution begins. (3) Capture raw output, logs, and any relevant artifacts. (4) Map the result to one of: PASS, WARN, FAIL, ERROR. (5) Populate all REQUIRED fields of the evidence schema (Section 6.1), including "register_version". (6) Store raw artifacts in the Evidence Store and populate the "artifacts" array with their URIs and digests. (7) Where commitment mode is in use, generate salts and compute the Commitment Root per Section 6.4. (8) Compute the canonical serialization (Section 6.3) and set the "digest" field. (9) Submit the pre-signature record to the Signer. Collectors MUST be designed to be idempotent with respect to re-execution. A re-run of the same Control within the same aggregation window MUST produce a new record with a unique "record_id"; it MUST NOT overwrite the prior record. A Collector that cannot complete a check MUST emit an ERROR record. Emitting nothing is not an acceptable response to a failed check, and under Section 9.5 will be counted as missing coverage rather than as silence. 9.3. Signing and Storage The Signer MUST: (1) Receive the pre-signature evidence record from a Collector over an authenticated, encrypted channel (TLS 1.3 REQUIRED per [RFC8446]). (2) Re-compute the canonical digest and verify it matches the submitted "digest" field before signing. A mismatch MUST result in rejection of the record. (3) Sign the digest using the Collector's assigned private key. (4) Return the signed evidence record to the Collector. The Evidence Store MUST: (1) Accept only signed evidence records (records missing a valid "sig" block MUST be rejected). (2) Verify the Collector signature against the published public key before storing. (3) Return a stable, resolvable URI for the stored record. (4) Enforce the configured WORM retention period. (5) Store field salts, where present, in a separate access- controlled store, and never in the same object as the record. 9.4. Aggregation and Anchoring At the close of each aggregation window, the Aggregator MUST: (1) Query the Evidence Store for all records with "ts_end" falling within the closed window. (2) For each record, validate the Collector signature against the published JWK Set. Exclude records failing validation. (3) Log all excluded records with the reason for exclusion, and carry that list into the manifest's "excluded" array. (4) Order the validated set per Section 7.2.1 and construct the Merkle tree per Section 7.2.2. (5) Retrieve the Control Coverage Attestation for the window and verify its signature. If no valid CCA exists, the Aggregator MUST NOT publish a manifest claiming coverage; it MUST publish a manifest with coverage_ratio 0 and an explicit exclusion reason naming the missing attestation. (6) Retrieve the preceding manifest for this chain_id and compute its digest. (7) Produce and sign the Aggregate Manifest per Section 7.4.2. (8) Store the Aggregate Manifest in the Evidence Store. (9) Submit the manifest digest to the Anchor across the configured anchor classes. (10) Receive and store the anchor receipts, publishing an Anchor Addendum where receipts arrive after signing. The Aggregator MUST NOT exclude a record on any ground other than signature validation failure, schema invalidity, or ts_end falling outside the window. In particular, a record MUST NOT be excluded on the basis of its "result" value. 9.5. Control Coverage Attestation This section is new in -02 and is the principal addition of this revision. 9.5.1. Purpose The Coverage Attestation converts the absence of evidence into a positive, signed, anchored claim. Under -01, a verifier could confirm that every record present was authentic, and could confirm nothing at all about records that were never created. Under this revision, an implementation states in advance what it will produce and states afterward what it did produce, and both statements are anchored. 9.5.2. Structure The CCA MUST be a JSON document containing: "rrp_version" (string, REQUIRED) "1.2" "cca_id" (string, REQUIRED) UUID "chain_id" (string, REQUIRED) "window_start", "window_end" (strings, REQUIRED) "register_version" (string, REQUIRED) "register_digest" (string, REQUIRED) Digest of the Control Register in force for the window. "controls" (array, REQUIRED) One entry per Control in the Register, each containing: "control_id", "pillar", "expected_count" (number, from the schedule), "observed_count" (number, valid records seen), "observed_digests" (array of record digests, or a digest-committed reference), "status": one of "COMPLETE" (observed >= expected), "PARTIAL" (0 < observed < expected), "MISSING" (observed = 0). "expected_total", "observed_total" (numbers, REQUIRED) "coverage_ratio" (number, REQUIRED) Computed per Section 9.5.3. "attestor_id" (string, REQUIRED) "digest", "sig" (REQUIRED) Every Control in the Register MUST appear in the "controls" array, including those with observed_count 0. A CCA that omits registered Controls is non-conformant, and a Verifier MUST reject it by comparing the control_id set against the register at "register_digest". 9.5.3. Coverage Ratio Coverage is computed per Control and then aggregated, so that one Control emitting many records cannot compensate for another emitting none: cov(c) = min( observed_count(c) / expected_count(c), 1.0 ) coverage_ratio = ( sum over c in Register of cov(c) ) / |Register| Per-Pillar coverage, used in scoring per Section 10.2, is: cov_P = ( sum over c in C_P of cov(c) ) / |C_P| where C_P is the set of registered Controls assigned to Pillar P. 9.5.4. Attestation Requirements (1) A CCA MUST be produced for every window, including windows with zero records. (2) The CCA MUST be produced by a principal whose signing key is distinct from the Collector keys whose output it counts, per Section 8 requirement (8). (3) The CCA MUST be committed by the window's Aggregate Manifest through "cca_digest", and is therefore anchored transitively. (4) A Verifier MUST recompute coverage_ratio from the "controls" array rather than trusting the stated value, and MUST recompute observed_count from the manifest's included record set rather than trusting the attestor. The attestation is a claim; the manifest is the evidence for it. Where the two disagree, the manifest governs and the disagreement is a finding. (5) The CCA MUST NOT be back-dated or amended. A correction is issued as a new record of type "register-change" in a subsequent window, referencing the CCA corrected. 9.6. Scorecard Publication The Scorecard Generator SHOULD publish the Resilience Scorecard within 4 hours of the Anchor completing its class A commitment. The Scorecard MUST include: (a) The aggregation date (UTC) and the manifest "seq". (b) The overall RRP composite score (0-100). (c) Per-pillar scores with weights, effective weights after any renormalization, and contributing controls. (d) Result summary (counts of PASS, WARN, FAIL, ERROR). (e) The coverage ratio, per-pillar coverage, and an explicit list of every Control with status PARTIAL or MISSING. (f) The Merkle root for the period. (g) The prev_manifest_digest and the chain_id. (h) A reference to each anchor receipt (class, chain or service, and txid or proof identifier). (i) Evidence Store URIs for all included records. (j) Any Remediation Event Records in the window at BR2 or above, summarized with their Autonomy Mode and authorizing party. (k) Any separation-of-duties limitation disclosed per Section 8 requirement (9). A Scorecard that reports a composite score without reporting coverage is non-conformant with this revision. The two figures are meaningless apart: a score of 98 over 30% coverage is a weaker claim than a score of 82 over full coverage, and a Scorecard that presents only the former is misleading whether or not it intends to be. The Scorecard SHOULD be produced in a machine-parseable format (JSON) in addition to a human-readable format (PDF). 9.7. Independent Verification Any Verifier MUST be able to perform the following steps without access to internal systems or organizational trust. Steps (10) through (13) are new in -02. (1) Retrieve a specific evidence record from its published URI. (2) Re-compute the canonical serialization and digest, confirming it matches the "digest" field in the record. (3) Retrieve the Collector's public key from the published JWK Set using the "kid" in the "sig" field. (4) Validate the signature in the "sig" field over the "digest" value using the retrieved public key. (5) Retrieve the Aggregate Manifest for the relevant window. (6) Confirm the record's digest appears in the manifest's included record list. (7) Recompute the Merkle root from the manifest's record list per Section 7.2, using the ordering of Section 7.2.1 and the construction named in the manifest's "construction" field. (8) Confirm the recomputed Merkle root matches the manifest's stated Merkle root. (9) Confirm the manifest digest matches the on-chain commitment by independently querying the referenced blockchain, and confirm the commitment height precedes the close of the Anchor Window. (10) Retrieve the Control Register at the manifest's register_version, retrieve the CCA at "cca_digest", and confirm that every registered Control appears in the CCA. (11) Recompute observed_count for each Control from the manifest's included set and confirm it matches the CCA, then recompute coverage_ratio. (12) Walk the continuity chain across the range of interest, confirming the invariants of Section 7.4.3. (13) Where the range spans an algorithm migration, retrieve the Migration Bridging Record and confirm the segment roots under both algorithms, reporting the verification as conditional on that MBR. A Verifier completing all thirteen steps has independently confirmed both that the evidence presented is authentic and that no evidence which should have been presented is absent. The second property did not exist in -01. 9.8. Autonomous Remediation and Human Oversight This section is new in -02. 9.8.1. Scope Deployed resilience systems increasingly act on what they measure. An agent that restarts a failed collector, rotates a near-expiry certificate, or fails over a lagging replica is operationally valuable and is not, in itself, contrary to this protocol. Two failure modes are. The first is an automated action whose scope exceeds the confidence warranted by the signal that triggered it. The second is a remediation loop that repairs a symptom on every cycle without ever clearing the cause, so that the Scorecard reports health while the underlying fault persists indefinitely. Both were observed in the reference deployments described in Section 1.2, and the mechanisms below exist because of them. 9.8.2. Blast Radius Classes Every candidate remediation MUST be classified before execution: BR0: Observation, diagnosis, notification, or ticket creation. No change to system state. BR1: Reversible change confined to a single instance or process with no customer-visible effect, such as restarting a collector or clearing a local cache. BR2: Reversible change spanning multiple instances or altering configuration within a single failure domain, with a defined and tested rollback path. BR3: Change that is cross-domain, data-destructive, irreversible, or security-critical. This includes primary datastore failover, deletion or truncation of data, credential or key rotation in response to suspected compromise, modification of the Control Register, and any change to WORM retention settings. BR3 actions MUST NOT be executed automatically under any Autonomy Mode. They MUST be queued for human authorization, and the authorizing identity MUST be recorded in the RER. Where classification is ambiguous, the higher class MUST be assigned. 9.8.3. Autonomy Modes OBSERVE: The Remediator MAY propose actions and MUST NOT execute any. All proposals enter the decision queue. SUPERVISED: The Remediator MAY execute BR0 and BR1 automatically. BR2 and BR3 enter the decision queue. AUTONOMOUS: The Remediator MAY execute BR0, BR1, and BR2 automatically. BR3 enters the decision queue. The active Autonomy Mode MUST be recorded in every RER. A change of Autonomy Mode is itself a BR3 action. Regardless of mode, a finding arising from an Anchor Expectation of "immutable" (Section 7.3.4) MUST be escalated and MUST NOT be auto-remediated. 9.8.4. Circuit Breaker A Remediator MUST maintain, per (control_id, action_type) pair, a count of automated executions within a rolling window. When the count exceeds a configured threshold (RECOMMENDED: 3 executions in 24 hours) without the triggering condition clearing for at least one full aggregation window, the Remediator MUST: (1) Suspend automated remediation for that pair. (2) Emit an RER with the suspension and the observed counts. (3) Escalate to human review. (4) Continue to allow the underlying control to record FAIL results, which MUST continue to affect the score. The purpose is to prevent a Remediator from converting a persistent fault into an indefinite sequence of successful repairs. A system that repairs the same thing every hour is not resilient; it is failing every hour, and the Scorecard MUST report it that way. 9.8.5. Result Immutability Under Remediation Remediation MUST NOT alter the recorded result of the triggering evidence record. Specifically: (1) The triggering record MUST NOT be modified, deleted, or excluded from the window. (2) A Collector MUST NOT re-run a Control after remediation and submit the passing result in place of the failing one. A post-remediation verification check MAY be run and MUST be recorded as an additional record; both records are included in the window and both are scored. (3) Linkage between a triggering record and its RERs is carried by a separate linkage record referencing both digests, never by mutating the original record. (4) Where the same Control produces both FAIL and a subsequent PASS in one window, the scoring function of Section 10.2 MUST use the worst result observed for that Control in the window, not the most recent and not the mean. 9.8.6. Remediation Event Record An RER is an evidence record with "record_type": "remediation" whose "metadata" MUST include: "trigger_record_digest", "blast_radius" (BR0-BR3), "autonomy_mode", "action_type", "action_description", "authorized_by" (identity, or the literal "automated"), "outcome" (one of "executed", "queued", "refused", "failed"), and "rollback_available" (boolean). RERs are signed, stored, aggregated, and anchored identically to control records, and are therefore subject to the same tamper-evidence and the same coverage accounting. 10. Resilience Scorecard Specification 10.1. Pillars, Weights, and Renormalization RRP organizes resilience across five standard Pillars. Implementers MAY redefine pillar weights for their specific risk profile, provided weights sum to 1.0 (100%). The default weights are: +------------------------------+--------+---------+ | Pillar | Symbol | Weight | +------------------------------+--------+---------+ | Recovery Capability | RC | 0.25 | | Availability & Continuity | AC | 0.25 | | Security Integrity | SI | 0.20 | | AI Pipeline Resilience | AI | 0.15 | | Operational Compliance | OC | 0.15 | +------------------------------+--------+---------+ | Total | | 1.00 | +------------------------------+--------+---------+ Each Control in the Register MUST be assigned to exactly one Pillar. Implementers SHOULD ensure at least one Control is assigned to each active Pillar. Renormalization (new in -02). Revision -01 did not define the composite score when a Pillar had no assigned Controls; the summation simply lost that weight, silently deflating the composite by up to 25 points and making an implementation with fewer Pillars look worse than one with more, irrespective of resilience. The following rule applies: (1) Let A be the set of Pillars with at least one Control in the Control Register. If A is empty, the composite score is 0. (2) For each P in A, the effective weight is: w_eff(P) = weight_P / ( sum over Q in A of weight_Q ) (3) Pillars not in A contribute nothing and their weight is redistributed proportionally by (2). (4) The Scorecard MUST list every Pillar not in A and MUST publish the effective weights used. (5) Renormalization applies only to Pillars with no registered Controls. A Pillar whose registered Controls all failed to report MUST NOT be renormalized away. That case is missing coverage and is handled by Section 10.2, which reduces the score. This distinction is deliberate: renormalization must never become a mechanism by which failing to measure improves the reported score. 10.2. Scoring Algorithm For each Pillar P in A, let: C_P = set of registered Controls assigned to P O_P = subset of C_P that produced at least one valid, non-stale evidence record in the window r(c) = worst result observed for Control c in the window, mapped PASS=100, WARN=75, FAIL=0, ERROR=0 cov_P = per-Pillar coverage from Section 9.5.3 The raw pillar score over observed Controls is: raw_P = ( sum of r(c) for c in O_P ) / |O_P|, or 0 if |O_P| = 0 The coverage-adjusted pillar score is: adj_P = raw_P * cov_P The capped pillar score is: If any c in O_P has result FAIL or ERROR, or cov_P < 1.0: pillar_P = min( adj_P, 60 ) Else: pillar_P = adj_P The composite RRP score is: RRP_score = sum over P in A of ( w_eff(P) * pillar_P ) The composite score is a value in [0, 100]. Two changes from -01 are load-bearing. First, r(c) is the worst observed result rather than an average over records, so that a Control which fails once and passes nine times in a window is scored as having failed. Second, adj_P multiplies by coverage and incomplete coverage triggers the same 60 cap as an outright failure, so that not measuring is never scored better than measuring and finding a problem. Under -01, disabling a failing Control raised the score. Under this revision it lowers it. 10.3. Score Decay Evidence currency is critical to the integrity of the Scorecard. To prevent stale evidence from inflating scores: (1) If a Control has not produced any evidence record within the 48-hour period ending at scorecard generation time, its result MUST be treated as ERROR for scoring purposes and its observed_count for coverage purposes MUST be 0. (2) If a Control's most recent record is treated as ERROR due to staleness, the Scorecard Generator MUST annotate the Scorecard with a "stale evidence" warning for that Control. (3) Implementers MAY define shorter decay windows for higher- frequency controls (e.g., controls scheduled hourly may apply a 4-hour decay window). Decay windows MUST be declared in the Control Register and MUST NOT be adjusted retroactively for a window already scored. 10.4. Band Assignment and Hysteresis For reporting purposes, RECOMMENDED bands are: [90, 100]: Excellent - All controls passing with strong SLO margin and full coverage. [75, 90): Good - Minor warnings present; review recommended. [60, 75): Moderate - Multiple warnings, a capped pillar, or incomplete coverage; remediation required. [0, 60): At Risk - One or more critical failures or substantially incomplete coverage; immediate remediation required. Hysteresis (new in -02). Band assignment MUST be asymmetric: (1) A downward band transition takes effect immediately, in the first window whose composite score falls below the current band's floor. (2) An upward band transition takes effect only after two consecutive windows at or above the higher band's floor. This asymmetry is intentional. A score oscillating around a boundary should be reported at the lower band, because the condition producing the oscillation has not been resolved. Symmetric banding permits a system to be reported as Excellent on alternate days while a genuine intermittent fault persists, and operational experience with the reference deployments in Section 1.2 produced exactly that pattern before hysteresis was introduced. (3) The Scorecard MUST report both the raw band implied by the current composite score and the effective band after hysteresis, so that the mechanism is visible rather than appearing as a reporting lag. 11. Compliance Mapping RRP evidence records directly support audit evidence requirements across the following frameworks. Mappings marked "(new in -02)" were added in this revision. SOC 2 (Trust Services Criteria): CC7.1 (System Monitoring), CC7.2 (Anomaly Identification), CC7.3 (Evaluation of Security Events), A1.2 (Recovery Plan Testing), A1.3 (Recovery Objectives). RRP Pillars: Recovery Capability, Availability & Continuity. The Coverage Attestation is directly responsive to the completeness assertions an auditor makes about a population of controls, which is ordinarily established by inquiry and sampling rather than by cryptographic means. ISO/IEC 27001:2022: Annex A 5.29 (Information Security During Disruption), Annex A 5.30 (ICT Readiness for Business Continuity), Annex A 8.6 (Capacity Management), Annex A 8.16 (Monitoring Activities). RRP Pillars: Recovery Capability, Operational Compliance. ISO/IEC 42001:2023 (AI Management Systems): (new in -02) Clauses on operational planning and control, performance evaluation, and continual improvement for AI systems. RRP Pillar: AI Pipeline Resilience. Evidence of model drift scanning and of the remediation governance in Section 9.8 supports the operational control requirements. NIST SP 800-53 Rev 5: CP-4 (Contingency Plan Testing), CP-9 (System Backup), CP-10 (System Recovery and Reconstitution), SI-7 (Software, Firmware, and Information Integrity), SI-12 (Information Management and Retention), AU-9 (Protection of Audit Information), AU-10 (Non-Repudiation). RRP Pillars: all. AU-9 and AU-10 (new in -02) are the closest existing analogues to the tamper-evidence and continuity properties this protocol provides. NIST AI RMF 1.0: (new in -02) MEASURE 2.6 (deployed system safety), MANAGE 2.4 (mechanisms for deactivation and remediation). RRP Pillar: AI Pipeline Resilience. PCI DSS v4.0: Requirement 10 (Log and Monitor All Access), Requirement 11.6 (Change Detection), Requirement 12.10 (Incident Response Plan). RRP Pillars: Security Integrity, Operational Compliance. HIPAA Security Rule (45 CFR Part 164): 164.308(a)(7) (Contingency Plan), 164.312(c)(1) (Integrity), 164.312(b) (Audit Controls). RRP Pillars: Recovery Capability, Security Integrity. Implementations in this domain SHOULD operate in commitment mode (Section 6.4) so that evidence can be disclosed to an auditor without exposing the operational detail that accompanies it. DORA (EU Digital Operational Resilience Act): Article 11 (Response and Recovery), Article 12 (Backup Policies and Restoration), Article 25 (Testing of ICT Tools and Systems), Article 26 (Threat-Led Penetration Testing). RRP Pillars: Recovery Capability, Availability & Continuity, Operational Compliance. NIS2 Directive (EU 2022/2555): (new in -02) Article 21(2)(b) (incident handling), 21(2)(c) (business continuity and backup management), 21(2)(f) (assessing effectiveness of risk-management measures). RRP Pillars: Recovery Capability, Operational Compliance. Article 21(2)(f) requires assessment of effectiveness, which is a claim about the measurement regime rather than about any individual measurement, and is therefore addressed by the Coverage Attestation rather than by evidence records alone. EU AI Act (Regulation 2024/1689): (new in -02) Article 12 (record-keeping and automatic logging), Article 15 (accuracy, robustness, and cybersecurity), Article 17 (quality management system), Article 26 (deployer obligations, including log retention). RRP Pillars: AI Pipeline Resilience, Operational Compliance. Where an RRP deployment measures an AI system subject to the Act, the evidence records and Remediation Event Records together constitute the automatically generated logs contemplated by Article 12, and Section 7.5 addresses the retention horizon. Governance-specific record types are treated more fully in [DRAFT-AIGOV-00]. SEC Cybersecurity Disclosure Rules (17 CFR 229.106): (new in -02) Item 106(b) (risk management processes) and Item 1.05 of Form 8-K (material incident disclosure). RRP evidence provides dated, externally anchored support for statements about the existence and operation of resilience processes, and the continuity chain provides a defensible basis for statements about when a condition was first observed. Implementers SHOULD include compliance framework mapping metadata in the Control Register and in the "metadata" field of evidence records to facilitate automated compliance reporting. This mapping is informative. Nothing in this document constitutes legal advice, and mapping a Control to a framework citation does not establish that any regulator will accept the resulting evidence as sufficient. 12. Threat Model 12.1. Adversary Classes RRP considers the following adversary classes. The Omission Adversary is new in -02 and motivates most of this revision. Internal Attacker (IA): An employee or contractor with access to Collector infrastructure who may attempt to falsify evidence records or suppress evidence of failures. External Attacker (EA): An adversary without initial access who may attempt to tamper with stored evidence records, compromise Collector signing keys, or perform a blockchain reorganization. Omission Adversary (OM): (new in -02) An adversary, typically internal and often acting without any intent recognizable as attack, whose method is to arrange that unfavorable evidence is never produced. The OM disables a Collector, narrows a Control's scope, removes a Control from the schedule, or simply lets a broken Collector remain broken. The OM defeats -01 entirely, because every record that -01 verifies remains authentic. The OM is the most common adversary in practice, and is frequently indistinguishable at the technical level from ordinary operational neglect. Collusion (CO): Two or more internal parties (e.g., Collector operator and Evidence Store administrator) colluding to produce and store fraudulent evidence records. Availability Adversary (AA): An adversary whose goal is to prevent the Anchor from publishing within the Anchor Window, thereby creating gaps in the evidence chain. 12.2. Attack Scenarios and Mitigations Scenario 1: Evidence Record Tampering Threat: IA or EA modifies an evidence record after storage. Impact: Fraudulent resilience claim. Mitigation: WORM Evidence Store prevents modification. Verification: Canonical digest mismatch detected by any Verifier recomputing the digest. Scenario 2: Collector Key Compromise Threat: EA compromises a Collector's private signing key and generates fraudulent signed evidence records. Impact: Fraudulent records accepted by the Aggregator. Mitigation: HSM/KMS key storage (Section 8 requirement 1). Key revocation (Section 8 requirement 6) limits forward impact. Per-Collector keys (Section 8 requirement 3) limit blast radius. Scenario 3: Aggregator Manipulation Threat: IA manipulates Aggregator to exclude FAIL records from the Merkle tree or compute an incorrect root. Impact: Inflated score, incomplete audit trail. Mitigation: Aggregate Manifest is signed and stored in WORM. The "excluded" array is mandatory and non-omittable (Section 7.4.2). Section 9.4 forbids exclusion on the basis of result. The Coverage Attestation is produced by a separate principal and counts records the Aggregator would have to have included, so an excluded FAIL appears as a discrepancy between CCA observed_count and manifest content, which Section 9.5.4(4) requires the Verifier to check. Scenario 4: On-Chain Reorg Threat: EA performs a blockchain reorganization that removes the anchor transaction. Impact: Anchor receipt invalidated. Mitigation: Wait for sufficient confirmation depth before treating an anchor as finalized. RECOMMENDED: 6 blocks for Bitcoin, finalized checkpoint for Ethereum. Use of two independent chains plus class B and C anchors (Section 7.3) means all must fail simultaneously. Scenario 5: Anchor Window Denial Threat: AA disrupts Anchor infrastructure, preventing publication within the Anchor Window. Impact: Gap in the anchor sequence for that window. Mitigation: Redundant Anchor agents. The manifest is still produced and chained, so the continuity chain does not break. Late anchoring MUST be flagged in the Scorecard with an explanation. Anchor receipts obtained outside the window remain valid evidence of existence-by-time as of the later anchor, but MUST reduce the Scorecard score for the affected window, and MUST NOT be represented as timely. Scenario 6: Silent Control Omission (new in -02) Threat: OM disables a Collector or removes a Control from the schedule without a register change, so that no failing evidence is generated. Impact: Under -01, the score improves. Every remaining record verifies. Mitigation: The Control Register (Section 9.1.2) states in signed, anchored form what was expected. The Coverage Attestation reports observed_count 0 with status MISSING. Section 10.2 multiplies the pillar score by coverage and applies the 60 cap. Removing a Control legitimately requires a signed, dated register-change record naming the authorizing party (Section 9.1.3). Residual risk: an OM who controls both the Register and the Coverage Attestor can rewrite expectations going forward. This is bounded but not eliminated: the register-change record is itself anchored and chained, so the narrowing is visible as a dated act by a named party rather than as silence. Section 8 requirements (8) and (9) raise the number of principals that must cooperate. Scenario 7: Whole-Window Deletion (new in -02) Threat: IA deletes an entire window's records, manifest, and local anchor receipt. Impact: Under -01, undetectable from surviving artifacts. Mitigation: The continuity chain (Section 7.4) makes the following window's prev_manifest_digest unresolvable and leaves a gap in seq. Section 7.4.3 invariants (1) through (3) fail. Because manifests are anchored externally, the original chain remains provable from third-party anchors even if every internal copy is destroyed. Residual risk: deletion of the most recent window, with no successor yet produced, is detectable only via the external anchor. This is why class A anchoring of every manifest, including empty ones, is mandatory. Scenario 8: Remediation Masking (new in -02) Threat: An automated Remediator repairs a recurring fault on every cycle, or a Collector re-runs a Control after remediation and submits only the passing result. Impact: A persistent fault is reported as continuous health. Mitigation: Section 9.8.5 forbids replacing or suppressing the triggering record and requires worst-result scoring within a window. Section 9.8.4 requires a circuit breaker that suspends automated remediation and escalates when the same condition recurs. RERs are themselves evidence and appear in the Scorecard at BR2 and above. Scenario 9: Selective Disclosure Manipulation (new in -02) Threat: An implementation in commitment mode discloses only favorable fields, or discloses a field value with a salt chosen after the fact to produce a desired commitment. Impact: Misleading but individually verifiable disclosures. Mitigation: Section 6.4.2 requires "result" and "register_version" to be committed in every record, so the outcome cannot be omitted from a disclosure. Salts are 32-octet CSPRNG output that MUST NOT be derived from content, and the Commitment Root is fixed at record signing time and anchored, so a later choice of salt cannot produce a matching commitment without a preimage attack. Scenario 10: Baseline Poisoning (new in -02) Threat: An adversary causes an immutable-class target's baseline to be sealed from an error page, a redirect, or a response served during a compromise window. Impact: The false content becomes the reference against which all future observations are judged, so the real content later reads as the violation. Mitigation: Section 7.3.4 requires baselines to be sealed only on validated, successfully received responses. Implementations SHOULD seal a baseline only after N consistent observations from at least two network vantage points, and MUST record the sealing event as an evidence record so that the baseline's own provenance is auditable. 13. Security Considerations 13.1. Cryptographic Agility The signing algorithm and hash function are specified per-record via the "sig.alg" field and are expected to evolve. Implementers MUST NOT hard-code algorithm identifiers into verifier logic. Verifiers MUST support at minimum Ed25519 and ES256. This specification mandates SHA-256 for evidence and Merkle tree hashing. Migration to a successor hash is specified in Section 7.5 and is a first-class protocol operation rather than a future consideration, because the retention horizons this protocol targets make migration a certainty rather than a contingency. 13.2. Replay Attacks An adversary who obtains a valid signed evidence record for a PASS result may attempt to replay it for a future window. The "ts_start" and "ts_end" fields provide temporal scope. The Aggregator MUST reject records whose "ts_end" falls outside the current aggregation window. The "record_id" UUID prevents exact-duplicate submission within the same window, and the Coverage Attestation counts distinct record digests, so a replayed record does not increase observed_count. 13.3. Sybil Attacks on Public Key Publication An adversary may publish a forged public key at a URL designed to resemble a legitimate Collector's key endpoint. Implementers MUST publish Collector public keys at URLs under organizational control with DNSSEC enabled [RFC4033] and protected with TLS [RFC8446]. Verifiers MUST validate the TLS certificate of the key endpoint. Implementations SHOULD additionally publish the JWK Set digest through the continuity chain, so that a substituted key set is detectable without reliance on the endpoint's own integrity. 13.4. Privacy Evidence records MAY contain operationally sensitive data (e.g., system names, IP addresses, restore durations). They MUST NOT contain personally identifiable information (PII) or protected health information (PHI). Artifacts stored in the Evidence Store that contain sensitive data MUST be encrypted at rest. Only the artifact's URI and digest appear in the evidence record; the artifact itself is not on-chain. Commitment mode (Section 6.4) provides the mechanism by which individual fields may be disclosed without disclosing the record. Implementers handling regulated data SHOULD operate in commitment mode by default. Implementers MUST consider the tension between permanence and erasure obligations. Anchoring a digest is not publication of the underlying content, and deletion of the content leaves the anchor intact and meaningless, which is the intended behavior: the record of what was measured can be destroyed while the record that a measurement occurred survives. Where an erasure obligation attaches to content committed in an evidence record, the content MUST be held only in the Evidence Store and MUST be erasable there without breaking the chain. This property is treated in more detail in [DRAFT-AIGOV-00]. 13.5. Chain Selection Implementers SHOULD select blockchain networks with established proof-of-work or finalized proof-of-stake security. Chain selection criteria SHOULD include: years of continuous operation, total value secured, and reorganization history. 13.6. Transport Security All communications between Collectors, Signers, Evidence Stores, Coverage Attestors, Remediators, and Aggregators MUST use TLS 1.3 [RFC8446]. Certificate validation MUST be enforced; self-signed certificates are NOT RECOMMENDED in production deployments. 13.7. Salt Handling (new in -02) Field salts are the confidentiality boundary of commitment mode. Compromise of the salt store does not permit forgery, since commitments are already anchored, but it does permit confirmation of guessed values for low-entropy fields. Salts MUST be generated from a CSPRNG, MUST be unique per field per record, MUST NOT be derived from record content, and MUST be stored under access control separate from the records. Salt disclosure in a Selective Disclosure Response reveals only the disclosed fields, since each field has an independent salt. 13.8. Autonomy Risk (new in -02) Automated remediation introduces a class of harm that measurement alone does not. A Remediator with write access to production is a high-value target: an adversary who controls it can cause damage under the appearance of routine repair. Implementations MUST scope Remediator credentials to the specific actions its Blast Radius Class permits, MUST NOT grant a Remediator the ability to modify the Control Register, the Evidence Store retention configuration, or its own Autonomy Mode, and MUST record every action including refusals. The prohibition on automating BR3 is a security requirement, not a conservatism. The signals that trigger BR3 actions, such as suspected key compromise, are precisely the signals an adversary can most easily manufacture. 13.9. Trust Assumptions of the Coverage Attestation (new in -02) The Coverage Attestation shifts, but does not eliminate, the trust required. It converts "trust that they told you about every control" into "trust that the Control Register was honest at the time it was signed, and observe every subsequent change to it." An implementation that begins with a deliberately impoverished Register achieves full coverage trivially. This is a real limit and implementers should not overstate the guarantee. What the mechanism provides is that the scope of measurement is public, dated, externally anchored, and monotonically auditable: a narrowing is a visible act rather than an absence. Assessing whether a given Register is adequate to the risk remains a human judgment, and this protocol does not attempt to automate it. 14. Relationship to Other Protocols in the Suite RRP is one member of a suite of tamper-evident assurance protocols sharing a common architectural lineage: canonical serialization, per-record signing, immutable storage, Merkle aggregation, hash-linked chaining, and dual-layer anchoring. They are designed to interoperate and compose while remaining independently deployable. REM Protocol [DRAFT-REM-02]: The Reilly EternaMark Protocol defines dual-layer digital permanence for arbitrary artifacts via DOI registration and blockchain timestamping, and in its -02 revision defines the defensive publication mode under which anchored artifacts function as prior art records. RRP Aggregate Manifests and Scorecards SHOULD be archived using REM. The manifest digest and anchor receipts SHOULD be embedded in the REM metadata envelope. See Section 16. Bulk Subtree Proofs [DRAFT-BSP-01]: Defines a bulk subtree consistency proof that verifies a contiguous span of a Merkle log by descent over full subtrees at landmark breakpoints. RRP Verifiers auditing a multi-year retention period SHOULD use this construction rather than per-record inclusion proofs; see Section 7.2.3. CTS (Cognitive Trust Stack) [DRAFT-CTS-01]: Addresses AI behavioral provenance, bridging alignment claims and cryptographic proof. CTS-generated behavioral attestations MAY be incorporated as evidence in the AI Pipeline Resilience pillar. CBPI [DRAFT-CBPI-00]: Cognitive Behavioral Provenance and Integrity for autonomous AI agents defines Reinforcement Event Records, the Operant Provenance Chain, the Conditioning Authority, and the Behavioral Drift Index. The Remediator governance of Section 9.8 is deliberately compatible: where a Remediator is an adaptive agent rather than a fixed rule set, its behavioral drift SHOULD be tracked under CBPI and its Remediation Event Records MAY be dual-registered as CBPI Reinforcement Event Records. AIGOV [DRAFT-AIGOV-00]: Verifiable AI governance and data privacy records define the AI System Record, Governance Event Record, Register Completeness Attestation, and Erasure Record, and introduce erasure-compatible permanence. The Control Coverage Attestation of Section 9.5 and the Register Completeness Attestation of AIGOV are the same construction applied to different registers, and implementations operating both SHOULD share a single attestor and a single continuity chain. MWS [DRAFT-MWS-01]: Machine-Web Symbiosis frames the operational relationship between autonomous agents and web infrastructure within which an RRP Collector and Remediator operate. VSR [DRAFT-VSR-00]: Verifiable Safeguards Records for nuclear material accountancy applies commitment-based selective disclosure and century-scale hash migration to a domain with extreme retention requirements. The field commitment construction of Section 6.4 and the Migration Bridging Record of Section 7.5 are aligned with VSR so that a single verifier implementation serves both. RSP (Reilly Sentinel Protocol): Focuses on AI model behavioral integrity and inference attestation. RSP-generated model integrity proofs MAY be referenced as artifacts in RRP evidence records for the AI Pipeline Resilience pillar. RBIP (Reilly Banking Integrity Protocol): Extends RRP with domain-specific controls for financial institution resilience, including transaction reconciliation proofs and regulatory reporting anchoring. RGIP (Reilly Government Integrity Protocol): Extends RRP with controls for government IT and public record integrity, including FISMA alignment and FedRAMP control mapping. 15. Implementation Guidance This section provides non-normative guidance for implementers. 15.1. Cloud-Native Reference Architecture The following reference mapping to cloud primitives is provided: Evidence Store: Object storage with a compliance-mode immutability policy, such as S3 Object Lock in COMPLIANCE mode, Cloud Storage Bucket Lock, or Blob Storage immutability policies. Governance-mode locks are NOT RECOMMENDED, since an administrator who can lift the lock defeats the WORM assumption. Signer / KMS: A managed KMS with HSM-backed key material. Salt Store: A secrets manager or separate encrypted store, with an access policy disjoint from the Evidence Store reader policy. Coverage Attestor: A scheduled function in a separate account, project, or subscription from the Collectors, with read-only access to the Evidence Store and its own KMS key. Co-locating the Attestor with the Collectors is the most common way to build a conformant-looking implementation that provides none of the assurance. Anchor (class A): OpenTimestamps calendar client, or a dedicated transaction submitter for an EVM chain. Anchor (class B): A DOI registration agency deposit, batched monthly. Anchor (class C): Submission of the public manifest URI to web and source archives. Aggregator: A scheduled function triggered after the UTC window boundary, with WORM-write access. Scorecard Generator: A rendering pipeline producing PDF and JSON. 15.2. Bootstrapping Sequence New implementers SHOULD follow this sequence: (1) Define Controls and SLOs and publish the initial Control Register per Section 9.1. (2) Provision KMS keys for each Collector, the Aggregator, and the Coverage Attestor, observing Section 8 requirement (8). (3) Publish Collector public keys at well-known URLs. (4) Deploy Collectors with automated scheduling. (5) Deploy Evidence Store with WORM and TLS. (6) Deploy the Coverage Attestor under separation of duties. (7) Deploy Aggregator with WORM-write access. (8) Produce the genesis manifest with seq 0 and prev_manifest_digest of 64 zeros. (9) Configure Anchor agents across classes A, B, and C. (10) Produce the first Scorecard and verify end-to-end using the thirteen-step procedure in Section 9.7. (11) Run for at least one window with deliberately disabled Collectors and confirm that the Coverage Attestation reports them MISSING and that the composite score falls. An implementation that scores well with a Collector switched off is misconfigured, and this is the fastest way to find out. 15.3. Incremental Adoption Organizations with existing monitoring infrastructure SHOULD begin by wrapping one or two controls to validate the pipeline before expanding to the full Control set. The Evidence Schema is designed to be populated from existing check tool outputs with minimal transformation. A small Register operated honestly is more useful than a large Register operated partially. Implementers SHOULD register only Controls they intend to run, and SHOULD expand the Register deliberately rather than aspirationally, since coverage is measured against what is registered. 15.4. Migrating from -01 Implementations conforming to -01 SHOULD migrate as follows: (1) Continue anchoring under the -01 construction until the cutover window. Do not recompute historical roots. (2) Publish the initial Control Register describing the Controls already in operation. (3) Begin producing Coverage Attestations. Expect the first several windows to show coverage below 1.0; this is informative, not a defect. (4) Produce the genesis manifest of the continuity chain with "legacy_ref" pointing at the last root anchored under -01. (5) Switch the Merkle construction at the genesis manifest and record "construction": "rfc6962". (6) Enable commitment mode and Remediator governance independently and later; neither is required for a conformant -02 deployment, whereas the Register, the Coverage Attestation, the continuity chain, and the corrected Merkle construction are. 16. Prior Art and Defensive Publication Artifacts produced under this protocol are anchored using the dual-layer method of [DRAFT-REM-02]: an external timestamp establishing existence-by-time and an archival deposit establishing citable, resolvable persistence. Together these constitute a public, dated, and independently verifiable disclosure. Where an implementer wishes an RRP artifact to serve as a defensive publication, the artifact and its anchoring metadata MAY be treated as a Prior Art Record in the sense of [DRAFT-REM-02] Section 12.1, establishing the disclosure of its contents as of the anchored date for the purposes of 35 U.S.C. 102(a)(1) [USC-35-102] and equivalent provisions in other jurisdictions. Two constraints apply and are stated here because they are commonly misunderstood: (1) Anchoring a digest is not disclosure of content. A Prior Art Record requires that the content itself be publicly accessible. An anchored manifest digest with the manifest held privately establishes only that something existed, not what it was. (2) The date established is the date of anchoring, and the assurance is only as strong as the weakest anchor relied upon. Class C anchors (Section 7.3.3) are corroborative and SHOULD NOT be relied upon alone for this purpose. This document is itself published defensively. Nothing in this section constitutes legal advice, and whether any particular artifact qualifies as prior art in any particular proceeding is a question for counsel and the relevant authority. 17. IANA Considerations This revision makes concrete the registrations that -01 deferred. The author requests that IANA consider the following when this specification achieves sufficient implementation and community review. 17.1. Media Type Registrations Type name: application Subtype name: rrp-evidence+json Required parameters: none Optional parameters: none Encoding considerations: binary; JSON is UTF-8 encoded Security considerations: See Section 13 of this document. Interoperability considerations: See Section 6.3. Published specification: this document Applications that use this media type: RRP Collectors, Evidence Stores, Aggregators, and Verifiers Fragment identifier considerations: as for application/json Person and email address to contact for further information: L.J. Reilly Intended usage: COMMON Change controller: IETF The following additional subtypes are requested under the same template, differing only in the object they carry: application/rrp-manifest+json application/rrp-coverage+json application/rrp-scorecard+json 17.2. Well-Known URI Registration URI suffix: rrp Change controller: IETF Specification document: this document Status: permanent Related information: Implementations publish key material at /.well-known/rrp/keys.json, the Control Register at /.well-known/rrp/register.json, and the continuity chain head at /.well-known/rrp/chain-head.json. A single suffix with a defined internal layout is requested in preference to the three separate suffixes contemplated by -01, which would have consumed registry space unnecessarily. 17.3. Structured Syntax Suffix No new structured syntax suffix is requested. Revision -01 contemplated a "+rrp" suffix; on review this is unnecessary, since RRP documents are JSON and CBOR documents and the existing "+json" and "+cbor" suffixes are sufficient. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015. 18.2. Informative References [RFC7089] Van de Sompel, H., Nelson, M., and R. Sanderson, "HTTP Framework for Time-Based Access to Resource States -- Memento", RFC 7089, DOI 10.17487/RFC7089, December 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [FIPS204] National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024. [I-D.SCITT-ARCH] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, . [DRAFT-REM-02] 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, . [DRAFT-RRP-00] Reilly, L.J., "Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience", Work in Progress, Internet-Draft, draft-reilly-resilience-protocol-00, September 2025, . [DRAFT-RRP-01] Reilly, L.J., "Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience", Work in Progress, Internet-Draft, draft-reilly-resilience-protocol-01, March 2026, . [DRAFT-CTS-01] Reilly, L.J., "Cognitive Trust Stack (CTS): Cryptographic Behavioral Provenance for AI Systems", Work in Progress, Internet-Draft, draft-reilly-cts-01, 2026, . [DRAFT-CBPI-00] Reilly, L.J., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-reilly-cbpi-00, 2026, . [DRAFT-AIGOV-00] Reilly, L.J., "Verifiable AI Governance and Data Privacy Records", Work in Progress, Internet-Draft, draft-reilly-aigov-00, 2026, . [DRAFT-MWS-01] Reilly, L.J., "Machine-Web Symbiosis (MWS)", Work in Progress, Internet-Draft, draft-reilly-mws-01, 2026, . [DRAFT-VSR-00] Reilly, L.J., "Verifiable Safeguards Records (VSR) for Nuclear Material Accountancy", Work in Progress, Internet-Draft, draft-reilly-vsr-00, 2026, . [DRAFT-BSP-01] Reilly, L.J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-reilly-plants-bulk-subtree-proofs-01, 2026, . [RRP-WHITEPAPER-V2] Reilly, L.J., "The Reilly Resilience Protocol (RRP): A Tamper-Evident, Blockchain-Anchored Framework for Proving IT, Cloud, and AI System Resilience", Zenodo, DOI: 10.5281/zenodo.17100703, September 11, 2025, . NOTE: This whitepaper was blockchain timestamped and DOI archived on September 11, 2025, at the time of its upload to Zenodo. [NIST-800-53] National Institute of Standards and Technology, "Security and Privacy Controls for Information Systems and Organizations", NIST Special Publication 800-53 Rev 5, September 2020, . [NIST-AI-RMF] National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1, January 2023, . [OPENTIMESTAMPS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", . [USC-35-102] United States Code, "Conditions for patentability; novelty", 35 U.S.C. 102. [EU-DORA] European Union, "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector", December 2022. [EU-NIS2] European Union, "Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union", December 2022. [EU-AI-ACT] European Union, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence", June 2024. Appendix A. Changes from -01 The following substantive changes were made from draft-reilly-resilience-protocol-01 to this revision (-02). A.1. Merkle Tree Construction Corrected (Section 7.2) Revision -01 duplicated the final digest when the leaf count was odd and attributed that construction to [RFC9162]. The attribution was incorrect: [RFC6962] and [RFC9162] promote the odd node rather than duplicating it. Duplication permits distinct leaf multisets to produce identical roots and prevents consistency proofs. Section 7.2 now specifies the [RFC6962] construction in full, including the empty-tree and single-leaf cases, with test vectors and an explicit statement of the non-conformant -01 computation. A.2. Leaf Ordering Changed (Section 7.2.1) Ordering by digest, as in -01, is replaced by ordering by (ts_end, record_id). Digest ordering destroyed temporal sequence and made concatenation of windows non-monotone, which is why -01 could not support consistency proofs. A.3. Control Register Introduced (Section 9.1.2, 9.1.3) A signed, versioned, published register of the Controls an implementation asserts it operates. Changes to the register are themselves evidence records requiring a named authorizing party. A.4. Control Coverage Attestation Introduced (Section 9.5) The principal addition of this revision. A signed per-window statement enumerating every registered Control with expected and observed record counts, produced by a principal with a key distinct from the Collectors, committed by the Aggregate Manifest, and therefore anchored. This converts the absence of evidence into a verifiable claim and closes the Omission Adversary gap described in Sections 1.1 and 12.1. A.5. Evidence Continuity Chain Introduced (Section 7.4) Aggregate Manifests are hash-linked by sequence number and predecessor digest, with mandatory window adjacency, so that deletion or reordering of a window is detectable. Empty Window Records replace the -01 behavior of producing no anchor when a window was empty, under which silence and suppression were indistinguishable. A.6. Anchoring Restructured (Section 7.3) The anchored value is now the Aggregate Manifest digest rather than the bare Merkle root, so that anchoring transitively covers the coverage attestation and the prior chain. Anchors are organized into three classes: blockchain, persistent identifier, and keyless archival. Anchor Expectations for measured external targets (live, dynamic, immutable) are defined, with immutable violations forced to human review. A.7. Field Commitments and Selective Disclosure (Section 6.4) Salted per-field commitments with a Commitment Root, and a Selective Disclosure Response format, allowing an individual field to be proven against an anchored root without disclosing the record. Addresses the privacy posture of -01 Section 13.4, which stated requirements but supplied no mechanism. A.8. Autonomous Remediation Governance (Section 9.8) New Remediator role with Blast Radius Classes BR0 through BR3, Autonomy Modes OBSERVE, SUPERVISED, and AUTONOMOUS, a mandatory circuit breaker, Remediation Event Records, and a prohibition on remediation altering the result of the triggering record. BR3 actions are never automated. A.9. Hash and Signature Migration (Section 7.5) Migration Bridging Records permit a chain segment computed under a retiring algorithm to be bound to its recomputation under a successor, without rewriting history. Required because the protocol's retention horizons exceed the confident lifetime of any specific algorithm. A.10. Scoring Corrections (Section 10) Weight renormalization is defined for Pillars with no registered Controls, an undefined case in -01 that silently deflated the composite. A coverage factor multiplies each pillar score, and incomplete coverage triggers the same cap as an outright failure, so that disabling a failing Control now lowers the score rather than raising it. Within a window, a Control is scored on its worst observed result rather than its most recent. Band assignment gains asymmetric hysteresis: downward transitions are immediate, upward transitions require two consecutive windows. A.11. Scorecard Requirements Expanded (Section 9.6) Coverage ratio, missing Controls, chain position, effective weights, and BR2-and-above remediations are now mandatory content. A Scorecard reporting a composite score without coverage is non-conformant. A.12. Verification Procedure Extended (Section 9.7) The nine-step procedure of -01 becomes thirteen steps, adding register and coverage verification, continuity chain walking, and migration bridging where applicable. A.13. Key Management Extended (Section 8) Three new requirements: distinct keys for Aggregator, Coverage Attestor, and Collectors; separation of duties between Aggregator and Coverage Attestor with mandatory disclosure where unachievable; and continuity of the chain across key revocation. A.14. Threat Model Extended (Section 12) New Omission Adversary class. New scenarios 6 through 10: silent control omission, whole-window deletion, remediation masking, selective disclosure manipulation, and baseline poisoning. Residual risks are stated explicitly rather than implied. A.15. Security Considerations Extended (Section 13) New subsections on salt handling, autonomy risk, and the trust assumptions of the Coverage Attestation, the last of which states plainly what the new mechanism does not guarantee. A.16. Compliance Mapping Extended (Section 11) Added ISO/IEC 42001, NIST AI RMF, NIS2, EU AI Act, SEC cybersecurity disclosure rules, and additional NIST 800-53 controls (CP-4, AU-9, AU-10). Corrected the DORA article mapping, which in -01 cited Article 11 as backup policies; in Regulation (EU) 2022/2554, backup and restoration are addressed in Article 12 and response and recovery in Article 11. A.17. Suite Relationships Updated (Section 14) Updated to reference the current suite, including bulk subtree proofs for efficient long-range verification, CBPI for adaptive remediators, AIGOV for the shared attestation construction, VSR for aligned commitment and migration mechanisms, and MWS. A.18. Prior Art Section Added (Section 16) Documents the treatment of RRP artifacts as prior art records under 35 U.S.C. 102(a)(1), consistent with [DRAFT-REM-02], with explicit statement of the two constraints most commonly misunderstood. A.19. IANA Considerations Made Concrete (Section 17) Full media type registration templates for four subtypes, a single /.well-known/rrp suffix with defined internal layout in place of the three suffixes contemplated by -01, and withdrawal of the proposed "+rrp" structured syntax suffix as unnecessary. A.20. Schema and Reference Updates "rrp_version" advanced to "1.2". New optional fields "record_type", "register_version", "anchor_expectation", "remediation_ref", and "commitments". UUID reference updated from RFC 4122 to RFC 9562; timestamp handling now cites RFC 3339 explicitly; I-JSON (RFC 7493) added for number handling; RFC 6901 added for JSON Pointer; RFC 6962 promoted to normative; RFC 7089 and RFC 7942 added; FIPS 180-4 and FIPS 204 added. RFC 5652 and RFC 7519, cited in -01 but unused in the body, are removed. A.21. Implementation Status Added (Section 1.2) An [RFC7942] implementation status section describing the reference deployments from which the hysteresis, circuit breaker, and anchor expectation mechanisms were derived. Appendix B. Worked Continuity Verification Example This appendix is informative. It illustrates detection of a deleted window. An auditor is given manifests for seq 100 through 106 and asked to confirm continuous operation for that period. Step 1. The auditor confirms seq values 100, 101, 102, 104, 105, 106. Invariant (1) of Section 7.4.3 fails: 103 is absent. Step 2. The auditor computes the digest of manifest 102 and compares it to manifest 104's prev_manifest_digest. They do not match, because manifest 104 committed to manifest 103. The organization's explanation that "nothing happened that day" is inconsistent with the artifacts it has itself published, since an empty window would have produced manifest 103 with merkle_root = MTH({}) rather than no manifest at all. Step 3. The auditor checks window adjacency. Manifest 102 ends at 2026-08-12T00:00:00Z and manifest 104 begins at 2026-08-14T00:00:00Z. Invariant (3) fails; twenty-four hours are unaccounted for. Step 4. The auditor queries the class A anchor for the period. If the organization anchored manifest 103 before deleting it, the on-chain commitment persists and the auditor recovers the digest of the deleted manifest, though not its contents. The organization can be asked to produce a manifest matching that digest, and cannot. Step 5. The auditor queries class C archival anchors. Where a third-party archive captured the manifest URI, the contents of the deleted window may be recoverable in full. Step 6. The auditor examines the Coverage Attestations for windows 102 and 104. If Control coverage drops sharply in 104 relative to 102, the deletion likely coincided with an operational failure rather than a routine gap. Under -01, steps 1 through 6 were unavailable. The auditor would have been given six authentic manifests, would have verified all six successfully, and would have had no basis on which to ask about the seventh. Author's Address Lawrence John Reilly Jr. REM Technologies & Consulting, LLC Email: lawrencejohnreilly@gmail.com IETF Datatracker: https://datatracker.ietf.org/person/lawrencejohnreilly@gmail.com Zenodo Archive: https://zenodo.org/records/17100703 DOI: 10.5281/zenodo.17100703