420Docs context
Skip to content

420Storage production launch closeout

SR-10.10 closes the production-hardening phase without creating a new authority layer. Launch approval is operational evidence tied to one exact software head and one exact deployment configuration. It does not alter canonical storage agreements, manifests, placements, proofs, authorization or settlement.

Frozen compatibility contracts

The launch candidate freezes the following public/evidence contracts:

  • Developer API: v1
  • Production topology/config schema: storage-topology-v1
  • Testnet evidence schema: storage-testnet-evidence-v1
  • Disaster-recovery evidence schema: storage-dr-v1

Any incompatible change to those contracts requires a new qualification cycle rather than being folded silently into the launch approval.

Main reconciliation

PR #302 was reconciled with current main before final qualification. The reconciliation commit is 8043e937a98b0edd46fe8f62d90067120147c789 with parents:

  • SR-10.9 qualified head: 65228dd50d232ac23221e2229575877c9fb15af3
  • current main at reconciliation: 805150238ff1ec50859a1e3b95be03c388a1cac4

The commit uses GitHub's clean PR merge tree, preserving both current mainline work and the complete SR-10 change set.

Required launch evidence

A production launch record must identify:

  1. the exact final SR-10 commit SHA;
  2. the exact deployment configuration fingerprint;
  3. the exact production topology fingerprint;
  4. the API and evidence schema versions above;
  5. the qualified SR-10.9 testnet evidence fingerprint;
  6. the final node420 Release Gate run ID and result;
  7. the final 420 Integrated Qualification run ID and result;
  8. the final 420Docs Qualification run ID and result;
  9. any remaining non-critical operational risks and their owners;
  10. an explicit assertion that no critical launch blocker remains unresolved.

The record is invalid if any required fingerprint is absent, if a critical blocker remains open, if the final qualification runs do not all point to the same exact final head, or if any frozen compatibility contract differs from the qualified values.

Qualified SR-10 evidence chain

The closeout inherits the following exact-head qualification chain:

  • SR-10.1 topology / multi-provider qualification — 7e85ca94a3dbbf708e5369d22417cdca45fb51c4
  • SR-10.2 adversarial / fault injection — 725b4132d2839df9540092b1ac72f24f3ad770ff
  • SR-10.3 sustained load / capacity — 63a8a12b686707463506f8d0f6b49ecb08885471
  • SR-10.4 upgrade / migration / compatibility — 0d4bb480be29b04c86a4b1c9e50a28350b53e6a6
  • SR-10.5 credential rotation / recovery — d54e5a1fe87518c9ddb5dc873efc412576675985
  • SR-10.6 backup / restore / disaster recovery — bc476b5d24e1fc55254ddd08494fa9d0263f6429
  • SR-10.7 security / abuse resistance — 34702a210f3545f7443a841aab56ab0792c22c0d
  • SR-10.8 operator alerts / SLOs — 3ff5110966b65f8082d24cc0ff1403961ed226b2
  • SR-10.9 testnet deployment evidence — 65228dd50d232ac23221e2229575877c9fb15af3

SR-10.6 through SR-10.9 final qualification run IDs are retained in the roadmap and PR closeout record.

Final merge gate

PR #302 remains unmerged until the final reconciled launch head passes all three required workflows:

  • node420 Release Gate
  • 420 Integrated Qualification
  • 420Docs Qualification

All three results must be successful on the identical commit SHA. If the branch changes after those results, the launch approval is invalidated and all three gates must qualify the new head.

After merge

After PR #302 merges, record the resulting main merge commit in the roadmap and treat SR-10 as COMPLETE / MERGED. Any subsequent production changes begin a new roadmap phase rather than modifying the already-qualified SR-10 evidence chain.

Authority invariant

Operational qualification, deployment fingerprints, launch approvals and CI results are evidence only. They cannot create or rewrite canonical storage identity, authorization, commitments, placements, proofs, economics or settlement.