Verification-First Software Factory — Mission Control Case Study
An agent can generate code, run a test, and confidently report success while still misunderstanding the request, exceeding its authority, weakening the test system, or validating a different artifact from the one placed in a pull request. T
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Exercise 1 — the assurance chain
From memory, draw Mission → Plan → WorkOrder → Attempt → Candidate → Verification Run → Evidence → Gate Decision → Approval → Publication Permit → Pull Request. Annotate each edge with the identity or authority that prevents a stale subject from advancing.
Success means you can explain why no box can mark itself accepted.
Exercise 2 — trust boundaries
Draw browser, Convex, Hono/orchestration, agent process, worktree, verifier, GitHub, and CI. Mark credentials, untrusted inputs, immutable subjects, and external side effects. Walk through candidate substitution, evidence replay, test weakening, and cross-tenant evidence access.
Success means every threat has both a prevention control and a detection or reconciliation path.
Exercise 3 — three audiences
Explain verification-first architecture in:
- 30 seconds to a CEO, emphasizing accountable speed;
- two minutes to a CTO, emphasizing policy, evidence, and risk; and
- ten minutes to a principal engineer, including state, identity, failure, and tradeoffs.
Enduring Principle
The central principle is:
No assertion without evidence. No autonomy without trust. No release without proof.
This does not mean a factory can prove software defect-free. It means no change may enter a governed state unless it satisfies a predefined, measurable, independently verified contract. The factory guarantees the integrity of the process and evidence boundary, not perfection of the artifact.
The operating pattern is:
The durable insight is the separation of observation from decision. A test result, security scan, or reviewer finding is evidence. Policy evaluates the complete evidence set against the active contract. Approval accepts a specific risk or grants a specific action. None of these records substitutes for the others.
Notes and lessons learned
Use this section as a personal synthesis prompt. Do not copy product prose.
- Verification is a plane of the architecture, but its decisions still belong in the control plane.
- Candidate identity is the join key connecting implementation, evidence, approval, and publication.
- Missing evidence is an explicit negative state, not an empty field that can be interpreted as success.
- Retry is a new historical fact. It should create a new Attempt or Verification Run instead of cleaning up the old story.
- A proof package is valuable only when it can be reproduced from canonical records and native artifacts.
- Approval fatigue is reduced by explaining exceptions and evidence, not by hiding risk or asking humans to reread all generated code.
After studying the code, replace or expand these statements in your own words. Record at least one disagreement with the current architecture and defend the alternative.
Interview questions
Architecture
- Why is an agent's report of passing tests not adequate evidence?
- How would you bind verification to the exact pull-request artifact?
- When should a changed candidate invalidate evidence?
- How do observation, gate decision, approval, and publication authority differ?
- Would you model the Quality Contract as its own aggregate or a projection of the approved Plan? Defend both sides.
- How do idempotency and immutable Attempts interact during recovery?
- What technical separation is sufficient for independent validation in a small company?
Executive and skeptical CTO
- Are you claiming the factory guarantees defect-free software?
- How does verification-first engineering affect lead time and cost?
- Why should the organization trust probabilistic agents at all?
- How do you prevent approvals from becoming theater?
- What evidence would you require before moving from delegated execution to governed autonomy?
- Which parts of this architecture are implemented and which are still vision?
Curriculum maturity is not implementation proof.
This case study records scoped implementation claims. Inspect the exact evidence, commit references, gaps, and verification boundaries in the source below.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence