Continuous Quality Contracts, Proof Packages, and Certificates

4. Tradeoffs and alternatives

Comprehensive assurance increases compute, latency, storage, and review cost. The answer is not universal gating; it is risk-proportional contract compilation. Low-risk changes receive a smaller contract. High-risk and irreversible changes require stronger methods, longer observation, and more specialized approval.

A graph is more expressive than a checklist but harder to implement and query. Start with stable criterion and receipt identifiers, then add richer claim and counterevidence relationships where they improve decisions.

Cryptographic signing proves issuer and integrity, not truth. A perfectly signed fabricated test result remains false. Independence, protected execution, method quality, and raw evidence remain necessary.

Quality scores reduce complexity for operators but invite Goodhart's law and approval theater. Keep the underlying dimensions visible, preserve uncertainty, and make hard failures impossible to average away.

Automated rollback limits impact but may be unsafe for irreversible data or external side effects. Some changes need roll-forward, containment, or a human-directed recovery plan instead.

5. Current Mission Control Implementation

This assessment uses Mission Control GitHub main commit b31e275 and the open study branch at 9d5f8e3, reviewed on 2026-08-11.

Mission Control already has important pieces of this architecture:

• Mission Plans define validation assertions, pass conditions, evidence requirements, independence, and waiver policy;
• released Plans materialize revision-bound WorkOrders and criteria;
• verification receipts bind criteria, runs, methods, results, artifacts, verifiers, validity, waiver decisions, and invalidation history;
• WorkOrder governance blocks acceptance on missing, failed, stale, expired, or unapproved evidence;
• WorkOrder revision and reopen preserve history while selectively invalidating affected evidence;
• GitHub PR checks retain source and head-SHA lineage;
• QC records model rulesets, runs, findings, evidence packs, risk grades, scores, artifacts, and dashboards; and
• shadow release-gate evaluations can consume QC, context-evaluation, and GitHub CI signals linked to a deployment.

The score/gate separation in the QC design is directionally correct: the quality score is informational, while failed delivery gates determine risk and eligibility. That matches the doctrine in this chapter.

The present implementation is not yet one canonical continuous-quality system. The older qcRuns.execute path explicitly uses mock assurance and agent-output adapters, skips its policy evaluation TODO, and generates synthetic evidence packs. Its release-gate integration operates in SHADOW mode. The newer Mission/WorkOrder/verification-receipt path has stronger authority and evidence semantics, but it is not unified with every QC, supply-chain, AI-evaluation, deployment, telemetry, and customer-outcome signal.

Study branch PR #64 adds frozen execution manifests, structured completion, bounded handoffs, path scope, durable leases, and a real GitHub App publication proof. These strengthen build provenance and authority, but PR #64 remains open and the browser-only golden path remains incomplete.

Mission Control therefore does not currently issue the Software Quality Certificate defined here. It has several required primitives and one legacy evidence-pack concept, but not the canonical contract compiler, assurance graph, signed certificate, revocation workflow, or complete production feedback loop.