Phase 4 of 12 · Architecture Operator
Spec & System Design
Phase 4 is the work of translating decisions into executable intent for humans and agents, where constraints, ADRs, evals, and security boundaries are set deliberately.
Translate evidence, decisions, and prototypes into executable intent for humans and agents.
Decision rules
Each rule connects a real situation to the skill or playbook that fits it. Linked terms open canonical sources.
| Situation | Missing skill | Recommended playbook | Alternatives | Why |
|---|---|---|---|---|
| A spec means different things to different readers because the domain language isn't pinned down. | Domain language alignment | grill-with-docs | Event Storming workshop | Grill-with-docs locks terminology and entities in CONTEXT.md before requirements are written; Event Storming is heavier and earns its keep when the domain itself is contested. |
| Engineering can't act on the spec without coming back with questions every day. | Plan completeness | writing-plans | ADR + RFC pair | Writing-plans produces a single document an engineer can resume cold; ADR + RFC is better when the decision history matters as much as the plan. |
| The product brief lives in conversation and keeps shifting from week to week. | PRD discipline | pm-execution:create-prd | to-prd | Create-prd is the right call when stakeholders outside engineering must review and sign off; to-prd is faster when you already have the context and just need a written artifact. |
| Engineering and product disagree on what 'done' means for a piece of work. | Acceptance criteria | pm-execution:user-stories | job stories | User stories with explicit acceptance criteria become the spec the agent satisfies; job stories work better when motivation and context matter more than role. |
| A spec is detailed on features but silent on backend, evaluation or security requirements. | Spec completeness review | AWS Kiro | grill-with-docs | Kiro runs a spec-to-code pass and surfaces missing NFRs, evals and threat model as concrete gaps; grill-with-docs catches the same gaps through interrogation but takes longer. |
Watch
Reality
Spec generation is useful, but system design still requires constraints, ADRs, eval plans, observability, and security boundaries.
Required skills
- Domain language alignment
- Architecture decision capture
- Non-functional requirement definition
- API contract thinking
- Security and eval handoff
Failure modes
- Ambiguous specs
- Prototype hides backend complexity
- Missing eval/cost/security requirements
- Untraceable decisions
Next operating step
Produce an agent-ready spec that connects intent, constraints, ADRs, eval criteria, observability needs, security boundaries, and handoff expectations.
Working through Spec & System Design?
I advise teams on this part of the lifecycle. Get in touch → if you want a direct, vendor-free conversation about what's worth doing next.