FAQ
General Questions
Why not just use a lineage catalog (OpenLineage, DataHub, Atlas)?
Lineage catalogs track derivation between datasets and columns, as mutable metadata populated by what a pipeline asserts about itself. That answers “which tables feed this table” — it does not answer “was this specific record’s derivation claim tamper-evident, and can I prove a retraction reached every downstream record that used it”.
AHL is complementary, not a replacement: it operates at record granularity, binds statements to content by digest, anchors them in an append-only verifiable log, and defines closure semantics for retractions. A lineage catalog can sit on top of an AHL corpus as a human-facing index; AHL is the evidence layer underneath it.
Why a pluggable log instead of shipping one specific product?
Because the protocol should be citable and implementable by anyone, and because conformance must not depend on trusting one vendor. AHL defines a log-binding contract (append-only, inclusion and consistency proofs, authenticated enumeration at L3) — any log satisfying it conforms. ATL is one example alongside RFC 9162-class transparency logs (Certificate Transparency, Rekor). This is also a constitutional constraint: an independent operator must be able to run a conforming log, witness, mirror, or verifier without asking permission.
Is this a new ATL?
No. ATL is a general-purpose cryptographic transparency log: append-only entries, inclusion proofs, consistency proofs, external anchoring. AHL is a domain protocol built on top of that class of primitive — it defines what a data-provenance statement looks like, what a producer’s obligations are when a source is retracted, and how to verify all of it. AHL can anchor into ATL, but it does not require ATL specifically; any conforming log works.
| Layer | Protocol | Question it answers |
|---|---|---|
| Derivation | AHL — Anchored History Log | ”What was this record asserted to have been computed from — and was every downstream derivative dispositioned within the declared corpus when it was retracted?” |
| Observation | APL — Anchored Parallax Log | ”What was observed, and under which methodology?” |
| Journal | ATL — Anchored Transparency Log | ”Was this recorded then, and has the history been rewritten?” |
Guarantees and Boundaries
What does L3 conformance guarantee?
At L3: statements are anchored with inclusion and consistency proofs; at least one independent witness cosigns checkpoints, making split-view and equivocation by the log operator detectable; entries and committed tree material are retrievable and enumerable without the producer’s cooperation; and revocation propagation obligations are met within the declared window, with completeness mechanically checkable by any verifier who reconstructs the corpus.
What does L3 NOT guarantee?
L3 does not guarantee that any statement is true, that unstated derivations do not exist outside the declared corpus, or that the log operator cannot refuse service. L3 reduces trust in the log operator to detectability of misbehavior — it does not eliminate the need for trust. AHL documents are required to say this explicitly; “no trust required” is not a claim the protocol supports.
Do I need to trust the producer’s database?
For the claims a receipt makes, no — verification runs against anchored, signed statements and witnessed checkpoints, not the producer’s internal state. What you do need to trust, and what AHL makes explicit rather than hidden, is the manifest’s declared scope: which pipelines and datasets are actually covered. AHL converts “is this complete?” into two separable questions — complete relative to the declared corpus (cryptographically checkable) and is the declared corpus the real corpus (an auditable scope assertion, not a cryptographic one).
What happens if a “complete” propagation claim is challenged?
A verifier reconstructs the corpus up to the propagation’s declared checkpoint D, recomputes the affected set independently, and compares it against the producer’s disposition tree. Both computations run over the same anchored statements, so disagreement is decidable — not a matter of taking anyone’s word for it. What it will never tell you is whether the corpus itself was scoped honestly; that’s an audit question about the manifest, not a verification question about the receipt.
Technical Details
Why does keyed commitment mode exist, and when is it required?
keyed mode (HMAC-SHA-256 with a producer-held dataset key) is REQUIRED for datasets containing personal or sensitive data. plain mode (a bare SHA-256 commitment) is invertible by dictionary attack against enumerable input spaces — an identity number or a small set of known feature values is guessable. keyed mode confines content-to-commitment mapping to holders of the dataset key, while still letting anyone verify signatures, anchoring, graph structure, and propagation completeness, since those operate on commitments alone.
Does destroying the dataset key erase history?
It stops future mapping of commitments back to content — but anchored equality relations among commitments remain visible. If two statements reference the same commitment, that fact stays provable even after the key is destroyed; only the ability to recover what the commitment represents is lost. Key destruction composes with erasure: erase the record bytes, keep the statements, and the evidence graph survives without the data.
Why is ordering always by entry index, never by timestamp?
Because logs are not required to assign monotonic or unique timestamps, and a producer could otherwise game an “as of” claim by asserting a favorable issued_at. AHL statements carry three separate time fields — valid_time (asserted domain validity), issued_at (asserted creation), and log-attested incorporation time (evidence only) — but every “before”, “after”, “latest”, and checkpoint-membership rule in the protocol resolves strictly from the entry’s position in the log.
What is not specified yet?
This is a working draft (v0.3), not for implementation. Publication gates for a public draft, in order: (1) the .ahl Evidence Receipt container format finalized; (2) test vectors published (all seven statement types, batch/input-set/disposition trees, closure computation over a published toy corpus, witness refusal evidence, and receipts for every claim type including a governance completeness proof); (3) at least one end-to-end log adaptor profile, published content-addressed. Open issues carried into 0.4 include canonicalization-registry entries, signature-algorithm agility, producer-key compromise recovery, multi-log anchoring, and formal privacy analysis of commitment linkability. Federation (cross-producer identity, disclosure accounting, foreign-trigger observation, a revocation-visibility horizon analogous in role to CT’s Maximum Merge Delay) is a planned, non-normative extension — every cross-boundary claim will name whose corpus it is relative to.
What is explicitly out of scope for AHL Core?
Cross-producer federation: translating record identity across different producers’ keyspaces without disclosing content, recipient-bearing disclosure statements (for accounting obligations like Privacy Act § 552a(c)), evidenced observation of a foreign producer’s triggers, and a revocation-visibility horizon for consuming records across corpus boundaries. These are a planned, non-normative extension (Protocol Appendix C) — AHL Core specifies the single-producer, single-log, single-keyspace case only. AHL Core also does not determine whether a legal notice is required, select notice recipients, or generate compliance narratives — it produces the evidence such decisions can be built on top of.
What happens when a source record is corrected?
A correction statement anchors, naming the old commitment, the new commitment, and a scope. From that entry index forward, deriving anything from the old record is a conformance violation, mechanically detectable from log order. At L3, the producer must compute the transitive closure over every derivation that consumed the old record (and their consumers, and so on), disposition each one — invalidated, recomputed with a successor statement, or assessed_unaffected with a retained assessment — and anchor a propagation statement, all within the declared window. Any verifier can independently recompute that closure and check it against the disposition tree.