Security claim ledger

This ledger is the docs-facing rule for strong claims. A page can describe a behavior as a product guarantee only when the relevant row is Shipped and links to implementation evidence.

For sandbox-parity claims, the detailed status table lives in Sandbox parity status. This page adds the docs relaunch-specific claims around mvm, SDKs, Nix, OCI, and tutorials.

Claim table

Claim	Status	Evidence required before stronger language
`mvm-runtime-boundary`	Shipped	Architecture docs and code paths show local runtime ownership of backend launch, guest protocol, builder VM dispatch, signed plan admission, and local audit.
`decorator-sdk-static-compile`	Preview	Static compile docs and tests prove declarations can emit Workload IR without importing user modules for supported syntax.
`runtime-sdk-lifecycle`	Planned	Python, TypeScript, and Rust lifecycle APIs pass shared create/exec/files/logs/snapshot/stop tests.
`secure-sandbox-product-parity`	Planned	Plan 114 tracks parity capability by capability without copying another product’s runtime architecture.
`builder-vm-secure-builds`	Shipped	Builder VM documents host-orchestrated Linux builds; source-checkout cache reuse and bootstrap policy are covered by current CLI behavior.
`persistent-builder-dx`	Preview	Low-level `persistent-builder` controls and build routing exist; top-level `cargo run -- dev up` and `cargo run -- build` docs must match the actual command behavior before this becomes Shipped.
`cold-mode-snapshot-recovery`	Preview	Firecracker sealed pause/resume, Vz save/restore, and pool Sleeping/Running paths exist, but docs must name backend support and restore semantics.
`platform-linux-macos`	Shipped	Local docs name Linux execution and macOS as the supported targets and keep Windows in the future/issue-tracked bucket.
`platform-windows`	Planned	Windows docs link mvm#428 and avoid implying shipped local runtime support.
`nix-first-auditability`	Preview	Builder VM docs, flake pinning docs, artifact provenance, and signed plan admission are linked from the guide.
`oci-compatibility`	Preview	OCI pull/materialization commands, digest verification, mutable-tag policy, cache isolation, and audit events are documented and tested.
`secure-agent-tutorials`	Planned	Agent, LLM, browser, file, and service tutorials name network, secret, filesystem, persistence, and audit boundaries.

Docs rules

If a claim is Planned, examples may describe the intended shape but must label it Planned.
If a claim is Preview, examples must name backend, platform, or feature limitations.
If a claim is Shipped, examples must link to CLI, SDK, test, or ADR evidence.
Pages should avoid broad security language when a narrower statement is more accurate.

High-risk phrases

The docs lint already gates a small set of high-risk phrases for OCI, secret, and latency claims. New pages should avoid introducing equivalent language without adding a gate.

Examples of safer wording:

Avoid	Prefer
”Run every registry image without limits"	"Run supported OCI inputs after digest resolution and verification."
"Secrets are impossible to leak"	"Secret references are designed to keep plaintext out of default guest-facing paths when the managed-ref flow ships."
"Instant boot"	"Measured boot and readiness numbers are published per backend and artifact.”

Required link targets

Tutorials and SDK pages should link to at least one of: