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, through a published, content-addressed adaptor profile. 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.

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; every governance-key rotation is attested under the outgoing log and witness states; 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.

Nor does the governance-key rotation rule establish that a producer’s incoming witnesses are independent. A cosigning witness attests log state, not the merits of its successors, so a producer that openly rotates to witnesses it controls — with the outgoing set’s cosignature on the anchoring — produces conforming material. The rule converts an undetectable substitution into a detectable and attested one; witness independence remains a declared property assessed against the verifier’s own trust policy (Protocol §8.3).

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.

What does a verifier report when it simply cannot tell?

unverifiable — one of the three values a completed run reaches, alongside verified and invalid (Protocol §7.7). The division is not stylistic. A defect decidable from the receipt’s own bytes is invalid, and every verifier decides it alike in every year; a capability the verifier lacks, a local configuration it was not given, or a local budget it set is unverifiable, because those are properties of the verifier and not of the artifact. Reporting one as the other would let two verifiers make contradictory statements about one artifact. A run also reports the per-assertion findings it reduced from, and an invalid result never asserts the negation of a historic fact: it says this artifact does not verify, not that the subject was never anchored.

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 SHA-256 commitment over the same preimage) 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.

Both modes commit to the same preimage, dsid || 0x1F || ddig || 0x1F || canonical bytes, where ddig is the digest of the dataset’s canonicalization descriptor (Protocol §2.6). Binding the descriptor means a verifier can check the descriptor it was handed by recomputation instead of assuming it is the one the commitment was computed under — detection, not disclosure.

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.

One consequence is worth planning for rather than discovering: a receipt asserting a content binding carries the record’s bytes as received, so it discloses the record to everyone who holds it, travels further than the system that issued it, and is outside the reach of an erasure workflow that accounts only for primary storage (Protocol §9).

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 the publication status?

The specification is at revision 0.4 of the Internet-Draft draft-zatona-ahl-00, which is self-contained and is the sole conformance source: it folds the Evidence Receipt container into its own §7. Revision 0.4 is a clean break — it defines no verification of material issued under any earlier revision, and a corpus anchored under one cannot be continued under this one.

The reference implementation is published on crates.io under Apache-2.0, with sources at github.com/evidentum-io: ahl-core 0.5.0, ahl-cli 0.4.1, ahl-mirror 0.3.2, ahl-witness 0.4.1. ahl-core ships a deterministic conformance corpus — regenerated from committed constants, verified from disk on every test run, and required to be byte-identical across two consecutive generator runs (see Test Vectors). The ATL adaptor profile ahl-adaptor-atl-v1 is released as an immutable, content-addressed artifact. An end-to-end pilot on a live ATL log passed; the harness is ahl-cli’s end-to-end test suite (tests/e2e), which anchors statements in a scratch atl-server, publishes through ahl-mirror, collects ahl-witness cosignatures and verifies the receipts it issues.

What is still open:

1. IETF submission of the Internet-Draft. The document has not been submitted.
2. Publication of the proofs artifact. The three invariants are machine-checked in Lean 4 (Protocol §8.7); proofs artifact to be published.
3. A deployment-side canonical checkpoint series. Adaptor profile §16 obligation 4: a published, gap-free, cadence-conforming, series-usable checkpoint series is a duty of the deployment, and nothing in the published ATL stack publishes one. Without it a propagation window has no determinable start.
4. The witness submission and retrieval protocol. Adaptor profile §17 question 7: the profile does not specify how a checkpoint and the authenticated entry and governance material a witness needs reach it, so it does not yet define an independently implementable L3 witness. To be specified before an L3 conformance claim.

The profile’s own §15 conformance statement records the rest clause by clause, including one property that must be accepted rather than built: ATL attests no per-entry incorporation time. The best available substitute is a deterministic upper bound, and whether an L3 propagation window may be measured from it is a decision for the core, not for the profile.

What is not specified in revision 0.4 itself?

Distinct from the publication items above, the I-D names its own boundaries: recovery from producer-key compromise is not specified, and until it is, a compromise invalidates conformance claims from the compromise time forward (§2.4.6, §8.2); algorithm agility, including posture toward post-quantum signatures, is not specified in this revision (§8.1); whether consuming a record dispositioned invalidated is itself a violation is an open issue in the core (§2.4.4); and a formal analysis of commitment linkability, with guidance for erasure workflows, remains open work (§9).

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 foreign-trigger observation horizon for consuming records across corpus boundaries — analogous in role to CT’s maximum merge delay. These are future work (Protocol Appendix A); the core specifies the single-producer, single-log, single-keyspace case only. AHL also does not define authorization, tenancy, account management or key distribution, and 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.

The seeds themselves are never members of the affected set: a seed is the record the trigger acts on, and the affected set is what derives from the seeds, transitively (Protocol §5.1).