Provable Provenance: How an Append-Only Ledger Makes History Checkable
Anyone can claim they knew something on a date. A provable record is one an outsider can verify — append-only storage, real timestamps, and third-party archives that would expose a backdated lie. Why we can prove when we knew things.
Published August 20, 2026
Anyone can say they saw it coming. The valuable thing — and the rare one — is a history an outsider can check. Provenance is the record of where a decision came from: who proposed it, who ruled on it, on what evidence, and when. Make that record append-only and anchor it against sources you do not control, and “we knew this then” stops being a claim and becomes a fact someone else can confirm.
Provenance is a chain, both directions
In the standards world, provenance is the record of the entities, activities, and people involved in producing something. In an agent ledger it runs both ways: from any verdict you can walk back to the exact dated data a seat sensed and the reasoning that drafted the proposal; from any piece of data you can walk forward to everything it ever caused. The chain is only as good as its links, and the links are only trustworthy if they cannot be edited after the fact.
Append-only is what makes it evidence
Our business record is append-only: corrections are new rows, never overwrites. A number that was wrong on Tuesday and fixed on Friday shows both, in order, forever. This is the same property that makes a ledger different from a log — you can add to history but you cannot quietly rewrite it. Without it, provenance is just a story with timestamps you are asked to believe.
The archive we don't control is the point
Here is the honest version of “we can prove when we knew things.” We do not fabricate publish dates, and not merely because it would be wrong. Third-party archives — the Internet Archive, Common Crawl — snapshot the public web on their own cadence, and they do not answer to us. A backdated claim that disagrees with those snapshots is exposed by anyone curious enough to look. For the one company whose product is an unfakeable record, a single caught fake date would hand the whole thesis to a rival as a story. So the archive we do not own becomes our strongest witness.
Why this is a competitive moat, not a compliance feature
A rival can copy a feature list overnight. It cannot copy a dated, externally-corroborated history it did not accumulate. Provable provenance compounds: every honest, timestamped verdict and refusal makes the next claim more credible and the archive harder to fake around. The moat is not the code — it is the accumulated, checkable past. That is why we publish the receipts, and why the honesty rails that produce them are enforced as code rather than promised in a deck.
Questions founders ask
- What does "provable provenance" mean for an AI agent?
- It means the origin and timing of every decision can be verified by someone who does not trust you. Provenance answers who proposed an action, who decided it, on what evidence, and when — and "provable" means those answers are anchored in an append-only record and, where it matters, corroborated by external sources like public archives. It is the difference between saying "we knew this in July" and being able to show it.
- Why does append-only storage matter?
- Because a record you can silently edit is not evidence — it is a draft. Append-only storage means corrections are new rows, never overwrites, so the history of what was believed and when is preserved even after it changes. That property is what lets a verdict, a prediction, or a refusal stand as proof later: no one, including us, can reach back and quietly rewrite what the ledger said.
- Couldn't you just backdate your records?
- We could set a field to any date we liked — and it would be a catastrophic thing to do, which is exactly why the architecture matters. A company whose entire pitch is an unfakeable ledger cannot afford one exposed fake date. Independent archives such as the Internet Archive and Common Crawl snapshot the public web on their own schedule; a claimed date that contradicts those snapshots is caught by anyone who looks. So we do the stronger thing: publish honestly and let the checkable trail carry the weight.
- How is this different from a normal database log?
- A normal log is mutable and internal — useful for debugging, worthless as proof, because the party who owns it can change it. Provable provenance requires the record to be append-only and, ideally, cross-checkable against sources you do not control. The claim is not "trust our logs"; it is "here is a record structured so that you don't have to."