Specification Engineering, Executable Requirements, and Plan Assurance
An agent cannot reliably implement intent that has never been made precise. “Improve onboarding” may be a valid business objective, but it does not identify the users, desired behavior, constraints, unacceptable outcomes, or proof needed fo
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.
Open the source exercise
Whiteboard a password-reset Mission. Show business outcome, functional requirements, NFRs, invariants, failure modes, risk class, assertions, plan coverage, two WorkOrders, evidence requirements, and the revision boundary. Then introduce a change from 15-minute to 5-minute token expiry and identify every downstream record that must be reconsidered.
4. Tradeoffs
More specification reduces rework but can delay learning and create false precision. The answer is risk-proportional detail: lightweight contracts for reversible, low-risk work; deeper requirements, threat analysis, and formal approval for consequential changes. Executable does not mean every business judgment becomes code. It means every advancement decision has explicit inputs, a responsible authority, and inspectable proof.
LLMs are useful ambiguity critics but can invent implied requirements. Preserve provenance: distinguish stakeholder statements, policy-derived constraints, agent-proposed assumptions, and human-approved decisions.
5. Current Mission Control Implementation
At local HEAD a490648, Mission Control supports draft Missions, versioned missionPlans, validation assertions, WorkOrder blueprints, submission, approval/rejection, revision forking, and atomic WorkOrder release in convex/missions.ts. The operator path is represented in apps/mission-control-ui/src/eos/views/MissionPlanWorkspace.tsx. WorkOrders carry acceptance criteria and later connect to verificationReceipts in convex/schema.ts and docs/software-factory/domain-contracts.md.
This is a meaningful specification skeleton, not a complete specification compiler. There is no demonstrated general-purpose contradiction engine, formal NFR schema, automated invariant analysis, or independently enforced plan-assurance gate on the main commit. A staged, uncommitted continuous-quality plan proposes treating the approved Plan revision as the top-level Quality Contract and WorkOrder criteria as scoped projections. Its SHA-256 is 31e3f6fc44824b643ef5bfa3389ba3da1e0e6b1f6827f66fdb63efcbb4c9313b. It is design input, not implemented capability.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence