Every workflow in the OpenChainGraph catalog can carry a zkVM receipt that proves its kernel computed the answer it published. This page walks the profile that asks for such a receipt on every deterministic node, the share of the live graph that carries one today, and the flag a node declares while it waits for its proving turn. Every number on this page was read against the repository at commit 2ab9097fcf3c on 5 October 2026, and each panel names the command that re-derives it.
Three steps: where a compute proof sits among the verification layers, the profile that asks for one across the deterministic estate, and the split the coverage gate prints today.
An artifact carries an execution_hash, and anyone holding the inputs can recompute it: that is tamper evidence (SPEC.md §4). A Data Integrity proof from a named key adds authorship, so a verifier knows which publisher stands behind the bytes (§16). A compute-integrity proof adds the third rung: a succinct zkVM receipt that the kernel computed this output, checkable without re-running anything, optionally without seeing the inputs (§18). The receipt is optional at the base-standard level, exactly like the signature beneath it.
One recipe binds the three rungs together: the same JCS canonicalization (RFC 8785) feeds the artifact hash, the signature input, and the journal bytes the receipt commits to. The deep dive on this estate, Proving It Ran, follows one real receipt from the kernel that produced it to the pairing check that verifies it.
Name the three verification rungs an OpenChainGraph artifact can carry, what each one establishes, and which of the three is optional in the base standard.
An optional proof is a weak promise: a verifier who needs the receipt never knows whether this particular node carries one. SPEC.md §18.6 closes that with a named conformance profile, ocg-p18-deterministic. Under it, every live node whose kernel is small and deterministic (the catalog's gpu:false flag) MUST do one of two things: attach a well-formed receipt whose journal commits exactly the node's own output, or declare compute_proof_ready:"deferred" alongside a stated deferred_reason. A node doing neither fails the profile. Heavy parallel compute (the 15 gpu:true nodes) sits outside the profile, because proving a Monte-Carlo loop in a zkVM guest costs more than the answer is worth; such a node may still attach a receipt voluntarily, and today every one of them does.
The flag the profile keys on already had a job: gpu:false marks a kernel that runs as a small deterministic server compute, the same signal the kernel-coverage gate reads. The profile introduces no new taxonomy; it borrows the boundary the catalog publishes and turns it into a proof obligation with an explicit exit.
State what the ocg-p18-deterministic profile requires of every live gpu:false node, which nodes fall outside it, and the two states a conforming node can be in.
Read at commit 2ab9097fcf3c on 5 October 2026: 669 live nodes, 665 of them ZK-proven, meaning each carries a real zkVM receipt over its own kernel output that anyone can verify offline. The deterministic profile covers 654 of the live nodes: 650 proven and 4 deferred, with 0 nodes in neither state. That puts whole-graph coverage at 99 percent, and the figure is derived from chaingraph.json on every build, so it moves only when the graph does. The long-form page that carries the live-updating figure is Proving It Ran.
Re-derive the split yourself from the published catalog; the gate prints one line and exits green when the profile holds (output read at commit 2ab9097fcf3c on 5 October 2026):
$ node scripts/check-compute-proof-coverage.mjs --summary §18 compute-proof coverage — gpu:false live: 654 | proven: 650 | deferred: 4 | missing: 0 (gpu:true out-of-scope: 15)
Run the §18 coverage summary against the current main of PostOakLabs/ainumbers and report the proven, deferred and missing counts for gpu:false live nodes, with today's date.
Three steps: the two members a deferral publishes, the four nodes currently in that state, and the ratchet that blocks silent regressions plus the commands that let you check all of it.
Proving a kernel means running it inside a zkVM guest and sealing a receipt, which happens offline with a dedicated toolchain (SPEC.md §18.2). That work is queued rather than instant, so a deferral is the profile's declared parking state: the node sets compute_proof_ready:"deferred" and publishes a deferred_reason that says what is true about this particular node. The gate reads both members, and a reason that is empty or a placeholder (the literal word deferred, todo, a dash) fails the check, because the state is only meaningful while the reason is real.
| Node (all four deferred today) | What it computes, and why it waits |
|---|---|
| match_invoice_three_way | three-way invoice match over integer arithmetic; shipped 1 Oct 2026 with its deferral declared and entered the proving queue |
| find_runway_goal_path | bounded grid search for a cash-runway path; shipped 2 Oct 2026 the same way |
| estimate_ai_token_spend | token-spend pricing over dated vendor price snapshots; shipped 4 Oct 2026 the same way |
| recompute_x402_permit2_digest | x402 permit digest recomputation; its measured guest cycle count is on record for the proving run to book against |
The pattern behind all four is the estate's stated order of operations for a new deterministic node: build it, land it with the deferral and its reason declared, review it beside the standard, then run the proving job. Nothing on the list is blocked by principle; each entry is queue position. The names come from the gate's own listing, so the table re-levels itself whenever a proof lands: run the command in step 6 and the deferred column shrinks in public.
List every live gpu:false node currently marked compute_proof_ready:"deferred" in chaingraph.json, and for each one quote its deferred_reason in one sentence.
A ceiling that can drift upward silently protects nothing, so the deferred count is held by a ratchet: scripts/compute-proof-baseline.json pins the allowed maximum (4 as of the same 5 October 2026 read), and the gate fails if the live count ever rises above the pin. A pull request that adds a new node may raise the pin by that node alone, in the open, and no other way exists to raise it. Two further checks close the quiet routes back. The provenance discriminator keeps a baseline rewrite from absorbing a regression: a node newly appearing in the deferred set that was already known at the last pin is named as a proof regression and blocks the rewrite. And the whole gate is wired into preflight and deploy CI, so the split is re-checked on the path to production rather than on demand.
The count has already made the full walk once: the pinned ceiling peaked at 52 deferred nodes in mid-July 2026, and the proving queue took it to zero on 18 September 2026. The four today are the October arrivals described in step 4, each a brand-new node landing with its deferral declared. The profile's own endgame, written into SPEC.md §18.6, is a ceiling of zero.
Explain the three controls that keep the §18 deferred count from rising: the pinned ceiling, the provenance discriminator on baseline rewrites, and the CI wiring.
Everything this page claims is re-derivable from the public catalog in under a minute. The summary prints the split; the listing names the deferred set; the strict gate checks the profile and its ratchet. All three are read-only over chaingraph.json, which is published at ainumbers.co/chaingraph/chaingraph.json.
$ node scripts/check-compute-proof-coverage.mjs --summary $ node scripts/check-compute-proof-coverage.mjs --list-deferred $ node scripts/check-compute-proof-coverage.mjs
A green strict run prints one line: every in-scope node proven, the deferred count at or under the pinned ceiling, and the heavy nodes reported informationally. Where the numbers go next is the proving queue's business; the gate's job is to make sure the graph never quietly stops matching the receipt column. For the receipt side itself, from guest program to pairing check, continue with Proving It Ran, and for the signature layer beneath it, Signatures and key retirement.
Verify against today's main of PostOakLabs/ainumbers that the deferred set is exactly the four nodes named on the proof coverage page, and report any difference.