Specification Engineering, Executable Requirements, and Plan Assurance

3. Enduring Principle

Convert intent into a governed Mission

A Mission is an owned outcome, not a prompt. It should establish:

• the business outcome and affected users;
• scope, exclusions, ownership, priority, and time constraints;
• functional requirements and measurable non-functional requirements;
• architecture, data, security, regulatory, and operational constraints;
• expected failure modes and recovery behavior;
• risk class and required decision owners; and
• the evidence required to show that the outcome was achieved.

The Mission remains the authority for why the work exists. A Plan explains how the factory proposes to achieve it. A WorkOrder authorizes a bounded part of that plan. Collapsing the three allows implementation detail to rewrite business intent.

Distinguish requirements, criteria, and assertions

These records answer different questions:

Acceptance criteria should be outcome-oriented and implementation-neutral where possible. Assertions may be implementation-aware because they define a method of proof. Tests are evidence-producing mechanisms; they are not the requirement itself.

Specify quality attributes and invariants

Functional behavior is only one part of the contract. Non-functional requirements should name a measure, operating condition, population, threshold, and observation window: p95 latency below 300 ms under a defined load is testable; “fast” is not.

An invariant is a condition that must hold across all permitted states and transitions. Examples include tenant isolation, append-only acceptance history, no deployment without an eligible artifact digest, and no completion report from a stale lease. Architecture constraints say how the solution space is bounded; invariants say what must never become false.

Design failure and recovery before the happy path

For each material dependency and transition, specify timeout, retryability, idempotency, cancellation, partial success, reconciliation, rollback, and operator-visible state. “GitHub is unavailable” is a failure mode. “The Attempt retains its commit, publication becomes retryable, no duplicate PR may be created, and the operator sees blocked-publication” is a recovery expectation.

Detect ambiguity, incompleteness, and contradiction

A specification assurance pass should reject or flag:

• vague terms such as “appropriate,” “quickly,” and “secure” without measures;
• compound requirements containing multiple independently decidable claims;
• missing actors, conditions, units, thresholds, owners, or evidence methods;
• unbounded words such as “all,” “never,” and “always” without domain definition;
• acceptance criteria that merely repeat the requirement;
• requirements that cannot be observed or verified;
• conflicting thresholds, states, authorities, retention rules, or dependencies;
• unresolved assumptions presented as facts; and
• orphan requirements with no plan coverage or evidence route.

Automated analysis may propose findings, but business meaning and risk acceptance remain human decisions. A useful finding records severity, affected requirement IDs, rationale, proposed resolution, owner, and deadline.

Review the plan independently

Plan assurance occurs before code mutation. A reviewer separate from the plan producer evaluates requirement coverage, architecture alignment, dependency and supply-chain impact, threat implications, test strategy, rollout, migration, rollback, observability, cost, and unresolved assumptions.

The output is not “looks good.” It is a coverage matrix plus findings and a decision: approved, revision required, or exception required. Validator disagreement increases governance; it does not trigger blind majority voting or random regeneration.

Decompose without losing lineage

Each WorkOrder should project a coherent subset of the approved Plan:

Mission requirement
  -> approved Plan decision
    -> WorkOrder acceptance boundary
      -> Task execution unit
        -> Attempt and artifact
          -> criterion-linked evidence

A WorkOrder must be independently understandable, bounded, authorized, and verifiable. Cross-WorkOrder invariants remain at the Mission or Plan level and require integration evidence. Decomposition is invalid if local completion can violate the global outcome.

Baseline and control change

Approval creates a specification baseline: an immutable version with a canonical digest, author, approver, rationale, and effective time. A material change creates a new revision; it does not silently edit history. The system must determine which WorkOrders, Attempts, evidence, approvals, and release decisions are invalidated or require re-evaluation.

NASA’s systems-engineering guidance provides a useful discipline: requirements should be clear, unambiguous, singular, traceable, and individually verifiable; verification shows conformance to specified requirements, while validation shows the right product works in its intended environment.

8. Personal notes and lessons learned

• The first dangerous hallucination often occurs before code: the system invents what “done” means.
• A Mission is governed intent; a Plan is a versioned proposal; a WorkOrder is delegated authority.
• Testability must be designed into requirements. Evidence cannot repair an unobservable claim later.
• The approved specification, not the builder narrative, controls acceptance.

9. Interview questions

1. How would you translate an ambiguous CEO request into a governed Mission without creating heavyweight bureaucracy?
2. What is the difference among a requirement, acceptance criterion, assertion, and test?
3. How do you detect contradictions across security, performance, data, and audit requirements?
4. When does a specification change invalidate completed evidence?
5. Why should a plan be independently reviewed before implementation?