AHL Protocol Specification (v0.3-draft)

Author:   Dmitrii Zatona
Status:   Working Draft — not for implementation
Version:  0.3-draft
Date:     August 2026

This document specifies the Anchored History Log (AHL) Protocol, version 0.3-draft. Scope is the closed-corpus core — one producer, one log, one keyspace. Cross-producer federation (cross-producer identity, disclosure accounting, foreign-trigger observation) is a planned extension, out of scope for core conformance.

Abstract

AHL is an open specification for record-level, tamper-evident provenance in data and ML pipelines. It defines signed, digest-bound statements over individual records (ingestion, derivation, retraction, correction, propagation, plus manifest and key statements for corpus governance); a log-binding contract for anchoring statements in an append-only, verifiable log with authenticated enumeration; and revocation propagation semantics computed and verified over an explicitly declared, enumerable corpus.

Conformance is graded L1–L3. AHL provides non-repudiation of assertions and tamper evidence of their history; it does not assert the truth of assertions, and every guarantee names its boundary.

1. Introduction

A derived record — a resolved identity, a risk score, an enriched attribute, a batch release certificate — is produced from other records by a transform. Later, an auditor or affected party may require derivation (which inputs, code, model produced it), reconstruction (asserted provenance as of a past time), or propagation (that a retraction of a source reached every affected derived record in the declared corpus).

Existing tooling records this as dataset- and column-level lineage, asserted by the pipeline about itself in mutable metadata, changeable without a trace. The Anchored History Log (AHL) Protocol addresses this by binding derivation to signed, digest-bound statements over individual records, anchored in an append-only, cryptographically verifiable log.

ATL proves history; APL proves meaning under frame; AHL proves what a record was asserted to have been computed from.

1.1. Core Philosophy

The AHL Protocol is built upon four principles.

1. Record-Level Binding: Every derived record carries its own signed statement naming the exact input records, code, model, and parameters that produced it — never an assertion about the dataset it belongs to.
2. Pluggable Log: Statements anchor into any log satisfying the binding contract (§4) — append-only, inclusion and consistency proofs, authenticated enumeration at L3. AHL mandates no specific operator or product.
3. Bitemporal, Index-Ordered: valid_time, issued_at, and log-attested incorporation time are three distinct fields, never conflated; every ordering and checkpoint-membership rule uses the entry’s position in the log, never a timestamp.
4. Revocation Propagation With a Named Boundary: At L3, a retraction or correction obliges computation of the transitive closure over the statement graph and an anchored propagation statement, with completeness defined and checkable at the trigger’s declared corpus checkpoint — never claimed to hold unconditionally. L2 carries no closure duty; conformance claims state “revocation recorded, not propagated” verbatim (§6.2).

Every Guarantee Names Its Boundary: AHL does not assert that any statement is true, that unstated derivations do not exist, or that the declared corpus is a producer’s whole world. Trust in the log operator is reduced to detectability of misbehavior, never claimed to be eliminated.

Open Verifiability: Everything required to generate or verify statements, manifests, proofs, and receipts is open source; a proprietary “official verifier” is out of scope for a conforming AHL deployment, regardless of SDK licensing.

1.2. Trust Model

Producers may err, and may later be motivated to misrepresent. AHL binds assertions to content digests and anchors them so history cannot be silently rewritten. AHL does not prove statements true, does not prove unstated derivations absent, and does not prevent a log operator from misbehaving — it makes each failure detectable within declared boundaries: false statements by cross-checking (§7), omissions by manifest coverage declarations (§8.2), equivocation by the witness protocol (§4.3). Every guarantee is relative to the manifest; AHL makes the boundary explicit.

AHL asserts: for an anchored statement verified against the applicable manifest and key state, that the statement was signed by the holder of the identified key, binds to exactly the committed content, and is included at a stated entry index. At L3, inclusion, consistency, and witnessed-checkpoint evidence make history rewriting and equivocation detectable. For a propagation claim at its declared checkpoint, AHL can determine whether the producer’s dispositions match the closure recomputed from the declared corpus.

AHL does not assert: that any statement is true; that unstated derivations do not exist; that the declared corpus is the producer’s whole world; or that a log operator cannot refuse service.

Implication: Witnessed checkpoints and authenticated enumeration at L3 let a verifier reconstruct the corpus and recompute closure without the producer’s cooperation for entries, and with mechanically checkable completeness for committed tree material.

1.3. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

• Record — the unit provenance is asserted about; AHL constrains identification (§3.4), not form.
• Record commitment — the stable, dataset-scoped cryptographic identifier of record content (§3.4); what a trigger names and closure traverses.
• Representation digest — hash of the bytes a transform actually consumed (full record or a projection).
• Statement — a signed assertion (§3). Statement id — SHA-256 over JCS(payload). Entry id — SHA-256 over JCS(envelope). Entry — the anchored envelope bytes.
• Corpus — all statements anchored in the declared log under the declared manifest lineage. Corpus manifest — the anchored declaration of §8.2. Manifest version id — the statement id of an anchored manifest statement.
• Dataset — a manifest-declared class of records sharing canonicalization, commitment mode, and authority. Dataset authority — the key set entitled to issue triggers for the dataset’s ingested records (in core: the producer; the field exists so federation can generalize it).
• Producer / Log operator / Witness / Verifier — as conventionally understood; the operator MAY be the producer, but the witness MUST be independent of both.
• Checkpoint — a signed commitment to log state {log_id, tree_size, root_hash, checkpoint_time}; a checkpoint C commits exactly the entries with index in [0, tree_size(C)). Entry index — the entry’s immutable position in the log — the ordering primitive for every “before”, “after”, “latest”, and checkpoint-membership rule in this specification. Log-attested incorporation time (LIT) — the log’s timestamp for an entry; AHL’s transaction time, for evidence purposes only. LIT is never used for ordering: logs are not required to assign monotonic or unique timestamps.
• Trigger — a retraction or correction statement.

2. Cryptographic Primitives

To ensure interoperability and security, implementations MUST adhere to the following cryptographic standards.

2.1. Hashing Algorithm

All hashing operations MUST use SHA-256 [RFC6234]. In text representations (JSON), hashes MUST be encoded as lowercase hexadecimal strings prefixed with sha256:.

Example: "sha256:a1b2c3d4..."

2.2. Digital Signatures

Statement signatures MUST use Ed25519 (EdDSA over Curve25519) [RFC8032]. In text representations (JSON), signatures MUST be encoded as standard Base64 strings prefixed with base64:.

Example: "base64:SGVsbG8gV29ybGQ..."

2.3. Canonicalization

To ensure deterministic hashing, all JSON objects — statement payloads, envelopes, manifests, tree leaves — MUST be canonicalized according to the JSON Canonicalization Scheme (JCS) [RFC8785] before being hashed.

2.4. Keyed Commitments

For datasets containing personal or sensitive data, record commitments MUST use HMAC-SHA-256 [RFC6234] keyed by a producer-held dataset key, rather than a bare hash. §3.4 defines the two commitment modes (plain, keyed) and their exact formulas.

Example: "hmac-sha256:9f86d081..."

3. Statements

3.1. Envelope, Identifiers, Signing

{ "payload": { ... }, "signatures": [ { "key_id": "<from manifest key set>", "sig": "<base64 Ed25519 over JCS(payload)>" } ] }

• Every statement MUST be signed, at every level. Unsigned objects are not AHL statements.
• Statement id = SHA-256(JCS(payload)): the reference used in the statement graph. Entry id = SHA-256(JCS(envelope)): the retrieval key for the anchored entry, and the reference used where signature or anchoring identity matters (manifest and key statements).
• A producer MUST NOT anchor two envelopes with the same statement id; if duplicates occur, the one with the smallest entry index governs and later ones are void.
• Anchoring commits the envelope, so LIT evidences the signature. DSSE wrapping MAY be used for interop (non-normative).

3.2. Common Payload Fields

{ "ahl_version": "0.3",
  "type": "ingestion | derivation | retraction | correction | propagation | manifest | key",
  "producer": "<producer id>",
  "manifest": "<manifest version id this statement is issued under (absent only in manifest statements)>",
  "valid_time": "<RFC 3339>" | { "from": "<RFC 3339>", "to": "<RFC 3339 or null>" },
  "issued_at": "<RFC 3339>" }

Three times per anchored statement, never conflated: valid_time (asserted domain validity), issued_at (asserted creation), LIT (evidenced incorporation time). Ordering always uses the entry index; LIT is evidence, not order. At L2 and above, a statement’s manifest MUST reference the manifest version active at the statement’s entry index — the manifest statement with the greatest entry index smaller than the statement’s own (§3.3.5); a mismatch is a conformance violation mechanically visible from log order. At L1 (unanchored), the binding is by signed reference to a published manifest version.

3.3. Statement Types

AHL defines seven statement types: ingestion, derivation, retraction, correction, propagation, manifest, key.

3.3.1. ingestion

Introduces a source record into the corpus. Every record referenced as an input MUST be introduced by exactly one anchored ingestion, or produced by an anchored derivation at a smaller entry index than its first use; consuming an unintroduced record is a coverage violation.

{ "type": "ingestion",
  "dataset": "<dataset id>",
  "record": "<record commitment>",
  "origin": "<optional non-personal descriptor: source system, batch reference>" }

The dataset authority declared in the manifest is the issuer of triggers for ingested records.

3.3.2. derivation

{ "type": "derivation",
  "pipeline": "<pipeline id from the manifest>",
  "outputs": [ { "dataset": "<dataset id>", "record": "<record commitment>", "locator": "<optional URI, no personal data>" } ],
  "inputs":  [ { "dataset": "<dataset id>",
                 "record": "<source record commitment — REQUIRED; what a trigger would name>",
                 "representation": "<digest of bytes actually consumed, if not the full record>",
                 "projection": { "descriptor": "<spec>", "digest": "<sha256 of JCS(descriptor)>" },
                 "role": "feature | reference | config",
                 "statement": "<optional statement id of the input's ingestion/derivation>" } ],
  "transform": { "code": { "digest": "<sha256>", "type": "git_commit | artifact | container" },
                 "model": { "digest": "<sha256>", "version": "<label>" },
                 "params": { "digest": "<sha256 of JCS(params)>" },
                 "environment": "<optional digest, e.g. SLSA provenance>" } }

Closure traversal uses (dataset, record) only; representation and projection narrow what was consumed, never identity. The statement MUST list every input record read for these outputs, or use a batch (§3.5).

A derivation MUST NOT consume a record for which an effective trigger (§3.3.3) is anchored at a smaller entry index; doing so is a conformance violation, mechanically detectable from log order. In the closed-corpus core, the semantic revocation horizon is zero entries: a derivation anchored at an entry index greater than an effective trigger’s index MUST NOT consume that record — this does not assert zero wall-clock latency from trigger submission to producer observation. A parameterized horizon for foreign triggers is a federation-extension concept (Appendix C).

3.3.3. retraction and correction

{ "type": "retraction",
  "dataset": "<dataset id>", "record": "<record commitment>",
  "scope": { "effective_from": "<RFC 3339>", "retroactive": true|false },
  "reason_code": "error | fraud | legal_obligation | consent_withdrawn | superseded | other" }
 
{ "type": "correction",
  "dataset": "<dataset id>", "record": "<old commitment>", "replacement": "<new commitment>",
  "scope": { ... }, "reason_code": "..." }

scope is REQUIRED; scopeless triggers are malformed. retroactive: true: every derivation consuming the record is affected regardless of valid time. retroactive: false: affected iff the derivation’s valid_time intersects [effective_from, ∞).

A trigger anchored at a smaller entry index than the record’s introduction is never effective: authority cannot predate the introduction that creates it. Authority: a trigger is effective only if signed by the record’s authority — the dataset authority for ingested records; for derived records, the introducing producer’s key set as of the trigger’s entry index (key rotation between introduction and trigger applies). Triggers from other keys anchor as challenges: surfaced by verification, never traversed.

A correction’s replacement MUST be introduced at an entry index no greater than the correction’s. Among effective triggers for one record, the greatest entry index governs; verifiers surface the chain.

3.3.4. propagation

{ "type": "propagation",
  "trigger": "<statement id>",
  "corpus_checkpoint": { "log_id": "...", "tree_size": n, "root_hash": "..." },
  "affected_root": "<root over disposition leaves, §3.5 tree rules>", "affected_count": 12,
  "complete_relative_to_manifest": true }

Disposition leaf (JCS): { "dataset", "record", "disposition": "invalidated | recomputed | assessed_unaffected", "successor_statement": "<REQUIRED for recomputed; its inputs MUST include the correction's replacement>", "assessment": "<REQUIRED for assessed_unaffected; sha256 of retained assessment artifact>" }.

invalidated is operational: the producer MUST NOT rely on or serve the record for covered purposes. Completeness of a propagation is defined at its declared corpus checkpoint D. §3.3.2 prohibits consuming the triggered record itself after the trigger, but a later derivation MAY consume an already-affected descendant, enlarging the transitive closure beyond D — closure is therefore not stable across later checkpoints, and completeness claims never extend past D.

3.3.5. manifest

The manifest statement payload IS the manifest object itself (§8.2 fields at top level; no wrapper key). The manifest version id — what every statement’s manifest field references — is the manifest statement’s statement id; a non-genesis manifest references its predecessor by entry id in a REQUIRED predecessor field (forbidden for genesis). The genesis manifest is the corpus trust anchor: its entry id and initial key fingerprints are distributed out-of-band. Each subsequent manifest statement MUST be signed by a key valid under the previous manifest version and references it by entry id — the manifest lineage is an anchored chain, and “the manifest version active at entry index i” is mechanically resolvable from the log.

3.3.6. key

Key-set transitions: { "type": "key", "action": "add | retire", "key": { "key_id", "pubkey", "valid_from" } } — signed by a currently valid key, anchored. Statements verify against the key set as of their entry index. For producer keys, key_id is sha256: plus lowercase hex SHA-256 of the raw 32-byte Ed25519 public key. Producer-key compromise recovery is an open issue (see FAQ — What is not specified yet?); until specified, compromise invalidates conformance claims from the compromise time forward.

3.4. Record Identity, Canonicalization, Privacy Modes

Per dataset, the manifest declares canonicalization and a commitment mode:

• plain: commitment = SHA-256( dsid ‖ 0x1F ‖ canonical bytes ), where dsid is the dataset id — domain separation makes identical bytes in different datasets distinct commitments.
• keyed (REQUIRED for personal or sensitive data): commitment = HMAC-SHA-256( k_dataset, dsid ‖ 0x1F ‖ canonical bytes ). k_dataset is held by the producer and disclosed under the manifest’s access rule to authorized verifiers.

One mode and one canonicalization per dataset, used by all statement types referencing that dataset. JSON canonicalizes per RFC 8785; non-JSON as exact bytes plus media type; other formats per a canonicalization registry. Projections never create identity; cross-corpus identity is federation’s subject (Appendix C).

Erasure: erasing record bytes while retaining statements preserves the evidence graph without the data. In keyed mode, destroying k_dataset prevents any future mapping of commitments to content — anchored equality relations among commitments remain visible; key destruction limits content recovery, it does not unlink history.

3.5. Batching and Tree Rules

Batch derivation: outputs_root, outputs_count, and leaf_format: "ahl-leaf-v2" are top-level members of the derivation payload, replacing outputs. Leaf v2 = JCS of { "dataset", "record", "inputs": ... }, where inputs is EITHER the full array of input objects OR the input-set form { "input_set_root", "input_set_count" }.

Tree rules for all AHL trees (outputs, input sets, dispositions): SHA-256; domain separation 0x00‖leaf / 0x01‖left‖right; leaves sorted by record (ascending lexicographic comparison of the UTF-8 bytes of the canonical commitment string); duplicates prohibited; membership proofs O(log n). Retrievability: the full leaf set of every committed tree is corpus material — retention and enumeration duties per §4.5 and §8.

4. Log Binding

AHL defines a log-binding contract; a log satisfies it via a published adaptor profile (pinned in the manifest). RFC 9162-class designs (CT logs, Rekor, ATL) are expected to satisfy it via thin adaptors — a feasibility claim, assessed per adaptor, not a conformance grant.

Contract:

1. Append-only; entries are opaque bytes; LIT recorded per entry.
2. Signed checkpoints at a declared cadence; log keys discoverable via the manifest.
3. Inclusion proofs (entry → checkpoint) and consistency proofs (checkpoint → checkpoint).
4. Retrieval by entry id.
5. Authenticated enumeration: serve entries [i, j) under a checkpoint with proof of completeness and order (Merkle range proofs) — a verifier can walk the whole log, or any interval, and know nothing was skipped.
6. Proof and checkpoint serialization per the adaptor profile. Adaptor profiles MUST be versioned, immutable, content-addressed (identified by name + hash), openly published, and independently implementable; the profile id and hash are pinned in the manifest and carried in every Evidence Receipt.

4.3. Witness Protocol (L3)

Inclusion and consistency proofs establish consistency only within the view shown — split views remain possible. L3 requires at least one independent witness per log, operating this state machine:

1. The witness retains, per log, the latest checkpoint it has cosigned.
2. On receiving a new checkpoint (at declared cadence): verify the log’s signature; verify a consistency proof from the retained checkpoint; on success, cosign, retain, and publish via a stable query interface.
3. On failure — inconsistency or missing proof — the witness MUST refuse to cosign and MUST publish signed refusal evidence containing both conflicting checkpoints.
4. Freshness: a witness whose latest cosigned checkpoint is older than the declared cadence by more than the declared grace period is stale; verifiers treat staleness as a finding.

Verifier algorithm at L3: accept a checkpoint C only with a valid witness cosignature; verify consistency from C to the latest witnessed checkpoint. Equivocation is thereby detectable; refusal evidence is self-authenticating.

Claim discipline: L3 reduces operator trust to detectability of misbehavior — service refusal remains possible and visible. AHL documents MUST NOT claim “no trust required”.

4.5. L3 Availability

At L3, digest-only anchoring is prohibited: entries MUST be retrievable (by id and by enumeration) from the log or an independent mirror outside producer control. The complete leaf material of every committed tree (§3.5) MUST be published to the log or to an independent mirror outside producer control, retrievable and enumerable in full with authenticated binding to the anchored root, for the retention period — closure recomputation MUST NOT depend on producer cooperation.

A verifier can therefore reconstruct the complete corpus up to any witnessed checkpoint without the producer’s cooperation for entries, and with mechanically checkable completeness for tree material.

5. Point-in-Time Reconstruction

Parameterized by an as-of checkpoint C (knowledge boundary: statements with entry index < tree_size(C)) and a valid time T (domain time asked about); the answer is “as known at C, about T”.

1. Fix C (witnessed). Enumerate statements about record (ds, r) with entry index < tree_size(C): its ingestion or derivations; effective triggers naming it or, transitively, its inputs.
2. Effective status for T at C: apply triggers whose scope covers T; among conflicting effective triggers committed by C, the greatest entry index governs. Corrections anchored beyond C are invisible at C by construction; re-running at C′ > C shows knowledge evolution.
3. Resolve the asserted derivation context: input commitments, representations, transform digests — under the manifest version each statement references.
4. Verify all of it: signatures (key set as of each statement’s entry index), inclusion against C, consistency C → latest witnessed checkpoint, manifest lineage back to genesis.

Boundary: reconstruction yields the evidenced assertion set. Reproducible reconstruction is an optional manifest-declared property requiring retention and retrieval of referenced artifacts (code, model, params) and canonical input/output bytes for a declared period; erasure of any required content terminates the property for the affected records, and reconstruction results MUST report it as terminated, not silently degrade. AHL always proves which artifacts are required and detects substitution; it cannot conjure unretained bytes.

6. Revocation and Propagation

6.1. Affected Set

For an effective trigger on (ds, X) with scope S, at checkpoint C committing the trigger: the transitive closure over derivations with entry index < tree_size(C) whose inputs match (ds, X), then their outputs’ consumers, and so on — filtered by S. For a retraction on (ds, X), the seed set is exactly {(ds, X)} — retractions never seed superseded replacements. Correction supersession: a correction X→X_new never adds its own replacement X_new as a closure seed; if a later correction of the same original X supersedes an earlier correction X→X_old, the later correction’s closure seeds include X and every prior superseded replacement X_old. The trigger’s scope applies to every seed.

6.2. Obligations

L3: within the declared propagation window from the trigger’s LIT — compute the affected set at a checkpoint committing the trigger; disposition every member with evidence; anchor the propagation statement. Completeness is relative to the declared checkpoint D; later consumption of affected descendants may enlarge the closure past D and creates fresh propagation duties for the enlarged set.

L2: MUST anchor its own triggers; carries no closure duty; claims MUST state “revocation recorded, not propagated” verbatim.

6.3. Completeness — Relative, and Honestly So

A verifier reconstructs the corpus up to the declared checkpoint (§4.5 makes this possible without producer cooperation), recomputes the affected set, and compares against the disposition tree. Both computations run over the same anchored statements: disagreement is decidable.

What this does not establish: that derivations outside the corpus don’t exist. That is the manifest’s coverage assertion — auditable by comparing declared inclusion and exclusion lists against the organization’s actual systems. AHL converts “is propagation complete?” into two separable questions: complete relative to the declared corpus? (cryptographically checkable) and is the declared corpus the real corpus? (auditable scope assertion).

6.4. Cycles

Derived attributes feeding later training data create cycles; the statement graph makes them visible. Closure MUST detect cycles, MUST NOT loop, and dispositions each record once. Producers SHOULD surface cycles: a cycle means apparent independent corroboration may be self-derived.

7. Verification

With the genesis trust anchor and the manifest lineage, a verifier checks: signatures; content bindings (in plain mode by recomputation; in keyed mode only by authorized verifiers holding the dataset key — unauthorized verifiers still verify signatures, anchoring, graph structure, and propagation completeness, since those operate on commitments); anchoring and history integrity (inclusion, consistency, witness cosignatures); trigger authority; closure completeness (§6.3); reconstruction (§5). Monitors — standing verifiers mirroring checkpoints and watching triggers — are RECOMMENDED assurance practice in core; cross-producer observation protocols are federation.

7.5. Evidence Receipts (.ahl)

The normative container format is a companion document (claim-type registry, governance currency modes, verification algorithm, test-vector layout) — see Data Structures for the wire format and Reference Implementations for tooling.

The AHL Evidence Receipt is the primary portable verification artifact: a versioned, JCS-canonical container proving a declared claim offline, years later, without access to the producer or log. Every receipt declares its claim type and boundary — a receipt proves exactly what it claims, nothing more.

8. Conformance

8.1. Levels

8.2. Corpus Manifest

Anchored as a manifest statement (§3.3.5); a machine-readable payload containing at minimum: producer id; key set; log (id, operator, adaptor: {id, hash}, checkpoint cadence, witness_grace_period, and the log’s checkpoint-signing key objects {key_id, pubkey, valid_from_index}); witnesses at L3 (witness ids with key objects, same form; log and witness key rotation happens by anchoring a new manifest version); datasets (id → canonicalization id, commitment mode, key-access rule, dataset authority as { "producer": "<id>", "key_ids": [...] } — an ingestion into an authority-less dataset is invalid); pipelines (covered transforms as inclusion and exclusion lists — the scope boundary); windows (anchoring; propagation); retention (statements; artifacts if reproducible reconstruction is claimed); level and optional properties.

A manifest’s producer keys array is the complete producer-key snapshot effective from that manifest’s entry index: it discards the prior snapshot; later key statements then modify it in entry order until the next manifest version. Statements bind to their manifest version (§3.2); scope games are visible on the face of the manifest chain.

9. Security and Privacy Considerations

Security: producer key security (compromise recovery is open, see FAQ — What is not specified yet?); log integrity — consistency and the witness protocol make rewriting and split views detectable, and refusal of service visible; coverage — manifest inclusion and exclusion lists turn silence into auditable misstatement.

Privacy: statements carry commitments, not content; keyed mode is mandatory for personal data (defeats dictionary attacks; confines content mapping to key holders; key destruction stops future mapping but anchored equality relations remain); locators and projection descriptors MUST NOT embed personal data; erasure composes with immutability — erase bytes, keep commitments; the reproducible-reconstruction property terminates where erasure occurs. Residual risk: commitment linkability within authorized sets; volume traffic analysis.

Appendix C. Federation extension (planned, non-normative)

Out of scope for core conformance. Outline only — not implementable from this text.

• Cross-corpus record identity: commitment translation across keyspaces without content disclosure.
• Recipient-bearing disclosure and receipt statements, carrying the Privacy Act § 552a(c) accounting mapping.
• Evidenced observation of foreign triggers (receipt checkpoints, monitor attestations).
• A revocation-visibility horizon: the normative maximum staleness of a consumer’s view of foreign logs, after which consuming a retracted record is a violation (analogous in role to Certificate Transparency’s Maximum Merge Delay; parameterized by conformance level).
• Cross-manifest propagation obligations.

Constraint inherited from core: every cross-boundary claim names whose corpus it is relative to.