A document's history can prove its own order. Each new version carries the hash of the version before it, so anyone holding the latest version can prove that an earlier record came first, with no clock involved. This walkthrough animates that chain, shows what breaks when someone tries to insert a record after the fact, and then shows how the estate's real anchors add what a chain alone cannot carry: time.
Show that a forward-committing hash chain proves order by itself, that a later insertion breaks the chain visibly, and that anchoring the chain head to independent timestamp authorities is what adds time and a public witness on top of that order.
a3f9…. No hash here is a real digest of anything.Write down a record, then write the next record with the hash of the first inside it. Each record is linked by two fields: a key that names it and a hash that reaches back to the record before. Repeat, and the document's history becomes a chain where every link commits to the one behind it.
Every record reaches back into the one before it. The newest record, the head, now speaks for the whole history behind it.
A reader holds only the head of the chain and asks: did record A come before record B? No clock is needed. If A's hash is inside B, then A existed before B did, because B could not have contained A's hash otherwise. Hashes are one-way, so B could not have reached back unless A was already there.
Order falls out of the linking itself. Containment is the proof: a later record cannot name an earlier record's hash unless that record already existed.
Now the failure mode. Someone wants record m2 to look like it came between m1 and m3, after the fact. To fit, the forged record must carry m1's hash, and m3 must carry the forger's hash instead of the real one. Every hash after the insertion point has to change, and the head the reader holds no longer matches the rewritten history.
A late insertion is not silently refused; it is visibly fatal. Every hash from the insertion point to the head changes, so the head the reader already holds stops matching. The rewrite is visible to every reader who holds an older head.
A chain is only honest if appending to it is serialized: two writers must never extend the same head at once. One published design gives each identity or document exactly one coordinating object that accepts appends one at a time, so there is never a fork to argue about. This walkthrough shows that object as a design, not as a running AINumbers service. What such a coordinator sees is commitments and hashes only, never the record contents.
The coordinator is a traffic controller for appends. It decides the order, and because each entry carries the previous entry's hash, its ordering decisions are checkable by anyone holding the chain afterwards.
The idea of one durable, single-writer object per identity or document appears in the public essay on trust surfaces for worker platforms, which this page links in the final step. The estate has no code for such an object today.
A chain says what came before what, but not when. The estate's anchor service, anchor.ainumbers.co, stamps any hash you give it through three independent authorities: a Sigsum public log, RFC 3161 timestamp authorities, and OpenTimestamps anchoring into the Bitcoin blockchain. That service exists and runs today for any hash. Stamping a mark-chain head through it is the pluggable part, labelled here as a design.
After the stamp, the chain carries both answers. Its links prove the order of the records inside it, and the anchored head proves that the whole chain, in that order, existed by a moment the outside world can check.
Keep the two claims apart and each stays checkable. The chain alone answers "which came first" with no trusted clock. The anchors alone answer "no later than when" with independent witnesses. Together, a reader gets ordered history with a verifiable lower bound on when each ordering existed.
| Claim | Who proves it | What is needed | Status |
|---|---|---|---|
| Record A came before record B | The chain itself: B carries A's hash | Only the head, and one-way hashes | the mechanism, described from BCR-2025-001 (beta) |
| An append could not be rewritten unnoticed | The head the reader already holds | A reader who keeps old heads | the mechanism, described from BCR-2025-001 (beta) |
| The chain existed by a point in time | The anchors: Sigsum, RFC 3161, OpenTimestamps | A stamp on the head | the estate does this today, for any hash |
| Records inside one artifact are ordered | OpenChainGraph parent_hashes | Artifact structure alone | the estate does this today |
| A mark-chain head stamped by the anchors | The anchors, over a chain head | Code the estate does not have yet | how it could plug in, a design |
Two pieces of this picture are real today. First, every hash can be stamped through anchor.ainumbers.co by Sigsum, RFC 3161 and OpenTimestamps, which is how the estate's anchor bindings and receipt trees get their "no later than" force; see the ten live runs sealed under one timestamp for a real anchored artifact. Second, OpenChainGraph artifacts already carry their own ordering in parent_hashes: a step cites the hash of the step before it, the same forward-committing idea this page animates, running inside the estate's artifacts today. The mark-chain itself, and one coordinating object per document, are the estate's nearest unplugged surfaces: no provenance-mark or durable-object code exists in the estate today, so both are presented here as designs.