Every compute node and every ordered workflow in this estate is indexed by one JSON file. This page walks through what chaingraph.json contains, how the per-node shard files on disk become that one file, where copies of it live, and how you can verify a downloaded copy with two public checks. Every number and hash on this page was measured on 3 October 2026 against the live site and the repository at commit e6ca04443.
Three steps: what the catalog holds, which source files the assembler reads, and which workflow is allowed to write the result.
chaingraph.json is the machine-readable index of the whole graph: every compute node, every ordered workflow, and the edges that record which node feeds which. The OpenChainGraph standard expresses it as a W3C DCAT 3.0 catalog in JSON-LD, published under a CC BY 4.0 license (SPEC.md §7).
On 3 October 2026 the catalog held 669 nodes and 374 workflows, and the served file was 3,737,587 bytes. The shape is a common one among registries: ethereum-lists/chains assembles one chains.json from per-chain source files, and a dbt project publishes a generated manifest.json whose artifacts each carry a schema-version URL.
Fetch https://ainumbers.co/chaingraph/chaingraph.json and list every workflow whose steps include node art-129-webbotauth-signature-verifier.
Nobody edits chaingraph.json by hand. The file is assembled from source shards: one JSON file per node under chaingraph/graph/nodes/, one per workflow under chaingraph/graph/chains/, and a chaingraph.meta.json header that lists the shards each build includes. The assembler is node scripts/assemble-chaingraph.mjs.
The assembler re-sorts the output at build time, so nodes land in natural order by tool_id and workflows by name regardless of shard order. On 3 October 2026 the meta header listed 669 node shards and 374 workflow shards, and the assembled file matched them exactly.
scripts/assemble-chaingraph.mjs check modeRead chaingraph/graph/nodes/art-591-x402-signer-recovery-verifier.json and name the kernel file that computes this node's execution_hash.
A pull request never edits chaingraph.json. After a merge lands on main, one GitHub Actions workflow, derived-artifacts-regen.yml, reassembles the file from its shards and commits it. Two branches editing the same generated bytes in parallel is the failure mode a single writer removes.
The same workflow regenerates the estate's other shared artifacts, sitemap and feeds included, from their own single writers. The discipline is general: for every generated surface there is exactly one writer, and everything else reads.
Show the workflow that regenerates chaingraph.json on main and name the check that fails when the committed catalog drifts from its shards.
Where the same bytes surface, how to hash a download against the published checksum list and its attestation, and which version field actually answers the question you asked.
The catalog is served at https://ainumbers.co/chaingraph/chaingraph.json. The MCP worker at mcp.ainumbers.co/mcp boots from a data directory generated from the same file at its last vendor step. Discovery surfaces point readers and agents at it: llms.txt links the catalog directly, and the MCP discovery shim at .well-known/mcp.json points agents at the MCP registry surfaces and at llms.txt.
On 3 October 2026 the served file returned HTTP 200 with the same 3,737,587 bytes as the repository copy at commit e6ca04443, and the deploy manifest recorded that commit as deployed_commit.
Download https://ainumbers.co/chaingraph/chaingraph.json and report the deployed_commit value in https://ainumbers.co/.well-known/deploy-manifest.json alongside the catalog size you received.
A checksum list published at /.well-known/deploy-checksums.txt carries one sha256 line per deployed file. Compare your download against its line, then check the list itself against the Sigstore attestation GitHub recorded when the deploy ran.
curl -sS -O https://ainumbers.co/chaingraph/chaingraph.json then sha256sum chaingraph.json.curl -sS -O https://ainumbers.co/.well-known/deploy-checksums.txt then grep "chaingraph/chaingraph.json" deploy-checksums.txt.gh attestation verify deploy-checksums.txt --repo PostOakLabs/ainumbers.On 3 October 2026 the served file hashed to f5a4543ca31b43291088a9f7036f0bcb3c729b9fec1371455f0cb3136cb095e7, that digest appeared on the catalog's line in a 9,912-line checksum list, and gh attestation verify exited 0 on the list from the same download. The attestation step is advisory in the deploy workflow, so a deploy can complete without a fresh attestation; the checksum comparison above is the check to run on any given file. The page you are reading is itself one of the files that list covers.
gh attestation verifyactions/attest-build-provenanceVerify a fresh download of chaingraph.json: hash it, confirm the digest appears on its line in /.well-known/deploy-checksums.txt, and run gh attestation verify on that list against repo PostOakLabs/ainumbers.
The standard layers its version identifiers on purpose, in the style of in-toto and SLSA, so that an additive release does not move a wire identifier. spec_version is the version of record: on 3 October 2026 it read 0.8.13. Each artifact envelope carries chaingraph_version, frozen at 0.4.0 until a breaking schema change, and a @context URL that names the JSON-LD vocabulary in force.
The header also carries version and updated fields. Both have shown the same values since July 2026, so read the release from spec_version and check a copy by its hash instead.
Read spec_version from https://ainumbers.co/chaingraph/chaingraph.json and confirm the chaingraph_version value declared by an artifact envelope you received from the MCP worker.