ZAMBO.

Bad chain link: an entry does not point at the entry before it.

An AER-1 timeline chains its entries: each entry carries a prev_digest that must equal the SHA-256 digest of the previous entry's canonical bytes, starting from a genesis value of 64 zeros. When a link does not match, the timeline was evaluated and the chain check did not pass: verification failed. The evidence below is the published chain vector files, read first-hand.

Evidence on this page was fetched first-hand from zambo.dev on 2026-10-24. Part of the failure patterns index.

The evidence

chain-vectors.json: chain-tampered-middle

The Section 7 chain file (chain-vectors.json, 7 vectors, file SHA-256 10de1cadb45b8d5c91ae94a601c6bb567aab59b26e89abbbb64af6896d3aba19) states the construction in its own spec line: entry digest is SHA-256 over the base64-decoded canonical bytes, prev_digest links entries, genesis prev_digest is 64 zeros, and the timeline must end with a closing entry carrying close=true. Its vector chain-tampered-middle (entries 9ca6d090-b769-4178-a590-0bf1d5e02e06, 57eeec6c-0026-4cae-aa90-c5ac08947ab4, 0af6a982-33cc-47d8-8343-b405a9082447) has expected verdict invalid and the expected failure, verbatim: "entry2 prev_digest does not match digest of entry1 bytes (link broken)". The middle entry's bytes were altered after its digest was committed into the next entry, and the link is what catches it.

The rest of the invalid chain cases in the same file

  • chain-reordered: invalid, "link broken (prev_digest mismatch in timeline order)".
  • chain-bad-genesis: invalid, "entry0 prev_digest is not genesis (64 zeros)".
  • chain-truncated-no-close: invalid, "last entry lacks close=true".
  • chain-close-wrong-type: invalid, "close is not boolean true".

chain-vectors-v07.json: the larger set

The earlier chain file (chain-vectors-v07.json, 28 vectors, file SHA-256 d72b815585afdb075311da892f54041c9ffd5e7d875afbf32bd8165c3ca9ea94) carries the same failure in several forms, each with expected verdict invalid and the failure "prev_digest does not match": v07-relabel-provenance, v07-relabel-tool-id, and v07-mixed-job-id, alongside contiguity breaks such as v07-seq-gap and v07-delete-identical-pair.

An honest limit: hosted receipt verification reports the chain as not checked

For Zambo hosted receipts, the public v2 verify endpoint reports its chain check as not_checked, with the detail that no append-only receipt-chain proof was checked. That is the Section 6 discipline working as designed: a checker that did not evaluate the chain says so, and never reports an evaluated outcome for an unevaluated check. The chain outcomes above come from the corpus runners, which do evaluate the timelines.

What the verifier reports

A timeline that was evaluated and whose links do not match is verification failed for the chain check. Individual entries can still pass their own digest checks: a chain failure says the sequence as presented is not the sequence that was committed, which is a fact about the set, not about any single receipt in it.

How to fix it

  1. Do not reorder, edit, or drop entries. Order is part of the commitment. A reordered timeline is a broken timeline, even with every entry present.
  2. Fetch the full timeline from genesis and confirm the first entry's prev_digest is 64 zeros and the last entry carries close=true.
  3. If a middle entry changed after commitment, only the original bytes restore the link. Ask the producer for the original timeline rather than recomputing prev_digest values to make a changed set fit: a relinked chain proves nothing about the original.
  4. Report per check. If your verifier does not evaluate chains, report the chain as not checked, the way the hosted verify endpoint does, and evaluate the entries on their own digests.

Put your own calls on a checkable record

Start at zambo.dev/add

Add Zambo to your AI at https://zambo.dev/add/. The free tier is 20 free calls per day, then they upgrade. A Day Pass is $0.99 for 24 hours. Every call returns a verifiable receipt, including a call that is rejected, so a failure like the ones on this page leaves a record you can open, check, and learn from instead of a claim you have to trust.

A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was right.

Questions

What is a bad chain link in an AER-1 timeline?

Each entry carries a prev_digest that must equal the SHA-256 digest of the previous entry's canonical bytes, with the first entry pointing at a genesis value of 64 zeros. When a prev_digest does not match, the link is broken and the timeline check reports verification failed. The corpus vector chain-tampered-middle states the expected failure verbatim: entry2 prev_digest does not match digest of entry1 bytes (link broken).

If one entry changes, does the whole chain fail?

The changed entry's own digest changes, so the next entry's prev_digest no longer matches, and the failure surfaces at that link. Entries before the change still check out on their own. That is the point of the construction: the location of the break is visible.

Does Zambo's public verifier check receipt chains?

For hosted receipts it reports the chain check as not_checked and says no append-only receipt-chain proof was checked. The evaluated chain outcomes on this page come from the published conformance corpus, whose runners evaluate the Section 7 timelines directly.