Quality and Evidence Architecture
Define how the factory proves that an exact candidate satisfies exact requirements under known conditions.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw the lineage from acceptance criterion to validation assertion, Worker Attempt, artifact, Validator Attempt, verification receipt, quality gate, review package, and human acceptance.
Then introduce these events:
- the pull-request head SHA changes;
- a security validator fails while two other validators pass;
- an approval expires;
- a criterion is waived;
- the WorkOrder is reopened after a customer defect.
Show which records remain historical, which become stale, which decisions are required, and what must be rerun.
4. Tradeoffs and alternatives
Comprehensive evidence costs time, compute, storage, and reviewer attention. Requiring every possible check for every change is wasteful. Risk-proportional policy should select the required validators and depth.
Reusing evidence can reduce cost but creates staleness risk. Reuse is safe only when artifact, environment, method, inputs, and policy remain equivalent and the receipt has not expired.
Highly structured receipts improve automation and auditability but may omit important narrative context. The solution is a stable envelope with linked raw artifacts and concise human interpretation.
Manual validation remains necessary for some product and business judgments. It should produce the same attributable receipt structure rather than exist as an undocumented conversation.
Waivers prevent the factory from becoming unusably rigid. Poorly governed waivers become a permanent bypass. They need scope, reason, owner, expiry, compensating control, and review.
5. Current Mission Control Implementation
This assessment uses Mission Control commit
8014d5af427b43ff5c5a63cfdf82ec92742c208c,
studied on 2026-08-08.
Evidence model
Mission Plans define validation assertions with ID, outcome, verification method, pass condition, required evidence, independence requirement, and waiver policy. Approved Plans materialize those assertions and link them to WorkOrders.
Verification receipts bind a WorkOrder criterion to a WorkflowRun. They retain method, command or check, result, evidence location, artifact references, verifier, status, waiver decision, revision, validity window, and invalidation lineage. Run artifacts can link to receipts and criteria and may include a content hash, producer, retention policy, and sensitivity.
Acceptance gates
Mission Control derives acceptance from the latest usable approval and receipt for each requirement. Missing, failed, stale, expired, or revoked records block acceptance. A waived criterion without an ApprovalDecision also blocks.
Run completion does not auto-accept a WorkOrder. WorkOrder acceptance requires no active run, a completed latest run, satisfied approvals, current receipts, and no failed criteria. Mission acceptance additionally requires accepted WorkOrders, complete handoffs, and independent validator linkage where required.
Revision and freshness
WorkOrder revisions append snapshots and identify affected criteria, approvals, and receipts. Reopen decisions preserve lineage while invalidating impacted evidence. Approval and verification validity windows allow records to expire. Newer execution can make prior receipts stale.
Pull-request evidence
GitHub ingestion records the pull-request URL, repository, branch, head SHA, CI status, provider run, source event, and merge facts. Head-SHA changes can require fresh evaluation. This is the correct direction: repository recency is not evidence lineage.
Capability assessment
| Quality capability | Status at studied commit | Interpretation |
|---|---|---|
| Criterion-level validation contract | Implemented | Plans and WorkOrders define traceable criteria and methods. |
| First-class verification receipts | Implemented | Receipts link criteria, runs, artifacts, verifier, status, and validity. |
| Independent validator linkage | Implemented mechanism | Required Mission assertions need a Validator run and receipt. |
| Evidence freshness and invalidation | Implemented | Expiry, revision, reopen, and newer execution can make evidence stale. |
| Governed waivers | Implemented mechanism | Waived receipts require linked ApprovalDecisions. |
| Explicit WorkOrder and Mission acceptance | Implemented | Completion and acceptance remain distinct commands and states. |
| Run evidence drill-down | Implemented | Ordered events, artifacts, and receipt-focused inspection exist. |
| GitHub head-SHA lineage | Implemented in PR evidence paths | CI and merge information can bind to an exact head SHA. |
| Heterogeneous validator conflict Risk Review | Not verified as one canonical workflow | Failed and conflicting evidence can be retained, but a complete first-class conflict-review journey was not proven here. |
| Complete review package | Partial | Relevant data and surfaces exist; one concise end-to-end decision packet was not freshly demonstrated. |
| Production outcome validation | Partial or future depending workflow | Release-gate mechanisms exist, but business-outcome confirmation is not proven across the V1 golden path. |
Existing verification documentation reports focused tests and local lifecycle evidence for missing, failed, waived, stale, expired, reopened, and superseded records. This chapter did not rerun those historical demonstrations or perform a new browser journey. It therefore treats them as versioned project evidence, not newly observed proof.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence