Check that the page you use is the page we shipped

A deploy that can be checked after the fact is a testable claim. Each deploy run writes a manifest describing the run and a checksum list covering every published file, and serves both from the site root.

The manifest, /.well-known/deploy-manifest.json, describes one deploy run: the commit it shipped, the time it ran, the number of files it published and the digest that pins the list. The list, /.well-known/deploy-checksums.txt, carries one <sha256> <path> line per published file in sha256sum format, sorted by path. Three names sit outside the list by design: the manifest and the list themselves, since a file cannot contain its own hash, and deploy-stamp.json, whose bytes carry a run timestamp no later check could reproduce.

Fetch https://ainumbers.co/.well-known/deploy-manifest.json and https://ainumbers.co/.well-known/deploy-checksums.txt. Report deployed_commit, generated_at, file_count, site_content_digest and the number of lines in the list.

Each field in the manifest is a checkable claim, and the most useful one pins the list. site_content_digest is the sha256 over the exact bytes of the checksum list, so the two files stand together.

Two of these link straight to git. deployed_commit names one commit on the main branch of the public repository, and the snapshot above resolves to a single commit whose subject begins chore(derived): regenerate shared derived artifacts on main. file_count agrees with the list line for line: 9912 lines, 9912 published files on the snapshot date. The digest closes the loop between the two files: hash the list you downloaded and the digest must come out the same, which it did on 2026-10-03.

Hash the downloaded deploy-checksums.txt with sha256 and compare the hex digest with site_content_digest from the manifest. Also compare the list line count with file_count. Report both pairs of values and whether they match.

The list turns "the site shipped this page" into arithmetic. Download any published file, hash it, and its line in the list must carry the same digest.

curl -fsSL https://ainumbers.co/chaingraph/agent-staircase-explainer.html -o page.html
curl -fsSL https://ainumbers.co/.well-known/deploy-checksums.txt -o sums.txt
sha256sum page.html
grep "agent-staircase-explainer" sums.txt

Any published file works the same way, from a tool page to chaingraph/chaingraph.json itself. A file whose hash differs from its list line has changed since the deploy, and a file whose name has no line at all was never part of that deploy.

Pick any file from the checksum list, download it from the site, run sha256sum on it, and confirm its digest equals the digest in its list line. Report the file, the two digests and the verdict.

The deploy run signs what it produced. GitHub records an artifact attestation for both provenance files, and one command fetches the statement and verifies its signature against the repository.

gh attestation verify sums.txt --repo PostOakLabs/ainumbers

Three facts in the statement deserve a read. The signing identity is the site deploy workflow on the main branch, so the signature names the pipeline that produced the bytes. The commit inside the signature is the same commit the manifest names as deployed_commit, and the subject digest for the list equals the digest the manifest publishes as site_content_digest. The statement and its Rekor transparency log entry stay retrievable after the deploy is long gone. The attestation is a process claim: this workflow, at this commit, produced these bytes; whether the content is correct is what the checks around it decide. The step is advisory today: the deploy treats an attestation failure as non-fatal, so a green deploy does not promise a fresh attestation, and the command above is how you find out.

Run gh attestation verify on the downloaded deploy-checksums.txt against the PostOakLabs/ainumbers repository. Report the exit code, the signing workflow identity, the commit named by the signature and the attestation subjects.

Check out the commit the manifest names, rebuild the list the way the deploy builds it, and compare bytes with what the site serves. Agreement from both directions is what makes the snapshot worth trusting.

The derivation is plain shell: walk the published tree, leave out the working files no visitor needs, sort the paths, and sha256sum the lot in sha256sum format. The published list follows that exact recipe, so a checkout at deployed_commit reproduces it line for line, and hashing your rebuilt list must yield site_content_digest. The deploy pipeline runs a version of this loop after every deploy: it re-fetches a sample of the listed URLs and hashes the bytes the edge actually serves, so a mismatch between the repository and the visitor is caught on the pipeline side too.

Clone https://github.com/PostOakLabs/ainumbers and check out the commit in deployed_commit. Rebuild a sha256sum-format list over the published files, sorted by path, then compare it with the served https://ainumbers.co/.well-known/deploy-checksums.txt. Report the first differing line, if any.