]> Certisyn, Inc.

United States of America jhillier@certisyn.com

Security Internet-Draft SCITT RATS attestation reconciliation cross-jurisdictional policy-version agentic-AI friend-or-foe This document specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, minimum-disclosure mechanism for reconciling verification claims against a plurality of sovereign authoritative registers without raw register records leaving their data-residency jurisdiction. ARP extends the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture to cross-sovereign claim reconciliation. A reconciliation server canonicalises a structured claim, binds the identity of the requesting principal -- including, where the requester is an autonomous agent, a friend-or-foe determination of that agent's verifiable principal binding -- projects the claim through register-specific controlled projection functions producing the nearest permitted ancestor predicate supported by each addressed register, transmits register-specific ciphertexts, receives partial attestations whose payload discloses, of the subject, only a verdict, an optional divergence axis, the applied profile parameters and a query binding digest, aggregates those attestations under a verdict arithmetic the deployment's policy resolves, committing each register's contribution to a Merkle tree, and seals the resulting reconciliation output against a policy-version hash. An append-only cross-jurisdictional settlement-layer ledger records digests and structural metadata, with no claim, register-record or principal content. The protocol supports retroactive re-evaluation of historical reconciliations under updated pattern libraries or policy versions without bilateral renegotiation, and a cryptographic-primitive-upgrade path including post-quantum primitives. This revision adds a normative binding to the SCITT Reference APIs, register data-format profiles for beneficial-ownership, corporate-registry, customs and consolidated-sanctions formats, and a source-data version binding that makes a change in a historical verdict attributable to a change in policy or to a change in the underlying published corpus.

Note to the RFC Editor RFC EDITOR: please remove this section before publication. This document is Standards Track and makes four normative references to Informational documents: RFC 6839, RFC 8785, RFC 9053 and RFC 9334. Each is a downref under . RFC 6839, RFC 9053 and RFC 9334 are already recorded in the downref registry, so no Last Call action is required for them; RFC 8785 is not, and it is the one that needs the announcement below. That reference is deliberately normative: ARP's Canonical Claim is a digest over an RFC 8785 serialisation preceded by Unicode Normalization Form C, and the subject digest of is a digest over an unmodified RFC 8785 serialisation. Neither can be computed without RFC 8785, and an implementation that substituted any other canonicalisation would compute a different value for the same claim. The reference is therefore load-bearing for interoperability and cannot be demoted to informative. This is called out here so that the downref can be noted in the IETF Last Call announcement, which Section 2 of strongly recommends without requiring. This document also makes a normative reference to , which at the time of writing has completed IETF process and is in the RFC Editor queue with no RFC number yet assigned. imposes requirements expressed in terms of that document's endpoints, status codes and media types, and an implementation cannot satisfy them without it, so the reference cannot be informative. RFC EDITOR: this document should not be published before that draft, and the reference should be updated to the resulting RFC number.

Introduction Sovereign authoritative registers record facts that are treated as conclusive within their jurisdiction. Examples include beneficial-ownership registers (such as the United States FinCEN Beneficial Ownership Secure System, the United Kingdom People with Significant Control register, and the European Union beneficial-ownership registers under the Anti-Money-Laundering Directives), corporate registries, consolidated sanctions lists, export-control registers, foreign-ownership-and-control-or-influence registers, maritime vessel registrations, flag-state registers, aviation registrations, land-title registries, customs declarations, and multilateral biometric registers. Institutional decision-makers -- including export-control compliance officers, anti-money-laundering review functions, foreign-investment screening review functions, sanctions-screening operators, multilateral aid distribution authorities, and platform-owned verification infrastructure -- routinely require reliance on facts recorded across two or more sovereign registers simultaneously. Cross-sovereign reliance today faces four structural problems, which this protocol is designed to address in combination: Raw-record disclosure. Existing approaches require the raw register record either to leave its data-residency jurisdiction or to be re-disclosed in plaintext to a relying party in another jurisdiction. Sovereign registers under data-protection regimes are jurisdictionally constrained against such re-disclosure. Non-reconcilable register outputs. Each sovereign register exposes a different schema, a different signing chain, a different verdict semantic, and a different statutory access regime. A relying party that requires a deterministic combined verdict over n sovereign registers therefore faces n parallel verification problems. Non-auditable settlement. Cross-sovereign reliance, where it occurs at all, occurs without a settlement-layer audit trail consumable by sovereign regulators. Unverifiable requester identity in an agentic setting. Cross-sovereign reliance is increasingly initiated not by an authenticated human operator but by an autonomous software agent acting on behalf of a principal. Where the agent's binding to a real, authenticated principal cannot be verified, the reconciliation is performed for an unknown or impersonated party, and the settlement record attributes reliance to no accountable principal. An agent whose principal binding cannot be verified is treated as hostile (zero-trust); the normative rules are in and . This document specifies ARP, a protocol that addresses all four deficiencies in combination, and is layered atop the SCITT architecture and the RATS architecture . The fourth deficiency is not hypothetical. Where an autonomous agent can act, its containment assumptions may not hold at run time, and a binding between an agent's claimed authority and its actual conduct that is established only after the fact is not a control. The binding must be checkable at the moment of action. ARP is designed for that moment. Forensic reconstruction establishes what an agent did after a consequence has occurred; ARP reconciles an agent's claimed authority and principal binding against authoritative registers while the action can still be refused. A reconciliation that yields a non-decisive or divergent verdict is a control input available before the action commits, not an audit finding available after. This document treats real-time reconciliation of claimed-versus-actual conduct as a first-class property of accountable autonomous action.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined for use throughout this document:

Sovereign Register:

An authoritative data store maintained by or on behalf of a sovereign and treated as conclusive within that sovereign's jurisdiction for the predicates the register is empowered to record.

Register Operator:

The entity that operates the Sovereign Register and is contractually empowered to bind the register's attestations.

Bilateral Register Agreement:

A negotiated contractual instrument between the operator of the reconciliation server and a Register Operator, declaring the permitted-predicate set, supported cryptographic primitives, supported cryptographic-primitive-upgrade path, the transport, endpoint, framing and encryption construction of the bilateral channel of , the regulator-identity-provider trust anchor, notification endpoint and statutory-regulator-access scope of together with the per-jurisdiction permitted-read-field and permitted-read-predicate sets it is computed from, the Subject Reference form and Freshness Window of , the register's data-format profile and its parameters under , the register's public key material, the response window after which a register is recorded unresponsive, the per-principal per-subject query budget and its interval and any per-subject ceiling under , the ledger-head notarisation interval and the Transparency Service of , the artefact retention period of , the read rate limit of , the notarisation polling bound of , the authority origin of the reconciliation server it authorises, at least one Audit Identity under , the Register Operator's own read key, whether the Per-Register Claim Projection must carry the Requester-Binding Class, the audit right over the query-budget counter of , the reserved proportion of any per-subject ceiling and its per-principal sub-budget, and OPTIONALLY an audience constraint under . Each Bilateral Register Agreement carries an Agreement Hash: the SHA-256 digest over the deterministically encoded CBOR array of the declared items above, in the order above, each absent optional item encoded as CBOR null. The reconciliation server and the Register Operator compute it independently and MUST obtain the same value, which "its canonicalised content" -- the wording of earlier revisions -- does not make possible.

Policy-Epoch Store:

The persisted, versioned record of a deployment's verification-policy state, from which the Policy-Version Hash of is reconstructible and from which the reconciliation server resolves, per predicate and named regime set, the Verdict Arithmetic and its parameters and the reliance interval. It holds the Deployment Blinding Value and the Requester-Binding of each reconciliation. It is internal to the reconciliation server; this document constrains what it must be able to answer and not how it is built.

Requesting Principal:

The accountable party on whose behalf a reconciliation is performed. A Requesting Principal is either an authenticated human or institutional operator, or an autonomous agent carrying a Verified Principal Credential that binds it to such an operator.

Requesting Agent:

An autonomous software agent that initiates a reconciliation. A Requesting Agent is FRIENDLY when it carries a verifiable identity -- a request signed under HTTP Message Signatures per Web Bot Auth , a genuinely verified declared bot, or a Verified Principal Credential -- and ENEMY when its principal binding is absent or unverifiable. Anything unverifiable is treated as ENEMY.

Verified Principal Credential:

A cryptographic credential asserting that a named, authenticated principal stands behind a request, verifiable without contacting the credential issuer in the reconciliation hot path. A Verified Principal Credential MAY be carried in any COSE-enveloped structure binding the claim, its evidentiary provenance, and the principal's credential, or in any equivalent verifiable-credential form .

Agent Friend-or-Foe (IFF) Determination:

The deterministic classification of a Requesting Agent as FRIENDLY or ENEMY, computed from the presence and cryptographic validity of a verifiable agent identity and, where required by policy, a Verified Principal Credential. The determination is recorded in the Requester-Binding field and committed to the Policy-Version Hash.

Canonical Claim:

A deterministic structured representation of a verification claim, comprising at least a subject identifier, a predicate, an attested value, an applicable-regimes set, and an evidentiary provenance manifest. Canonicalisation is performed in the following order, which is normative because the operations do not commute: Unicode Normalization Form C is applied to every string value and to every object member name. Object member names are sorted by UTF-16 code unit, as specified in Section 3.2.3 of . Declared array order is preserved. Numbers are rendered as specified in Section 3.2.2.3 of . A member whose value is absent is omitted, rather than serialised with a null placeholder. Steps 1 and 2 are order-dependent and observably so: for an object carrying the member names "A" followed by COMBINING RING ABOVE (U+0041 U+030A) and "B", normalising before sorting and sorting before normalising yield different serialisations and therefore different Claim Hashes. This specification requires normalisation first. The member-sort code unit is normative. An implementation that sorts by Unicode code point rather than by UTF-16 code unit produces a different Claim Hash for any object carrying a member name outside the Basic Multilingual Plane. The two orderings are not interchangeable, and this specification pins the UTF-16 reading, which is the one Section 3.2.3 of specifies. This construction is NOT the construction defined in for subject_digest. The two MUST NOT be substituted for one another; see .

Predicate Taxonomy:

A controlled hierarchical classification of predicates that may be the subject of reconciliation, enabling taxonomic prefix match in projection. The taxonomy includes an agent: branch whose predicates reconcile the verifiability of an agent's binding to a principal (for example agent:principal-binding-verifiable and agent:credential-attested).

Per-Register Claim Projection:

The narrowest structured query sufficient to elicit the required Partial Attestation under a register's Bilateral Register Agreement, computed by the controlled projection function as the nearest ancestor of the Canonical Claim Predicate that is a member of the register's permitted-predicate set. Where the taxonomy admits more than one such ancestor, the projection MUST fail rather than choose.

Partial Attestation:

A cryptographically signed output produced by a Sovereign Register in response to a Per-Register Claim Projection. The Partial Attestation payload SHALL disclose, of the subject, only a Reconciliation-Verdict field, an OPTIONAL Divergence-Axis field, the applied parameters of and the Query Binding, which is a digest; it SHALL NOT disclose any register record. Fields denoting state rather than the subject -- the Freshness Timestamp, and the Source-Data Version Identifier of -- are enumerated in .

Applicable-Regimes Set:

The set of regulatory regimes a Canonical Claim names as applicable. It is a claim field chosen by the requester and states which law the requester asserts governs the question. It does not carry the Verdict Arithmetic, its parameters or the reliance interval; those are resolved by the reconciliation server from the policy-epoch store of , keyed on the predicate and the named regimes, and are committed to the Policy-Version Hash. A requester names the regime; the deployment's policy determines how evidence under it combines and how long a verdict may be relied upon.

Combined Verdict:

The single verdict value produced by aggregating the Reconciliation-Verdict fields of the Per-Register Result Set of under the Verdict Arithmetic resolved under . Its values are match, no-match, partial-match and indeterminate. The decisive values are match and no-match.

Reconciliation Hash:

The SHA-256 digest over the deterministically encoded CBOR serialisation of a Reconciliation Output excluding its Sealing Signature and Sealing-Key Identifier, as specified in .

Divergence Axis:

A controlled descriptor identifying a structural qualification on a verdict. Most identify the reason for a non-match; those recorded by the reconciliation server may qualify a verdict of any value. The controlled set is the registry of , which at the time of writing comprises identity-mismatch, jurisdictional-scope-mismatch, temporal-mismatch, ownership-threshold-mismatch, sanctions-list-match, register-record-absent, claim-predicate-unsupported, claim-projection-narrowed-beyond-attestation-scope, agent-principal-unverifiable, agent-credential-absent, agent-impersonation-suspected, agent-action-scope-divergence (the authorised scope attested for an agent action and the actual conduct attested for it do not reconcile), source-version-skew, register-threshold-divergence (two registers answered the same predicate under different declared interest thresholds, per ), declared-not-determined (the register could answer only over a declared fact where the claim ranged over a determined one, per ), and freshness-stale. Divergence Axes recorded by the reconciliation server rather than by a register, which the registry marks as such and which initially are freshness-stale, source-version-skew, register-threshold-divergence, declared-not-determined and agent-action-scope-divergence, are carried in the Reconciliation Output, not in the register's signed Partial-Attestation payload.

Source-Data Version Identifier:

An identifier denoting the state of a published corpus, external to both the Bilateral Register Agreement and the Policy Version, against which a register evaluated a Projected Predicate. A consolidated sanctions list is the characteristic case. Its purpose is attribution: without it, a change in a historical Combined Verdict cannot be attributed to a change in policy state rather than to a change in the underlying corpus. Requirements are in .

Post-Seal Evaluation Qualifier:

A controlled descriptor identifying a condition arising after a Reconciliation Output has been sealed, carried in a Post-Seal Evaluation Record per rather than in the Output. The values are those of the registry in , at the time of writing notarisation-incomplete and attribution-indeterminate. A Post-Seal Evaluation Qualifier is not a Divergence Axis: a Divergence Axis qualifies a verdict, and a Post-Seal Evaluation Qualifier qualifies an operation on an Output whose verdict is already fixed.

Threshold-Sensitive Predicate:

A Predicate whose truth depends on an interest threshold, so that two registers evaluating it under different declared thresholds are not answering the same question. A profile registered under MUST state which of its predicates are threshold-sensitive.

Source Class:

A partition of the Addressed-Registers Identifier Set resolved for the named regimes under , over which source-class-quorum is evaluated.

Sovereign Re-Notification:

A signed notification emitted through the Regulator Portal to each regulator whose statutory scope covers a reconciliation whose historical Combined Verdict has materially changed. The supersession that occasions it is separately recorded as a continuation-supersession entry on the Settlement-Layer Ledger under , so that a relying party that acted on the superseded Output can discover the change.

Reconciliation Nonce:

A value of at least 128 bits drawn from a cryptographically secure random source, unique to one Per-Register Claim Projection and therefore to one register within one reconciliation. It is never reused. Two registers addressed in the same reconciliation receive different nonces, so their Query Bindings differ even where the Projected Predicate and Subject Reference are identical, and an attestation elicited from one register cannot be presented as an answer from another.

Source-Version Skew:

The condition, recorded as source-version-skew, in which two Partial Attestations answer the same Projected Predicate against different states of the same published corpus. Both are within their freshness windows; the skew is in the corpus, not in the attestations. It is not a disagreement, and an implementation MUST NOT treat it as one.

Attribution Indeterminate:

The Post-Seal Evaluation Qualifier, recorded as attribution-indeterminate, in which a Retroactive Evaluation cannot determine whether a material change in a historical Combined Verdict arose from a change in policy state or from a change in Source-Data Version. It is a statement about the evaluation, not about any register's answer.

Reconciliation Output:

A data structure aggregating Partial Attestations from a single reconciliation event, sealed against a Policy-Version Hash.

Verdict Arithmetic:

The operator governing how per-register verdicts combine into the Combined Verdict, specified in . The controlled set comprises conjunction, disjunction, threshold-count and source-class-quorum.

Hash-Linkage Aggregation:

An aggregation of Partial Attestations in which the per-register attestations are canonical-hashed, ordered, committed to a Merkle tree, and emitted with a Merkle root and a per-register verdict band. The Merkle commitment and its inclusion proofs MAY be encoded as COSE Receipts .

Policy-Version Hash:

A cryptographic commitment to the canonical verification-policy state in force at the moment of reconciliation, including reconciliation rules, threshold parameters, pattern-library version, applicable-regimes precedence, verdict-arithmetic selection with every parameter it takes, the reliance interval, the Agent-IFF policy in force, the Requester-Binding, and the Bilateral-Register-Agreement Hashes of the addressed registers.

Settlement-Layer Ledger:

An append-only cross-jurisdictional log retaining hashes of reconciliations and no Canonical-Claim, register-record or principal content. It carries entries of two kinds, discriminated by an entry type: a reconciliation entry, which records a sealed Reconciliation Output, and a Continuation entry, which records a notarisation outcome, a Post-Seal Evaluation Record or a supersession arising after that Output was sealed. Every entry carries a sequence number, the entry type, the claim hash, the reconciliation hash, an entry timestamp, a prior-entry hash, a self-entry hash and an entry signature; the fields each kind carries in addition are enumerated in . A Continuation entry may also carry a transparency-service identifier, an entry identifier, an HTTP status code, a post-seal evaluation record hash, a material-change indicator, a superseding reconciliation hash and a superseding entry sequence number. Not every field is a digest -- the sequence numbers, the timestamps, the entry type, the descriptors and the indicators are not -- but no field carries Canonical-Claim, register-record or principal content, and no field is a retrieval address.

Audience Set:

The set of Audience Members of a Reconciliation Output, sealed with it under . Each Audience Member is an accountable-principal identifier together with a verification method that can be presented after the reconciliation. The Requesting Principal is a member wherever it can be identified. Entitlement to read about a reconciliation follows membership, not possession of the artefact.

Reliance Horizon:

The time after which an Audience Member MUST NOT treat a Combined Verdict as current without reading the Continuation entries for its Reconciliation Hash. It is the Reconciliation Timestamp advanced by the reliance interval that deployment policy declares for the predicate and the named regimes, resolved as resolves the Verdict Arithmetic. It bounds reliance and does not affect the validity of the Sealing Signature.

Ledger Head Statement:

A signed statement of the current head of the Settlement-Layer Ledger, published at a well-known URI and notarised at a declared interval, comprising the head's Entry Sequence Number, its Self-Entry Hash, its Entry Timestamp, the time the Statement was produced, and a pointer to the most recent completed head notarisation. Defined in .

Evaluation Sweep Statement:

A signed record that a retroactive evaluation was performed, comprising the trigger, the policy state applied, the ledger head at the start and end of the sweep, the counts examined and materially changed, a Merkle root over the Claim Hashes examined, a timestamp, a pointer to the notarisation of the previous Statement. Defined in . Its purpose is to make an evaluation that never ran a signed omission rather than a silence.

Non-Answer Statement:

A statement signed by a register recording that it declined to answer, over the Reconciliation Identifier, the Projected Predicate, the Subject Reference, the Reconciliation Nonce and the reason. Required wherever a Non-Answer Reason is register-attested, per .

Architecture ARP comprises seventeen subsystems arranged as a deterministic pipeline: Canonical Claim Ingestion Requester Identity Binding and Agent Friend-or-Foe Gate Adversarial Pre-Transmission Test Per-Register Projection Function, under the profile of declared in the Bilateral Register Agreement Per-Register Encryption Partial-Attestation Reception, including Source-Data Version Binding Non-Answer Resolution Verdict Re-Typing Aggregation under the Verdict Arithmetic, per Policy-Version-Hash Sealing Settlement-Layer Ledger Write Notarisation under , where performed Regulator Portal Retroactive Evaluation Output Delivery under Post-Seal Evaluation Recording Cryptographic-Primitive-Upgrade Path Given an identical Canonical Claim, an identical Requester-Binding, an identical Audience Set, an identical Addressed-Registers Identifier Set, identical Bilateral-Register-Agreement Hashes for the addressed registers, an identical Pattern-Library Version Identifier, and an identical Policy-Version Identifier, the system MUST produce Reconciliation Outputs identical in every field save those enumerated below as outside this requirement, and identical Claim Hash and Policy-Version Hash values in the corresponding Settlement-Layer Ledger entries. The Reconciliation Hash is deliberately not among those values. It is a content commitment over one sealed Output, taken over a preimage that includes that Output's Reconciliation Timestamp, and it is not reproducible across runs; the Reconciliation Identifier of is the reproducible index, and it is the Claim Hash and Policy-Version Hash that make it so. Requiring an identical Reconciliation Hash would require an identical timestamp, which no implementation can deliver. The per-event fields of a Ledger entry -- Entry Sequence Number, Entry Timestamp, Prior-Entry Hash, Self-Entry Hash and Entry Signature -- are position-dependent by construction and are outside this requirement; the Entry Signature is further outside it because a signature scheme is not required to be deterministic. Within the Reconciliation Output itself the Reconciliation Timestamp, the Reliance Horizon computed from it, the Sealing Signature and any Override Record are outside it: the first is per-event, the second need not be deterministic, and an Override Record records an operator's discretionary act rather than a function of the enumerated inputs. The register-produced signatures the Output carries -- the Partial Attestation inside each Query Binding Record, and each Non-Answer Statement -- are outside it on the same ground as the Sealing Signature: they are signatures, and a signature scheme need not be deterministic. So is the Sealing-Key Identifier, which is rotation state and not an enumerated input. So are attestation-stale and register-unresponsive, and the Divergence-Axis and verdict consequences that follow from either: both are functions of wall-clock timing and network conditions rather than of the enumerated inputs, which is the same ground on which the Freshness Timestamps themselves are outside it. A reconciliation driven to a query-budget-exhausted or subject-ceiling-exhausted Non-Answer Reason under is also outside it, because the budget is accumulated state and not an enumerated input. The residual risk that carve-out creates, and why this document does not close it, is set out in . The Freshness Timestamps of the constituent Partial Attestations, and any Source-Data Version Identifiers they carry per , are likewise outside it: both denote state external to the enumerated inputs. Two reconciliations agreeing on every enumerated input but differing in Source-Data Version are not required to agree field for field, and an implementation MUST NOT treat such a difference as a determinism failure.

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 ( 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 form of the preceding fields as 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.

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 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 . 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 with a key resolvable through a Web Bot Auth signature-agent card , advertised via the Signature-Agent header and resolved through the HTTP Message Signatures directory it names , 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.

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 , absent fields as CBOR null, and is returned to the requester as 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 the identifier of the authorising operator an Override Timestamp ( 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 , and carrying as its key identifier the JWK thumbprint, computed as in , 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 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 can see that a bypass occurred without holding the Output. Having seen it, the regulator reads the Output itself under 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 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 . 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.

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 that the register is to apply OPTIONAL Requester-Binding Class, present exactly where the Bilateral Register Agreement requires it under , 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 , 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 . 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.

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 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 , on which the third re-typing ground of 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 : arp-profile-bods () arp-profile-corporate-org () arp-profile-customs-wco () arp-profile-sanctions-consolidated () 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 .

Beneficial ownership: BODS For registers expressing beneficial ownership as records, the permitted-predicate set is expressed over relationship records -- termed ownership-or-control statements before BODS 0.4 -- reachable from a declared subject entity. This profile is written against BODS 0.4. Taxonomic narrowing corresponds to reducing the depth of the ownership chain a predicate ranges over. A relying party's question is characteristically about ultimate beneficial ownership -- the transitive closure -- while a register may be able to answer only a bounded-depth predicate over direct or once-removed interests. The parent of a predicate at depth n is the corresponding predicate at depth n-1. The direct-interest predicate is the root of this profile's branch of the Predicate Taxonomy, and the walk of fails as projection-unsupported on reaching it, as it does at the taxonomy root. A Bilateral Register Agreement declaring arp-profile-bods MUST supply the maximum chain depth over which the register's permitted predicates are evaluated. Where the Canonical Claim ranges over the transitive closure and the register's declared maximum depth is finite, the projection is a narrowing and MUST be recorded in Narrowed-From. An implementation MUST NOT treat a bounded-depth no-match as a transitive-closure no-match. The rule is stated in and applies to that register's contribution, not to the Combined Verdict: a no-match returned at bounded depth against a closure claim is re-typed to indeterminate before aggregation, and the Verdict Arithmetic then proceeds unchanged. A match found at any depth does establish the existential closure predicate and is not re-typed. The depth at which the register answered is reported in the Applied-Parameter Set of its Partial Attestation and MUST be carried into the Projection Record of . A register MAY answer at a shallower depth than the declared maximum; the declared maximum is therefore not a substitute for the applied value, and re-typing under turns on the applied value. Interest thresholds -- the percentage at which an interest becomes reportable -- vary by jurisdiction and are properties of the register, not of the claim or of the format. A Bilateral Register Agreement declaring arp-profile-bods MUST supply the threshold its permitted predicates assume. Two registers answering the same predicate under different thresholds are not answering the same question. The reconciliation server MUST add register-threshold-divergence to the Server-Recorded Divergence-Axis Set wherever the Reconciliation Output combines registers whose declared thresholds differ, irrespective of the verdicts they returned. In this profile the ownership and control predicates are threshold-sensitive; the identity and existence predicates are not.

Corporate registries: vCard and the Organization Ontology A profile in this class MUST declare for any branch of its predicate space over which taxonomic narrowing is defined. expresses organisational hierarchy only within one organisation's own ORG structured value and defines no property relating one organisation to another, so a vCard-only profile has no term capable of satisfying the parent-relation requirement of and MUST NOT declare a narrowing branch. vCard remains available for the identifying and contact predicates, over which no narrowing is defined. For registers expressing legal-entity and organisational structure, a profile MAY declare vCard properties or classes and properties as the vocabulary in which permitted predicates are expressed. A profile MUST declare exactly one parent relation for each branch of its predicate space, and MUST partition that space so the branches do not overlap. Declaring two relations applicable to one predicate would make the taxonomic walk of reach two predicates at equal distance, which that section requires to fail as projection-ambiguous. Where is used, org:subOrganizationOf is the parent relation for the organisational-structure branch, and org:hasSite for the branch of predicates ranging over establishment or place of business. Neither vocabulary asserts the legal effect of a recorded fact. does carry a notion of legal recognition -- org:FormalOrganization denotes an organisation recognised in legal jurisdictions, and org:identifier a company registration number -- but recognition is not determination. A predicate expressed in these terms is a predicate about a register's recorded representation of an entity, not about the entity's status in law, and a profile MUST NOT be read as asserting the latter. The vocabulary is pinned to as at its 2014 Recommendation and to . A Bilateral Register Agreement declaring this profile supplies the register's jurisdiction identifier and the identifier scheme of its org:identifier values. No predicate in this profile is threshold-sensitive: corporate registries record recognition rather than a quantified interest.

Customs and transport: UN/CEFACT and the WCO Data Model For customs declarations and transport registers, a profile MAY declare core components or classes as the vocabulary for permitted predicates. Both express declaration-side and authority-side facts, and telling them apart is the purpose of this profile rather than a property of the vocabularies. The WCO Data Model's Declaration Response and its Licence, Permit, Certificate and Other packages record authority determinations, as does UN/CEFACT's eCERT for sanitary and phytosanitary certification; the goods and cargo declaration classes in both record what was declared to an authority. A Bilateral Register Agreement declaring arp-profile-customs-wco MUST supply, for each permitted predicate, whether it ranges over a declared fact or over a determined one. Where a relying party's Canonical Claim ranges over a determined fact and the register can answer only over a declared one, that is a narrowing and MUST be recorded in Narrowed-From. The reconciliation server MUST derive the Divergence Axis declared-not-determined from the Narrowed-From field and add it to the Server-Recorded Divergence-Axis Set of whenever the narrowing occurred, whether or not it changed the Combined Verdict; the corresponding contribution is re-typed under . The register cannot record it: the register never sees the Canonical Claim, and the Combined Verdict does not exist until every Partial Attestation has been received. The vocabulary is pinned to Version 4 of the and to the UN/CEFACT Core Component Library release the Bilateral Register Agreement names, which it MUST name. The Agreement also supplies the declaration types the register answers over. No predicate in this profile is threshold-sensitive.

Sanctions: consolidated list formats For registers expressing designation status by reference to a consolidated list -- , or equivalent -- the permitted-predicate set is expressed over designation of a subject entity on a named list. Consolidated lists are republished on no fixed schedule -- OFAC states there is no predetermined timetable, and the EU list is updated as amending regulations are adopted -- and are distributed either as full republications or as delta updates against a prior state. That the cadence is event-driven strengthens the requirement below rather than weakening it: a relying party cannot infer list state from the clock. A designation verdict is meaningful only relative to the list state that produced it, and this has a consequence the rest of this document depends on: without it, a change in a historical Combined Verdict cannot be attributed to a policy change rather than to a list change. Accordingly the requirements of apply. A Bilateral Register Agreement declaring arp-profile-sanctions-consolidated MUST supply the set of lists the register consults and, for each, the identifier by which the register expresses that list's state. Where the register publishes both a full list and deltas, the identifier MUST denote the resulting state and not the delta applied to reach it. A profile in this class names no single vocabulary, consolidated sanctions lists having no common schema. It instead pins, per register, the list identifier and the publisher's state-identifier form that requires, both supplied by the Bilateral Register Agreement, together with the matching predicate set the register answers over. No predicate in this profile is threshold-sensitive: a designation is a listed-or-not fact.

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 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 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 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 .

Per-Register Encryption These are requirements on whatever bilateral channel 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 .

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 and carried in the arp-source-data-version COSE header parameter of 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 . The register's signing key is published in its key set under , 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 with the reason attestation-unverifiable. The Query Binding Record of 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 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 .

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 . 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.

Aggregation The aggregation subsystem operates in Hash-Linkage Aggregation. Each Partial Attestation is canonical-hashed and committed to a Merkle tree as 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 , 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.

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 subject-ceiling-exhausted, where the reconciliation would exceed a per-subject ceiling declared under audience-constraint-exceeded, where the requested Audience Set exceeds the audience constraint that register declares under 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 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 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 , whose payload is the CBOR array

encoded under Section 4.2.1 of . The Reconciliation Identifier is inside the payload for the reason the Query Binding of 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 , and MUST NOT be combined by the Verdict Arithmetic. Its effect is given in : 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 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.

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 . 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 , 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.

Verdict Arithmetic The Verdict Arithmetic combines the Reconciliation-Verdict Fields of the Per-Register Result Set, after any re-typing under , 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 , 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: 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 , 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 . 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 would re-type a contribution to partial-match under an operator that does not admit it, the contribution is re-typed to indeterminate instead.

Reconciliation Output A Reconciliation Output comprises: Reconciliation Identifier Claim Hash Reconciliation Timestamp Reliance Horizon of Audience Set of Combined Verdict Verdict Arithmetic as resolved under , 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 Merkle Root, constructed as in 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 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 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 , 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 Re-Typing Ground, drawn from the registry of , 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 , 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 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 , 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 . Every timestamp this document places inside a digest preimage or a signature payload MUST be expressed in the form YYYY-MM-DDTHH:MM:SSZ: with the Z designator rather than a numeric offset, and with no fractional seconds. admits several renderings of one instant, and a preimage that admits several renderings admits several digests. CBOR rather than : 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 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 and MUST NOT be represented as fields of the Reconciliation Output.

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.

Audience A Reconciliation Output carries an Audience Set of zero or more Audience Members, encoded as a CBOR array which is empty only in the case described below. Each Audience Member comprises: an Audience Member Identifier: a URI, in the same identifier space a Requester-Binding uses for an accountable principal a Verification Method Reference: the JWK thumbprint, computed as in , of the public key under which that member signs a read request under . It MUST be a durable key and MUST NOT be a session credential or a one-time request signature, because the member has to present it long after the reconciliation is over Audience Members are sorted in bytewise lexicographic order of the deterministic CBOR encoding of the Audience Member Identifier, and each member is encoded as a two-element array in the field order above. Ordering is stated because the Audience Set is inside the Reconciliation Hash preimage, and an unordered set would give one Output as many hashes as it has permutations. The server MUST NOT require proof of possession from a named member at reconciliation time -- the member is typically not present -- and naming one is therefore an assertion by the Requesting Principal, not a fact about the member. Two consequences follow and are stated so that neither surprises. Naming a party places a row in that party's GET /arp/outputs enumeration and in the server's access log that the party did not ask for, so a deployment SHOULD constrain who may be named through the audience constraint below and through the enrolment requirement of . And a member that loses or rotates the key its thumbprint names loses entitlement to every Output that names it, permanently, because the Audience Set cannot be amended after sealing; a member that expects to rely on Outputs over time SHOULD be named by a thumbprint of a key held for that purpose. The Requesting Principal is an Audience Member of every Output performed on its behalf where it can be identified: by its accountable-principal identifier where the Requester-Binding carries one, and otherwise as below. Where it does not -- classes agent-unverified and agent-key-verified -- the Set carries a member whose Identifier is the URI form of the verified signing key's thumbprint. Every requester signs, by , so there is always a key to name and an Audience Set is never empty. Further members are named in the reconciliation request, are enumerated inputs for the purposes of , and are sealed with the rest of the Output. The Audience Set MUST NOT be enlarged after sealing; naming a further member requires a new reconciliation, which is a new question and gets a new answer. A Bilateral Register Agreement MAY declare an audience constraint: a maximum cardinality, a permitted class of member, or both. Where the Audience Set exceeds the constraint an addressed register declares, the reconciliation server MUST NOT transmit a projection to that register and MUST record audience-constraint-exceeded as its Non-Answer Reason. It MUST NOT refuse the reconciliation, and MUST NOT quietly drop the register: the first leaves no artefact stating why, and the second is the addressed-register-cherry-picking exists to prevent. The reconciliation is sealed and, by , cannot reach a decisive Combined Verdict. The requester is not a party to any Bilateral Register Agreement and cannot read the constraint, so it learns the cap from the reason recorded against that register rather than by inspection. A register that attests about a subject is entitled to bound how widely that attestation travels, and a constraint enforced after transmission would be enforced too late. The constraint is enforced by the reconciliation server on the register's behalf and the register cannot verify that enforcement from any artefact this document defines; a register that requires assurance of it should negotiate an audit right in its agreement. A party MUST NOT be treated as entitled to a Reconciliation Output by possession alone. A relying party that has been handed an Output and is not an Audience Member of it MAY verify its Sealing Signature and read its Combined Verdict -- nothing prevents this, and the signature is what makes the Output worth handing on -- but it obtains no read under , learns nothing of supersession or post-seal evaluation, and MUST NOT treat the verdict as current. Reliance without entitlement is reliance on a snapshot of unknown age.

Reliance Horizon A Reconciliation Output carries a Reliance Horizon: a time in the form of , being the Reconciliation Timestamp advanced by the reliance interval the reconciliation server resolves from the policy-epoch store of , keyed on the predicate and the regimes the claim names, exactly as it resolves the Verdict Arithmetic under . A requester able to set its own reliance interval could set its own staleness window, which is the same defect as choosing its own Verdict Arithmetic. After that time an Audience Member MUST NOT treat the Combined Verdict as current without having read the Continuation entries for its Reconciliation Hash under and found no supersession. The Horizon does not invalidate the Output and does not weaken the Sealing Signature: what was sealed remains true of the moment it was sealed. It bounds reliance, not validity. A sanctions no-match is a statement about consolidated lists as they stood, and those lists change on a daily cadence (); an artefact that asserted such a verdict indefinitely and carried no marker of its own staleness would be relied upon indefinitely, which is the failure exists to prevent and could not, having no way to reach the party that had relied. The Reliance Horizon is derived from the Reconciliation Timestamp and is therefore outside the reproducibility requirement of on the same ground.

Delivery The reconciliation server MUST return the sealed Reconciliation Output to the Requesting Principal in the response to the request that commissioned it, in the form states. Where the Adversarial Pre-Transmission Test emitted a Remediation Advisory, the server returns that Advisory and no Output. enumerates the responses to a commissioning request. A refusal under or an audience constraint under is not among them: those refuse a register and not the reconciliation, so an Output is produced and delivered, carrying the reason against the register it concerns. That the server returns the Output is stated because nothing in earlier revisions did. The document specified in detail what an Output contains, how it is sealed, digested, ledgered and notarised, and never that any party receives one. Every discovery path in this document begins with a party holding a Reconciliation Hash, and it holds one because of this paragraph. An Audience Member other than the Requesting Principal is not delivered to. It retrieves under : the server has no channel to a party it has never spoken to, and pushing a confidential artefact to an address named by somebody else is not a mechanism this protocol should define. The Reconciliation Hash is the retrieval key and is not reproducible across runs (), so a party that has discarded it cannot recompute it, and the Reconciliation Identifier is no help because the Claim Hash within it is blinded under and cannot be computed outside the deployment. The server MUST therefore also answer the enumeration of , returning to an authenticated principal the Reconciliation Hashes of the Outputs whose Audience Set names it. Without it, an Audience Member that has lost a 32-byte value has lost every entitlement this section grants it, permanently and silently. The server MUST retain each sealed Output, and MUST answer reads of it and of its Continuation entries, for the retention period, which is the LONGEST period any Bilateral Register Agreement addressed by that reconciliation declares, and in no case ending before the Reliance Horizon advanced by one further reliance interval. Where two agreements declare different periods the longest governs. That direction is specific to a retention period, which is a floor: the shortest declaration would let one register's agreement extinguish another's. Wherever else this document takes a value from a plural set of agreements, the direction is the one that makes the obligation stricter, and it is stated at each site. For every interval that bounds a deadline -- the ledger-head notarisation interval of , and the Evaluation Sweep and supersession deadlines measured against it -- the SHORTEST declaration governs. Taking the longest there would let one permissive agreement postpone every deadline for every other register, which inverts the obligation instead of strengthening it. For the read rate limit of , the most permissive declaration governs, a rate limit being a ceiling on the server's refusals rather than on its duties. The extra interval matters. requires an Audience Member to read before relying past the Horizon, and entitlement is evaluated against the Audience Set of the retained Output; a retention floor that ended exactly at the Horizon would permit the server to discard the basis of that evaluation at the moment the obligation begins, and the member would receive the 404 of -- indistinguishable, by design, from never having been entitled.

Policy-Version-Hash Sealing The Policy-Version Hash MUST commit to: Reconciliation rules Threshold parameters Pattern-Library Version Identifier Applicable-Regimes precedence Verdict-Arithmetic selection, together with every parameter that operator takes The reliance interval from which the Reliance Horizon of is computed Agent-IFF policy identifier and the Requester-Binding Bilateral-Register-Agreement Hashes of the addressed registers The Policy-Version Hash is the SHA-256 digest over the deterministically encoded CBOR array

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 provides. 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 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 . 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 .

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 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 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 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 is the SHA-256 digest over that array in its entirety, signature included, so that the digest is over the artefact as served under . A Post-Seal Evaluation Record MUST be retained by the reconciliation server for the period of , 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 and retrieves it by its hash under the same binding. The record travels as the result element of the signed read response of ; 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 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 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.

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 , 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 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 Entry Type, from the ARP Ledger Entry Types registry of Claim Hash, the index of Reconciliation Hash of the Reconciliation Output the entry concerns Entry Timestamp ( 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 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 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 . Where a status cannot be so resolved -- the 404 of 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 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: 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 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 , 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 , 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 ; 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 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 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 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. 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 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 , 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 ; an Audience Member's under ; and an Audit Identity's under . 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 ; 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 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 , 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 's rule that a register may cap how wide an Audience Set addressing it may be. Where the Ledger is replicated per , 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 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 . 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 , 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 . 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 . It is not registered under the binding of , 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 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 . 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 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 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 : 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.

Replication The Ledger MAY be distributed across a plurality of per-jurisdiction secondary stores under synchronous replication, each operated under the data-residency constraints of its host jurisdiction. The append-only derivation-chain invariant -- that every entry's Prior-Entry Hash equals the digest, taken as in , over the immediately preceding entry in its entirety -- MUST be preserved across all secondary stores. A secondary store replicates the single sequence of and originates no entry of its own.

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 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.

Sovereign Re-Notification A Sovereign Re-Notification is a COSE_Sign1 by the reconciliation-server sealing key, under the media type registered in , whose payload is the CBOR array of: the Claim Hash and the Reconciliation Hash of the superseded Output the Entry Sequence Number of the continuation-supersession entry recording the supersession the Material-Change Indicator the verdict values before and after the Attribution, one of policy-state, source-data-version or attribution-indeterminate, and where it is the last, the Post-Seal Evaluation Record Hash of the record requires a Notification Timestamp, in the form of encoded as a CBOR array in that order, an absent conditionally-absent element as CBOR null so that the array's length is fixed, the first element a two-element array of the two hashes and the fourth a two-element array of the verdict before and after; and signed under the Sealing-Key Identifier its protected header carries. The signature is not a payload element. The server MUST deliver it to the notification endpoint each affected regulator's Bilateral Register Agreements declare, MUST retry until acknowledged or until the retention period of elapses, and MUST make every Re-Notification retrievable by a regulator under . A regulator that is unreachable when a verdict changes is exactly the case the mechanism exists for, so delivery cannot be a single attempt, and an obligation with no artefact and no endpoint -- which is what earlier revisions specified -- is an obligation no party can discharge or audit.

Audit Path Several requirements in this document are justified by what an auditor can reproduce: the re-typing decision of "without the server's assurance", the Query Binding of , the Policy-Version Hash "under audit" of , and the Deployment Blinding Value of . 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 uses for an Audience Member. A party authenticating as an Audit Identity under is entitled to: every operation of , 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 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 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 . An unaudited audit right is a standing unaccountable read of every Output a deployment holds.

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 , 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 , 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.

Evaluation Sweep Statements Every trigger of retroactive evaluation is observed by the reconciliation server, every decision to run is taken by it, and until this revision nothing recorded that a sweep had run. "We evaluated and found no change" and "we never evaluated" were the same observation from every position outside the server, which made the central obligation of this section unfalsifiable. The Retroactive Evaluation Subsystem MUST emit exactly one Evaluation Sweep Statement for each trigger, within the ledger-head notarisation interval of measured from the trigger event. One Statement per trigger, on a deadline tied to an event outside the server, is what makes a missing Statement provable; "one per sweep" would let an operator batch a quarter's triggers into a single Statement and remain conformant while evaluating nothing in time. A Statement comprises: the trigger, drawn from the registry of and initially one of pattern-library, policy-version, source-data-version or credential-revocation, and the identifier of the artefact that triggered it the Policy-Version Hash and Pattern-Library Version Identifier applied the Entry Sequence Number of the Ledger head when the sweep began and when it completed the count of Reconciliation Outputs examined, and the count found materially changed the Examined-Set Root: the root of a Merkle tree, constructed as defines it, over the Claim Hashes of the Reconciliation Outputs examined, sorted in bytewise lexicographic order, so that a party entitled to one of those reconciliations can be shown an inclusion proof and the counts are not bare assertions an Evaluation Sweep Timestamp, in the form of the Transparency Service Identifier and EntryID of the notarisation of the previous Evaluation Sweep Statement, encoded as CBOR null in the first Statement of a series a Sealing-Key Identifier a signature by the reconciliation-server sealing key, 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, an absent field likewise, encoded under Section 4.2.1 of . The first, second, third, fourth and seventh items are each a two-element array, so that a field carrying two values occupies one position Statements are retrievable under and MUST each be notarised into the Transparency Service of under their own media type, within the same interval that bounds their emission. The previous- notarisation pointer above makes the published series a chain, so that a withdrawn Statement is detectable rather than merely absent; retrieves by EntryID and offers no query surface, so a party not told an EntryID could not find that notarisation by search. A Statement is retained for the retention period of . On request under , a server MUST return an inclusion proof of a given Claim Hash in the Examined-Set Root of a given Statement, to a party entitled to a reconciliation carrying that Claim Hash. A Statement does not prove a sweep was performed honestly, and this document does not claim it does. What it changes is that a sweep not performed is now a statement the operator has to make, sign and date, rather than a silence. A Source-Data Version publication is a public event with a public timestamp; an operator with no Statement within the deadline has not evaluated in time, which is checkable. The other three triggers are not public events, so the Policy Parameters Document of carries the identifier and effective time of every Pattern-Library and Policy-Version transition the server applies, which makes those two triggers observable. A credential-revocation trigger is observable to the credential's issuer and to the affected principal and to nobody else, and this document does not make it more so. The falsifiability argument therefore holds for three triggers in four, which is stated rather than rounded up. An operator that signs a Statement it did not earn is making a false attributable claim, which is a different thing from an invisible omission, and the Examined-Set Root means an Audience Member can require it to prove that its own reconciliation was in the set it claims to have examined. Where a Sovereign Re-Notification cannot state whether a material change arose from policy state or from Source-Data Version, the attribution-indeterminate Post-Seal Evaluation Record it references MUST state which of the two candidate causes were examined and why neither could be excluded. A bare qualifier is a discretionary escape signed by the party that benefits from it.

Revocation and the reliance window Revocation of a Verified Principal Credential cannot be detected at the moment of reliance by a party that is not checking, and this protocol does not put a revocation check in the hot path of every relying party. What it does instead is bound the window. An Audience Member MUST read the Continuation entries for a Reconciliation Hash under before relying on that Output past its Reliance Horizon (), and the supersession that records a revocation is among the entries that read returns. Reliance inside the horizon on a credential revoked during it is possible and is not prevented; reliance years later on an Output whose principal was disowned the following week is prevented, which is the case that matters and the case earlier revisions left open. The horizon is declared per predicate, so a deployment needing a shorter window for a sanctions predicate than for a corporate-registry one sets one.

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 for key encapsulation and ML-DSA 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 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.

Agentic Principal Reconciliation The Agent Friend-or-Foe Determination described in the Requester Identity Binding and Agent Friend-or-Foe Gate above establishes whether the requester of a reconciliation is friendly. ARP additionally supports reconciling an agent's principal binding as the subject of a reconciliation in its own right, so that the question "does a real, authenticated principal stand behind this agent?" can itself be answered against authoritative identity registers rather than asserted. A reconciliation over the agent: predicate branch takes as its Subject Identifier the agent's declared identity (for example its signature-agent-card key thumbprint or a directory identifier) and as its Attested Value the principal binding the agent asserts. Addressed registers for this predicate class are identity and credential registers -- for example an organisational directory, a credential-issuer status list, or a national identity register -- each under its own Bilateral Register Agreement. The Combined Verdict answers whether the asserted principal binding is corroborated: match: the agent's asserted principal binding is corroborated by the addressed registers; the agent is FRIENDLY with an attributable principal. no-match with divergence axis agent-impersonation-suspected: the asserted binding is contradicted; the agent is asserting a principal it is not bound to. no-match with divergence axis agent-credential-absent or agent-principal-unverifiable: no corroborating record exists; the binding cannot be established and the agent MUST be treated as ENEMY. This composition allows a relying party to gate an action not merely on the presence of an agent signature but on register-corroborated proof that an accountable principal stands behind it, narrowing the impersonation surface at the reconciliation layer. The result is a Reconciliation Output like any other: sealed against a Policy-Version Hash, written to the Settlement-Layer Ledger without claim or register content, and re-evaluable if the underlying credential is later revoked.

Encoding

CBOR-COSE Encoding The mandatory-to-implement encoding for ARP messages on the wire is CBOR with COSE 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 . 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.

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 for a reconciliation request, save for the Canonical Claim, which is carried as a CBOR byte string holding the 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 declines to define, and two servers receiving identical bytes would compute different Claim Hashes. The request MUST be signed under the profile of , 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 where the request's own signature was not accepted. A 200 whose body is the signed read response of , 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 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 requires of a 4xx, so a refused requester holds evidence of what it asked and what it was told. A refusal under or an audience constraint under is not a fourth case: those refuse a register, and the reconciliation is sealed and delivered with the reason recorded against that register.

HTTP Message Signature Binding Where a reconciliation is requested over HTTP by an autonomous agent, the request MUST be signed under HTTP Message Signatures , with the signature-agent key resolvable through a Web Bot Auth signature-agent card , advertised via the Signature-Agent header and resolved through the HTTP Message Signatures directory it names . 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.

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 . 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 provides; and every timestamp in a path or query parameter is in the form pins. The @target-uri is inside the request-binding digest of , 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.

Request signing profile requires an application that uses it to state a profile. This is that profile. It governs every request to an operation of and the commissioning request of . Every request MUST carry exactly one signature, labelled arp. The covered components MUST be @method, @target-uri, and, where the request carries a body, content-digest as defines it, together with the signature parameters created, expires, nonce, keyid, alg and tag. A request covering fewer MUST be refused. tag is arp-read for an operation of and arp-reconcile for the commissioning request of ; those are the only two values, and a server MUST reject a request whose tag does not match the endpoint it was sent to. Covering content-digest is what binds the body. The commissioning request carries the Canonical Claim, the requested Audience Set and any asserted principal in its body; a signature that covered only the target would leave an intermediary free to substitute the subject or add Audience Members and have the result sealed, ledgered and notarised as the signed requester's. The nonce MUST be at least 128 bits drawn from a cryptographically secure random source, base64url-encoded. expires MUST be no more than 300 seconds after created. A server MUST reject a request whose created is more than 300 seconds in the past or more than 60 seconds in the future, and MUST reject a repeated nonce from the same keyid within that window. Without this a captured read request replays indefinitely, which closes only for requests that initiate a reconciliation. The permitted signature algorithms are those the deployment declares for the partial-attestation-signature class in its Cryptographic-Primitive-Upgrade Path, so that read authentication rotates with everything else. keyid MUST be the JWK thumbprint of the requester's public key, computed as in . For an Audience Member it MUST equal the Verification Method Reference the Output names. For a regulator, a Register Operator or an Audit Identity it MUST be a key the corresponding Bilateral Register Agreement declares. For a requester commissioning a reconciliation it is the key that becomes that requester's Verification Method Reference in the resulting Audience Set. Key material is retrieved as that agreement provides, or, for an agent, through the Web Bot Auth directory of . The reconciliation server MUST publish a Policy Parameters Document at /.well-known/arp-policy-parameters on its authority origin: a COSE_Sign1 by its sealing key, under the media type registered in , whose payload is the three-element CBOR array of: the array of permitted signature algorithm identifiers; the array of per-predicate entries, each a four-element array of the predicate, the admitted regime set sorted in bytewise lexicographic order, the two-element array of the resolved Verdict Arithmetic and its parameters, and the reliance interval, the entries themselves sorted by predicate; and the array of two-element arrays of the identifier and effective time of every Pattern-Library and Policy-Version transition the server has applied, sorted by effective time, which relies on. A requester is party to no Bilateral Register Agreement and could not otherwise determine how to sign, and publishing the resolved parameters removes the regime-shopping probe of by making its result available without probing. A request that is unsigned, that fails signature verification, that is outside the freshness window, or that replays a nonce MUST be refused with 401. A 401 is the one response of this section that is not signed under : its payload would have to bind a request carrying no nonce and no key identifier, and there is no requester key to bind it to. A 401 therefore carries no body, and a requester receiving one has learned only that its own signature was not accepted.

Read operations Nine operations are defined, and no read of an Output or of the Settlement-Layer Ledger by a party outside the reconciliation server is defined anywhere else in this document. An Audit Identity under is entitled to every one of them, unredacted, over reconciliations addressing the register whose agreement declares it; the Entitlement clauses below state the other parties and do not repeat that. The Ledger Head Statement of is not a read of the Ledger: it is a published statement about the Ledger, served without authentication at a well-known URI, and is deliberately outside this section so that a party holding no entitlement at all can still observe a head. GET /arp/outputs/{reconciliation-hash} returns the sealed Reconciliation Output. Entitlement: an Audience Member of that Output; an Audit Identity under for a reconciliation addressing its register; and a regulator in scope for that reconciliation under , whose response is field-restricted by that section. GET /arp/reconciliations/{reconciliation-identifier}/registers/{register-identifier} returns the Per-Register Result Set entry concerning that register alone, keyed on the Reconciliation Identifier the register received in its Per-Register Claim Projection, since a register never holds a Reconciliation Hash. Entitlement: the Register Operator of that register. It is what lets a register see what was recorded of its own answer. Without it a server could discard a register's signed match and record register-unresponsive, and the only party holding the contradicting artefact would have no operation with which to produce it. GET /arp/outputs returns, for the Outputs whose Audience Set names the authenticated principal, the Reconciliation Hash, the Reliance Horizon and the Entry Sequence Number of the reconciliation entry that records each. It is ordered by that Entry Sequence Number descending, which is a total order and needs no tie-break. A since parameter carrying an UTC time is REQUIRED; a server MUST return at most 100 entries and MUST carry a next parameter value in the response where more exist, which the requester supplies on the following request. Entitlement: any authenticated principal, as to its own membership only; and an Audit Identity, as to the Outputs of reconciliations addressing the register whose agreement declares it, without which an auditor entitled to Outputs by hash would hold no operation that yields the hashes. GET /arp/continuations/{reconciliation-hash} returns the Continuation entries of carrying that Reconciliation Hash, in Entry Sequence Number order, and no reconciliation entry. Entitlement: an Audience Member of the Output that Reconciliation Hash identifies, or a regulator in scope for that reconciliation under . GET /arp/entries/{entry-sequence-number} returns one Ledger entry. Entitlement: a regulator, subject to ; an Audience Member, for an entry carrying a Reconciliation Hash it is entitled to; and a Register Operator or regulator requesting the Self-Entry Hash alone, for the consistency check of , by the fields=self-entry-hash query parameter. GET /arp/post-seal-records/{post-seal-evaluation-record-hash} returns the Post-Seal Evaluation Record of . Entitlement: as for the Continuation entry that carries the hash. GET /arp/sweeps/{examined-set-root}/inclusion/{claim-hash} returns an inclusion proof of that Claim Hash under that Examined-Set Root. Entitlement: a party entitled to a reconciliation carrying that Claim Hash. The Statement is keyed on its Examined-Set Root rather than on its timestamp, which is pinned to whole seconds and would collide where two triggers fall in one second. GET /arp/re-notifications returns the Sovereign Re-Notifications of whose Notification Timestamp falls in the interval named by REQUIRED since and until parameters, at most 100 per response under the same next rule. Entitlement: a regulator, as to notifications addressed to it. GET /arp/sweeps returns the Evaluation Sweep Statements of whose Evaluation Sweep Timestamp falls in the interval named by REQUIRED since and until parameters, at most 100 per response under the same next rule. Entitlement: a Register Operator, a regulator or an Audience Member. Its counts are deployment-wide aggregates and disclosing them to a party named in one Audience Set is a real cost, recorded in ; the Statement is a signature over a fixed array and cannot be served with fields removed without destroying the signature that makes it worth serving. The enumeration is what makes the Entry Sequence Number of a party's own reconciliation entry reachable. Without it an Audience Member entitled to that entry under would have no operation that maps its Reconciliation Hash to a sequence number, and its only route to an entitlement this document grants would be the sweep of GET /arp/entries/{n} that the rate limit below exists to prevent.

Responses Every response to an operation of or to the commissioning request of , including every 4xx other than the 401 of , MUST be a COSE_Sign1 by the reconciliation-server sealing key, under the media type registered in , whose payload is the CBOR array

where: request-binding is the SHA-256 digest over the CBOR array of the request's @method, its @target-uri normalised as in Section 6.2.2 and 6.2.3 of , the request's nonce, and its keyid. Digesting a normalised binding rather than echoing the target as sent leaves nothing to disagree about and binds the response to one requester and one request. status is the HTTP status code. response-time is the time the response was produced, in the timestamp form of . as-of-sequence-number and as-of-self-entry-hash MUST be those of the Ledger head at the moment the read was served, and MUST NOT be those of any earlier entry. A response naming a head lower than the most recently published Ledger Head Statement is non-conforming, and a reader MUST reject one: a server free to answer against a head it chooses could suppress a supersession indefinitely by answering truthfully about a stale head, and its answer would never contradict anything. result is the operation's result, an empty array where the operation is set-valued and nothing matched. On a 404 it is an empty array. On the 422 or 403 of it is the Remediation Advisory, which is the artefact a refused requester needs; on a 429 it is an empty array. For a response to the commissioning request, as-of-sequence-number and as-of-self-entry-hash are those of the Ledger head at the moment the response was produced, and the request-binding digest is taken over a five-element array, the request's content-digest appended after its keyid. Signing errors as well as successes is the load-bearing part. A server that signed only its successes could suppress any continuation channel by answering 404 or 429 forever, and the party it was suppressing would hold an unsigned status line: no proof that it asked, no proof of what it was told, and no way to distinguish suppression from a hash that names nothing. Binding the response to the requester's nonce and key, and stamping it with a time, is what stops a server serving one party's response to another or replaying a year-old empty result; without those the same bytes verify forever and against everybody. A reader MUST check that the request-binding matches the request it sent, that the response-time is within a declared freshness tolerance, and that the as-of-sequence-number is at least that of the most recent Ledger Head Statement it has seen. A deployment MUST declare that tolerance in its Bilateral Register Agreements and it MUST NOT exceed the ledger-head notarisation interval of : a tolerance left to each reader is not a property two implementations can be tested against, and one longer than the notarisation interval would admit a response naming a head the reader could already know to be superseded. Without those checks a server may serve a cached response for a repeated request tuple indefinitely, and the properties below do not hold. An empty result is therefore an assertion and not an absence: a signed statement that as of a named head, at a named time, in answer to this requester's request, there was nothing. A continuation-supersession entry later found at or below that head contradicts it, in one operator's own signature. That contradiction is conditional on the reader and the later observer having been served one chain, and the condition is load-bearing. states that detection of a fork is opportunistic: an operator publishing to two audiences at disjoint sequence numbers never emits a colliding pair. Under such a fork the superseding entry lands on a branch the holder of the empty result never reads, the at-or-below test never fires, and the assertion stands uncontradicted for as long as the branches are kept apart. An empty result is therefore an assertion about a named head on the chain its reader was served, and it is falsifiable to the extent that the reader holds head-consistency evidence for that chain from an observer independent of the responding service. Head evidence obtained only from that service does not bound this. A fork at disjoint sequence numbers is invisible from a single vantage by construction, and the vantage is what is in question: equivocation is precisely the condition that no single consistent chain explains two observations, so it becomes observable when two independent observers compare heads and not before. A relying party acting on an empty result SHOULD hold head-consistency evidence for the served chain from at least one observer independent of the responding service -- a witness countersignature over the head, or, where no witness set is available, an independently anchored head digest, in decreasing order of strength. This document does not specify a witness quorum and does not claim to close the gap; it names the evidence that bounds it, so that a relying party can tell whether it holds any. The contradiction is only as tight as the operator's freedom to defer. A continuation-supersession entry MUST be appended within the ledger-head notarisation interval of , measured from the completion of the Evaluation Sweep that produced the superseding Output -- an event the Evaluation Sweep Statement of dates and signs, and which therefore exists for an immaterial supersession as much as for a material one. Where the supersession is the revocation of a Verified Principal Credential and no superseding Output is produced, the deadline runs from the completion of the sweep the revocation triggered, which likewise dates and signs. Measuring from "the material change" would leave both that case and an immaterial supersession with no start point and so no deadline. Without a deadline an operator defers every supersession above the highest head it has ever named and no contradiction ever arises.

Error semantics A request that is well-formed and signed but that names a resource the requester is not entitled to, and a request naming a resource that does not exist, MUST both be refused with 404. Only an entitled requester receives 200. Answering 403 for the first and 404 for the second would turn every endpoint into an existence oracle: a party could sweep Reconciliation Hashes, or sequence numbers, and learn what a deployment had done without being entitled to any of it. The two cases MUST be equivalent under the normalised observation this section defines, rather than byte-identical, which a conforming server cannot make them: requires every response to bind the request and the serving instant, so the request-binding, the response-time, the As-Of pair and the resulting signature differ between any two requests whether or not the resource exists. A requirement of byte equality would be unsatisfiable, and a test written against it would fail every conforming implementation. The normalised observation of a response is that response with exactly those four values removed. Two responses are equivalent when their normalised observations are equal. Across the two cases a server MUST therefore produce the same status, the same media type, the same set of HTTP header field names, the same set of protected COSE header parameters, the same empty-result representation, the same cache directives and the same rate-limit effects, and the signed payload MUST NOT carry any error discriminator whose value depends on whether the resource exists. Every value removed by normalisation MUST still be valid for its own request: normalisation is how two responses are compared, not a licence to omit a required field or to carry an existence-dependent discriminator inside one. A response to either case MUST carry Cache-Control: no-store. A response bound to a nonce and a serving instant is not reusable by another requester, and a cache that retained one case and not the other would reintroduce through intermediaries the distinction the rest of this section removes. Two channels survive that rule and MUST be closed with it. A server MUST charge the rate-limit counter before evaluating entitlement, so that an unentitled request and a nonexistent one consume the same budget and a burst of each yields the same sequence of statuses. And entitlement evaluation MUST NOT be short-circuited: a server MUST perform the same work for a Reconciliation Hash it does not hold as for one whose Audience Set does not name the requester, so that the two do not differ in response time. Response timing is a separate claim from the requirements above and MUST be stated separately. Serving both cases from one processing path is evidence about the design and is not evidence that the two latency distributions are indistinguishable to an observer. An implementation that claims resistance to timing-based existence inference MUST publish the measurement population, the sample count, the network placement of the measurement, the decision rule and the acceptance threshold under which the two response classes were compared. An implementation that makes no such claim is not for that reason non-conforming: the requirements above are met or not met independently of it, and conflating the two would let a deterministic conformance failure be excused as a measurement artefact, or a measurement result be read as protocol conformance. A server MUST rate-limit these operations, per authenticated principal, at the most permissive rate any of its Bilateral Register Agreements declares, and MUST answer 429 when the limit is reached. The declared rate MUST admit at least one read of each operation per Reconciliation Hash per reliance interval, so that a limit cannot silently void the obligation of . GET /arp/entries/{n} in particular ranges over the whole Ledger; unlimited, a party entitled to one consistency check could sweep for the deployment's entry count, write rate, and the timing of retroactive bursts, which is disclosure by aggregation of a surface every individual answer to which is innocuous. A read served under with any field redacted MUST NOT return the Prior-Entry Hash or the Self-Entry Hash of that entry, and MUST NOT return the Prior-Entry Hash of the entry that follows it, which is a digest over the redacted entry in its entirety. The Self-Entry Hash is a digest over the entry's own fields and carries no blinding value; a reader holding the leading fields and denied the type-specific block could otherwise recover the block by search over register subsets, a small aggregation descriptor set, four binding classes and a bounded timestamp, and would do so off the audit trail that section imposes. A redacted field is returned as CBOR null in its position, so that the array's length is still the length fixed by the Entry Type; a regulator receiving a redacted entry therefore cannot verify its chain hashes, which is the price of redaction and is why an unredacted read is the ordinary case. Each read served under this section MUST be recorded in an append-only access log, retained for the period of . The log is not the Settlement-Layer Ledger and MUST NOT be written to it: who asked a question is not a fact about the reconciliation, and a Ledger that recorded reads would disclose the pattern of interest in a subject to every party entitled to read it. The log is readable only by a regulator under and by an Audit Identity under , to which it is disclosed out of band as the policy-epoch material is; the reasoning that keeps it off the Ledger applies equally to the log itself.

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. 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.

Registration The Reconciliation Output MUST be registered as a Signed Statement by POST /entries as defined in , with the HTTP Content-Type that document requires on that request. A Transparency Service returns a Location header on both 201 Created and 202 Accepted; an implementation MUST use it in both cases rather than constructing a polling URL of its own. Notarising an Output does not enlarge its Audience Set. Registration places the sealed Output in a log whose retrieval is by EntryID, and a party that obtains it that way holds it on the terms of : it may verify the Sealing Signature and read the Combined Verdict, and it obtains no read under and no notice of supersession. A deployment for which that is the wrong disclosure should not notarise; is composed permissively for that reason. The payload of the Signed Statement MUST be the sealed COSE_Sign1 -- the Reconciliation Output under its Sealing Signature, as produced by -- and MUST NOT be the bare Reconciliation Output. Nesting is what makes the requirements below checkable: a relying party holding only the bare Output has neither the sealing key identity nor the Policy-Version Hash the seal committed to, and could not verify either. The Signed Statement is therefore a COSE_Sign1 whose payload is itself a COSE_Sign1. Its protected header MUST carry: the content type application/arp-sealed-reconciliation-output+cose, registered per . The outer payload is a COSE_Sign1 wrapping a Reconciliation Output, not a Reconciliation Output, and labelling it with the latter's media type would have a conforming decoder parse a signature envelope as an Output; arp-policy-version-hash; arp-bilateral-agreement-hash, carrying the array of the Bilateral-Register-Agreement Hashes of the addressed registers, sorted in lexicographic byte order as required by . A Reconciliation Output aggregates registers under more than one agreement, and an unordered encoding would make two conforming implementations produce non-interchangeable Signed Statements. The outer COSE_Sign1 MUST carry a kid in its protected header, MUST be signed under a key resolvable through , and that key's Sealing-Key Identifier MUST equal the Sealing-Key Identifier of the nested Output in both components. A relying party MUST verify the outer signature and that equality. "Signed by the server that sealed it" is otherwise not a predicate a relying party can evaluate: any operator of a conforming server could wrap another server's sealed Output, sign it under its own resolvable key, and every other check here would pass, and the Receipt would attribute the statement to the Transparency Service and to nobody else. Fixing the nested payload closes a false-policy-version attack; fixing the outer signer closes a wrong-registrant one. The arp-bilateral-agreement-hash in the outer protected header MUST equal the value carried in the nested sealed COSE_Sign1, and the arp-policy-version-hash in the outer protected header MUST equal the Policy-Version Hash carried in the nested sealed COSE_Sign1. A relying party MUST verify the Sealing Signature over the nested payload, MUST verify that equality, and MUST reject the Signed Statement where either fails. The verification key for the Sealing Signature is identified by the Sealing-Key Identifier of , whose kid component MUST equal the kid in the protected header of the nested COSE_Sign1, and is resolved through . A relying party that cannot resolve the Sealing-Key Identifier MUST NOT rely on the notarised statement. Without nesting and this equality the Signed Statement would be a second and independent envelope: any party holding a valid Reconciliation Output could register it under a protected header asserting a policy version it was not sealed under, and a relying party following would believe that assertion. A protected header cannot be altered after signing, but it can be false when signed, and integrity is not correctness. The payload MUST NOT be the Verifiable Credentials serialisation of . That form is an interop convenience for relying parties and is not the notarised object; registering it instead would notarise a representation whose canonical form is unspecified.

Asynchronous registration A Transparency Service may register synchronously or asynchronously, and an implementation MUST support both. This is the most likely source of divergence between two otherwise conforming implementations, and is therefore stated as a requirement rather than left to the referenced document. On 201 Created the Receipt is available immediately. On 202 Accepted the response carries a Location header, and the implementation MUST poll that URL verbatim rather than constructing a path of its own. A 204 No Content means registration is still in progress and MUST NOT be treated as failure or as a negative result. A 4xx other than 404 returned synchronously by POST /entries is a terminal refusal and MUST NOT be retried under the same Signed Statement; it is the ordinary refusal case and is recorded as such under . A 404 Not Found ends polling and MUST NOT be polled further. It carries two meanings in -- that no Receipt was found for the specified EntryID, and that an asynchronous registration has failed and no Receipt will be produced -- and an implementation MUST distinguish them from the response body where the service supplies one, because the second is a registration failure and the first may follow from having polled a URL the Transparency Service did not issue. Ending polling is not the same as resolving the outcome: only the second meaning is a terminal refusal for the purposes of , and a 404 the implementation cannot resolve to one meaning or the other is recorded as an incomplete notarisation, not as a refusal. An implementation MUST honour a Retry-After header where one is present, MUST NOT poll more frequently than once per second in its absence, and MUST bound total polling, to the shortest bound any Bilateral Register Agreement addressed by the reconciliation declares; a bound of 300 seconds is RECOMMENDED where the Bilateral Register Agreement declares none. Exhaustion of the bound MUST be recorded in a Post-Seal Evaluation Record carrying notarisation-incomplete per , rather than as either success or refusal. A Reconciliation Output whose notarisation is incomplete remains valid under its Sealing Signature; notarisation is an additional property, not a precondition of validity.

Sealing-key discovery A signed key set, wherever this document requires one, is a COSE_Sign1 whose payload is the deterministically encoded CBOR serialisation of the COSE_KeySet, under the media type registered in . Each key in the set carries the arp-key-status and arp-key-validity COSE Key common parameters registered in . An Authorised-Origin Document is a COSE_Sign1 whose payload is a CBOR array of three-element arrays -- the server's authority origin, the identifier of the key signing its sealing key set, and the identifier of the key signing its operator key set -- sorted in bytewise lexicographic order of the origin. A relying party is not a party to any Bilateral Register Agreement and holds only the hashes of those agreements. It therefore cannot resolve the sealing key from them, and a binding that assumed otherwise would oblige every conforming relying party to refuse every Reconciliation Output. A reconciliation server MUST publish its sealing keys as a COSE Key Set at /.well-known/arp-sealing-keys on the reconciliation server's authority origin, and a single key by identifier at /.well-known/arp-sealing-keys/{kid_value}. The Sealing-Key Identifier is the pair of that origin and the kid; where this document requires a kid to equal the Sealing-Key Identifier, it is the kid component that is compared. Resolving a key is not sufficient. Web PKI establishes that an origin is the origin it claims to be; it does not establish that the origin is entitled to seal Reconciliation Outputs naming a given register set. A relying party that accepted any well-formed key set would accept an Output minted by any party able to stand up a host, since the Bilateral-Register-Agreement Hashes can be copied from a genuine Output and are one-way. Each Bilateral Register Agreement MUST therefore declare the authority origin of the reconciliation server it authorises, and each register operator MUST publish an Authorised-Origin Document at /.well-known/arp-authorised-origins on its own register origin. A Register Identifier is an origin, so the register origin is a member of the Addressed-Registers Identifier Set and is known to the relying party from the Output. An Authorised-Origin Document is a COSE_Sign1 whose payload comprises, for each reconciliation server the register operator has authorised, that server's the three-element arrays pins above. It MUST be signed under a key served as a COSE Key Set at /.well-known/arp-register-keys on the same register origin -- a key set carrying the same arp-key-status and arp-key-validity parameters as a sealing key set, so that a compromised register key has an in-band revocation path, and the same key set that resolves a register's signatures on Partial Attestations and Non-Answer Statements -- which the relying party fetches over its ordinary web PKI. Signing it matters for the same reason signing the sealing key set matters: an unsigned document fetched over TLS can be varied per audience, and this one is the root of the chain. A relying party MUST verify that the origin component of the Sealing-Key Identifier appears in the Authorised-Origin Document published by every register in the Addressed-Registers Identifier Set, and MUST reject the Output where it does not or where any such document cannot be verified. The chain is then: register origins from the Output; each register's own key from its register origin; the Authorised-Origin Document verified under that key; the authorised server origin and its key-set signing key identifier from that document; and the sealing key from the server's key set, verified under that identifier. Every step is fetchable by a party holding only the Output. A key entry MUST carry the arp-key-validity and arp-key-status parameters of active, retired or revoked. A relying party MUST reject a Sealing Signature made under a revoked key irrespective of when the Output claims to have been sealed, MUST accept one made under a retired key only where the Reconciliation Timestamp falls within that key's validity interval, and MUST reject one whose Reconciliation Timestamp falls outside the interval of the key it resolves to. A key MUST NOT be removed from the set while any Reconciliation Output it sealed may still be relied upon: retirement is by status, not by deletion, so that a historical Output remains verifiable while a compromised key can still be refused. The key set MUST itself be signed under the key whose identifier the Authorised-Origin Document gives for that server, and a relying party MUST verify that signature. The identifier comes from a document the relying party can fetch, not from an agreement it does not hold. A key set fetched over TLS alone can be varied per audience, which would let a server present one key to one relying party and another to a second and seal two contradictory Outputs for the same reconciliation, each verifiable only by its intended audience -- reopening at the origin the equivocation that closes at the Transparency Service.

Receipt validation A relying party MUST validate the Receipt against Transparency Service keys obtained from GET /.well-known/scitt-keys, or from GET /.well-known/scitt-keys/{kid_value} for a single key identified in the Receipt.

Policy-version determination A relying party MUST determine the Policy Version of a notarised Reconciliation Output from the arp-policy-version-hash parameter in the verified protected header of the Signed Statement, and MUST NOT determine it from any retrieval path, query parameter or Transparency Service index entry. Because the parameter is in the protected header, it is covered by the Receipt; and because requires the sealed COSE_Sign1 to be the nested payload and the outer parameter to equal the Policy-Version Hash it carries, what the header asserts is verifiably what the seal committed to. The policy version is therefore established by verification rather than by lookup, and a Transparency Service that indexed an entry incorrectly, or presented different index results to different relying parties, cannot cause a relying party to attribute a Reconciliation Output to a policy version it was not sealed under. This holds only because of the nesting and equality requirements in , both of which the relying party checks. A protected header alone establishes that a value was not altered after signing, not that it was true when signed. defines retrieval by EntryID and defines no query surface. Correlating entries by policy version is consequently outside the scope of this binding and is a property of the deployment, not of the protocol. An implementation MUST NOT assume a standard retrieval path keyed on the Policy-Version Hash exists.

Verifiable Credentials Interop A Reconciliation Output MAY be additionally serialised as a JSON-LD document conforming to the W3C Verifiable Credentials Data Model , under the media type application/arp-reconciliation-output+json registered in -- +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 exists to retire, reintroduced through the interop form.

Security Considerations

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 , 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 . 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.

Budget Exhaustion as a Suppression Channel 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 (). 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 , 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 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. 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 can be given the counter state directly. That is an out-of-band remedy and it is stated as one.

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.

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 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.

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.

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 with the Non-Answer Reason attestation-stale and a freshness-stale divergence axis attributed to that register. A signed agent request under MUST additionally carry a nonce and created/expires parameter set that requires, so that a captured signed request cannot be replayed to initiate a fresh reconciliation.

Post-Quantum Migration The Cryptographic-Primitive-Upgrade Path is the mechanism by which ARP deployments migrate to post-quantum primitives. ML-KEM-1024 is RECOMMENDED for the claim-encryption primitive class. ML-DSA-65 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.

Side-Channel Considerations The disclosure model as a whole, and the residual risks this document accepts, are set out in . 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.

Privacy Considerations This protocol operates over beneficial-ownership registers, corporate registries, consolidated sanctions lists and customs records. Its subject is almost always a party that is neither the requester nor a recipient, and that is not told a reconciliation about it occurred. The disclosure model has two artefacts and one division. A Reconciliation Output is confidential to its Audience Set and carries subject references, register-signed attestations and principal identifiers; the Settlement-Layer Ledger is broadly readable and carries digests, register origins and structural metadata. states the division and the rules that rest on it. What is protected. The Deployment Blinding Value of keeps the Claim Hash and the Policy-Version Hash from being inverted by exhaustive search over their low-entropy preimages, which is what stops a Ledger reader recovering the subject and the commissioning principal. Entitlement follows the Audience Set, so possession of an Output is not authorisation to learn what happened to it afterwards. Enrolment under means a requester cannot direct an Output at a party that has not agreed to receive one. The per-principal query budget of bounds recovery of a register record by repeated querying. Read responses are rate-limited and logged, and the log is not on the Ledger, because a Ledger that recorded reads would disclose the pattern of interest in a subject to everyone entitled to read it. What is not. A subject has no standing in this protocol: it is not notified, it cannot object, and it cannot learn that it was reconciled. That is a deliberate property of a sanctions-screening protocol and a real cost, and a deployment operating where subject rights attach should provide for them outside this document. An Audience Member learns the subject, the predicate and every register's answer; the audience constraint of lets a register cap how many such parties there may be, and the register cannot verify that the cap was enforced. Notarising an Output under places it in a log whose retrieval is by EntryID, and a deployment for which that is the wrong disclosure should not notarise. The Ledger Head Statement is unauthenticated and carries a contiguous sequence number, so it discloses the deployment's size and approximate rate at the notarisation interval. An Audit Identity under reads every Output of every reconciliation addressing its register irrespective of Audience Set, and each register declares one, so a deployment's disclosure surface grows with the number of registers it addresses. An Override Record names an authorising operator in the clear inside the Output. records a further residual risk, and the projection-narrowing channel.

IANA Considerations This document requests IANA to register the following: Three COSE header parameters in the COSE Header Parameters registry, values to be assigned by IANA: arp-bilateral-agreement-hash (value TBD) arp-policy-version-hash (value TBD) arp-source-data-version (value TBD) arp-policy-version-hash is a CBOR byte string; arp-bilateral-agreement-hash is a CBOR array of byte strings; arp-source-data-version is a CBOR array of two-element arrays, each of a list name and that publisher's state identifier, as constructs it. Each MUST appear in a protected header and MUST NOT appear in an unprotected one: every one of them is a commitment a verifier relies on, and a commitment a signature does not cover is not a commitment. arp-policy-version-hash and arp-bilateral-agreement-hash are used by ; arp-source-data-version is used by . Two COSE Key common parameters in the COSE Key Common Parameters registry, values to be assigned by IANA: arp-key-status (value TBD), a CBOR text string of active, retired or revoked; and arp-key-validity (value TBD), a two-element CBOR array of the not-before and not-after times in the form of . requires both on every key it publishes, and a key parameter used normatively and never registered is a parameter no other implementation can read. A registry of ARP Divergence-Axis values, registration policy Specification Required, initially containing the descriptors enumerated in the Divergence Axis definition of . Each entry MUST record whether the axis is register-attestable or server-recorded, a distinction eight normative sections depend on and which is otherwise carried only in prose. The designated expert MUST refuse a registration that does not state it. A registry of ARP Non-Answer Reasons, registration policy Specification Required, initially containing the values enumerated in . Each entry MUST record whether the reason is register-attested or server-observed, which determines whether a Non-Answer Statement signed by the register is required; the initial entries are recorded as states. A Non-Answer Reason is not a verdict; the designated expert MUST refuse a registration that could be combined by the Verdict Arithmetic, and MUST refuse a register-attested registration that does not state what the register signs over. A registry of ARP Post-Seal Evaluation Qualifiers, registration policy Specification Required, initially containing notarisation-incomplete and attribution-indeterminate, defined in . A registration MUST identify a condition arising after a Reconciliation Output is sealed; the designated expert refuses a registration that qualifies a verdict, which belongs in the Divergence-Axis registry. A registry of ARP Register Data-Format Profile identifiers, registration policy Specification Required, initially containing arp-profile-bods, arp-profile-corporate-org, arp-profile-customs-wco and arp-profile-sanctions-consolidated, defined in . Identifiers beginning x- are reserved for bilateral use and are not registered. A registration MUST state the dated vocabulary in which permitted predicates are expressed where it names one and state that it names none otherwise, the relation corresponding to taxonomic narrowing for each branch of its predicate space, and the parameters a Bilateral Register Agreement declaring it must supply. The designated expert refuses a registration that defines any means of transporting register records, that declares more than one parent relation applicable to a single predicate, that names a vocabulary without pinning its version, or that fixes in the profile a parameter varying between registers using the same format. A registry of ARP Aggregation-Method Descriptors, registration policy Specification Required, initially containing hash-linkage-conjunction, hash-linkage-disjunction, hash-linkage-threshold-count and hash-linkage-source-class-quorum: the aggregation mode of joined to the Verdict-Arithmetic operator it sequenced. A registration naming a new aggregation mode MUST specify that mode's construction; the descriptor is a signed Ledger field and a mode with no construction gives it no meaning. A registry of ARP Retroactive Evaluation Triggers, registration policy Specification Required, initially containing pattern-library, policy-version, source-data-version and credential-revocation, defined in . A registration MUST name an event whose occurrence and time a party outside the reconciliation server can establish, or state plainly that it cannot, since the falsifiability of turns on it. A registry of ARP Override Grounds, registration policy Specification Required, initially containing operational-continuity, pattern-false-positive and statutory-obligation, defined for use in the Override Record of the Adversarial Pre-Transmission Test. A registration MUST state the circumstances in which the ground is available and MUST NOT admit a ground that could be asserted of every override, which would return the field to free text. A registry of ARP Re-Typing Grounds, registration policy Specification Required, initially containing bounded-depth-not-closure, declared-not-determined and threshold-divergence, corresponding to the three grounds of . A registry of ARP Verdict-Arithmetic operators, registration policy Specification Required, initially containing conjunction, disjunction, threshold-count and source-class-quorum, defined in . A registration MUST state the operator's result as a total function of the multiset of contribution values and the operator's declared parameters, and MUST state whether it admits partial-match, on which turns. A registry of ARP Ledger Entry Types, registration policy Specification Required, initially containing reconciliation, continuation-notarisation, continuation-post-seal-record and continuation-supersession, defined in . Entry Type values are CBOR text strings. A registration MUST enumerate the fields an entry of that type carries in addition to the fields every entry carries, MUST state their order, since the Self-Entry Hash is taken over that order, and MUST state each field's value type and whether it is conditionally absent and on what condition. The designated expert MUST refuse a registration whose type restates a field already carried by the reconciliation entry it continues, and MUST refuse any type other than reconciliation that records a reconciliation rather than a fact arising after one was sealed. The initial registrations are those of , with these value types. Every hash is a 32-octet CBOR byte string; every sequence number is a CBOR unsigned integer; every timestamp is a CBOR text string in the form of ; every Entry Type is a CBOR text string; the Addressed-Registers Identifier Set is a CBOR array of text strings, each an authority origin, sorted in bytewise lexicographic order of its UTF-8 encoding; the Aggregation-Method Descriptor and the Requester-Binding-Class Descriptor are CBOR text strings, the first drawn from the ARP Aggregation-Method Descriptors registry and the second from the four classes of the Requester Identity Binding and Agent Friend-or-Foe Gate section; the Override Indicator and the Material-Change Indicator are CBOR booleans; the Transparency Service Identifier is a CBOR text string carrying an authority origin; the EntryID is a CBOR text string as returns it; an HTTP status code is a CBOR unsigned integer; and every Entry Signature is a COSE_Sign1.

Well-Known URIs Six entries are requested in the Well-Known URIs registry of . For each, the change controller is the IETF, the status is permanent, and the specification document is this document. URI suffix Defined in Path syntax below the suffix arp-sealing-keys /{kid}, where {kid} is a JWK thumbprint, returns that single key arp-register-keys /{kid} as above arp-operator-keys the Adversarial Pre-Transmission Test /{kid} as above arp-authorised-origins none arp-ledger-head none arp-policy-parameters none

Media types Eleven media types are requested, registered under the template of . 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 for +json -- and are otherwise none, no fragment identifier syntax being defined for the +cbor and +cose forms. Subtype Carries Defined in arp-reconciliation-request+cbor a request commissioning a reconciliation arp-remediation-advisory+cbor a Remediation Advisory the Adversarial Pre-Transmission Test arp-sovereign-re-notification+cose a Sovereign Re-Notification arp-sealed-reconciliation-output+cose a Reconciliation Output under its Sealing Signature, whether delivered directly or nested in a SCITT Signed Statement arp-policy-parameters+cose a Policy Parameters Document arp-post-seal-evaluation-record+cbor a Post-Seal Evaluation Record arp-reconciliation-output+json the Verifiable Credentials JSON-LD form arp-ledger-head+cose a Ledger Head Statement arp-read-response+cose a signed read response arp-evaluation-sweep+cose an Evaluation Sweep Statement arp-key-set+cose a signed COSE Key Set or an Authorised-Origin Document

Acknowledgments This document benefits from the SCITT Architecture , the SCITT Reference APIs , COSE Receipts , the RATS Architecture , HTTP Message Signatures , and the Web Bot Auth HTTP message signature protocol . Named findings, because a specification improved by review should say by whom. Songbo Bu established that the indistinguishability requirement of could not be satisfied as -02 stated it: the response profile of binds each response to its request and its serving instant, so two responses cannot be byte-equal, and a conformance rule demanding that they be would fail every conforming implementation. The normalised observation in , its enumeration of HTTP metadata and cache behaviour, and the separation of the deterministic requirements from any statistical timing claim are his design, contributed as an executable vector class. Steven Mih established that the empty-result contradiction of is conditional on the reader and any later observer having been served one chain, and that under the fork admits it may be opportunistic to detect, an absence assertion can stand uncontradicted indefinitely. The boundary now stated in is his finding. He also confirmed, against three independent drafts, that the deterministic encoding requirements relied on here are those of Section 4.2.1 of and not those of Section 9 of . Iman Schrock established, with Anton Sokolov, that a content digest cannot serve as a correlation key across independently produced descriptions of one act. He then established that the earlier repair was itself imprecise: declares required and optional fields per action type and marks no field as a correlation key, so the selection belongs to the profile. The requirements in to pin the action type and version, the selected field and its normalisation and comparison rules, and to require that the selected field be present in the Canonical Claim so that the Claim Hash commits to it, are his, substantially as he drafted them. Walter Hawkins established that the falsifiability condition of is bounded by observer diversity rather than by any stronger single-log property: head evidence obtained from the responding service cannot bound a fork, because a fork at disjoint sequence numbers is invisible from a single vantage by construction and the vantage is what is in question. Naming the independent observer, and the ordering of witness countersignature over independently anchored head digest, is his. Tiago Pinto established that the obligation to answer with a signed response carrying a log position belongs on the party making the claim rather than on the party relying on it, and that an unsigned or position-less answer is to be treated as the log not having answered. takes that shape at his argument. Tom Sato's leaf-construction work on Certificate Transparency logs informed the inclusion-proof requirements of .

Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. The Unicode Consortium EMILIA Protocol, Inc. Authorization, delegation, execution, and audit artifacts often identify an action using format-local content and digests. Those digests are not directly comparable when the formats select or encode material action fields differently. This document defines the Canonical Action IDentifier (CAID): a typed action object, a canonicalization and digest suite, a compact identifier string, and immutable action-type definitions with required material fields. It also defines an Action-Mapping Profile for projecting independently verified native artifacts into a common action type, with the closed results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, and INDETERMINATE. CAID carries no trust semantics. It does not establish identity, authority, authorization, execution, safety, or legal reliance. Open Ownership World Wide Web Consortium World Customs Organization United Nations Economic Commission for Europe United States Department of the Treasury, Office of Foreign Assets Control European Union Action State Group, Inc. MyAuberge K.K. Independent EMILIA Protocol, Inc. Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. Action State Group Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly re-derive the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, a receipt placed in the unprotected header of the Signed Statement, and a typed reference mechanism that lets one record cite another by digest across profile boundaries. This document defines that construction as a reusable profile — the Canonical Payload Binding — so that each payload class declares its canonicalization algorithm and exclusion set once, obtains an interoperable derived identifier, and inherits statement-to-receipt binding and typed digest reference semantics without restating the mechanics in every profile. IANA registries govern both the canonicalization algorithms and the artifact types that may appear in typed references; entries are immutable. Cloudflare Google This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. Cloudflare Google This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as a new HTTP Method Context for in-band key discovery. Cloudflare Amazon Cloudflare This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using [DIRECTORY] publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same namespace used by [CIMD], extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members.

Examples

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 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.

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.

Example: Agentic Principal Reconciliation An autonomous agent requests reconciliation of sanctions:any-list-match over HTTP, signing the request under HTTP Message Signatures 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.

Example: Divergent Agent-Action Reconciliation This example is illustrative and non-normative. Capsule slots are those of ; see . 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.

Composition with the SCITT Architecture The SCITT Architecture provides notarisation of supply-chain artefacts through a Transparency Service, which registers Signed Statements and returns Receipts, yielding Transparent Statements. ARP composes with SCITT in four ways: SCITT receipts MAY be the input claim to ARP. A claim referencing a SCITT-anchored artefact (its hash and its registration receipt) is reconciled across registers without disclosing the underlying artefact. ARP Reconciliation Outputs MAY be notarised into a SCITT Transparency Service as Transparent Statements, enabling SCITT-aware relying parties to verify the cross-sovereign reconciliation event in the same way they verify any other supply-chain claim. Registration and retrieval MAY use the SCITT Reference APIs . Notarisation does not enlarge the Audience Set of : what is registered is the sealed Output, and a party that retrieves it by EntryID holds it on the same terms as a party handed it directly. The SCITT Architecture's Issuer role maps to the Bilateral Register Agreement structure: each Sovereign Register acts as a SCITT Issuer for a constrained predicate set. RFC 9943 defines no role for a party that combines statements from several Issuers, and this document does not claim one: the reconciliation server is an ARP role that acts as a SCITT Client toward the Transparency Service, registering its own Signed Statements. ARP Hash-Linkage Aggregation MAY emit its Merkle commitment as COSE Receipts , the same inclusion-proof format SCITT uses for transparency receipts, so a single verifier library checks both.

Composition with the RATS Architecture The RATS Architecture provides remote-attestation procedures for compute-substrate trust. ARP composes with RATS in two ways: The Adversarial Pre-Transmission Test runs inside a confidential computing boundary attested under RATS. The reconciliation server's integrity MAY be verified by relying parties through standard RATS verification flows. Compute-attestation reconciliation across heterogeneous TEE / CC providers is the natural specialisation of ARP to the RATS evidence class. That specialisation is outside the scope of this document.

Composition with Agent-Action Accountability Capsules models accountable autonomous action as four independently verifiable slots -- CAN, what the agent was permitted to do; WHO, which human authorised it; WHAT the agent did; and AUDIT, the runtime enforcement record -- each filled by a separately signed profile. This document does not restate that model; the slot definitions, their semantics and their composition rules are those of , and this appendix uses them as defined there. This appendix calls a filled slot a capsule. That is this document's term and not that draft's, which speaks of slots and profiles; it is used here because ARP admits each filled slot as a Partial-Attestation source and the word names the signed unit rather than the position it occupies. What this appendix adds is reconciliation across those capsules. Each capsule may be signed by a different party, under a different signing chain, with a different payload schema -- the same non-reconcilable-outputs problem this document addresses for sovereign registers, arising in the agent-action domain. What the capsules share is the action serialisation over which the subject digest is computed. ARP composes such capsules without requiring them to share a producer, a schema, or a signing chain. The capsules are bound to a common action through a shared subject digest, computed as the SHA-256 of the JSON Canonicalization Scheme serialisation of the action being attested:

where JCS is the JSON Canonicalization Scheme specified in , and action is one action object serialised once. All capsules composed under this appendix MUST be computed over that same serialised action object. subject_digest is a join key across capsules over a shared serialisation; it is NOT a correlation key across independently produced descriptions of an act, and MUST NOT be used as one. See . The shared serialisation is established once, by the party that authorises the action, and is echoed verbatim by every later attester. An attester that re-serialises its own account of the action MUST NOT compute subject_digest over that account; it MUST carry the serialisation it received. This is what makes the digest a join key here rather than a correlation across independent descriptions, and a profile that cannot guarantee it is in the second case of rather than the first. Implementations MUST use and MUST NOT substitute another canonicalisation. In particular, does not apply Unicode normalisation. An implementation that normalises before serialising therefore computes a different subject digest from a conforming implementation for any input carrying a member name or string value that is not already in the normalisation form it applies -- silently, since both parties obtain a well-formed digest. The agreement of this construction with a deployed profile depends on both parties having selected , which the normative reference above makes an obligation. freezes a conformance vector only once two independent implementations have recomputed it and specifies no implementation, so no pinned corpus is cited here. The capsules may disagree about the action -- that disagreement is the finding ARP exists to surface -- but they do not disagree about which action is under attestation, because they carry the same action serialisation. Each capsule's own account travels in its payload, committed by its receipt-payload digest below, not in subject_digest. Two further profile-tagged digests, defined by this document rather than by , position each capsule for reconciliation: an authority-reference digest committing to the authorising instrument (tagged transparency where it is the SHA-256 of a COSE_Sign1 transparency receipt, or offline where it is the SHA-256 of the serialisation of an offline receipt payload), and a receipt-payload digest committing to the capsule's own payload. Each capsule is admitted to ARP as a Partial-Attestation source keyed on the shared subject digest, in the slot assigns it. The reconciliation server verifies each capsule's signature under its own trust anchor, projects each into the agent: predicate branch, and aggregates the per-capsule verdicts under the Verdict Arithmetic declared for the action class -- yielding a single, producer-agnostic Combined Verdict over an action whose constituent attestations were never designed to interoperate. Where the authorised-scope capsule and the actual-conduct capsule reconcile to divergent scopes, the Combined Verdict is no-match with divergence axis agent-action-scope-divergence; the divergence is a refusable control input, produced at decision time and sealed to the Settlement-Layer Ledger without claim or capsule content. This composition is the agent-action specialisation of the mechanism ARP applies to sovereign registers: reconcile heterogeneous authoritative outputs over a shared subject into one deterministic verdict, disclose only verdict and divergence, and seal against a Policy-Version Hash. It allows a relying party to reconcile what an agent was permitted to do against what it did, at the moment of action, across attestations no single party produced.

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 together with the Deployment Blinding Value of . Its purpose is to index a claim in the Settlement-Layer Ledger. It applies Unicode Normalization Form C.

subject_digest:

SHA-256 over the serialisation of an action, per . 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. 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. 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.

What a content digest does and does not establish subject_digest is collision-resistant over content: two actions whose serialisations differ in any byte produce different digests except with negligible probability, so a receipt bound to one action does not bind another. That property is what makes it usable as a join key between capsules computed over the SAME serialised action. It does not, and cannot, establish that two INDEPENDENTLY DESCRIBED accounts of one act correlate. The action types, their required and optional members and the reference issuer that minted the instances measured below are those of ; the measurement is not reproducible without it. Where an action type declares optional members, two conforming producers describing the same act may legitimately differ on whether an optional member is present, and their subject digests then differ. Stability under permitted variation and collision resistance over content are contradictory requirements, and no single digest satisfies both. This is measured, not assumed. Five action objects, each a conforming instance of one registered action type and each accepted by that type's reference issuer, differing only in content the type declares OPTIONAL, produced five distinct subject digests. The divergence appeared at the first optional member and did not require any nested reference or unusual value. Accordingly: A profile MAY key capsules on subject_digest where those capsules are computed over the same serialised action object. is such a profile: the capsules it composes share one action serialisation. A profile that requires correlation across independently produced descriptions of one act MUST NOT rely on subject_digest alone. It MUST either pin the exact member set over which the digest is computed, so that permitted variation cannot enter it, or designate a typed field that the action type itself requires, and correlate on that. The second is the more robust of the two, because it does not require every producer to agree on a serialisation before they can agree that they are describing the same act. The selection is the profile's and not the registry's. declares required and optional fields per action type; it does not mark any field as a correlation key, and a specification that says an action type "declares a material identifier" attributes to that registry a semantic it does not carry. A profile therefore MUST pin the action type and its version, the field it has selected for correlation, and that field's normalisation and comparison rules. The selected field MUST be present in the Canonical Claim, so that the Claim Hash commits to it and the join cannot be made on a value the reconciliation does not cover. Equality of the selected value identifies candidate descriptions only. It MUST NOT establish action equivalence, authorisation or execution. Exact-action agreement remains a separate comparison, under the subject-digest construction of or under the profile of . Where the selected values match and the exact-action digests differ, that is a conflict to surface and not a failed join, and surfacing it is what reconciliation is for. Three substitutions are forbidden, because each is available to an implementer who has read only part of the foregoing and each fails silently. The designated join key MUST NOT be treated as the action's identity. The identity of an exact action is its content commitment; the join key is stable across the variation that commitment is required to detect, which is what makes it usable for correlation and useless for authorisation. A Claim Hash MUST NOT be treated as a cross-deployment identifier. It is a digest over a canonical serialisation preceded by the Deployment Blinding Value of , so two deployments reconciling the same claim compute different Claim Hashes by construction, and equality of Claim Hashes across deployments is not a comparison that can be made at all. Equal join keys MUST NOT be taken to mean equal claims. Two reports sharing a designated join key have been asserted to describe one act; whether they agree about it is the question reconciliation exists to answer. Where their Claim Hashes differ, the difference is the finding, and a profile that collapsed them on the strength of the join key would report agreement it never established. Stated positively, each object has one job: the designated field joins candidate reports across permitted variation, the Claim Hash commits to the exact claim under the deployment's blinding value, and the action type's own content commitment remains what authorisation and execution bind to. A specification that describes a content digest as a correlation key without stating which of the two preceding cases it relies on invites an implementer to assume a stability property the construction does not have. The resulting failure is a correlation that silently does not occur.

Document History RFC Editor: please remove this section before publication.

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. 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. 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 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. 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 -- , with , with , 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. 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. 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 , 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. 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 is never displaced. A match found at any depth still establishes an existential closure predicate and is not re-typed. 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. moves from informative to normative, because 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. 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. 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 treats Transparency Service keys. is new. Every operator is now given its result for every combination of contribution values, and whether it admits partial-match, on which 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. 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. 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.

Five things the protocol assumed and never stated Working through the Ledger changes made it clear that a class of gap ran under all of them. Every discovery path in -02 ended at a value its holder could not present to anything, and each attempt to fix one by adding a pointer moved the dead end without removing it. Five substrate layers were missing. They are now written, and adding them closed more open items than any mechanism in this revision. states what the pipeline returns. No earlier revision said that a Reconciliation Output is delivered to anybody. The document specified in detail how an Output is composed, sealed, digested, ledgered and notarised, and never that any party receives one. Every discovery path begins with a party holding a Reconciliation Hash; until now nothing said how it came to hold one. states who may hold an Output. -02 made it a bearer artefact: possession was the whole of the entitlement, it never expired, and every read predicate the document attempted was expressed in terms of a Requester-Binding the reader could not present and the Ledger could not evaluate. An Output now carries a sealed Audience Set and a Reliance Horizon. Entitlement follows the Audience Set rather than possession, which admits the party the Requesting Principal named and excludes the party that merely came into possession; a register may cap how wide an Audience Set addressing it may be, because a register that attests about a subject is entitled to bound how far that attestation travels. The Horizon bounds reliance without touching validity: a sanctions no-match is a statement about lists that change daily, and an artefact asserting one indefinitely was relied upon indefinitely. states how a read is requested. -02 and every draft of this revision before it stated what a read returns and never the endpoint, the request form, the response form, the media type, or the error semantics -- and the two errors that matter most, "nothing exists" and "you may not ask", are the two a reader most needs distinguished, because a server suppressing a supersession returns what a server with nothing to report returns. There are nine operations. Every response, success or error, is signed and carries the ledger head it was served against, so an empty result is an assertion rather than an absence, and a supersession later found at an earlier sequence number is evidence against the operator who signed the denial. Not-entitled and not-found are both 404 with no distinguishing body, so no endpoint is an existence oracle. Reads are rate-limited, because a surface whose every individual answer is innocuous discloses entry count, write rate and retroactive-burst timing when swept. With those in place, the Continuation entries of this revision are reachable by the parties they were written for, a superseded Output's replacement is retrievable because a superseding Output inherits the Audience Set of what it supersedes, and the fork check reconciles two heads at different sequence numbers through a signed consistency read rather than through an unsigned answer from the party under suspicion. Retrieval URIs, which an earlier draft of this revision put in Continuation entries, are gone: every artefact is now fetched by hash from the origin that served the entry, so the Ledger holds no retrieval address, no reader is obliged to dereference an operator-chosen URL before it can check anything, and the covert channel that host selection and path structure carried is closed. The published ledger head is a signed statement carrying a sequence number, and Entry Sequence Numbers are allocated in one sequence so that two conforming stores cannot present the same number over different entries. Two limits are stated rather than claimed away: an operator publishing to two audiences at disjoint sequence numbers never emits a colliding pair, and a party holding neither an Output nor an agreement cannot anchor the signing key. The Reconciliation Hash is no longer among the values required to be reproducible across runs. Its preimage includes the Reconciliation Timestamp, so the requirement was unsatisfiable; the Reconciliation Identifier is the reproducible index and always was. states how a reconciliation is commissioned. The document imposed obligations on "the response to the request that commissioned it" without defining that request anywhere. states who an auditor is. Four requirements were justified by what an auditor could reproduce, and the auditor was not a party this document admitted; an Audit Identity is now declared in a Bilateral Register Agreement, so that the audited party cannot choose its auditor after the facts are known. Several corrections follow from checking this document's claims about other specifications against those specifications. The deterministic CBOR encoding every digest here depends on is that of Section 4.2.1 of , which is now a normative reference; RFC 9052 narrows those requirements to COSE's own signing structures and states no map-key ordering rule, so the previous citation did not support what was built on it. , , and are referenced rather than named in prose. no longer attributes an Identity Manager or an Aggregator role to , which defines neither. no longer presents "capsule" as that draft's term. An unsourced claim about agreement on twenty-two pinned conformance vectors is removed, that draft having frozen none. The EU consolidated financial sanctions list and the OFAC SDN list are retargeted at the resources that actually publish them. Three further sections follow from those. pins the tree both Merkle roots in this document use, with domain separation and an inclusion- proof encoding, so that a proof produced by one implementation verifies under another. gives the Sovereign Re-Notification an artefact, a payload, a media type, a delivery endpoint and a retry obligation; it was a MUST with none of those in -02. states the disclosure model and the residual risks this revision accepts rather than leaving them to be inferred -- the subject has no standing in this protocol, an Audit Identity reads broadly, and the published ledger head discloses a deployment's size at the notarisation interval. Every digest preimage and signature payload in the document is now pinned to a CBOR array with a normative field order and null-substitution for absent fields: the Reconciliation Output and its Sealing Signature, the Partial Attestation, the Per-Register Claim Projection, the ledger entry, the Post-Seal Evaluation Record, the Non-Answer Statement, the Ledger Head Statement, the Evaluation Sweep Statement and the read response. -02 left several of them as "the canonical serialisation of the foregoing", which is not a preimage two implementations can agree on. Homomorphic Aggregation Mode is removed and Hash-Linkage is the only mode. The mode named no primitive, had no class in the Cryptographic-Primitive-Upgrade Path for one to be declared in, and defined no encrypted-contribution structure; and the reconciliation server must read every per-register verdict in the clear in any case, to verify the register's signature, recompute the Query Binding, check the echoed Policy-Version Hash and apply re-typing. The privacy property the mode advertised was therefore not available under it, and ARP's actual minimum-disclosure property -- controlled projection, and a Partial Attestation payload that discloses of the subject only a verdict, a divergence axis, the applied parameters and a digest -- is unaffected by its removal. Four homomorphic-* Aggregation-Method Descriptors go with it. The interface between the reconciliation server and a sovereign register is now stated to be out of scope, and the claim that enumerating the Per-Register Claim Projection lets two register operators build interoperable endpoints is withdrawn. Enumerating a structure is not specifying a binding. That leg -- an endpoint, a media type, and a COSE_Encrypt construction pinning the AEAD and its authenticated additional data -- is the principal item this revision leaves for the next.

Ways the protocol could be gamed, closed 's query budget is now measured per accountable principal per subject. A budget shared across requesters is exhausted for everyone by any one of them -- including an unidentified agent -- which forced every reconciliation about that subject to indeterminate for the interval. The countermeasure was a denial of service. Exhaustion now refuses the register and not the reconciliation, which resolves a contradiction in -02: the old text refused the reconciliation and then recorded a Non-Answer Reason in an Output that consequently did not exist. A register-attested Non-Answer Reason now requires a Non-Answer Statement signed by that register over the projection values and the reason, and records which reasons are register-attested and which are server-observed. Without it a register-refused was an unattested assertion by the party that transmitted the projection, and a server could suppress a match by claiming the register had declined. A server can still downgrade a reconciliation by asserting a server-observed reason and the document says so; what it can no longer do is dress suppression as an act of the register. is new. Every trigger of retroactive evaluation was server-observed, every decision to run was the server's, and nothing recorded that a sweep had happened -- so "we evaluated and found no change" and "we never evaluated" were the same observation from outside. A signed Evaluation Sweep Statement per sweep, notarised on the head interval, makes the absence of one an assertion the operator has to make. A Source-Data Version publication is a public event with a public timestamp; an operator with no Statement covering one has not evaluated, which is now checkable. The Verdict Arithmetic is resolved by the reconciliation server from policy, keyed on the predicate and the regimes the requester names. -02 read as though the requester declared the operator and its threshold in its own claim, which would let it 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. Naming a regime is a claim about which law applies and the requester is accountable for it; selecting an operator is a determination about how evidence combines, and the deployment makes it. source-class-quorum now carries its per-class threshold into the Output as well as its partition, without which it was as irreproducible as carrying neither. The Requester-Binding gains a fourth class, agent-key-verified, for an agent whose signing key verified but whose asserted principal was not corroborated. -02 recorded key possession and principal binding as one fact. An agent that signs correctly has shown it is the same agent as last time and not that any accountable party stands behind it; recording that as agent-verified overclaimed to every downstream reader and recording it as agent-unverified discarded something real. states what revocation of a Verified Principal Credential does and does not reach. It is not detected in the hot path and this document does not pretend to put it there; what it does is bound the window, by requiring an Audience Member to read continuations before relying past the Reliance Horizon. Reliance years later on an Output whose principal was disowned the following week is the case that matters, and -02 left it open. The Override Record is enumerated, carries an Override Ground from a new registry, and is signed by the authorising operator rather than by the server. A record the server signs attests only that the server says an operator authorised a bypass. It names that operator in the clear, which is consistent with : blinding protects the published Ledger, and the Output is confidential to its Audience Set. Retroactive Evaluation now triggers on a new Source-Data Version. It previously triggered only on a Pattern Library or Policy Version change, so a sanctions list republication -- the case was written for -- fired nothing. A material change now includes a transition between decisive values: a no-match becoming a match is the case the motivating domain cares most about, and the earlier definition omitted it. Homomorphic Aggregation Mode was restricted in -02 and is removed in -03; see the -03 entry above. The Pattern-Library Version Identifier is no longer bound as authenticated additional data: registers are never told the pattern-library version, so binding it either failed universally or was supplied by the party that chose it. The Reconciliation Hash is taken over deterministic CBOR rather than , because the Output is CBOR and several fields are byte strings for which JSON has no type. Regulator Portal scope is the intersection across agreements rather than the union, which had let one permissive agreement widen access to a stricter register's reconciliations. The Freshness Timestamp is now enumerated before the signature line in and is therefore covered by it. It was listed after the signature in earlier revisions, and both replay defence and the new freshness-versus-skew distinction depend on it being signed. Not adopted: a statement that a reference implementation is forthcoming. It does not exist yet, and a draft should not carry a claim about an artefact a reader cannot check. When it is published it will be cited by repository and commit alongside the conformance vectors it is checked against.

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. is now a NORMATIVE reference. -01 named JCS in 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 . It is now an obligation rather than a coincidence. The Canonical Claim in now pins its member-sort code unit to UTF-16, per Section 3.2.3 of . -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 . -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 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 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 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 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. remains an informative reference. 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 . The status of both references will be revisited as those documents progress. 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. 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 and the COSE Merkle tree proofs reference is now . -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 . , which defines the signature-agent card, is retained. 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 downref explicitly, so that it can be called out at IETF Last Call per rather than found there. 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 -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 argues for: one identified construction per digest role, committing to the parameters that affect the serialised bytes and to nothing else.

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 and Web Bot Auth for signed agent requests, and added an Agent Impersonation security consideration. Replaced the stale scitt-receipts reference with COSE Receipts and added the SCITT Reference APIs ; 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 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).