One root over everything you have sealed, recomputable by anyone
checkpoint/1 — a Merkle tree head over the sealed claims an organisation already publishes. RFC 6962 hashing, inclusion and consistency proofs, verifiable offline against the fragments themselves.
A Merkle tree head over the claims you already publish — what shipped, what you intend, what your directory says — so a reader can recompute one hash and see whether your record still describes what you said it did. RFC 6962 verbatim rather than a house variant, and the estate tier is a tree over other heads’ roots, so a hub holds hashes and no data and a property can still prove its own record with the hub absent.
`checkpoint/1` is a Merkle tree head over the sealed claims you already publish — RFC 6962 verbatim rather than a house variant. `checkpoint head` writes a `checkpoint.json` beside the fragments it commits to; anybody can recompute the root and compare. The estate tier is a tree over other heads’ roots, so a hub holds hashes and no data and a property can still prove its own record with the hub absent.
It proves the fragments you published are the fragments the root describes — catching a record edited after the fact, an emitter that dropped entries, or a served copy that drifted. It does not prove history was never rewritten: you compute, publish and hold the data, so that gap closes only with consistency proofs between retained heads and a witness who is not you.
A v1 head is therefore unsigned on purpose, and it refuses to hash an unsealed record — a claim missing a digest is skipped, never hashed as a blank, in a tree whose whole purpose is to prove sealing.
Installing it puts this command on your path — read from the package’s own manifest, so this list cannot drift from what you actually get.
flashy-checkpointThe format is a static file beside the fragments — no server, no collector, no uptime — so its honesty is that anyone recomputes the root and compares. packages/checkpoint/SPEC.md states the boundary in the format’s own documentation, so a reader cannot mistake a reproducible root for tamper-evidence: the transparency-log half (retained heads, served consistency proofs, witness cosigning) is deliberately gated. Verify it yourself with `npx @flashyos/checkpoint head --origin repo/your-repo` and compare the root.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.