Attestation Reconciliation Protocol

4.1. Canonical Claim Ingestion

A Canonical Claim comprises:¶

• Subject Identifier¶

• Predicate (drawn from the controlled Predicate Taxonomy)¶

• Attested Value (in the canonical type for the Predicate)¶

• Applicable-Regimes Set¶

• Evidentiary Provenance Manifest¶

• Claim Timestamp ([RFC3339] UTC)¶

• Claim Hash: the SHA-256 digest over the deterministically encoded CBOR array ["arp-claim-v1", Deployment Blinding Value, canonical serialisation], where the canonical serialisation is the [RFC8785] form of the preceding fields as Section 3 constructs it, carried as a CBOR byte string. Framing the blinding value as an array element rather than concatenating it is what stops two deployments differing on order, separator or length prefix while claiming the same construction identifier¶

Two claims whose canonical field values are identical MUST produce the same canonical form, and the same Claim Hash within one deployment. Across deployments the Claim Hash differs by the Deployment Blinding Value while the canonical form does not. Declared array order is significant; claims differing only in declared array order are distinct claims. The Claim Hash is the index on the Settlement-Layer Ledger and the key for retroactive re-evaluation.¶

The Evidentiary Provenance Manifest MAY be carried in any COSE-enveloped evidence structure; the container form is an interop convenience and does not alter the Claim Hash, which is computed as Canonical Claim Ingestion constructs it and over nothing else.¶

4.2. Requester Identity Binding and Agent Friend-or-Foe Gate

Before the Adversarial Pre-Transmission Test, the reconciliation server MUST establish the identity of the Requesting Principal and record it in a Requester-Binding field. The Requester-Binding comprises a requester-binding class, the identifier of the accountable principal where known, and a reference to the verification method used. The class is one of:¶

• human-operator, where an authenticated human or institutional operator is the accountable principal.¶

• agent-verified, where an agent's signing key verified AND the principal it asserts was corroborated by a reconciliation under Section 5 or by a Verified Principal Credential whose status was checked.¶

• agent-key-verified, where an agent's signing key verified but the principal it asserts was not corroborated.¶

• agent-unverified, where the request was signed under a bare key that resolves to no signature-agent card, carries no Verified Principal Credential, and asserts no principal. The key gives continuity of identity between requests and nothing else, which is why it is a class and not a refusal; a request that carries no verifying signature at all is not admitted, by Section 6.4.1.¶

agent-key-verified exists because possession of a key and binding to a principal are different facts and earlier revisions recorded them as one. An agent that signs correctly under a Web Bot Auth key has demonstrated that it is the same agent as last time; it has not demonstrated that any accountable party stands behind it. Recording that state as agent-verified overclaims to every downstream reader, and recording it as agent-unverified discards a real and useful fact. A relying party that requires an attributable principal should treat agent-key-verified as it treats agent-unverified; one that requires only continuity of identity may treat it as it treats agent-verified. This document states no requirement on a relying party's own risk policy; what it requires is that the two states be recorded distinctly so that the policy can be applied. The Agent-IFF policy states which reconciliations may be decisive at each class.¶

Where the requester is an autonomous agent, the server MUST perform an Agent Friend-or-Foe (IFF) Determination. An agent is classified FRIENDLY only where at least one verifiable identity is present and cryptographically valid: a request signed under HTTP Message Signatures [RFC9421] with a key resolvable through a Web Bot Auth signature-agent card [I-D.meunier-webbotauth-registry], advertised via the Signature-Agent header [I-D.meunier-webbotauth-httpsig-protocol] and resolved through the HTTP Message Signatures directory it names [I-D.meunier-webbotauth-httpsig-directory], a genuinely verified declared bot, or a Verified Principal Credential. An agent presenting no such identity, or an identity that fails verification, MUST be classified ENEMY.¶

The Agent-IFF policy in force declares, per predicate class, whether an ENEMY requester is refused outright, permitted only for non-decisive advisory reconciliation, or permitted with the requester-binding class recorded as agent-unverified, and whether an agent whose key verified but whose principal was not corroborated -- class agent-key-verified -- may reach a decisive verdict. The server MUST NOT silently upgrade an ENEMY requester to FRIENDLY. The Requester-Binding and the Agent-IFF policy identifier are committed to the Policy-Version Hash so that the settlement record is attributable to a determined requester class.¶

4.3. Adversarial Pre-Transmission Test

Before any Per-Register Claim Projection is produced, the Adversarial Pre-Transmission Test Subsystem applies the current Pattern Library to the Canonical Claim. The Pattern Library enumerates structural evasion patterns against the projection and aggregation mechanisms of this protocol, including projection-narrowing-evasion, predicate-substitution-evasion, attested-value-bracketing-evasion, addressed-register-cherry-picking, agreement-staleness-injection, pattern-library-version-pinning, and agent-principal-spoofing (an unverifiable agent asserting a principal binding it does not hold).¶

The Subsystem emits either a Pass result or a Remediation Advisory. A Remediation Advisory comprises:¶

• a Refusal Ground, one of pattern-matched, regime-not-admitted, audience-member-not-enrolled or agent-iff-refused¶

• the identifiers of the Pattern Library patterns that matched, and the narrowing or substitution each concerns, present exactly where the Ground is pattern-matched¶

• the regime, the Audience Member Identifier or the Agent-IFF ground the other three Grounds concern respectively, present under the corresponding Ground¶

It is encoded as a CBOR array in that field order under the media type registered in Section 9, absent fields as CBOR null, and is returned to the requester as Section 6.2 provides. No projection is transmitted and no Reconciliation Output is produced. The Advisory is the only artefact a refused requester receives, so it carries the ground rather than leaving the requester to infer it.¶

The Per-Register Encryption Subsystem MUST architecturally withhold external transmission until a Pass result has been emitted or until an authorised operator has explicitly overridden the outcome. An override MUST be recorded in the Reconciliation Output as an Override Record and is thereby covered by the Sealing Signature. An override that left no artefact would be indistinguishable from a Pass to every external party, which would make the only manual bypass of the protocol's own adversarial gate invisible to the regulators that gate exists to serve.¶

An Override Record comprises:¶

• the identifiers of the Pattern Library patterns that matched¶

• the Pattern-Library Version Identifier under which they matched¶

• the Override Ground, drawn from the registry of Section 9¶

• the identifier of the authorising operator¶

• an Override Timestamp ([RFC3339] UTC)¶

• a signature by the authorising operator, a COSE_Sign1 whose payload is the CBOR array of the fields above in the order listed with the signature position encoded as CBOR null, encoded under Section 4.2.1 of [RFC8949], and carrying as its key identifier the JWK thumbprint, computed as in [RFC7638], of a key published in the reconciliation server's Operator Key Set at /.well-known/arp-operator-keys on its authority origin. That key set is published and validated as the sealing key set of Section 6.5.3 is, save that the Authorised-Origin Document MUST name a key identifier for the operator key set distinct from the one anchoring the sealing key set. Sealing keys and operator keys are separate sets because they are held by different parties for different purposes: a server able to sign an override with its sealing key could manufacture an operator's authorisation, and a server holding the only key that anchors its own operator key set could do the same one level up¶

The signature is by the operator and not by the server. A record the server signs attests only that the server says an operator authorised the bypass; a record the operator signs is a statement the operator made and cannot later disown, which is what a manual override of an adversarial gate has to be for the regulator reading it. The Override Ground is drawn from a registry so that grounds are enumerable and comparable across deployments rather than free text that no reviewer can aggregate.¶

The reconciliation entry that records an overridden reconciliation carries an Override Indicator, so that a regulator reading the Ledger under Section 4.19 can see that a bypass occurred without holding the Output. Having seen it, the regulator reads the Output itself under Section 4.20 or through the entitlement its statutory scope gives it, and reads the Record. An Override Record visible only to the Audience Set the operator chose to serve would be invisible to the party the mechanism exists for, which is the failure this paragraph and the Indicator together close.¶

The Record names an operator in the clear, in an artefact whose Policy-Version Hash is blinded under Section 4.16 precisely to keep principal identities out of reach. That is not a contradiction: blinding protects the Ledger, which is published, and the Reconciliation Output is confidential to its Audience Set under Section 4.15. An override is a discretionary act by a named human against a named pattern, and the parties entitled to the Output are the parties entitled to know who performed it. Nothing about the override reaches the Ledger except through the Reconciliation Hash, which is a digest.¶

4.4. Per-Register Projection Function

For each addressed register, the controlled projection function MUST inspect the Canonical Claim against the permitted-predicate set declared in the Bilateral Register Agreement. Where the Canonical Claim's Predicate is directly a member of the permitted-predicate set, the Projected Predicate equals the Canonical Claim Predicate.¶

Where it is not, the projection function resolves the Predicate through taxonomic prefix match: walking the Predicate Taxonomy upward from the Canonical Claim Predicate until reaching a Predicate that is a member of the permitted-predicate set. Where the walk reaches more than one such Predicate at the same taxonomic distance, the projection MUST fail with projection-ambiguous rather than choose between them. Where the walk reaches the taxonomy root without finding one, the projection MUST fail with projection-unsupported. The narrowing operation MUST be recorded in the Narrowed-From field of the Per-Register Claim Projection.¶

A Per-Register Claim Projection comprises:¶

• Reconciliation Identifier¶

• Register Identifier¶

• Projected Predicate¶

• Subject Reference, in the form the addressed register's Bilateral Register Agreement declares¶

• Attested Value, where the Projected Predicate takes one¶

• Narrowed-From, absent where the Projected Predicate equals the Canonical Claim Predicate¶

• Bilateral-Register-Agreement Hash¶

• Policy-Version Hash¶

• Freshness Window, as declared in the Bilateral Register Agreement¶

• Reconciliation Nonce¶

• Profile Parameter Set, being the values the Bilateral Register Agreement declared under Section 4.5 that the register is to apply¶

• OPTIONAL Requester-Binding Class, present exactly where the Bilateral Register Agreement requires it under Section 7.1, disclosing the class and not the principal¶

A Per-Register Claim Projection is encoded as a CBOR array in the field order above, an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved. This is the only structure a sovereign register receives, and it is enumerated here so that its contents are determinate and its digest constructions reproducible.¶

The wire binding over which it is transmitted is not specified by this document. This document specifies what the channel must achieve -- the structure it carries, the confidentiality and authenticated-additional-data properties of Section 4.7, and the Query Binding the register signs over -- and leaves the transport, the endpoint, the framing and the concrete encryption construction to be declared in each Bilateral Register Agreement.¶

That is a deliberate scoping decision and it is a real limitation, stated here rather than left to be discovered: two reconciliation servers addressing the same register do so over channels the register defined, so ARP is interoperable in its artefacts and not yet in that leg's transport. Specifying it -- an endpoint, a media type, and a COSE_Encrypt construction pinning the AEAD and the ordering of its authenticated additional data -- is the principal item of work this revision leaves for the next. The register does not receive the Canonical Claim, the Addressed-Registers Identifier Set, or any other register's projection.¶

The register echoes the Policy-Version Hash in its Partial Attestation; it does not compute it, and it is not required to be able to. The reconciliation server MUST send the same Policy-Version Hash to every addressed register in one reconciliation, and MUST verify on reception that each Partial Attestation echoes it. A mismatch MUST be treated as a refusal by that register and recorded under Section 4.11. Without this the per-register signatures over the Policy-Version Hash -- the only independent corroboration of it -- would be discarded at aggregation, and a server could address different registers under different policy versions undetectably.¶

4.5. Register Data-Format Profiles

A Bilateral Register Agreement MUST declare the data format in which the addressed register expresses the facts the permitted-predicate set ranges over. The projection function of Section 4.4 operates on predicates, not on records; a format profile is what lets an implementer determine which predicates a given register can actually answer, and what a narrowing means against that register's own structure.¶

A profile is a property of a data format, not of a register. It states, for the format it covers, how a permitted predicate is expressed and what the Predicate Taxonomy's parent relation corresponds to in that format. Parameters that vary between registers using the same format -- interest thresholds, maximum chain depths, the set of named lists and the identifiers a register uses for their states -- are not properties of the profile and MUST be declared in the Bilateral Register Agreement. A profile MUST enumerate the parameters a Bilateral Register Agreement declaring it is required to supply, and MUST state which of its predicates are threshold-sensitive per Section 3, on which the third re-typing ground of Section 4.12 turns.¶

Without that split a single registered identifier would carry facts that differ between registers, and two registers using the same format under different thresholds could not both declare it. A profile MUST NOT introduce a means of transporting register records; profiles constrain predicate expression only.¶

The vocabulary documents a profile names are informative to this document and normative to an implementation of that profile: an implementation cannot evaluate a projection expressed in a vocabulary without it. A profile MUST pin the dated version of each vocabulary it names.¶

This document defines four profiles, with the identifiers registered in Section 9:¶

• arp-profile-bods (Section 4.5.1)¶

• arp-profile-corporate-org (Section 4.5.2)¶

• arp-profile-customs-wco (Section 4.5.3)¶

• arp-profile-sanctions-consolidated (Section 4.5.4)¶

Identifiers beginning x- are reserved for bilateral use and MUST NOT be registered. A Bilateral Register Agreement MAY declare one.¶

Each of the four profiles below states the dated vocabulary it uses where it names one, the parent relation for each branch of its predicate space over which narrowing is defined, the parameters a Bilateral Register Agreement declaring it must supply, and which of its predicates are threshold-sensitive within the meaning of Section 4.12.¶

4.6. Source-Data Version Binding

Where a register's answer depends on a source data state that changes independently of the Bilateral Register Agreement and of the Policy Version -- a consolidated sanctions list being the characteristic case -- the Partial Attestation MUST carry a Source-Data Version Identifier Set: one identifier for each source consulted in evaluating the Projected Predicate. Each identifier is a tuple of the list name as declared in the Bilateral Register Agreement and the state identifier the LIST PUBLISHER assigns to that state -- a published version token, or a digest of the published corpus where the publisher assigns none -- rather than any value of the register's own devising. A register-chosen opaque string would be an arbitrary-bandwidth channel from register to relying party, carried under signature into a sealed and ledgered artefact, and the rule that differing identifiers MUST NOT be read as disagreement would normalise it. The reconciliation server MUST reject an identifier that is not drawn from the publisher's own state sequence, under Section 4.11 with the reason attestation-unverifiable. The tuple form is what keeps identifiers issued by one register over different lists from colliding, so that a register consulting several lists can denote the state of each.¶

The Source-Data Version Identifier Set MUST be carried in the arp-source-data-version COSE header parameter of the Partial Attestation's protected header, and is thereby covered by the Partial-Attestation signature. It MUST be carried into the Per-Register Result Set of Section 4.14 for each addressed register that supplied one, and is thereby covered by the Sealing Signature.¶

A register MUST evaluate every Projected Predicate over a given list against the state the corresponding member of its declared Source-Data Version Identifier Set denotes, and MUST use the same identifier for every Partial Attestation it issues over that list until it adopts a new state. Without this the identifier would vary per subject and become a disclosure channel.¶

Given that requirement this does not weaken minimum disclosure: a list-state identifier is a property of a published corpus rather than a register record, it discloses which published state was consulted and nothing about the subject entity, and it is identical across every Partial Attestation the register issues over that list regardless of verdict.¶

Retroactive Evaluation depends on this. On re-evaluation under an updated Pattern Library or Policy Version, an implementation MUST distinguish a material change in a historical Combined Verdict arising from the change in policy state from one arising from a change in Source-Data Version. Both MUST trigger Sovereign Re-Notification where material, and the notification MUST state which of the two occurred. Where an implementation cannot distinguish them, it MUST emit a Post-Seal Evaluation Record carrying attribution-indeterminate per Section 4.17 rather than attribute the change to policy.¶

An implementation MUST NOT infer that two Partial Attestations whose Source-Data Version Identifier Sets differ for a list they have in common disagree. They may be answers to the same predicate against different states of the same corpus. The reconciliation server MUST record this as source-version-skew, which is distinct from freshness-stale: a skewed attestation is within its freshness window and is retained and combined, whereas a stale one falls outside that window and is rejected under Section 7.6.¶

4.7. Per-Register Encryption

These are requirements on whatever bilateral channel Section 4.4 leaves each Bilateral Register Agreement to declare; they are properties the channel MUST provide and not a wire construction this document pins.¶

Each Per-Register Claim Projection MUST be encrypted under the addressed register's public key material declared in the Bilateral Register Agreement. The Reconciliation Nonce MUST be transmitted in the clear alongside the ciphertext, and the encryption operation MUST bind the Bilateral-Register-Agreement Hash and that nonce into the ciphertext as authenticated additional data, such that a register attempting to decrypt under a stale Bilateral-Register-Agreement Hash, or with a nonce other than the one the ciphertext was sealed against, fails at the authenticated-additional-data verification step. The register MUST verify that the nonce so bound equals the Reconciliation Nonce field of the decrypted projection.¶

The nonce travels in the clear because authenticated additional data is an input to the decryption operation and cannot be recovered from the plaintext that operation produces. It discloses nothing: it is a random value carrying no information about the subject or the claim.¶

These two are the only values so bound. Authenticated additional data detects a mismatch only against an expectation the receiver independently holds. A register independently holds its own agreement, and it is handed the nonce. It does not hold the Pattern-Library Version Identifier: the Pattern Library is the reconciliation server's internal adversarial-test corpus and is not published to registers, so binding it would either fail universally or be supplied alongside the ciphertext by the same party that chose it, detecting nothing.¶

A register MUST NOT issue more than one Partial Attestation for a given Reconciliation Nonce, and MUST reject a projection whose nonce it has already answered. Without this a captured ciphertext could be replayed indefinitely, each replay yielding a freshly timestamped signed attestation and defeating the freshness window of Section 7.6.¶

4.8. Partial Attestation Reception

A Partial Attestation comprises:¶

• Register Identifier¶

• Reconciliation-Verdict Field (match, no-match, partial-match, or indeterminate)¶

• OPTIONAL Divergence-Axis Field¶

• Bilateral-Register-Agreement Hash¶

• Policy-Version Hash¶

• OPTIONAL Source-Data Version Identifier Set, present where required by Section 4.6 and carried in the arp-source-data-version COSE header parameter of Section 9¶

• OPTIONAL Applied-Parameter Set, being the profile parameters the register actually applied in evaluating the Projected Predicate, present wherever the Profile Parameter Set of the Per-Register Claim Projection was non-empty¶

• Query Binding, the SHA-256 digest over the deterministically encoded CBOR array ["arp-query-binding-v1", Reconciliation Identifier, Projected Predicate, Subject Reference, Reconciliation Nonce], those four values taken from the Per-Register Claim Projection it answers. The construction is a five-element array whose first element is a fixed domain-separation string, rather than a byte concatenation, so that two implementations cannot differ on framing and the digest cannot collide with any other construction in this document¶

• Freshness Timestamp¶

• Cryptographic Signature, a COSE_Sign1 by the register whose payload is the CBOR array of the fields above in the order listed, with an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved, encoded under Section 4.2.1 of [RFC8949]. The register's signing key is published in its key set under Section 6.5.3, so that a relying party or auditor holding the attestation can resolve the key and verify the signature without the reconciliation server's assurance¶

The Query Binding is what makes an attestation an answer to a question rather than a free-standing assertion. Without it the signed payload says only that a register returned a verdict under some agreement and policy version at some time, and says nothing about what it was asked. Two consequences follow, and both are severe: an attestation harvested for one subject could be placed into the Per-Register Result Set of a reconciliation about another subject and would verify against every other check; and a register could answer the same question differently to two requesters and deny having done so, because its signature would not identify the question.¶

The arp-policy-version-hash and arp-bilateral-agreement-hash in a Partial Attestation's protected header MUST equal the corresponding payload fields, and an implementation MUST reject an attestation where they differ: a value carried twice with no equality rule is a value an implementation may read either way.¶

The reconciliation server MUST recompute the Query Binding from the projection it transmitted and MUST reject an attestation whose Query Binding does not match, under Section 4.11 with the reason attestation-unverifiable.¶

The Query Binding Record of Section 4.14 carries the three projection values and the register's signed attestation into the Output, so that a relying party or auditor can recompute the binding and verify the register's signature independently. A check performed only by the reconciliation server would rest on the honesty of the party the rest of this document declines to trust. The Reconciliation Nonce is unique per Per-Register Claim Projection per Section 3 and MUST NOT be reused, so that an attestation is admissible only into the reconciliation, and against the register, that elicited it.¶

The Partial Attestation payload SHALL NOT contain any register-record field, any pre-image of the register record, or any field beyond those enumerated. Restricting the Partial-Attestation payload to the enumerated fields, of which the verdict, the divergence axis, the applied parameters and the Query Binding -- a digest over the Subject Reference -- vary with the subject, is the mechanism by which ARP limits raw-record disclosure. Residual inference channels are discussed in Section 7.8.¶

4.9. Merkle Construction

Two structures in this document commit to a set of digests through a Merkle tree: the Merkle Root of Hash-Linkage Aggregation, and the Examined-Set Root of Section 4.21.1. Both use this construction, so that an inclusion proof produced by one implementation verifies under another.¶

Leaves are the digests to be committed, sorted in bytewise lexicographic order and deduplicated. Deduplication is why an Examined-Set Root commits to distinct Claim Hashes and the count beside it counts Reconciliation Outputs: two Outputs over one claim share a Claim Hash, so the leaf count and the examined count need not be equal and neither is derivable from the other. A leaf node is SHA-256(0x00 || leaf). An internal node is SHA-256(0x01 || left || right). Where a level has an odd number of nodes, the last is carried up to the next level unchanged rather than duplicated. A tree over one leaf has that leaf's leaf-node hash as its root; a tree over no leaves has thirty-two zero octets as its root.¶

An inclusion proof is a CBOR array of the leaf, its zero-based index, the leaf count, and the array of sibling hashes from the leaf's level upward. Domain separation between leaf and internal nodes is what stops a proof of an internal node being presented as a proof of a leaf.¶

Three properties of that array are stated here because each is a place two implementations otherwise diverge while both believing they conform. The array carries one entry for each level at which the node being proved has a sibling, and no entry for a level at which it was carried up unchanged, so its length is not in general the base-two logarithm of the leaf count and a verifier MUST NOT derive the expected length that way. No direction bit is carried: at each level the verifier derives whether the sibling is the left or the right operand from the index and the leaf count, halving the index and the level width as it ascends, which is well defined because the shape of the tree is fixed by the leaf count alone. And the empty tree's root of thirty-two zero octets admits no inclusion proof; a verifier MUST reject any proof presented against it rather than treat a root it can reproduce as a root that commits to something.¶

4.10. Aggregation

The aggregation subsystem operates in Hash-Linkage Aggregation. Each Partial Attestation is canonical-hashed and committed to a Merkle tree as Section 4.9 defines it,, and emitted with a Merkle root and the Merkle Root carried in the Reconciliation Output. Its per-register inclusion proofs MAY be encoded as COSE Receipts [RFC9942], enabling any SCITT-aware verifier to check inclusion without a bespoke proof format. Each leaf commits one register's attestation individually, so an inclusion proof discloses no other register's payload.¶

4.11. Registers That Do Not Answer

A register may fail to produce a usable Partial Attestation. Every such state has a defined outcome, because dropping the register silently would produce exactly the addressed-register-cherry-picking pattern the Adversarial Pre-Transmission Test exists to detect.¶

The Per-Register Result Set MUST carry an entry for every addressed register. Where no usable attestation was received, the entry carries no Attested Verdict and carries instead, in its own field, a Non-Answer Reason drawn from:¶

• projection-ambiguous and projection-unsupported, where the projection itself failed and no projection was transmitted¶

• agreement-drift-suspended, where reconciliation against that register was suspended for Bilateral-Register-Agreement drift¶

• attestation-stale, where the Freshness Timestamp fell outside the declared window and the attestation was rejected¶

• attestation-unverifiable, where the signature did not verify or the echoed Policy-Version Hash did not match the one sent¶

• register-unresponsive, where no attestation was received within the window declared in the Bilateral Register Agreement¶

• register-refused, where the register declined to answer, whether under its own statutory access regime or under the Agent-IFF policy¶

• query-budget-exhausted, where the reconciliation would exceed the per-principal per-subject query budget declared under Section 7.1¶

• subject-ceiling-exhausted, where the reconciliation would exceed a per-subject ceiling declared under Section 7.1¶

• audience-constraint-exceeded, where the requested Audience Set exceeds the audience constraint that register declares under Section 4.15.1¶

• non-answer-unattested, where the register asserted a register-attested reason without a verifying Non-Answer Statement¶

Each Non-Answer Reason is either register-attested or server-observed, and the registry of Section 9 MUST record which for every registration. register-refused is register-attested. attestation-stale and attestation-unverifiable are server-observed but arise from an attestation the server holds. The remainder are server-observed with no register artefact behind them.¶

Where a Non-Answer Reason is register-attested, the Per-Register Result Set entry MUST carry a Non-Answer Statement in the field Section 4.14 defines for it. The Statement is a COSE_Sign1 by that register, under the primitive its Bilateral Register Agreement declares and under a key resolvable as in Section 6.5.3, whose payload is the CBOR array¶

["arp-non-answer-v1", Reconciliation Identifier, Projected Predicate,
 Subject Reference, Reconciliation Nonce, Non-Answer Reason]

encoded under Section 4.2.1 of [RFC8949]. The Reconciliation Identifier is inside the payload for the reason the Query Binding of Section 4.8 carries it: without it a refusal elicited in one reconciliation is admissible as a refusal in another over the same subject and predicate.¶

Where a register-attested reason is recorded without a Statement, or with one that does not verify, the reason MUST be replaced by non-answer-unattested. That is a distinct reason and not attestation-unverifiable, which denotes a Partial Attestation the server holds and could not verify; collapsing the two would put the missing-refusal case back into a server-observed bucket and undo the distinction this rule exists to draw.¶

Without that rule a register-refused is an unattested assertion by the party that transmitted the projection, and a server can suppress a match by claiming the register declined. The server can still downgrade a reconciliation to indeterminate by asserting a server-observed reason -- register-unresponsive is indistinguishable from a network failure by construction, and this document does not pretend otherwise -- but it cannot dress suppression as an act of the register. Suppressing a sanctions hit is the harm this domain cares about, and the difference between "the register would not say" and "I did not ask" is the difference the record must preserve.¶

A Non-Answer Reason is not a verdict, occupies its own field of the Per-Register Result Set per Section 4.14, and MUST NOT be combined by the Verdict Arithmetic. Its effect is given in Section 4.13: a reconciliation with any non-answering register cannot reach a decisive Combined Verdict.¶

Where the reason is attestation-stale, freshness-stale MUST also be added to the Server-Recorded Divergence-Axis Set against that Register Identifier.¶

A reconciliation server MUST reject a Partial Attestation that attests a Divergence Axis the registry of Section 9 records as server-recorded, with the reason attestation-unverifiable. A register cannot attest a relation between itself and another register, which is what those axes are.¶

4.12. Verdict Re-Typing

A register answers the Projected Predicate it was sent, which may be a narrowing of the Canonical Claim Predicate. Where the narrowing means the register's answer does not bear on the claim as asked, the reconciliation server MUST re-type that register's Reconciliation-Verdict Field before aggregation, and MUST record the attested value, the re-typed value and the ground on which it re-typed in the Per-Register Result Set, so that an auditor can reproduce the decision without the server's assurance.¶

Re-typing is confined to these cases:¶

• Any contribution other than match, attested against a bounded-depth predicate where the Canonical Claim ranged over a transitive closure, is re-typed to indeterminate. A bounded-depth answer that is not a match is evidence about the bounded depth only, and that is as true of partial-match and indeterminate as of no-match. A match is not re-typed: an interest found at any depth establishes the existential closure predicate.¶

• A match or no-match attested over a declared fact, where the Canonical Claim ranged over a determined fact, is re-typed to partial-match under an operator that admits that value and to indeterminate under one that does not, per Section 4.13.¶

• A contribution from a register whose declared interest threshold differs from that of any other addressed register, where the Canonical Claim's predicate is threshold-sensitive, is re-typed to partial-match under an operator that admits that value and to indeterminate under one that does not. Two registers answering under different thresholds are not answering the same question, and annotating that on the Reconciliation Output while allowing a decisive Combined Verdict to be built from it would state a conclusion the inputs do not support.¶

  Threshold-sensitivity is a property of a Register Data-Format Profile, which declares which of its predicates are threshold-sensitive, and the test above names the Canonical Claim Predicate, which is not expressed in any profile. The test is therefore evaluated as follows, and is defined over a register set whose members declare different profiles. The Canonical Claim Predicate is threshold-sensitive where the Per-Register Claim Projection transmitted to ANY addressed register was a predicate that register's declared profile marks threshold-sensitive. Taking the disjunction rather than requiring agreement is deliberate: a mixed-profile register set in which one profile marks the predicate threshold-sensitive and another is silent is precisely the set in which the thresholds may differ unnoticed, and requiring every profile to mark it would disable the test in the case it exists for.¶

Re-typing operates on a register's contribution. It does not override the Verdict Arithmetic resolved under Section 4.13, which is applied afterwards to the re-typed set and is otherwise unaffected. An implementation MUST NOT re-type on any ground not enumerated here.¶

4.13. Verdict Arithmetic

The Verdict Arithmetic combines the Reconciliation-Verdict Fields of the Per-Register Result Set, after any re-typing under Section 4.12, into the Combined Verdict. The requester names the applicable regimes in its Canonical Claim; it does not choose the operator. The operator and every parameter it takes are resolved by the reconciliation server from the policy-epoch store of Section 4.16, keyed on the predicate and the named regimes, and are committed to the Policy-Version Hash. They are carried into the Reconciliation Output so that a relying party can reproduce the combination.¶

A requester able to choose both the operator and its threshold could choose the verdict: disjunction over five registers and threshold-count with a threshold of five differ only in which answer they return over the same contributions, and selecting between them after seeing which registers were addressed is verdict shopping that no downstream check would detect. Naming a regime is a claim about which law applies, which the requester is competent to make and accountable for; selecting an operator is a determination about how evidence combines, which the deployment's policy makes.¶

Naming regimes is not thereby unconstrained. The reconciliation server MUST verify that every regime the Applicable-Regimes Set names is one the policy-epoch store admits for that predicate, and MUST refuse a claim naming a regime that is not, returning a Remediation Advisory identifying it. Without that check a requester enumerates admissible regime sets, reads out of the Outputs it receives which operator, threshold and reliance interval each resolves to, and selects the combination that returns the answer it wants -- taking the longest reliance interval with it. That is verdict shopping at one remove. There is nothing to probe for: Section 6.4.1 requires the server to publish the resolved operator, its parameters and the reliance interval per predicate and regime set, so the mapping is available without probing and the admitted-regime check is what constrains the choice.¶

Two rules apply to every operator and take precedence over the operator's own table:¶

• Where any addressed register has no decisive contribution because it did not answer, was refused or was rejected under Section 4.11, the Combined Verdict MUST be indeterminate. An operator MUST NOT reach a decisive verdict over an incomplete register set, which would be indistinguishable from addressed-register-cherry-picking.¶

• Where any contribution is indeterminate, the Combined Verdict MUST be indeterminate wherever the operator's table would otherwise yield no-match. An indeterminate contribution is an absence of evidence and a decisive negative may not be built on one, so the rule states the substitute result rather than only a prohibition; a prohibition without a substitute would leave the verdict undefined in exactly the cases it governs.¶

Operators are drawn from the registry of Section 9. Subject to those rules, the initial four are:¶

conjunction:

match where every contribution is match. no-match where any contribution is no-match. partial-match where every contribution is match or partial-match and at least one is partial-match. indeterminate otherwise.¶

disjunction:

match where any contribution is match. no-match where every contribution is no-match. partial-match where at least one is partial-match and none is match. indeterminate otherwise.¶

threshold-count:

match where the count of match contributions meets or exceeds the threshold resolved for the named regimes. no-match where the count of match contributions cannot reach the threshold and no contribution is indeterminate. indeterminate otherwise, which includes every case in which an indeterminate contribution is present and the threshold is not met. partial-match contributions do not count toward the threshold.¶

source-class-quorum:

threshold-count evaluated per source class, over the partition and the per-class threshold resolved for the named regimes, then combined across classes by conjunction.¶

Every operator admits partial-match except threshold-count and source-class-quorum, which do not. Where Section 4.12 would re-type a contribution to partial-match under an operator that does not admit it, the contribution is re-typed to indeterminate instead.¶

4.14. Reconciliation Output

A Reconciliation Output comprises:¶

• Reconciliation Identifier¶

• Claim Hash¶

• Reconciliation Timestamp¶

• Reliance Horizon of Section 4.15¶

• Audience Set of Section 4.15¶

• Combined Verdict¶

• Verdict Arithmetic as resolved under Section 4.13, together with every parameter that operator takes -- the threshold for threshold-count, and both the source-class partition and the per-class threshold for source-class-quorum¶

• Addressed-Registers Identifier Set, each member an authority origin, sorted in bytewise lexicographic order of its UTF-8 encoding¶

• Bilateral-Register-Agreement Hash Set, sorted in bytewise lexicographic order of the digests themselves, in the order of the Addressed-Registers Identifier Set having no meaning once a register may be absent from a set¶

• Policy-Version Hash¶

• Pattern-Library Version Identifier¶

• Requester-Binding Class¶

• Per-Register Result Set, one entry per addressed register, ordered by Register Identifier in bytewise lexicographic order of its UTF-8 encoding¶

• Aggregation-Method Descriptor, drawn from the registry of Section 9¶

• Merkle Root, constructed as in Section 4.9¶

• Server-Recorded Divergence-Axis Set, possibly empty¶

• OPTIONAL Override Record, present exactly where an Adversarial Pre-Transmission Test failure was overridden¶

• Sealing-Key Identifier¶

• Sealing Signature, a COSE_Sign1 by the reconciliation-server sealing key whose payload is the CBOR array of this Output with the Sealing Signature position alone encoded as CBOR null, so that it covers every other field including the Sealing-Key Identifier¶

The Reconciliation Identifier is the Claim Hash concatenated with the Policy-Version Hash. It is therefore reproducible from enumerated inputs and satisfies the determinism requirement of Section 4 without a separate construction rule.¶

The Claim Hash binds the Output to the question it answers. Without it a relying party receives a Combined Verdict with nothing to attribute it to, and the Retroactive Evaluation Subsystem has no key to select on.¶

The Verdict Arithmetic and its parameters are carried because a relying party cannot otherwise reproduce the combination from the Per-Register Result Set, and because Section 4.12 turns on which values the operator admits. The Applicable-Regimes Set is a Canonical Claim field and is not itself carried in the Output, so naming the operator without its parameters would leave threshold-count and source-class-quorum irreproducible. source-class-quorum is threshold-count evaluated per class and therefore takes a threshold as well as a partition; carrying the partition alone would leave it as irreproducible as carrying neither, which an earlier revision did.¶

Each entry of the Per-Register Result Set comprises:¶

• Register Identifier¶

• Answer State, either answered or not-answered¶

• Attested Verdict, present exactly where the Answer State is answered¶

• Non-Answer Reason of Section 4.11, present exactly where the Answer State is not-answered¶

• Effective Verdict, present exactly where the Answer State is answered, being the Attested Verdict or its re-typing under Section 4.12¶

• Re-Typing Ground, drawn from the registry of Section 9, present exactly where the Attested and Effective Verdicts differ¶

• Policy-Version Hash as echoed by that register, present exactly where the Answer State is answered¶

• OPTIONAL Divergence-Axis Field, as attested by that register¶

• OPTIONAL Source-Data Version Identifier Set, as attested by that register¶

• Projection Record, comprising the Narrowed-From field of the Per-Register Claim Projection where a projection was transmitted, and the Applied-Parameter Set the register reported where the Answer State is answered; required wherever a projection was transmitted and either the projection narrowed or the Profile Parameter Set was non-empty¶

• Query Binding Record, present exactly where the Answer State is answered, comprising the Projected Predicate, the Subject Reference and the Reconciliation Nonce the server transmitted, and the register's signed Partial Attestation¶

• Non-Answer Statement, present exactly where the Answer State is not-answered and the Non-Answer Reason is register-attested under Section 4.11, comprising the Projected Predicate, the Subject Reference and the Reconciliation Nonce the server transmitted, and the register's signature over them together with the reason and the Reconciliation Identifier, as Section 4.11 constructs it. The three projection values are carried here as well as in the Query Binding Record because the two are never both present and a verifier of either needs the preimage in the artefact it holds.¶

Each member of the Server-Recorded Divergence-Axis Set is a two-element array of a Divergence Axis and the Register Identifier it concerns, the second element being CBOR null where the axis concerns the reconciliation as a whole. Members are sorted in bytewise lexicographic order of that encoding. A uniform two-element member with an explicit null, rather than a member that is sometimes a pair and sometimes a scalar, is what makes the Set's contribution to the Reconciliation Hash determinate. Of the axes recorded by the server, freshness-stale and declared-not-determined are per-register and MUST carry a Register Identifier. source-version-skew is a relation between two or more registers, and one member MUST be added for each register involved, so that the set is a determinate function of the inputs rather than a choice between them; register-threshold-divergence concerns the reconciliation and MUST NOT. Recording a bare axis over five addressed registers would state that something was stale without stating what, which is not reproducible.¶

The Set is a set rather than a single value: a reconciliation may be qualified on more than one axis, and an encoding admitting only one would force an implementation to choose between them silently.¶

A Reconciliation Output is encoded as a CBOR array in the field order of this section, an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved and the array's length is fixed. The Per-Register Result Set is an array of arrays, each in the field order enumerated above, under the same rule. The order is normative because the Reconciliation Hash is taken over it, and because a CBOR map would be re-sorted into bytewise lexicographic key order under Section 4.2.1 of [RFC8949], which would override it.¶

The Reconciliation Hash is the SHA-256 digest over that same CBOR array with the Sealing-Key Identifier and Sealing Signature positions encoded as CBOR null. The array's length is unchanged: "excluding" means null-substitution at fixed positions and MUST NOT be implemented as truncation, because a shorter array carries a different CBOR array header and therefore a different digest, and two implementations reading "excluding" the two ways would never agree on a ledger index. It is the value recorded in the Settlement-Layer Ledger, the value a Post-Seal Evaluation Record references, and the retrieval key of Section 6.4.¶

Every timestamp this document places inside a digest preimage or a signature payload MUST be expressed in the form YYYY-MM-DDTHH:MM:SSZ: [RFC3339] with the Z designator rather than a numeric offset, and with no fractional seconds. [RFC3339] admits several renderings of one instant, and a preimage that admits several renderings admits several digests.¶

CBOR rather than [RFC8785]: the mandatory-to-implement encoding for a Reconciliation Output is CBOR, and several of its fields are byte strings, for which JSON has no type. Digesting a JSON rendering of it would require a CBOR-to-JSON mapping this document does not define, and two implementations would produce different ledger indices. The Canonical Claim is serialised under [RFC8785] and that serialisation is carried as one element of the CBOR array the Claim Hash is taken over; the Reconciliation Output is CBOR throughout.¶

A Reconciliation Output is immutable once sealed. Conditions arising after sealing are recorded under Section 4.17 and MUST NOT be represented as fields of the Reconciliation Output.¶

4.15. Output Entitlement and Delivery

The Reconciliation Output is the confidential artefact of this protocol and the Settlement-Layer Ledger is its public one. An Output carries subject references, register-signed Partial Attestations and principal identifiers; a Ledger entry carries digests, register origins and structural metadata, and no claim, register-record or principal content. Every rule in this document about who may see what rests on that division, and they are not interchangeable. A party admitted to a Ledger read learns nothing of the subject or the answer. A party holding an Output already holds the content of one reconciliation, and admitting it to reads about that same reconciliation discloses nothing it does not have.¶

Earlier revisions had no answer to who may hold an Output. It was a bearer artefact: possession was the whole of the entitlement, it never expired, and every read predicate this document attempted was expressed in terms of a Requester-Binding that the reader could not present and the Ledger could not evaluate. This section supplies the missing term.¶

4.16. Policy-Version-Hash Sealing

The Policy-Version Hash MUST commit to:¶

1. Reconciliation rules¶

2. Threshold parameters¶

3. Pattern-Library Version Identifier¶

4. Applicable-Regimes precedence¶

5. Verdict-Arithmetic selection, together with every parameter that operator takes¶

6. The reliance interval from which the Reliance Horizon of Section 4.15.2 is computed¶

7. Agent-IFF policy identifier and the Requester-Binding¶

8. Bilateral-Register-Agreement Hashes of the addressed registers¶

The Policy-Version Hash is the SHA-256 digest over the deterministically encoded CBOR array¶

["arp-policy-version-v1", Deployment Blinding Value,
 reconciliation rules identifier, threshold parameters,
 Pattern-Library Version Identifier, applicable-regimes precedence,
 [Verdict Arithmetic, its parameters], reliance interval,
 Agent-IFF policy identifier, Requester-Binding,
 Bilateral-Register-Agreement Hash Set]

in that order, the Hash Set sorted in bytewise lexicographic order of the digests and every other composite element a CBOR array in the order this section states it. It MUST be reconstructible under audit from that array, held in the policy-epoch store. A value every addressed register echoes and every auditor recomputes cannot be left to "a canonical policy state", which earlier revisions were content with and which is not a preimage.¶

The Claim Hash and the Policy-Version Hash MUST each be computed over a preimage that includes the Deployment Blinding Value: a secret of at least 128 bits drawn once from a cryptographically secure random source, persisted in the policy-epoch store, constant for the life of the deployment, and disclosed outside the policy-epoch store only as Section 4.20 provides. Section 4.20 discharges an auditor's need as far as it can without disclosing the constant that blinds every digest in the deployment, and states what that leaves unverified.¶

It is constant rather than per-claim, and that is what makes it compatible with the rest of this document. The Claim Hash remains a deterministic function of the canonical claim fields within a deployment, so it remains usable as the Settlement-Layer Ledger index and as the retroactive-evaluation key, and the reproducibility requirement of Section 4 continues to hold: the same deployment given the same enumerated inputs produces the same digests. What changes is that the preimage is no longer guessable from outside the deployment. A per-claim random value would defeat all three properties.¶

Both digests are otherwise taken over low-entropy preimages: a subject identifier is typically a company number of ten or so digits, a predicate is drawn from a published taxonomy, and the accountable principal, agent-IFF policy identifier and verdict arithmetic are each drawn from small enumerable sets within one deployment. Both digests then appear where adversaries can reach them -- the Policy-Version Hash in the protected header of every notarised Signed Statement and in every reconciliation entry of the Ledger, the Claim Hash in the Output and in every Ledger entry of either kind. Without blinding, anyone holding either can recover by exhaustive search the subject that was investigated and the principal that commissioned the reconciliation, which is the disclosure this protocol exists to prevent. Blinding does not weaken reconstructibility under audit, since the Blinding Value is persisted with the state it blinds.¶

A register receives the same Policy-Version Hash as every other addressed register, by Section 4.4. The Blinding Value prevents two colluding registers from recovering the Addressed-Registers Identifier Set from it by search; that they can observe they were addressed together is inherent and is discussed in Section 7.8.¶

4.17. Post-Seal Evaluation Records

Two conditions arise after a Reconciliation Output has been sealed and therefore cannot be fields of it, and are not Divergence Axes: a Divergence Axis qualifies a verdict, and these qualify an operation performed on an Output that is already immutable.¶

• notarisation-incomplete, where notarisation under Section 6.5 neither completed nor was refused within the polling bound.¶

• attribution-indeterminate, where a Retroactive Evaluation could not determine whether a material change arose from a change in policy state or from a change in Source-Data Version.¶

Each is recorded in a Post-Seal Evaluation Record comprising:¶

• the Reconciliation Hash of the Output it concerns¶

• the Post-Seal Evaluation Qualifier, drawn from the registry of Section 9¶

• the Policy-Version Hash and Pattern-Library Version Identifier in force at the time of the evaluation, which may differ from those the Output was sealed under¶

• a Post-Seal Evaluation Timestamp, in the form of Section 4.14¶

• an Attribution Account, present exactly where the Qualifier is attribution-indeterminate: a text string stating which of the two candidate causes were examined and why neither could be excluded. A bare qualifier would be a discretionary escape signed by the party that benefits from it¶

• a Sealing-Key Identifier¶

• a signature by the reconciliation-server sealing key, a COSE_Sign1 whose payload is the CBOR array of this record with the signature position encoded as CBOR null¶

A Post-Seal Evaluation Record is encoded as a CBOR array in the field order above, an absent conditionally-absent field encoded as CBOR null so that position is preserved. The Post-Seal Evaluation Record Hash of Section 4.18 is the SHA-256 digest over that array in its entirety, signature included, so that the digest is over the artefact as served under Section 6.4.¶

A Post-Seal Evaluation Record MUST be retained by the reconciliation server for the period of Section 4.15.3, and a Continuation entry of type continuation-post-seal-record MUST be appended to the Settlement-Layer Ledger carrying the record's hash. The hash is not written into the entry that recorded the reconciliation: that entry is already signed and the Ledger exposes no UPDATE. An Audience Member of the Output discovers the record by reading the Continuation entries for its Reconciliation Hash under Section 6.4 and retrieves it by its hash under the same binding. The record travels as the result element of the signed read response of Section 6.4.3; the media type registered for the record labels it wherever it is carried outside that envelope, and the Post-Seal Evaluation Record Hash is taken over the record itself and not over the response that carried it. A record emitted but not appended would be undiscoverable, which would make the attribution safety valve of Section 4.6 unreachable in exactly the case it exists for.¶

A Post-Seal Evaluation Record MUST NOT alter the Reconciliation Output it references, and a relying party MUST NOT treat the existence of one as invalidating that Output. A Reconciliation Output whose notarisation is incomplete remains valid under its Sealing Signature.¶

Where a Sovereign Re-Notification is emitted under Section 4.21 for a material change, the notification MUST state whether the change arose from policy state or from Source-Data Version, and where it cannot, a Post-Seal Evaluation Record carrying attribution-indeterminate MUST be emitted and referenced by the notification.¶

4.18. Settlement-Layer Ledger

The Ledger carries two kinds of entry. A reconciliation entry records a sealed Reconciliation Output. A Continuation entry records a fact that arose after that Output was sealed and therefore could not be a field of it. Every entry carries an Entry Type drawn from the registry of Section 9, and the Entry Type determines which further fields the entry carries. An entry whose Entry Type is not reconciliation is a Continuation entry. Without a discriminator a verifier reading an entry cannot tell which field list to apply, and an entry legitimately lacking a field would be indistinguishable from one that is malformed.¶

Every entry, of either kind, comprises these fields and in this order:¶

• Entry Sequence Number, a strictly increasing integer with no gaps: the first entry of a chain is 1 and each subsequent entry is its predecessor's plus one. Contiguity is required because the consistency read of Section 6.4.2 cannot otherwise distinguish a sequence number the operator never allocated from one it is refusing to answer for, the two being the same 404 by Section 6.4.4¶

• Entry Type, from the ARP Ledger Entry Types registry of Section 9¶

• Claim Hash, the index of Section 4¶

• Reconciliation Hash of the Reconciliation Output the entry concerns¶

• Entry Timestamp ([RFC3339] UTC), the time at which the entry was appended¶

• Prior-Entry Hash, being the SHA-256 digest over the deterministically encoded CBOR serialisation of the immediately preceding entry in its entirety, including that entry's Entry Signature; in the first entry of a chain, which has no preceding entry, thirty-two zero octets¶

followed by the type-specific fields enumerated below, followed by:¶

• Self-Entry Hash, being the SHA-256 digest over the CBOR array of this same entry with the Self-Entry Hash and Entry Signature positions encoded as CBOR null, so that the array's length is the length fixed by the Entry Type and is the same array a verifier already holds¶

• Entry Signature, a COSE_Sign1 by the reconciliation-server sealing key whose payload is the CBOR array of this same entry with the Entry Signature position alone encoded as CBOR null -- so it covers every other field including the Self-Entry Hash -- and whose protected header carries the Sealing-Key Identifier that resolves it¶

An entry is encoded as a CBOR array in the field order of this section, an absent field -- whether marked OPTIONAL or conditionally absent under a stated condition -- encoded as CBOR null, so that position is preserved and the array's length is fixed by the Entry Type. Absence MUST be encoded and MUST NOT be expressed by a shorter array: two encodings of one entry would otherwise yield two Self-Entry Hashes, which the head comparison of this section treats as a fork. The order is normative because the Self-Entry Hash is taken over it; an encoding as a CBOR map would be re-sorted by key under the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949] and would override it. A field whose value is itself a choice -- the second field of a continuation-notarisation entry -- is encoded as a two-element array of a discriminant and a value, the discriminant being the CBOR text string entry-id or refused.¶

The Self-Entry Hash is enumerated after the type-specific fields so that it covers them. Placing it before them would leave a Continuation entry's payload outside it. The Prior-Entry Hash is taken over the whole preceding entry rather than over that entry's Self-Entry Hash, so that Entry Signatures are inside the chain. Were the chain to link Self-Entry Hash to Self-Entry Hash, no signature would be covered by anything, and an operator could re-sign or strip every historical Entry Signature -- resolving each to a revoked or unresolvable key -- while every hash in the chain, and every head already published and notarised, continued to verify. The one field this document relies on to make a second chain attributable would have been the one field outside the structure that detects tampering. The trailing entry's own signature is covered as soon as the next entry is appended, and until then it is covered by nothing; the published head commits to the head entry's Self-Entry Hash, which by construction excludes that entry's own signature.¶

An entry is signed exactly once. A second signature over the same fields is a different entry, MUST NOT be appended at the same Entry Sequence Number, and MUST NOT replace the first. Signature schemes are not required to be deterministic, so two signings of one entry would otherwise yield two byte-different entries, two divergent but individually valid chains, and two heads at one sequence number -- which Section 4.18 treats as a fork. An operator would then have a blameless explanation for one.¶

The Entry Timestamp is distinct from the Reconciliation Timestamp. A Continuation entry may be appended weeks after the reconciliation it concerns, and an entry carrying only a Reconciliation Timestamp would state that the notarisation, the post-seal evaluation or the supersession occurred at the moment of the reconciliation, which is false in every case the mechanism exists for.¶

An entry whose Entry Type is reconciliation additionally comprises:¶

• Policy-Version Hash¶

• Addressed-Registers Identifier Set, each member an authority origin, sorted in bytewise lexicographic order of its UTF-8 encoding¶

• Aggregation-Method Descriptor¶

• Merkle Root¶

• Requester-Binding-Class Descriptor, one of the four classes enumerated in the Requester Identity Binding and Agent Friend-or-Foe Gate section¶

• Reconciliation Timestamp, as sealed in the Reconciliation Output¶

• OPTIONAL Source-Reconciliation-Output Identifier, being the Reconciliation Hash of the Output this reconciliation supersedes, present exactly where it supersedes one¶

• Override Indicator, true exactly where the Reconciliation Output carries an Override Record under the Adversarial Pre-Transmission Test¶

An entry whose Entry Type is continuation-notarisation additionally comprises:¶

• Transparency Service Identifier, being the authority origin of that service¶

• exactly one of the EntryID that service returned, or the HTTP status code by which that service terminally refused registration¶

Only the status code is recorded, never a response body. A body is authored by the Transparency Service, is unbounded, and routinely echoes submitted content; writing one into an append-only log with no DELETE would put text this document does not control inside a record that forbids claim and principal content in the clear.¶

A continuation-notarisation entry MUST be appended where notarisation completes, and where the Transparency Service returns a status the implementation resolves as a terminal refusal under Section 6.5.2. Where a status cannot be so resolved -- the 404 of Section 6.5.2 carries two meanings and a service is not obliged to distinguish them -- it is not a terminal refusal, and the reconciliation is treated as one whose polling bound was exhausted. In that case no continuation-notarisation entry is appended and the outcome is recorded under Section 4.17 as notarisation-incomplete. Requiring an entry only on failure would leave the successful case -- the case the join exists for -- unrecorded.¶

Where an implementation subsequently learns the EntryID of a registration it had recorded as incomplete, it MUST append the continuation-notarisation entry then. This document defines no means by which it would learn that: [I-D.ietf-scitt-scrapi] retrieves by EntryID and the EntryID is precisely what was not received, polling is bounded, and no callback is specified. A notarisation-incomplete record will therefore usually stand permanently, and it is evidence that registration did not complete within the polling bound and not that it failed. That is open.¶

An entry whose Entry Type is continuation-post-seal-record additionally comprises:¶

• Post-Seal Evaluation Record Hash¶

An entry whose Entry Type is continuation-supersession additionally comprises:¶

• Material-Change Indicator, stating whether the Combined Verdict changed materially within the meaning of Section 4.21¶

• Superseding-Reconciliation Hash, being the Reconciliation Hash of the Reconciliation Output that supersedes the one this entry concerns, present exactly where a superseding Output was produced and absent where the supersession is the revocation of a Verified Principal Credential under Section 4.21, which supersedes an Output without producing another¶

• Superseding-Entry Sequence Number, being the Entry Sequence Number of the reconciliation entry that records the superseding Output, present under the same condition¶

No Continuation entry carries a retrieval URI. Every artefact a Continuation entry points at is retrieved under Section 6.4, by hash for a Post-Seal Evaluation Record and by Reconciliation Hash for a superseding Output, from the same authority origin that served the entry. Carrying a URI instead would oblige every reader to dereference an operator-chosen address before it could check anything -- a forced fetch, a de-blinding oracle correlating a reader's network identity with one Reconciliation Hash, and a covert channel that no constraint on the URI's content can close, since host selection and path structure carry the signal without stating anything. It would also put a non-digest field in a Ledger whose whole disclosure argument is that it holds digests.¶

A Reconciliation Output produced by Retroactive Evaluation to supersede an earlier Output MUST carry the Audience Set and the Requester-Binding Class of the Output it supersedes. Without that rule the party entitled to learn that its verdict had changed would be entitled to the entry saying so and not to the Output that says what it changed to, and the traversal would end one step short. Such an Output has no commissioning request and is not delivered under Section 4.15.3; it is retrieved.¶

Where the superseding reconciliation addresses a register whose audience constraint the inherited Audience Set exceeds -- which can happen, since the superseding reconciliation may address registers the superseded one did not -- that register is recorded audience-constraint-exceeded under Section 4.11 like any other. The Audience Set is not truncated to fit: truncating it would strand the party the supersession exists to notify, and the constraint is satisfied by not obtaining that register's answer rather than by silencing the reader.¶

A party retrieving a Post-Seal Evaluation Record MUST verify that the retrieved bytes digest to the Post-Seal Evaluation Record Hash carried in the entry, and MUST discard them otherwise. That hash is constructed as Section 4.17 defines it. Without the check the hash is decorative and an operator can serve a different record to each audience, reopening at the record the equivocation the Ledger closes at the entry.¶

A Continuation entry carries no Policy-Version Hash, no Addressed-Registers Identifier Set, no Aggregation-Method Descriptor, no Merkle Root and no Requester-Binding-Class Descriptor. Those describe the reconciliation, which the reconciliation entry already records and the Reconciliation Hash already binds; carrying them a second time would create a second place for them to disagree. A Continuation entry MUST carry the same Claim Hash and Reconciliation Hash as the reconciliation entry it continues, and the storage interface layer MUST reject a Continuation entry whose Reconciliation Hash matches no earlier reconciliation entry, returning a rejection the appending subsystem can distinguish from a transport failure. Because Entry Sequence Numbers are allocated in one sequence and secondary stores replicate rather than originate, every store holds the reconciliation entry against which the check is made.¶

Prior-Entry and Self-Entry Hashes establish that no entry has been removed from a chain; they do not establish that only one chain exists. Signing each entry makes a second chain attributable rather than merely possible.¶

A Reconciliation Output is sealed before it is notarised and so cannot itself carry the EntryID, and the Ledger exposes no UPDATE, so the join cannot be made by amending the original entry. It is made by appending. Without it a successful notarisation would be unlinkable to the reconciliation from every side, since retrieval is by EntryID and [I-D.ietf-scitt-scrapi] offers no query surface.¶

A continuation-supersession entry MUST be appended against the superseded Output on every supersession, whether or not the change is material. Where the supersession produced a superseding Output, the superseding reconciliation entry MUST also carry the Source-Reconciliation-Output Identifier naming what it replaced, and the two records are inverse pointers over one relation. Where it did not -- the revocation of a Verified Principal Credential -- there is no superseding entry and no second record, and the Continuation entry stands alone. The Material-Change Indicator distinguishes a material supersession from an immaterial one in either case. Section 4.21 imposes the further obligation of a Sovereign Re-Notification where the change is material; it does not condition the ledger record, which is written either way, since a party relying on a superseded Output needs to know it was superseded before it can be told the change was immaterial.¶

Where both records exist they are inverse pointers over one relation and neither substitutes for the other. A party holding the superseded Output cannot follow a pointer that exists only on an entry it has not been returned, and a regulator whose scope under Section 4.19 covers the superseded reconciliation is not thereby returned the superseding one, whose addressed registers and therefore whose agreements may differ. The constraint is on what a reader is returned, not on what a store holds.¶

The Ledger MUST NOT store Canonical-Claim content, register records, Partial-Attestation payloads, or any principal identifier in the clear; the requester's accountable principal is committed only through the Policy-Version Hash. The append-only constraint MUST be enforced at the storage interface layer. The Ledger interface MUST expose APPEND and READ operations only, with no UPDATE and no DELETE operation exposed or implemented. Retroactive Evaluation and the derivation-chain invariant check are subsystems of the reconciliation server and read the Ledger without scope restriction. Every read by a party outside the reconciliation server is served under Section 6.4, which states the operations, the entitlement each requires, the response form, and the error semantics. Three entitlements reach the Ledger: a regulator's, governed by Section 4.19; an Audience Member's under Section 4.15; and an Audit Identity's under Section 4.20. A Register Operator holds the narrower entitlement of the consistency check below.¶

An Audience Member is entitled to the Continuation entries carrying the Reconciliation Hash of an Output that names it, and to the reconciliation entry carrying that same Reconciliation Hash. It is entitled to no other entry. This is the predicate earlier revisions could not express. It is evaluable, because the Audience Set is a sealed field of the Output and the server retains the Output under Section 4.15.3; the Ledger is not asked to evaluate it, and could not, since it stores no principal identifier in the clear. It admits the right party, because entitlement follows the Output rather than the request, so a member the Requesting Principal named at reconciliation time is admitted and a party that merely came into possession of the artefact is not. And it survives the events that broke its predecessors: an Audience Member's verification method is required by Section 4.15.1 to be presentable after the fact, and revocation of the Requesting Principal's Verified Principal Credential does not remove the other members of the Audience Set, so the supersession entry recording that revocation has a reader.¶

Where an Output's Audience Set is reduced to members that can no longer authenticate -- a single-member Set whose sole member's credential has been revoked -- its Continuation entries are reachable only through the Regulator Portal. The reconciliation MUST still have been performed with a Requester-Binding class recorded under Section 7.4, so the condition is visible to the regulator that scope serves.¶

An Audience Member's read discloses only facts about a reconciliation whose full content it already holds: that a supersession or a post-seal evaluation exists, what it points to, and the ledger position of each. The one exception is worth naming, because it is not obvious: a Post-Seal Evaluation Record carries the Policy-Version Hash and Pattern-Library Version Identifier in force at the time of the evaluation rather than at sealing, and those are values the member did not previously hold and, being stable within a deployment, are durable correlators. That is a deliberate disclosure to a party already entitled to the reconciliation they qualify, and it is bounded by Section 4.15.1's rule that a register may cap how wide an Audience Set addressing it may be.¶

Where the Ledger is replicated per Section 4.18.1, each secondary store MUST be able to demonstrate that its chain and every other secondary store's chain share a common prefix.¶

A common-prefix demonstration between stores under one operator is that operator attesting to itself. The reconciliation server MUST therefore publish a signed Ledger Head Statement at /.well-known/arp-ledger-head on its authority origin. It is republished once per notarisation interval and not on every append: the resource is unauthenticated and carries a contiguous sequence number, so a continuously updated head would hand any observer the deployment's exact entry count, its write rate and the timing and size of every retroactive supersession burst -- the aggregate disclosure Section 6.4.4 rate-limits the authenticated surface to prevent. A Statement comprises:¶

• the Entry Sequence Number of the current head¶

• the Self-Entry Hash of that entry¶

• the Entry Timestamp of that entry¶

• a Statement Timestamp, being the time the Statement was produced, in the form of Section 4.14. Without it two Statements published across a quiet period differ only in their notarisation pointer and neither is dateable, so the interval a register negotiated is unverifiable from the artefact¶

• a two-element array of the Transparency Service Identifier and the EntryID of the most recent completed notarisation of a Ledger Head Statement, encoded as CBOR null until the first such notarisation completes¶

• a signature by the reconciliation-server sealing key over the foregoing, carrying the Sealing-Key Identifier that resolves it¶

A Ledger Head Statement is encoded as a COSE_Sign1 over the deterministically encoded CBOR array of the first five items above, in that order, under the media type registered in Section 9, with the fifth item encoded as CBOR null until the first notarisation completes. The server MUST notarise the Ledger Head Statement current at each interval into a SCITT Transparency Service. The interval is the shortest declared by any Bilateral Register Agreement, per the direction rule of Section 4.15.3. The Transparency Service MUST be one every Bilateral Register Agreement the deployment holds declares, and MUST NOT be operated by or under the control of the reconciliation server or any party controlling it. A notary the operator owns is the operator attesting to itself, which is the condition this mechanism exists to escape; the same requirement governs the notarisation of Evaluation Sweep Statements under Section 4.21.1. It is not registered under the binding of Section 6.5, which is scoped to sealed Reconciliation Outputs and whose protected header requires a Policy-Version Hash and a Bilateral-Register-Agreement Hash that a head statement does not have; it is registered as a Signed Statement under its own media type. Statements published between intervals are not notarised.¶

Entry Sequence Numbers are allocated in a single sequence for the logical Ledger. A secondary store under Section 4.18.1 replicates that sequence and MUST NOT allocate independently, or two conforming stores would present the same sequence number over different entries and be indistinguishable from a fork.¶

The Entry Sequence Number is what makes two heads comparable. A bare hash cannot distinguish a fork from ordinary progress: two parties who have each seen a different head learn only that the values differ, which is the expected case whenever they observed at different times. Two Head Statements bearing the same Entry Sequence Number and different Self-Entry Hashes are therefore a fork on their face, and both are signed, so both are attributable.¶

Two Head Statements bearing different sequence numbers are reconciled by the consistency read of Section 6.4.2. A party entitled to that read -- a Register Operator or a regulator -- presents the lower of the two sequence numbers and receives the Self-Entry Hash of the entry at that position in a signed response bound to the request it answers. The two views agree only where that value equals the one the lower Head Statement carried, and where they disagree the party holds two signed statements by one key that cannot both be true of one chain. That is why the response is signed and bound to its request: an unsigned answer would let an operator serve each questioner from that questioner's own branch and leave the questioner with nothing it could show a third party.¶

The rate limit of Section 6.4.4 is load-bearing on that operation and not merely hygiene. The consistency read ranges over every sequence number up to the head; swept without limit it yields the deployment's exact entry count by binary search, its write rate by polling, and the timing and size of a retroactive supersession burst by watching for a step change -- none of which any single answer discloses.¶

A party that holds two irreconcilable signed statements MUST cease to rely on any Reconciliation Output sealed by that server after the lower of the two sequence numbers, MUST report the pair to every regulator whose Bilateral Register Agreements it can identify from the Outputs it holds, and MUST NOT treat the server's subsequent statements as evidence of anything until the discrepancy is resolved. A Register Operator that holds such a pair MUST additionally refuse further Per-Register Claim Projections from that server, on which the server records agreement-drift-suspended against that register under Section 4.11 as it would for any other suspension. Detection without a required response leaves the mechanism ending in a held contradiction and no consequence.¶

Two limits remain and are stated rather than claimed away. An operator that publishes to two audiences at disjoint sequence numbers never emits a colliding pair, so detection by collision is opportunistic even though reconciliation by consistency read is not. And a party holding neither a Reconciliation Output nor a Bilateral Register Agreement has no register set against which to anchor the signing key under Section 6.5.3: it can check that a Head Statement is signed and not that the signer was entitled to publish it. Both bear on a party outside the entitled set; a Register Operator, which is the party with standing to care whether its attestations sit on one chain, has the agreement that anchors the key and the entitlement that completes the check.¶

4.19. Regulator Portal

The Regulator Portal Subsystem authenticates a sovereign regulator's jurisdictional credentials against a regulator-identity-provider trust anchor that MUST be declared in every Bilateral Register Agreement addressed by the reconciliation being read. It restricts returned fields to those within the regulator's statutory scope as declared in the statutory-regulator-access scope of those agreements. Each Bilateral Register Agreement declares, per regulator jurisdiction, a permitted-read-field set: the names of the Reconciliation Output and Ledger entry fields a regulator of that jurisdiction may be returned, and the predicates over which it may be returned them. The scope restriction is the INTERSECTION of the per-agreement permitted-read-field sets scoped to the regulator's jurisdiction, taken only over reconciliations whose Canonical Claim Predicate is in the intersection of the corresponding permitted-read-predicate sets, and further intersected with the regulator's requested field set. Fields and predicates are different domains and are intersected separately; intersecting one with the other would yield the empty set, which earlier text did. Each access MUST be recorded in an append-only subpoena-grade audit trail.¶

The Portal is a subsystem of the reconciliation server and reads the Ledger without scope restriction. The scope governs what it RETURNS, not what it may read. Stating it the other way round would make the Portal unable to compute the authority under which it answers, since that computation requires reading the entry first.¶

Where the entry read is a Continuation entry, the Portal computes the trust anchor and the scope from the agreements addressed by the reconciliation entry carrying the same Reconciliation Hash. A Continuation entry names no registers of its own, and an intersection taken over an empty set of agreements would either deny every regulator or restrict none, which are the two failures the rest of this section exists to avoid.¶

The fields a Continuation entry carries are structural: an entry type, a sequence number, a timestamp, chain hashes, and a pointer to an artefact. None is a register record, a claim value or a verdict. A regulator in scope for a reconciliation entry is therefore in scope for every field of every Continuation entry carrying that entry's Reconciliation Hash, without any agreement having to enumerate those fields. The alternative -- intersecting a set of field names no agreement mentions -- yields the empty set, and would make a Sovereign Re-Notification arrive at a regulator that is then returned nothing when it follows the pointer. Agreements negotiated before this revision name none of these fields, and Section 4.21 forbids retroactive evaluation from requiring any agreement to be renegotiated.¶

Both intersections are load-bearing. Taking the union across agreements would let one register operator's permissive agreement widen what a regulator may read about a reconciliation that also addressed a restrictive register, inverting the data-residency property this protocol exists to preserve; and requiring the trust anchor in only one agreement would let a single register operator unilaterally introduce a regulator identity that authenticates against multi-register events. Intersecting with the requester's own requested set is not itself a restriction, since the requester chooses it.¶

4.20. Audit Path

Several requirements in this document are justified by what an auditor can reproduce: the re-typing decision of Section 4.12 "without the server's assurance", the Query Binding of Section 4.8, the Policy-Version Hash "under audit" of Section 4.16, and the Deployment Blinding Value of Section 4.16. No earlier revision defined that path, so every one of those justifications rested on a party the document did not admit.¶

Each Bilateral Register Agreement MUST declare at least one Audit Identity: an identifier and a key thumbprint, in the form Section 4.15.1 uses for an Audience Member. A party authenticating as an Audit Identity under Section 6.4.1 is entitled to:¶

• every operation of Section 6.4.2, unredacted, over any reconciliation addressing the register whose agreement declares that identity¶

• the Reconciliation Outputs of those reconciliations, irrespective of their Audience Sets, by GET /arp/outputs/{reconciliation-hash}¶

• for a named reconciliation, every element of the Policy-Version Hash preimage of Section 4.16 EXCEPT the Deployment Blinding Value, together with a Reconstruction Proof: a keyed digest, computed as HMAC-SHA-256 under the Deployment Blinding Value over the disclosed elements, which the auditor recomputes only if it is also given the Value, and otherwise compares against the Reconstruction Proof the server returns beside the Output under GET /arp/outputs/{reconciliation-hash} to a requester authenticated as an Audit Identity¶

An Audit Identity is NOT given the Deployment Blinding Value, and is not given the preimage in full, because the preimage contains it. The Value is one deployment-wide constant and its holder can invert every Claim Hash and Policy-Version Hash on the published Ledger by the exhaustive search Section 4.16 describes, including those of reconciliations the auditor's own register had no part in; every agreement declares an Audit Identity, so disclosing the Value to one would disclose the deployment to all of them.¶

What the auditor can therefore establish is that the disclosed policy elements are the ones the server used, and not that the resulting hash is correct: the last step needs the Value. A deployment that requires the stronger property MUST appoint an Audit Identity jointly with every register whose agreement it holds, and MAY disclose the Value to that joint identity alone. This document states the limit rather than resolving it, because a construction that let one register's appointee verify a deployment-wide digest without holding the deployment-wide secret is a different mechanism than the one specified here.¶

An Audit Identity is declared in an agreement rather than named by a requester, because the party being audited must not choose its auditor after the facts are known, and because the register whose records are at issue is the party with standing to insist on one. Its entitlement is scoped to reconciliations addressing that register: an auditor appointed under one agreement reads nothing about a reconciliation that agreement had no part in.¶

Every access under an Audit Identity MUST be recorded in the append-only audit trail of Section 4.19. An unaudited audit right is a standing unaccountable read of every Output a deployment holds.¶

4.21. Retroactive Evaluation

Upon publication of an updated Pattern Library, an updated Policy Version, or a new Source-Data Version for any list a register consulted under Section 4.6, the Retroactive Evaluation Subsystem MUST execute a deterministic re-application of the updated state to the retained metadata of historical Reconciliation Outputs -- the Per-Register Result Set, the resolved arithmetic and its parameters, and the Source-Data Version Identifiers, being the inputs from which a Combined Verdict is recomputed. Under a Pattern-Library or Policy-Version trigger the set to be examined is those Outputs sealed against a superseded Policy-Version Hash. Under a Source-Data Version trigger the policy state is unchanged and that set would be empty; the set is instead those Outputs whose Per-Register Result Set carries a Source-Data Version Identifier from the list that was republished. Under a credential-revocation trigger it is those whose Requester-Binding rested on the revoked credential. Where permissible under the applicable Bilateral Register Agreements, partial attestations MAY be re-invoked.¶

The retroactive evaluation MUST be executable without re-negotiation of any Bilateral Register Agreement. A material change in a historical Combined Verdict -- defined as any change of verdict value into, out of, or between the decisive values, the decisive values being match and no-match -- MUST trigger a Sovereign Re-Notification through the Regulator Portal, and MUST additionally be recorded as a Continuation entry of type continuation-supersession against the superseded Output, under the field rules of Section 4.18, so that a party which acted on the superseded Output can discover that it was superseded. Notifying only the regulator would leave the party that acted on a verdict the last to learn it had changed. A transition from no-match to match is material: it is the case the protocol's motivating domain cares most about, and a definition that excluded transitions within the decisive class would omit it. Revocation of a Verified Principal Credential relied upon in a historical reconciliation is itself a material change: the Retroactive Evaluation Subsystem MUST re-derive the affected Requester-Binding class and, where a decisive reconciliation was performed for what is now an unverifiable requester, emit a Sovereign Re-Notification.¶

4.22. Cryptographic-Primitive-Upgrade Path

Each Bilateral Register Agreement MUST declare a Cryptographic-Primitive-Upgrade Path comprising an ordered equivalence list for each of three primitive classes: claim-encryption, partial-attestation-signature, and sealing-signature. The equivalence list MUST include at least one post-quantum primitive for each class, drawn from a set including ML-KEM [FIPS203] for key encapsulation and ML-DSA [FIPS204] for signature operations.¶

A primitive rotation MAY be executed simultaneously across the three layers without bilateral renegotiation. The Settlement-Layer Ledger remains continuous across the rotation because Ledger entries commit to hashes of canonicalised content rather than to cryptographic identities. The Entry Signature and the Sealing-Key Identifier it carries are the exception, and a verifier MUST resolve the Sealing-Key Identifier carried by each entry rather than assume one key across the chain. An entry signed under a superseded primitive remains verifiable under the key that identifier resolves. The chain is unbroken across a rotation, but not because it is independent of the primitive: the Prior-Entry Hash of Section 4.18 is taken over the whole preceding entry including its Entry Signature, so it depends on that signature's bytes and on the algorithm identifier in its protected header. It is unbroken because those bytes are fixed at the moment the entry is appended and are never rewritten. A verifier recomputing a Prior-Entry Hash across a rotation boundary MUST therefore be able to re-serialise a signature made under a primitive it does not itself implement, which is a weaker requirement than verifying it.¶

6.1. CBOR-COSE Encoding

The mandatory-to-implement encoding for ARP messages on the wire is CBOR with COSE [RFC9052] [RFC9053] envelopes. COSE_Sign1 is used for both Partial Attestations and the Sealing Signature. The protected header of a Partial Attestation and of a sealed Reconciliation Output MUST include the Bilateral-Register-Agreement Hash and Policy-Version Hash as COSE header parameters; the other COSE_Sign1 structures this document defines carry the headers their own sections state registered per Section 9. arp-bilateral-agreement-hash always carries an array, sorted in lexicographic byte order: a Partial Attestation's array has exactly one member, and a Sealing Signature's has one per addressed register. A single encoding for both avoids a decoder having to infer the type from context. Pending registration, implementations MAY use labels from the private-use range of the COSE Header Parameters registry; such use is not interoperable.¶

6.2. Reconciliation Request Binding

A reconciliation is commissioned by POST /arp/reconciliations on the reconciliation server's authority origin, with a request body carrying the Canonical Claim, the Audience Set the requester asks for, and, where the requester is an agent, its asserted principal. The body is CBOR under the media type registered in Section 9 for a reconciliation request, save for the Canonical Claim, which is carried as a CBOR byte string holding the [RFC8785] serialisation of the claim exactly as the Claim Hash is taken over it. Carrying the claim as native CBOR would need the CBOR-to-JSON mapping Section 4.14 declines to define, and two servers receiving identical bytes would compute different Claim Hashes. The request MUST be signed under the profile of Section 6.4.1, with tag set to arp-reconcile.¶

An Audience Member other than the Requesting Principal MUST have been enrolled at the reconciliation server before it may be named: an enrolment binds an accountable-principal identifier to a Verification Method Reference, is performed by the party being enrolled, and is out of scope for this document. A server MUST refuse to name an unenrolled member. Without enrolment a requester could name any identifier it liked, and the named party -- a competitor, a journalist, a foreign ministry -- would be handed a sealed, register-attested record that a named subject had been investigated under a named predicate, without its consent and without any register's. Naming is an assertion by the requester; enrolment is what makes it an assertion about a party that has agreed to receive.¶

The response is one of four things, the fourth being the 401 of Section 6.4.1 where the request's own signature was not accepted. A 200 whose body is the signed read response of Section 6.4.3, whose result element is the sealed Reconciliation Output and whose As-Of pair gives the Ledger head at the moment of delivery. That is the delivery Section 4.15.3 requires, and it is what carries the Reconciliation Hash: the requester computes it over the Output it has just been handed, and the signed response fixes the head against which every later read of that Output is compared. A 422 carrying a Remediation Advisory, where the Adversarial Pre-Transmission Test did not emit a Pass and no override was authorised, or where a named regime is not one the policy-epoch store admits for the predicate, or where a named Audience Member is not enrolled. Or a 403 carrying a Remediation Advisory whose sole content is the Agent-IFF ground, where the Agent-IFF policy of the Requester Identity Binding and Agent Friend-or-Foe Gate section refuses the requester outright for the predicate class. Both refusals are signed as Section 6.4.3 requires of a 4xx, so a refused requester holds evidence of what it asked and what it was told.¶

A refusal under Section 7.1 or an audience constraint under Section 4.15.1 is not a fourth case: those refuse a register, and the reconciliation is sealed and delivered with the reason recorded against that register.¶

6.3. HTTP Message Signature Binding

Where a reconciliation is requested over HTTP by an autonomous agent, the request MUST be signed under HTTP Message Signatures [RFC9421], with the signature-agent key resolvable through a Web Bot Auth signature-agent card [I-D.meunier-webbotauth-registry], advertised via the Signature-Agent header [I-D.meunier-webbotauth-httpsig-protocol] and resolved through the HTTP Message Signatures directory it names [I-D.meunier-webbotauth-httpsig-directory]. The reconciliation server derives the Agent Friend-or-Foe Determination from verification of that signature and, where required by the Agent-IFF policy, a Verified Principal Credential carried in the request body.¶

6.4. Output and Ledger Read Binding

This section is the wire binding for every read this document requires of a party outside the reconciliation server. Earlier revisions stated what a read returns and never how one is requested, which left every discovery path ending at a value its holder could not present to anything.¶

Requests are HTTP over TLS to the reconciliation server's authority origin, the same origin whose Sealing-Key Identifier resolves under Section 6.5.3. Every hash appearing in a path segment is base64url-encoded without padding; every authority origin appearing in one is percent-encoded as Section 2.1 of [RFC3986] provides; and every timestamp in a path or query parameter is in the form Section 4.14 pins. The @target-uri is inside the request-binding digest of Section 6.4.3, so an encoding two implementations could choose differently would make their bindings differ over the same read. A non-Requesting Audience Member is not told that origin by this protocol; it learns it from the party that named it, and this document defines no directory by which a principal discovers the servers at which Outputs naming it may exist.¶

["arp-read-v1", request-binding, status, response-time,
 as-of-sequence-number, as-of-self-entry-hash, result]

6.5. SCITT Reference API Binding

A Reconciliation Output MAY be notarised into a SCITT Transparency Service as a transparent statement. Where it is, an implementation MUST use the binding in this section. Appendix B states the architectural relationship; this section states the wire behaviour, so that two implementations registering the same Reconciliation Output against the same Transparency Service produce interchangeable results.¶

6.6. Verifiable Credentials Interop

A Reconciliation Output MAY be additionally serialised as a JSON-LD document conforming to the W3C Verifiable Credentials Data Model [W3C-VC-DM-2.0], under the media type application/arp-reconciliation-output+json registered in Section 9 -- +json rather than +ld+json, there being no such registered structured syntax suffix -- with the Reconciliation Hash, Addressed-Registers Identifier Set, Bilateral-Register-Agreement Hash Set, Requester-Binding-Class, Policy-Version Hash, Claim Hash, Combined Verdict, Audience Set and Reliance Horizon included as credential subject fields. The COSE_Sign1 envelope is the normative form; the Verifiable Credential serialisation is an interop convenience for relying parties operating in W3C VC ecosystems.¶

The Audience Set and the Reliance Horizon are not optional in this serialisation. A credential is the form of an Output most likely to reach a party outside its Audience Set, and one carrying neither the membership list against which such a party could determine that it is not entitled, nor the marker of its own staleness, would be the bearer artefact Section 4.15 exists to retire, reintroduced through the interop form.¶

7.1. Service-Operator Containment

The reconciliation server operates under a service-operator entity standing in bilateral contractual relationship with each Register Operator. The service-operator entity MUST NOT be given access to any register record or any Partial-Attestation payload beyond the verdict and divergence-axis fields, and a deployment MUST enforce that by construction -- by encryption addressed to the requester or by an equivalent measure that no internal operator action can reverse -- rather than by policy. A conformance test for this requirement is whether an operator holding every credential the deployment issues can obtain a register record; if it can, the deployment does not conform.¶

That property is per-event and MUST NOT be read as a property of the system under repeated querying. A verdict is a function of an attested value the requester chooses, so a sequence of reconciliations varying that value recovers the underlying record field by search, and several Divergence Axis values -- ownership-threshold-mismatch, register-record-absent, temporal-mismatch -- disclose record content on their own. Each event conforms while the sequence does not.¶

A deployment MUST therefore declare in each Bilateral Register Agreement a query budget and the interval over which it is measured, and the budget MUST be measured per accountable principal per subject, not per subject alone. Where the budget is shared across requesters, any one requester exhausts it for all of them -- including a requester whose Requester-Binding class is agent-unverified, which is to say a party the deployment has declined to identify -- and every subsequent reconciliation about that subject is forced to indeterminate for the remainder of the interval. That is a denial of service against every other requester, granted by the countermeasure. The recovery property this budget bounds is a property of one requester's sequence, and sequences run by colluding principals are the business of the repeated-narrowing pattern below rather than of a shared counter.¶

The budget is keyed on the accountable principal identifier where the Requester-Binding carries one. Where it does not -- classes agent-unverified and agent-key-verified -- the budget MUST be keyed on the verified signing key where one exists, and otherwise on a deployment-declared fallback key such as the authenticated transport client identity. Every requester signs, by Section 6.4.1, so every requester has a key and none falls outside the budget. Admitting a requester to a shared counter is the denial of service this paragraph exists to remove.¶

A deployment MAY additionally declare a per-subject ceiling across all principals. A ceiling is a shared counter and reintroduces that denial of service by construction, so where a deployment declares one it MUST partition it: a stated proportion reserved for principals of class human-operator and agent-verified, and within that proportion a per-principal sub-budget, so that no one principal can consume the reserve. Classes carrying no corroborated principal -- agent-key-verified and agent-unverified -- are charged only against the remainder. A reserve with no per-principal partition is exhausted by a subject that incorporates enough entities to hold enough corroborated principals, which is a purchase and not a barrier. A subject able to mint identities cheaply can otherwise exhaust the ceiling on itself and force every third-party reconciliation about it to indeterminate, which is a self-service veto over the verdicts this protocol exists to produce. Exhaustion of a ceiling is recorded as subject-ceiling-exhausted rather than query-budget-exhausted, so that the two are distinguishable in the record and an auditor can see which counter refused.¶

Where a reconciliation would exceed the budget, the reconciliation server MUST NOT transmit a projection to the affected register and MUST record query-budget-exhausted as that register's Non-Answer Reason. The reconciliation proceeds and is sealed; it cannot reach a decisive Combined Verdict, by Section 4.13. It is the register that is refused, not the reconciliation: refusing the reconciliation outright would leave no Output in which to record the reason, which is the artefact the requester needs in order to know why it was refused and the regulator needs in order to see that it was.¶

The Pattern Library MUST include a repeated-narrowing pattern so that the Adversarial Pre-Transmission Test detects the sequence rather than only the event.¶

A register cannot apply its own statutory access regime to a requester it cannot see. Where a Bilateral Register Agreement requires it, the Per-Register Claim Projection MUST carry the Requester-Binding Class, which discloses the class and not the principal.¶

7.2. Budget Exhaustion as a Suppression Channel

Section 4 places a reconciliation driven to query-budget-exhausted or subject-ceiling-exhausted outside the reproducibility requirement, because the budget is accumulated state rather than an enumerated input. That carve-out is a suppression channel and is recorded here as one.¶

Any non-answering register makes a decisive Combined Verdict unreachable (Section 4.13). An operator that wishes to prevent a particular reconciliation from reaching a decisive verdict can therefore record query-budget-exhausted against one register, and an auditor replaying the enumerated inputs is required not to treat the divergence as a determinism failure. The reason is server-observed under Section 4.11, so no register signature contradicts it.¶

Two mitigations are available and neither is adopted here. Publishing the budget counter and interval boundaries beside the refusal would let an auditor distinguish exhaustion from suppression -- and would tell every requester how much third-party interest a subject has attracted, and exactly when to exhaust the counter so that no other party obtains a decisive verdict, which is a worse disclosure than the one it cures. Requiring a register-signed acknowledgement of each charge against the budget would remove the server's discretion, at the cost of a round trip to every addressed register on every refused reconciliation, including the ones the budget exists to avoid making.¶

The per-subject ceiling of Section 7.1 is the stronger of the two channels, because it is a counter several principals share: an operator need not fabricate anything, only decline to reserve enough of it. Section 7.1 requires the reserve to be partitioned per principal for that reason, and the residual is that the size of the reserve is a deployment choice this document does not bound.¶

A deployment concerned with either channel should bound it contractually: the budget, its interval and the audit right over the counter are all declared in the Bilateral Register Agreements, and an Audit Identity under Section 4.20 can be given the counter state directly. That is an out-of-band remedy and it is stated as one.¶

7.3. Pattern-Library Integrity

The Adversarial Pre-Transmission Test gates onward transmission. The Pattern Library MUST be bound to a Pattern-Library Commitment Hash. Any modification to the Pattern Library MUST produce a new Pattern-Library Version Identifier, and the Adversarial Pre-Transmission Test MUST be re-executed against the new library before the change takes effect.¶

7.4. Agent Impersonation and Friend-or-Foe Integrity

The Agent Friend-or-Foe Determination is the mechanism by which ARP resists reconciliation initiated by an agent impersonating a principal. The determination MUST default to ENEMY: absence of a verifiable identity, an expired or revoked signature-agent key, a failed HTTP Message Signature [RFC9421] verification, or a Verified Principal Credential that does not validate MUST all yield an ENEMY classification. The server MUST NOT infer friendliness from network origin, User-Agent string, or any self-asserted identifier, as these are trivially forgeable. Where an ENEMY requester is permitted for advisory reconciliation, the resulting Reconciliation Output MUST NOT carry a decisive verdict binding, and the Settlement-Layer Ledger entry MUST record the requester-binding class the gate determined -- agent-unverified where no verifiable identity was presented, or agent-key-verified where a key verified and the asserted principal was not corroborated -- so that downstream reliance is aware no accountable principal was established and can still tell the two apart.¶

7.5. Bilateral-Register-Agreement Drift

Each Bilateral Register Agreement carries an Agreement Hash. Each Partial Attestation includes a reference to the Agreement Hash under which it was issued. Agreement drift is detectable by comparison of agreement-hash references across Partial-Attestation batches. Reconciliation MUST be suspended for an addressed register whose Agreement Hash deviates from the hash committed at the start of a reconciliation event.¶

7.6. Replay Defence

Each Partial Attestation MUST carry a Freshness Timestamp. The reconciliation server MUST verify the Freshness Timestamp against a freshness window declared in the Bilateral Register Agreement. Stale Partial Attestations MUST be rejected, and the rejection MUST be recorded in the Reconciliation Output under Section 4.11 with the Non-Answer Reason attestation-stale and a freshness-stale divergence axis attributed to that register. A signed agent request under [RFC9421] MUST additionally carry a nonce and created/expires parameter set that Section 6.4.1 requires, so that a captured signed request cannot be replayed to initiate a fresh reconciliation.¶

7.7. Post-Quantum Migration

The Cryptographic-Primitive-Upgrade Path is the mechanism by which ARP deployments migrate to post-quantum primitives. ML-KEM-1024 [FIPS203] is RECOMMENDED for the claim-encryption primitive class. ML-DSA-65 [FIPS204] is RECOMMENDED for the partial-attestation-signature and sealing-signature primitive classes. Implementations MUST declare their chosen post-quantum primitives in the Bilateral Register Agreement.¶

7.8. Side-Channel Considerations

The disclosure model as a whole, and the residual risks this document accepts, are set out in Section 8.¶

Per-register projection narrowing is observable to the addressed register through the Projected Predicate. Implementations MUST NOT use narrowing patterns to fingerprint individual subjects. The Predicate Taxonomy SHOULD be designed such that the set of permitted narrowings is small enough that narrowing observation does not materially weaken subject privacy.¶

9.1. Well-Known URIs

Six entries are requested in the Well-Known URIs registry of [RFC8615]. For each, the change controller is the IETF, the status is permanent, and the specification document is this document.¶

9.2. Media types

Eleven media types are requested, registered under the template of [RFC6838]. For each: the type name is application; there are no required and no optional parameters; the encoding considerations are binary, save for the +json type, which is 8-bit UTF-8 text; the security and interoperability considerations are those of this document; the published specification is this document; the intended usage is COMMON; the change controller is the IETF; the applications that use the type are ARP reconciliation servers, registers, regulators and relying parties; there are no restrictions on usage; the author is the author of this document and the contact address is the one on its front page; there are no deprecated alias names, no magic numbers and no customary file extensions; and fragment identifier considerations are those of the structured syntax suffix where one applies -- Section 3.1 of [RFC6839] for +json -- and are otherwise none, no fragment identifier syntax being defined for the +cbor and +cose forms.¶

A.1. Example: Three-register Sanctions Reconciliation

This example is illustrative and non-normative; register identifiers, values and parties are fictitious, and no bilateral agreement with any named authority is asserted or implied. Suppose a relying party requests reconciliation of the predicate sanctions:any-list-match for subject identifier corp:EXAMPLE:0123456789 against three consolidated sanctions registers.¶

Each Bilateral Register Agreement permits the predicate. The projection function emits identical Per-Register Claim Projections to all three registers. All three return Partial Attestations with verdict no-match.¶

The Aggregation Subsystem operates in Hash-Linkage Aggregation. The Verdict Arithmetic, resolved from policy for the regimes the claim names, is disjunction. The Combined Verdict is no-match.¶

The requester named itself and its compliance department's shared identity in the Audience Set; no addressed register declared an audience constraint, so both are admitted. The reliance interval that policy declares for sanctions: predicates is seven days, so the Reliance Horizon is 2026-05-04T19:47:14Z. The Output is sealed against the current Policy-Version Hash and returned to the requester in the signed read response to the request that commissioned it, over which the requester computes its Reconciliation Hash.¶

The Settlement-Layer Ledger entry comprises:¶

• Entry Sequence Number: 42¶

• Entry Type: reconciliation¶

• Claim Hash: <32 bytes>¶

• Reconciliation Hash: <32 bytes>¶

• Entry Timestamp: 2026-04-27T19:47:15Z¶

• Prior-Entry Hash: <32 bytes>¶

• Policy-Version Hash: <32 bytes>¶

• Addressed-Registers Identifier Set: ["https://register-a.example", "https://register-b.example", "https://register-c.example"]¶

• Aggregation-Method Descriptor: hash-linkage-disjunction¶

• Merkle Root: <32 bytes>¶

• Requester-Binding-Class Descriptor: "human-operator"¶

• Reconciliation Timestamp: 2026-04-27T19:47:14Z¶

• Source-Reconciliation-Output Identifier: CBOR null -- this reconciliation supersedes none¶

• Override Indicator: false¶

• Self-Entry Hash: <32 bytes>¶

• Entry Signature: COSE_Sign1, Sealing-Key Identifier (https://arp.example, example-sealing-2026-01)¶

The one absent field occupies its position as CBOR null, so that the array's length is fixed by the Entry Type and the Self-Entry Hash is taken over a determinate encoding. When the sealed Output is registered with a Transparency Service, the EntryID it returns is not written into entry 42, which is already signed; it is appended as a later entry:¶

• Entry Sequence Number: 57¶

• Entry Type: continuation-notarisation¶

• Claim Hash: <the same 32 bytes as entry 42>¶

• Reconciliation Hash: <the same 32 bytes as entry 42>¶

• Entry Timestamp: 2026-04-27T19:52:03Z¶

• Prior-Entry Hash: <32 bytes>¶

• Transparency Service Identifier: https://ts.example/¶

• the notarisation outcome: ["entry-id", <the identifier that service returned>]¶

• Self-Entry Hash: <32 bytes>¶

• Entry Signature: COSE_Sign1, Sealing-Key Identifier (https://arp.example, example-sealing-2026-01)¶

Entry 57 carries no Policy-Version Hash and no Addressed-Registers Identifier Set; entry 42 records those and the shared Reconciliation Hash binds them. No register record content is stored on the Ledger in either entry. Had the registration neither completed nor been refused within the polling bound, entry 57 would not exist: the outcome would be a Post-Seal Evaluation Record qualified notarisation-incomplete, pointed to by a continuation-post-seal-record entry, and a later completion -- were the server able to learn of one, which Section 4.18 records as an open question -- would be appended as a continuation-notarisation entry later in the sequence. Had the service instead refused registration terminally, the second field would read ["refused", 400].¶

On 2026-05-06, two days past the Reliance Horizon, the compliance department wishes to rely on the verdict again. Being an Audience Member it presents a signed GET /arp/continuations/{reconciliation-hash}. The server answers 200 with a signed response carrying the ledger head it was served against and, as its result, entry 57 alone. That the result contains no continuation-supersession entry is a signed statement by the server that as of that head there was none -- not merely the absence of one -- and the department retains it. Had it not been an Audience Member the same request would have returned 404, which is also what it would have received had the Reconciliation Hash named nothing at all.¶

A.2. Example: Retroactive Re-evaluation

Continuing the illustrative example above: six weeks after that reconciliation, the list register-a.example consults adds the subject as part of a new tranche. That register, on next invocation over the bilateral channel its agreement declares, returns verdict match.¶

The Retroactive Evaluation Subsystem detects the new Source-Data Version the list publisher issued, re-invokes Partial Attestations on the historical reconciliations whose Per-Register Result Set carries a Source-Data Version Identifier from the republished list, identifies the material verdict change, and emits a Sovereign Re-Notification through the Regulator Portal to the regulators whose statutory-regulator-access scope intersects the changed reconciliation.¶

It also emits an Evaluation Sweep Statement recording the trigger source-data-version, the identifier of the list version that triggered it, the policy state applied, the ledger head at the start and end of the sweep, the Examined-Set Root over the Claim Hashes it examined, and the counts examined and materially changed. The compliance department later presents that root and its own Claim Hash to GET /arp/sweeps/{examined-set-root}/inclusion/{claim-hash} and is shown that its reconciliation was in the set the server claims to have examined. Had the server not run the sweep, there would be no Statement covering a list republication whose date is public, and its absence would itself be the finding.¶

The supersession is recorded from both ends. A new Reconciliation Output is sealed against the current Policy-Version Hash and appended as a reconciliation entry whose Source-Reconciliation-Output Identifier is the Reconciliation Hash of the superseded Output. A continuation-supersession entry is then appended against the superseded Output, carrying that Output's Claim Hash and Reconciliation Hash, a Material-Change Indicator of true -- the verdict moved from no-match to match, which is decisive-to-decisive and therefore material -- the Superseding-Reconciliation Hash of the new Output, and the Entry Sequence Number of the entry that records it.¶

The compliance department, an Audience Member of the original Output, presents GET /arp/continuations/{reconciliation-hash} again. This time the signed response carries the continuation-supersession entry. It reads the Superseding-Reconciliation Hash, presents GET /arp/outputs/{superseding-reconciliation-hash}, and is served the new Output -- because a superseding Output inherits the Audience Set of the Output it supersedes, so the party entitled to learn that its verdict changed is entitled to see what it changed to. It verifies the new Sealing Signature, reads the match, and acts.¶

Had the department retained the earlier signed empty response and the server now denied that any supersession existed, the two signed statements by one key would be irreconcilable, which is the point of signing them.¶

A party that is not an Audience Member -- one that was handed the Output by someone who was -- reaches none of this. It may verify the Sealing Signature and read the no-match, which is what makes an Output worth handing on, and it obtains no read, learns of no supersession, and must not treat the verdict as current. Entitlement follows the Audience Set, not the artefact.¶

A.3. Example: Agentic Principal Reconciliation

An autonomous agent requests reconciliation of sanctions:any-list-match over HTTP, signing the request under HTTP Message Signatures [RFC9421] with a key published in a Web Bot Auth signature-agent card. The reconciliation server verifies the signature (Agent Friend-or-Foe Determination: the agent carries a verifiable identity). That establishes the class agent-key-verified -- the key verified and the asserted principal is so far uncorroborated -- and the Agent-IFF policy for the sanctions: class does not admit a decisive verdict at that class.¶

The server therefore first performs an agent:principal-binding-verifiable reconciliation with Subject Identifier set to the agent's key thumbprint and Attested Value set to the asserted principal org:ACME:operator:jdoe, addressing the ACME organisational directory register and the credential-issuer status-list register. Both return match. The Requester-Binding class is raised to agent-verified with accountable principal org:ACME:operator:jdoe, committed to the Policy-Version Hash, and only then is the sanctions reconciliation performed with a decisive verdict binding. Had either identity register returned no-match with an attested Divergence-Axis Field of agent-impersonation-suspected, the agent would have been classified ENEMY -- a contradicted binding is a stronger signal than an absent one -- and the sanctions reconciliation refused or downgraded to advisory per policy.¶

The distinction is not bookkeeping. Under -02 both states were recorded as agent-verified, so a relying party reading the Ledger entry for the first reconciliation could not tell an agent whose principal had been corroborated against two registers from one that had merely signed correctly.¶

A.4. Example: Divergent Agent-Action Reconciliation

This example is illustrative and non-normative. Capsule slots are those of [I-D.mih-sato-agent-accountability-composition]; see Appendix D.¶

An autonomous agent is authorised, by a signed CAN capsule, to read from a named evaluation dataset and to write only to a sandboxed result store. During execution the agent's actual conduct, attested by a WHAT capsule produced by the execution environment, includes an outbound network connection to an external host and a write outside the sandboxed store.¶

A relying party submits both capsules to ARP over the agent: predicate branch with a shared subject digest computed over the action. ARP verifies each capsule's signature, projects the authorised scope from the CAN capsule and the actual scope from the WHAT capsule, and reconciles them. The scopes diverge: the actual conduct exceeds the authorised scope. The Combined Verdict is no-match, and agent-action-scope-divergence is recorded in the Server-Recorded Divergence-Axis Set: it is a relation between two capsules and no single capsule producer can attest it, on the same reasoning that makes source-version-skew server-recorded.¶

Because the Agent-IFF policy for this action class requires a decisive match before the action is treated as authorised, the divergent verdict is available as a refusal at decision time -- the reconciliation surfaces the excess while the action can still be refused, rather than after the consequence. The Reconciliation Output is sealed against the Policy-Version Hash and written to the Settlement-Layer Ledger without claim or register content, with requester-binding class agent-verified -- the agent's asserted principal having been corroborated as in the preceding example -- and no register or capsule content disclosed.¶

D.1. The two digest constructions are distinct

This document defines two digest constructions over a JSON serialisation, for two different purposes, and they are NOT interchangeable:¶

Claim Hash:

SHA-256 over the Canonical Claim serialisation of Section 3 together with the Deployment Blinding Value of Section 4.16. Its purpose is to index a claim in the Settlement-Layer Ledger. It applies Unicode Normalization Form C.¶

subject_digest:

SHA-256 over the [RFC8785] serialisation of an action, per Appendix D. It is a CONTENT digest: it commits to the action object as serialised, and any difference in the serialised bytes yields a different digest except with negligible probability. [RFC8785] does not normalise.¶

An implementation that substitutes one for the other MUST be assumed to produce incorrect correlations. The failure is silent: both constructions return a well-formed 32-octet digest for any input, so a substitution surfaces as a correlation that does not occur, or as two distinct actions correlating to one subject, rather than as an error.¶

Two cases are worse than a mere difference of bytes, because the substitution produces a COLLISION rather than a mismatch. Under the Claim Hash construction, which normalises, an input in Normalization Form D and the same input in Normalization Form C yield the SAME digest; so do U+212B ANGSTROM SIGN and U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE. Under the subject_digest construction, which does not normalise, all four are distinct. An implementer who reuses the Claim Hash where a subject digest is required will therefore correlate two actions that a conforming implementation keeps apart. Neither case needs measuring: both follow from the two constructions as this document defines them, and either can be checked by computing the two digests over the four inputs named above.¶

Accordingly:¶

• An implementation MUST NOT use the Claim Hash construction where subject_digest is specified, or the reverse.¶

• Where a digest is carried on the wire for correlation, the producer MUST identify the construction used, by an identifier that commits to the declared canonicalisation parameters -- member-sort code unit, normalisation, number rendering, absent-member handling and hash algorithm -- so that a consumer can determine compatibility rather than assume it. Such an identifier MUST NOT commit to facts about a specification that do not affect the serialised bytes, so that two implementations producing identical bytes share an identifier. [I-D.mih-sokolov-scitt-payload-binding] expresses a compatible rule statement-side.¶

• Where the correlation digest is computed over a TYPED action object whose type declares required material fields, the producer MUST validate the object against a pinned definition of that type before emitting a correlation identifier for it, and MUST NOT emit one where validation fails. A digest is well-formed over any object, including one that omits fields the type requires; emitting an identifier in that case mints a join key for an action the identifier does not fully describe, which is the condition a relying party has no way to detect downstream. Validation against a pinned type definition is therefore required before emission.¶

E.1. Since draft-hillier-scitt-arp-02

This revision answers a review of -02 on the SCITT list. Of its five asks, three are adopted as put, one is adopted in its goal and not in its mechanism, and one is declined for now with a reason.¶

Section 6.4.3 now names the evidence that bounds the empty-result falsifiability condition. -02, and this revision as circulated for comment, said that an empty result is falsifiable to the extent that the reader "independently holds head-consistency evidence" for the served chain, without saying independent of whom. Head evidence obtained from the responding service bounds nothing, because a fork at disjoint sequence numbers is invisible from a single vantage by construction and the vantage is what is in question. The condition now names an observer independent of the responding service and carries a SHOULD on the relying party, with witness countersignature over the head preferred to an independently anchored head digest. The gap is not closed and is not claimed to be; it is bounded by evidence an implementation can be said to hold or not hold. The finding is Walter Hawkins's.¶

Section 6.5 is new and normative. -02 composed with the SCITT Reference APIs permissively -- Reconciliation Outputs MAY be notarised, registration MAY use the APIs -- which is a permission and not a binding: two implementations could both conform to -02 and fail to interoperate against the same Transparency Service. The section now fixes the registration endpoint, the COSE_Sign1 framing and content type, receipt validation, and the asynchronous registration path. The asynchronous case is stated as a requirement because it is the most likely divergence between conforming implementations: a 202 Accepted with polling against 204 No Content is not the same code path as a 201 Created, and an implementer who codes only the latter interoperates with some Transparency Services and not others.¶

The review also asked for a standard retrieval path keyed on the Policy-Version Hash. That is not specified here, because [I-D.ietf-scitt-scrapi] defines retrieval by EntryID and defines no query surface at all; a binding that specified one would specify an endpoint that does not exist. The goal -- preventing policy equivocation over time -- is met instead by requiring the Policy-Version Hash in the protected header of the Signed Statement, so that it is covered by the Receipt. A relying party therefore establishes the policy version by verification rather than by lookup, which is the stronger property: an index can be wrong, or can present different results to different relying parties, and a signed protected header cannot.¶

Section 4.5 is new. -02 specified the controlled projection function over an abstract Predicate Taxonomy without saying how an implementer determines what a given register can answer. Four profiles are defined -- [BODS], [RFC6350] with [W3C-ORG], [UNCEFACT] with [WCO-DM], and consolidated sanctions list formats. Profiles constrain predicate expression only and are prohibited from introducing any means of transporting register records, which would defeat the property the protocol exists to provide.¶

Section 4.6 is new, and is the substantive addition rather than the largest one. A designation verdict against a consolidated sanctions list is meaningful only relative to the state of that list, and consolidated lists are republished on a cadence and distributed as deltas. -02 could therefore record that a historical Combined Verdict had changed but could not attribute the change: a verdict that flipped because the policy changed and one that flipped because the list changed were indistinguishable, and Sovereign Re-Notification reported both as policy changes. Partial Attestations now carry a Source-Data Version Identifier under signature, Retroactive Evaluation must distinguish the two causes, and where it cannot it must report attribution-indeterminate rather than attribute the change to policy. A list-state identifier is a property of a published corpus and not a register record, so this does not weaken minimum disclosure.¶

Three structural gaps predating this revision are closed, because the new material could not be made testable without them. Section 4.14 enumerates the Reconciliation Output, which no earlier revision did although both the Partial Attestation and the Ledger entry were enumerated; Reconciliation Hash and Combined Verdict are now defined in Section 3, the former having been used inside the bit-for-bit determinism requirement while undefined; and the Server-Recorded Divergence-Axis Set is a set, since a reconciliation may be qualified on more than one axis and a single-valued encoding would force a silent choice.¶

Section 4.12 is new. Where a narrowing means a register's answer does not bear on the claim as asked, that register's contribution is re-typed before aggregation rather than the Combined Verdict being overridden after it, so the Verdict Arithmetic resolved under Section 4.13 is never displaced. A match found at any depth still establishes an existential closure predicate and is not re-typed.¶

Section 4.17 is new. Notarisation outcomes and retroactive attribution failures arise after a Reconciliation Output is sealed and so can be carried neither in a Partial Attestation nor in the Output; they are Post-Seal Evaluation Qualifiers recorded in a separate signed record referencing the Reconciliation Hash, and are expressly not Divergence Axes.¶

New Divergence Axis values: register-threshold-divergence, declared-not-determined and source-version-skew. New COSE header parameter arp-source-data-version, carrying a set so that a register consulting several lists can denote the state of each. arp-bilateral-agreement-hash now always carries a sorted array, of one member on a Partial Attestation and one per addressed register on a Sealing Signature, so that a decoder never has to infer the type from context. New IANA registries for Register Data-Format Profile identifiers and for Post-Seal Evaluation Qualifiers. -03 adds registries for Ledger Entry Types, Override Grounds, Retroactive Evaluation Triggers and Aggregation-Method Descriptors. [I-D.ietf-scitt-scrapi] moves from informative to normative, because Section 6.5 imposes requirements that cannot be met without it.¶

A role-by-role walkthrough of the whole pipeline -- requester, agent, reconciliation server, register operator, relying party, Transparency Service, regulator, retroactive subsystem and IANA expert -- was run against this revision and found a further class of defect that no earlier review had reached: requirements addressed to an actor that does not hold the inputs they name. Those are closed here, and most of them predate -02.¶

Section 4.4 now enumerates the Per-Register Claim Projection. It is the only structure a sovereign register receives and it was the sole major structure in the protocol without a field list, which made the register role unimplementable. The register echoes the Policy-Version Hash rather than computing it, and the server MUST now send one Policy-Version Hash to every addressed register and verify each echo -- without which the per-register signatures over it, the only independent corroboration the protocol has, were discarded at aggregation.¶

Section 6.5.3 is new. -02 and the earlier -03 text told a relying party to verify a Sealing Signature whose key it had no way to obtain: it holds hashes of bilateral agreements it is not party to. Sealing keys are now published at a well-known location on a declared authority origin, mirroring how [I-D.ietf-scitt-scrapi] treats Transparency Service keys.¶

Section 4.13 is new. Every operator is now given its result for every combination of contribution values, and whether it admits partial-match, on which Section 4.12 turns. -02 delegated combination to an operator it named but never defined, so two conforming implementations could produce different Combined Verdicts from identical inputs while the determinism requirement demanded they not.¶

Section 4.11 is new. A register may fail to answer in eleven distinct ways and no earlier revision defined an outcome for any of them; dropping the register silently produces exactly the addressed-register-cherry-picking the adversarial test exists to detect. A reconciliation with any non-answering register can no longer reach a decisive Combined Verdict.¶

The Reconciliation Output gains the Claim Hash, a timestamp, the Verdict Arithmetic, the Sealing-Key Identifier, per-register attested and effective verdicts with the re-typing ground, per-register echoed Policy-Version Hashes, and register attribution on the server-recorded divergence axes. Without the Claim Hash a relying party received a verdict with nothing to attribute it to, and the retroactive subsystem had no key to select on although the Claim Hash was already declared its key. The Settlement-Layer Ledger gains the Claim Hash and now exposes READ as well as APPEND -- the Regulator Portal, retroactive evaluation and the chain-invariant check all require reads that "only APPEND" forbade. Ledger entries are now signed, because prior-entry hashes prove that nothing was removed from a chain and not that only one chain exists.¶

The Ledger now carries two kinds of entry under an Entry Type discriminator, and each type's fields are enumerated. Facts arising after an Output is sealed -- the outcome of notarisation, a Post-Seal Evaluation Record, a supersession -- are recorded as Continuation entries appended against the Reconciliation Hash they concern. An earlier revision of this text described Continuation entries without giving them a form: they carried fields the entry list did not admit, supplied none of the fields it made mandatory, and nothing distinguished one kind from another. Section 4.17 correspondingly no longer requires a Post-Seal Evaluation Record Hash to be appended to an already-signed entry, which the Ledger's absent UPDATE made impossible. Supersession is now recorded from both ends, the superseding entry naming what it replaced and a Continuation entry naming what replaced it, because neither pointer is reachable from the other's starting point. A retriever of a Post-Seal Evaluation Record must now check the retrieved bytes against the hash carried beside them, and that hash's construction is defined. A supersession entry carries the superseding entry's sequence number rather than a retrieval URI: obliging every reader to dereference an operator-chosen URI before it could check anything would have been a forced fetch, a de-blinding oracle and a covert channel no constraint on the URI's content could close.¶

The Self-Entry Hash is defined, and is taken after the type-specific fields so that it covers them. The Prior-Entry Hash is now taken over the whole preceding entry including its Entry Signature. Chaining Self-Entry Hash to Self-Entry Hash would have left every signature outside the structure that detects tampering, which is a poor place for the field this document relies on to make a second chain attributable. Entry encoding and field order are stated, because the Self-Entry Hash is taken over them and a CBOR map would have been re-sorted by key.¶

E.2. Since draft-hillier-scitt-arp-01

This revision closes canonicalisation ambiguities identified by running an implementation of -01 against two published conformance corpora -- the EMILIA clean-room frozen-v1 agent-action corpus and the Noa AI-agent-receipt corpus -- states the role of the Appendix D subject digest explicitly, and corrects a number of requirements that were unsatisfiable, untestable or out of scope as written in -01. The harness and its machine-readable results were posted to the SCITT mailing list.¶

• [RFC8785] is now a NORMATIVE reference. -01 named JCS in Appendix D without identifying which JCS; the string "8785" did not occur in -01 at all. Agreement with a deployed profile depended on both parties having independently selected [RFC8785]. It is now an obligation rather than a coincidence.¶

• The Canonical Claim in Section 3 now pins its member-sort code unit to UTF-16, per Section 3.2.3 of [RFC8785]. -01 said "lexicographic sorting of object keys", which does not determine the ordering of member names outside the Basic Multilingual Plane.¶

• Number rendering now cites Section 3.2.2.3 of [RFC8785]. -01 cited "canonical JSON RFC 8259 number rendering"; RFC 8259 defines no canonical number rendering, and was an informative reference in -01.¶

• "Stripping of undefined values" is replaced by a statement about absent members, JSON having no undefined value to strip.¶

• New Appendix D.1 states that the Claim Hash and subject_digest are distinct constructions that MUST NOT be substituted for one another, and records the two observed COLLISION cases (Normalization Form D against Form C, and U+212B against U+00C5) in which a substitution fails silently rather than visibly.¶

• New Appendix D.1.1 states what subject_digest is and what it is not, which -01 left to be inferred. subject_digest is a content digest: collision-resistant over content, and therefore NOT stable under the variation an action type permits. Measured: five conforming instances of one registered action type, each accepted by that type's reference issuer and differing only in content the type declares OPTIONAL, produced five distinct subject digests. The section now separates the case the construction supports -- capsules over one shared serialisation, which is what Appendix D composes -- from the case it does not, and requires a profile needing the latter to pin its member set or to join on a material identifier the action type declares. It also forbids describing a content digest as a correlation key without saying which case is relied on.¶

• The order of canonicalisation operations in Section 3 is now normative. Normalization Form C is applied BEFORE the member sort. The two do not commute: for an object whose member names are U+0041 U+030A and "B", normalising first and sorting first produce different Claim Hashes. -01 gave the operations as an unordered list.¶

• [I-D.mih-sato-agent-accountability-composition] remains an informative reference. Appendix D composes over the capsule slots it defines and would cite it normatively, but it is an individual draft; making it normative now would create a publication dependency. The same applies to [I-D.mih-sokolov-scitt-payload-binding]. The status of both references will be revisited as those documents progress.¶

• Appendix D.1 requires that a correlation digest carried on the wire identify its construction, and requires that such an identifier not commit to facts which do not affect the serialised bytes, so that two implementations producing identical bytes share an identifier.¶

• Appendix D.1 additionally requires that a correlation identifier over a typed action object be emitted only after the object validates against a pinned definition of its type.¶

Reference and source corrections in this revision:¶

• The SCITT Architecture reference is now [RFC9943] and the COSE Merkle tree proofs reference is now [RFC9942]. -01 cited both as Internet-Drafts; both have since been published as RFCs.¶

• The Web Bot Auth architecture reference is replaced. -01 cited draft-meunier-web-bot-auth-architecture, which has been replaced by [I-D.meunier-webbotauth-httpsig-protocol]. [I-D.meunier-webbotauth-registry], which defines the signature-agent card, is retained. [I-D.meunier-webbotauth-httpsig-directory] is added, because the card is resolved through the directory the Signature-Agent header names and -01 cited no document for that step.¶

• The document date, RFCXML version and submission type are declared in the source, and keyword is a single YAML sequence.¶

• A note to the RFC Editor records the [RFC8785] downref explicitly, so that it can be called out at IETF Last Call per [RFC8067] rather than found there.¶

• Appendix D now REQUIRES that all composed capsules carry one shared action serialisation, established by the authorising party and echoed verbatim by later attesters, and states that a capsule's own account of the action travels in its payload rather than in subject_digest. -01 left the shared-serialisation condition implicit, which is the condition the digest depends on.¶

• The determinism requirement is scoped to the Reconciliation Output and to the Claim Hash, Reconciliation Hash and Policy-Version Hash; -03 removes the Reconciliation Hash from that set, as the -03 entry above records. -01 required bit-for-bit identical Settlement-Layer Ledger entries, which the entry's own sequence number, timestamp and prior-entry hash make unsatisfiable.¶

• The Claim Hash is pinned to SHA-256 in Canonical Claim Ingestion. -01 named the algorithm only in an appendix, leaving a parameter the construction identifier is required to commit to unstated in the normative body.¶

• Claim equality is stated over canonical field values, and declared array order is significant. -01 required semantically-equivalent claims to hash alike without defining semantic equivalence, which no implementer could test.¶

• The Per-Register Claim Projection is defined as the nearest permitted ancestor predicate rather than a greatest lower bound, which the Predicate Taxonomy -- a tree -- does not have, and the projection function now fails explicitly on an ambiguous or unreachable walk rather than choosing.¶

• The Settlement-Layer Ledger entry carries an OPTIONAL Source-Reconciliation-Output Identifier, which the retroactive re-evaluation example already relied on and the entry's closed field list did not admit.¶

• freshness-stale is added to the Divergence-Axis controlled set, and server-recorded axes are stated to travel in the Reconciliation Output rather than in a register's signed payload, which the reconciliation server cannot modify.¶

• COSE header labels are requested from IANA rather than asserted as a vendor-private range, and an IANA registry is requested for Divergence-Axis values.¶

• The examples are de-identified. Register identifiers are illustrative and no bilateral agreement with any named authority is asserted.¶

• Two independent implementations of an [RFC8785]-based digest construction, one in Go and one in Python and sharing no source, were measured as agreeing byte-for-byte on 24 generated inputs selected to exercise absent-field normalisation, arrays, string escaping, UTF-16 member sorting and both integer bounds. Two implementations derived from one source would have demonstrated code identity rather than agreement, which is why the pair is named. That is the outcome Appendix D.1 argues for: one identified construction per digest role, committing to the parameters that affect the serialised bytes and to nothing else.¶

E.3. Since draft-hillier-scitt-arp-00

• Added a fourth motivating deficiency (unverifiable requester identity in an agentic setting) to the Introduction.¶

• Added a new pipeline subsystem, Requester Identity Binding and Agent Friend-or-Foe (IFF) Gate, and renumbered the pipeline to twelve subsystems.¶

• Added the agent: predicate branch, a new Agentic Principal Reconciliation section, and the divergence axes agent-principal-unverifiable, agent-credential-absent, and agent-impersonation-suspected.¶

• Added Requester-Binding to the Policy-Version Hash commitment and a requester-binding-class descriptor to the Settlement-Layer Ledger entry.¶

• Bound ARP to HTTP Message Signatures [RFC9421] and Web Bot Auth for signed agent requests, and added an Agent Impersonation security consideration.¶

• Replaced the stale scitt-receipts reference with COSE Receipts [RFC9942] and added the SCITT Reference APIs [I-D.ietf-scitt-scrapi]; Hash-Linkage Aggregation now emits COSE Receipts.¶

• Described the Evidentiary Provenance Manifest's optional carriage as a COSE-enveloped Verified-Principal-Credential evidence container.¶

• Extended Retroactive Evaluation to treat credential revocation as a material change, and added a new IANA header label and worked agentic example.¶

• Added the motivating agentic-containment failure class to the Introduction and framed real-time reconciliation of claimed-versus-actual conduct as a first-class property, distinct from after-the-fact forensic reconstruction.¶

• Added a Composition with Agent-Action Accountability Capsules section reconciling heterogeneous CAN/WHO/WHAT/AUDIT capsules [I-D.mih-sato-agent-accountability-composition] over a shared subject digest into a producer-agnostic verdict, with a worked divergent agent-action example.¶

• Added the agent-action-scope-divergence divergence axis.¶

• Removed two unused informative references (JWS, JWT).¶