test(deployment): prove disconnected Perseus + Vault + Ledger operation and claim boundary

[tcconnally]

Context

Hypothesis 3 is not closed by saying that the products are local-first. We need a reproducible acceptance run showing that the Perseus stack can be installed, operated, observed, recovered, and updated inside a disconnected/on-prem deployment boundary.

Iron Bank provides hardening/scanning evidence, but its own documentation says hardened containers do not receive an ATO or CtF; the downstream program remains responsible for authorization. This issue is therefore an evidence and claim-boundary workstream, not an IL5/IL6 certification task.

Current gap

The products have strong local/offline design claims, but the H3 evidence is incomplete:

• the Perseus --offline CLI flag is currently a no-op and cannot be treated as an enforcement guarantee;
• there is no committed cross-product disconnected acceptance bundle covering Perseus, Vault, and Ledger together;
• no reproducible resource envelope, restart/recovery, upgrade/rollback, and denied-egress report has been published for the deployment;
• current public wording must distinguish offline-capable/self-hostable from Iron Bank assessed, IL5/IL6 deployable, and ATO-authorized.

Proposed acceptance harness

Run a fixed, synthetic DevSecOps flow in a clean, network-isolated environment:

1. Install the versioned Perseus, Vault, and Ledger artifacts from an offline bundle.
2. Verify artifact manifest, checksums, SBOMs, and available signatures/provenance.
3. Render/query context through Perseus and persist/retrieve evidence through Vault.
4. Record and verify a Ledger evidence receipt for the synthetic build/deploy trace.
5. Exercise the H1 OSCAL projection contract (fix: resolve all open issues (#251-#258) #259) and H2 supply-chain lineage fixtures (feat(supply-chain): ingest SPDX/CycloneDX and build queryable software lineage #995) where applicable.
6. Deny DNS and all egress; capture attempted network calls and classify each as expected/blocked/defect.
7. Restart each component, reopen state, and verify recovery without external services.
8. Perform an offline upgrade and rollback using a second versioned bundle.
9. Measure CPU, memory, disk, startup time, storage growth, and log volume under the declared workload.

Acceptance criteria

• Freeze the fixture, versions, platform, network policy, resource limits, and test commands.
• Produce a machine-readable manifest with artifact names, versions, digests, SBOM references, and test results.
• Prove the core flow succeeds with no external network dependency.
• Prove all unexpected network attempts fail closed and are reported.
• Record resource envelopes and persistent-state behavior for Perseus, Vault, and Ledger.
• Verify restart, backup/restore, upgrade, rollback, and partial-failure behavior.
• Publish a claims matrix with explicit ceilings: local/offline-capable, Iron Bank submitted, Iron Bank assessed, customer-platform deployable, and ATO/IL status must remain separate states.
• Decide whether --offline should become an enforceable runtime boundary or be removed/renamed in favor of a tested deployment profile; do not leave a no-op flag as implied assurance.
• Preserve negative results and failed cells; the evidence bundle must be reproducible from a clean host.

External gates

• Platform One onboarding requires a real DoD military/civilian Government POC who can validate mission need. This issue must not invent a POC or submit the form.
• A formal IL5/IL6 or ATO claim requires the downstream mission owner/authorizing authority and is outside this local acceptance run.

Non-goals

• Handling classified or CUI data in the test fixture.
• Claiming that a successful disconnected run is an ATO, IL5/IL6 authorization, or Iron Bank approval.
• Replacing customer-specific RMF, Kubernetes, identity, monitoring, or incident-response controls.

Related

• Iron Bank Perseus container preparation issue
• Iron Bank Vault container preparation issue
• Ledger cATO evidence projection: feat(provenance): export cATO evidence as validated OSCAL RMF artifacts ledger#259
• Perseus supply-chain lineage: feat(supply-chain): ingest SPDX/CycloneDX and build queryable software lineage #995
• Existing Vault resource-envelope work: bench(observability): measure reproducible edge resource envelopes for recall and context assembly perseus-vault#1105