Seal docs — where to start, by what you came for

The product’s front door is the repository README: requirements, a short install, seal demo, protect / status / unprotect, and a five-bullet boundary list. This docs/assurance/README.md page maps everything else in docs/, grouped by reader. Files in the last two groups describe the Seal family of research repositories or a past design state — they are kept for the record and are not claims about the Node CLI this repository ships.

I want to use this

1. The README — requirements, short install, demo, protect, status, unprotect. Start here; everything below is secondary.
2. install.md — the SHA256SUMS verification wall moved off the front page: digest, byte count, and named refusals before the installer runs.
3. evaluator-walk.md — the forensic receipt check for a source build after seal demo, using the checkout checker, with no captured transcript.
4. assurance/RELEASE-NOTES-v0.4.0.md — what v0.4.0 contains and what it deliberately does not, with each claim citing the test or commit that holds it. The immutable assurance/RELEASE-NOTES-v0.2.0-rc.2.md remains available as the historical record for that tag. v0.2.0 was withdrawn before publication. Its record remains historical at assurance/RELEASE-NOTES-v0.2.0.md. The candidate assurance/RELEASE-NOTES-v0.4.0.md describes this checkout. The v0.3.0 release record is assurance/RELEASE-NOTES-v0.3.0.md. The historical record prepared with the v0.2.1 release tree is assurance/RELEASE-NOTES-v0.2.1.md. Generated current-release routes stay tied to published facts and are updated by the post-publication documentation workflow.
5. assurance/distribution.md — what the three installable artifacts are, how the SHA-256 pin works, and the named refusals the installer and launcher give you instead of silent failure.
6. assurance/version-identity.md — why a build off a release tag names itself -dev.g<commit>, which check refuses which lie, and what the pinned digest can and cannot say about an untagged build.
7. assurance/architecture.md — the shipped Node product path first, followed by the wider family assurance lineage.
8. assurance/current-scope.md — current guarantees, tested behaviour, trusted assumptions and what is not established, tied to the README’s own “Guarantees and non-guarantees” section.
9. verify/README.md — choose between the browser checker, the CLI assurance kit, and this product’s own seal verify.

• reference/cli.md — commands, flags, argument ranges and exit codes.

• start/README.md — the start section map.

The dated archive/pass2-captures.md preserves the version-specific walkthrough measurement.

Family task guides

• check/README.md — Check receipts.
• check/your-first-receipt.md — Your first receipt.
• check/from-seal.md — From a Seal demo to the browser.
• check/results.md — Read receipt results.
• check/formats.md — Receipt formats and compatibility.
• check/keys-and-sharing.md — Keys and safe sharing.
• check/run-locally.md — Run the checker locally.
• check/reference/README.md — Receipt checking reference.
• assure/README.md — Assurance CLI.
• assure/start.md — First assurance check.
• assure/verify.md — Verify a receipt in the kit.
• assure/scan.md — Scan policy coverage.
• assure/receipt-diff.md — Compare receipt authorization surfaces.
• assure/adequacy.md — Check finite monitor adequacy.
• assure/conformance.md — Run the boundary conformance corpus.
• assure/ci.md — Use kit results in CI.
• assure/configure.md — Prepare a reviewable host policy.
• assure/reference/README.md — Assurance CLI reference.
• assure/reference/schemas.md — Policy, tools and labels.
• assure/reference/verify-profiles.md — Verification profiles.
• concepts/README.md — Concepts.
• concepts/gate.md — The gate and alternate routes.
• concepts/approval.md — Approval binds an exact request.
• concepts/decision-and-effect.md — A decision is not an effect.
• concepts/replay-and-trust.md — Replay and trust.
• concepts/glossary.md — Scope glossary.
• evidence/README.md — Current evidence and gaps.
• evidence/dependencies.md — Verification dependencies.
• evidence/proofs.md — Proof and source index.
• evidence/correspondence.md — Model-to-runtime correspondence.
• evidence/conformance.md — Finite conformance evidence.
• guide/first-approval.md — Your first approval.
• guide/lifecycle.md — Change, recover and remove protection.
• evidence/sources.md — Source versions and captured examples.

I want to know what it does not do

1. “What Seal covers, and what it does not” — the boundary list at the end of the README is the current, tested statement. Gate, not sandbox; one server’s named tool set; and receipt-key custody limits. Seal supports install, demo, receipt checking and Protect on Linux x86-64 and macOS x64/arm64. Windows, Linux ARM and other platforms are unsupported.
2. “What Seal does not cover” in assurance/RELEASE-NOTES-v0.2.0-rc.3.md — the historical rc.3 boundary with its historical citations. It differs from the current macOS Protect boundary in the platform table above.

I want to check the evidence myself

Lean proof source: seal-host’s proof reference is the reader-facing index for the Lean proof properties stated in this section.

1. The SHA256SUMS release asset and scripts/build-dist.cjs — download a binary and the SHA256SUMS asset attached to the same release, then compare the digest and byte count yourself.
2. test/four-beats.test.cjs — the acceptance walk: install, demo, check, protect, unprotect, from the installed artifact, on a PATH that cannot see Docker, Lean or Python.
3. test/demo-witness.test.cjs — the scope witness established from files on disk (the child’s count file, the receipts directory, the outside write), not from stdout.
4. assurance/claude-code-evidence.md — the client matrix, why the Claude Code row is still untested, and the human-assisted acceptance harness and checker that would close it. 4a. verify/browser.md and verify/cli.md — the browser (seal-check) and CLI (seal-assurance-kit) checking routes, and what each reports separately from this repository.
5. The seal-receipt-v2.mjs release asset — the receipt checker is a sibling asset published with the release and is also inside the installed payload as checker/seal-receipt-v2.mjs, byte for byte. Download it with the binary to verify both against that release’s SHA256SUMS asset. To check a receipt, run node checker/seal-receipt-v2.mjs RECEIPT from a source checkout or from the installed store. The checker implements receipt canonicalisation and signature checking itself with the same Node crypto platform as the producer, but imports Seal’s kernel decision runner for decision replay; read what that does and does not establish.
6. guide/github-actions-provenance.md — download and verify the GitHub-hosted runner’s attested demo-receipt evidence, and read the boundary of that provenance claim.
7. assurance/installed-tree-pin-control.md — the INJECTED human-control boundary for the hand-maintained installed-tree pin site manifest.
8. assurance/linkcheck-population-control.md — what the link-check population cross-check measures, and its shared blind spots.
9. reproduce.md — for a post-import release whose tag contains kernel-source/, compare the installed kernel with a build from that checkout.
10. Receipt operations — the canonical four-verb reference, checked output, vectors, and trust ceiling.
11. SEAL-RECEIPT-V2.md — the Phase A v2 receipt schema and canonicalisation rule.
12. Receipt operations vector set v1 — the runnable fixture used by the reference conformance check.

I want to operate Seal day to day

• guide/README.md — the operating-guide entry point, including prerequisites and a recommended route through the guide.
• guide/choosing-what-to-protect.md — how to choose the one tool that needs a gate and understand what protection changes or leaves alone.
• guide/what-is-protected-right-now.md — how to read every seal status protection state and use seal doctor.
• guide/knowing-it-worked.md — how to interpret approval prompts, refusals, demo evidence, and receipt checks.
• guide/when-something-looks-wrong.md — what each refusal token means, what caused it, and what to do next.
• reference/README.md — the reference section map.
• reference/multi-tool-semantics.md — the shipped named-set behavior, its code and command evidence, and the measured multi-tool state-coverage gap.

The evaluator-facing family truth surface is docs/assurance/evaluator-start.md, at the repository root; it audits the family’s artifacts and proofs, not this CLI.

Previous: Receipt operations vector set v1. Up: Documentation map. Next: Evaluator truth surface.