Verification model

The local implementation is running. Test status is a separate question. The operator uses OpenShell agent sandboxes and Ansible configuration as code; BoundaryKit draws on that operational experience. The worked example is a separate fictional teaching packet. Its NOT RUN labels mean its particular acceptance probes and recovery drill were not executed—not that the real local system is merely theoretical or offline.

This framework distinguishes operation, static repository checks, historical observations, and specific security/recovery test results. Evidence for one does not automatically establish another.

Verification levels

Level	What it supports	What it does not support
Operational experience	The operator confirms a running local implementation: generic host → operator-core VM → logical workload groups → agent sandboxes.	Independent certification or a particular isolation/recovery test result without its corresponding receipt.
Static validation	Public docs and remaining examples are reviewable.	That a VM, sandbox, provider path, or workload ran.
Historical acceptance example	Fictional receipt shape and proposed checks.	Any measured PASS or maintained runnable lab.
Historical boundary observation	One named earlier boundary refused reported probes, or one misroute stopped.	Current runtime/version behavior or neighboring boundaries.
Production-ready	A real workload produced canary, auth, egress, audit, rollback, and SLO evidence.	General safety for all future workloads.

Static validation

Run from the repository root after installing requirements-docs.txt into an isolated environment as shown in the public reader quickstart:

make ci DOCS_PYTHON=.venv/bin/python
.venv/bin/python scripts/public-safety-scan
git diff --check

make ci is intentionally safe for CI. It does not require VM access or secrets. The public safety scan is necessary but not sufficient; manual declassification review is still required.

Operational experience and historical observations

Case study describes the running local implementation and separates that experience from specific test claims.
Receipt #1 reports negative probes at an earlier inner sandbox, not current realm isolation or outer containment.
Receipt #2 reports placeholder configuration and a stopped run for one deliberate misroute. It does not show a successful governed request with credential resolution at a mediating boundary.

The historical substrate receipt contains fictional PASS examples only. Former platform/ lab executables have been retired. Ansible configuration as code is an operator-reported implementation outcome; its repeatable provisioning, maintenance, and recovery workflows do not prove a completed recovery drill.

Boundary receipt requirements

A valid public boundary receipt should include:

the exact boundary under test, named precisely;
a negative-test matrix where each row is a crossing attempt;
the observed refusal or fail-closed behavior;
an explicit "what this does not prove" section;
no raw command transcripts, private addresses, private hostnames, token material, live VM names, or incident-specific details.

Promotion and rollback evidence

A promotion or recovery receipt should include:

exact source revision, artifact digest, policy version, or equivalent identifier;
dry-run/review record before apply;
rollback target captured before apply;
post-change boundary checks;
recovery or rollback result;
remaining non-claims.

Claim discipline

Use these terms precisely:

Operational (operator-confirmed) - the operator is running the implementation locally. This records actual use; it is not an independent security audit or a recovery-test result.
Static-validated - safe local checks ran and passed, if recorded for this revision.
Fictional example - illustrative acceptance format, never a measured PASS.
Historical scoped observation - a reported test at one earlier named boundary.
Production-ready - a real workload produced canary, auth, egress, audit, rollback, and SLO evidence.

Use NOT RUN only for a specific check that was not executed in the stated scope. If a test's result is simply absent from the public record, say no public result recorded rather than assuming it was never run. Neither label means the implementation itself is not running.