An OpenChainGraph artifact already carries a hash any reader can recompute. This page walks the layer above that hash: the anchor bindings of SPEC.md §20, portable evidence that the artifact's bytes existed by a point in time, carried in a transparency log or a timestamp authority. Every hash and timestamp quoted here comes from records already published on this estate, read at commit 63999678 on 5 October 2026, and each step names where you can verify it offline.
What an anchor binding attests, the four evidence types the standard accepts, and the batch form that lets one timestamp cover many artifacts.
An artifact may carry a top-level anchor_bindings array, and each entry is one piece of evidence that its execution_hash was included in a transparency log or signed by a timestamp service by a point in time. The binding attaches after hashing and is excluded from the hash preimage, so anchoring an artifact never moves its hash. The standard states the semantics plainly (SPEC.md §20.1): a binding proves existence of the artifact bytes by a time and inclusion in the named log. Whether the computation itself was correct is a separate question with its own section of the standard, and so are authorship and kernel identity; each claim verifies independently.
Nothing about the evidence is estate-specific. The four evidence types are public formats, the verification procedures are the standards' own, and a verifier needs no AINumbers server to check any of them. An RFC 3161 token's DER bytes are stored verbatim, never re-encoded, so openssl ts -verify keeps working without this estate.
An OpenChainGraph artifact carries an anchor_bindings entry. State the two things that binding proves and name the claims it leaves to other sections of the standard.
The standard accepts four evidence types in an anchor_bindings entry, and each one verifies under its own published procedure.
| Type | What it holds and how it verifies |
|---|---|
| rfc3161-tst | a token from an RFC 3161 timestamp authority: the token's message imprint must match the hash, the CMS signature over the timestamp data must be valid, the signer must chain to a verifier-pinned authority root, and the signing certificate must carry the critical timestamping EKU |
| opentimestamps | a proof that completes against Bitcoin block headers alone, with no signature anywhere in its attestation path |
| c2sp-tlog-proof-v1 | a checkpoint signature against the log's public key plus a Merkle inclusion proof for the leaf that commits the anchored hash |
| scitt-receipt-rfc9942 | a COSE receipt per RFC 9942, accepted as an evidence type for interoperability |
One artifact can carry several bindings at once: several timestamp authorities plus an OpenTimestamps proof, and redundancy across independent authorities and algorithms is the recommended posture (RFC 4998). Whatever the mix, every binding anchors the same value: anchored_hash must equal the artifact's recomputed execution_hash, and a verifier rejects any binding where it differs.
Name the four anchor evidence types the OpenChainGraph standard accepts and say what each one verifies against.
A timestamp per artifact would not scale, so the standard lets one timestamp cover many. A binding may carry a merkle_inclusion member: the anchored value is the root of an RFC 6962 Merkle tree and each covered artifact's execution_hash is a leaf, so a verifier rebuilds the root from the leaf hash plus the inclusion path and requires the result to equal anchored_hash. On top of that, a batch anchor may carry witness_cosignatures: independent k-of-n cosignatures over the root in the C2SP signed-note format. The cosignatures close anchor equivocation, the failure where one root is shown to verifier A and a different root to verifier B, because the cosigners are independent third parties and would have to sign a second head for a second story to exist.
The pattern already runs on this estate. The lineage registry at ainumbers.co/registry/lineage publishes signed checkpoints, and each checkpoint goes in as a leaf to the public Sigsum log. The anchor record stored beside the checkpoint, registry/lineage/checkpoint.sigsum-record.json, read on 5 October 2026, shows tree size 70300, the checkpoint at leaf index 70299, and eleven witness cosignatures over the log's tree head, all timestamped 4 October 2026.
Reconstruct the Merkle root from a merkle_inclusion leaf and its path, and state the two comparisons that must pass for the binding to verify.
The anchor service and its live worked example, the witness-cosigned public log the estate's checkpoints ride, and what the evidence stays worth as signature algorithms age.
The anchor service at anchor.ainumbers.co asks independent timestamp authorities to sign a hash as RFC 3161 tokens and hands the tokens back; verify_anchor_binding checks a binding offline against pinned authority roots. The Agent Staircase page ran this path live on 26 September 2026: ten execution hashes from its examples were folded into one session receipt with build_session_receipt, root sha256:7bc2980bc7d8a719166804e9bd9e553f767d9dd2fd3f96c1ac9b14cbd669c26b, and three authorities signed that root: Sigstore TSA and DigiCert at 02:48:56 UTC, FreeTSA at 02:48:57 UTC.
The receipt and its three tokens are downloadable from the staircase page's last step, so the timestamp claims are checkable by anyone. Decode a token to a .tsr file and verify it against the digest the way the page shows: openssl ts -verify -in digicert.tsr -digest 7bc2980bc7d8a719166804e9bd9e553f767d9dd2fd3f96c1ac9b14cbd669c26b -CAfile <that authority's root>. The browser tools that produce these receipts stay zero-egress: only the hash travels to the anchor service, never the inputs behind it.
Timestamp one execution hash with anchor_hash using two RFC 3161 authorities plus OpenTimestamps, then report what verify_anchor_binding checks for each returned binding.
Sigsum is a minimal public transparency log, and it is where this estate's long-lived checkpoints get outside scrutiny. The lineage log's own head goes in as a leaf to the public Sigsum log operated at seasalp.glasklar.is, and the stored anchor record carries the full proof: the log's origin and public key, an inclusion proof for the leaf, the signed tree head, and eleven cosignatures from independent witnesses. A consumer who checks the record can detect equivocation of the lineage log's head, because a second story would need a second head and the witnesses would have had to sign that one too.
Verification is offline. A verifier confirms the note's origin and root match the binding, then requires at least the policy's threshold of valid cosignatures against a pinned witness key set; fewer than the threshold, or a cosignature over a different root, fails the binding. This is the same witness mechanism the spec cites from existing verifiers such as sigsum-verify and Armored Witness. The estate's errata feed carries an independent anchor of its own in the same log: any future edit to the feed produces a new witnessed checkpoint, and the old one stays in the log as a durable, tamper-evident record of what the feed said on the day.
Explain what witness cosignatures add to a transparency-log checkpoint, and name the two conditions that make a verifier reject the note.
Anchor evidence keeps its timestamp value as signature algorithms age, because inclusion evidence is SHA-256 Merkle data. An OpenTimestamps proof contains no signature anywhere in its attestation path: its integrity comes from SHA-256 Merkle aggregation committed in Bitcoin proof-of-work, so an adversary who stores the proof today and tries to forge it later gains nothing from quantum algorithms against it. RFC 3161 tokens do carry a classical signature and inherit that scheme's exposure window; the spec records that no public post-quantum RFC 3161 authority existed at its July 2026 survey and tracks the migration as a watch item against the NIST IR 8547 timeline.
The standard also defines what the evidence is worth when the bytes behind it go away (SPEC.md §20.3). An artifact body may be pruned only behind a retained batch anchor whose root carries witness cosignatures meeting the verifier's own k-of-n policy, the checkpoint itself is kept forever, and a verifier holding only the checkpoint reports the artifact as body-absent: anchored-hash-only rather than claiming a hash verdict it can no longer compute. Periodic re-anchoring of checkpoints under a fresh timestamp binding is the standing practice the section recommends.
Explain why an OpenTimestamps binding keeps its timestamp value against a store-now-forge-later adversary, and what changes for an rfc3161-tst binding.