The method
The sequence a design runs through, the gate in the middle of it, and where each step's output lives.
A system is delivered once and lived in for years. The method exists to stop the two failures that follow from forgetting that: carving today's answer into the product, and specifying from a briefing nobody wrote down.
The sequence
Each step feeds the next. Skipping one does not save the work — it moves it to where it costs more.
brief → interview → domain → questions → spec → roast → stories → tasks
what does it entities what only the where does what must do this
was work for and use the client normative it break become now
learned them? cases can answer rules them? true
⇧
APPROVAL GATE — nothing downstream runs without it| Step | Produces | Page |
|---|---|---|
brief | What the client has told us, written down before anything is specified | Brief |
interview | A panel of the brief's actors, run against the brief | Panels |
domain | Entities and use cases in GraphQL SDL. Approval gate | Domain model |
questions | Product-wide or module-local open-question sections containing only real decisions | Open questions |
spec | Product reference plus module references with stable requirement identifiers | Module reference |
roast | The same panel, adversarially, against the specification | Panels |
stories | WBS epics and outcome stories citing requirement identifiers, with explicit delivery gates | Work register |
tasks | Work someone can start today. Regenerable | Tasks |
Two more run outside the sequence, whenever they are needed:
| Step | Produces | Page |
|---|---|---|
decide | A decision record for something expensive to reverse | Decision records |
review | An audit of an existing design for hardcoded constants and rigid flow | Red flags |
The sequence describes how knowledge matures. The project documentation structure describes where each output lives. Use both: method without authority creates duplicates; authority without method creates empty templates.
Why brief comes first
Not because the briefing has not happened yet — but because it has, and nothing has written it down. Specifying from an unwritten briefing means specifying from a mixture of what the client said and what you assumed, with nothing left to tell the two apart.
Why an unwritten briefing rots within weeks
Why domain is a gate
The most expensive artefact to get wrong, and the one whose failure is silent: a missing entity raises no error, it quietly becomes a boolean on something else.
A wrong entity discovered after stories exist invalidates the requirements that trace to it, the stories that cite them, their acceptance tests, and any migration already decided. So it stops and waits for approval.
The six checks, and the approval artefact
What runs at every step
- The four lenses — no structural decision is taken having been looked at only one way.
- The naming lookup — before naming anything reusable, find out what it is already called.
- The red flags — the sentences that mean stop, this is data, not specification.
Working method
- Do not ask what you can make configurable. Reach for the configuration artefact before the question list. You do not need the client's list to design the shape that holds it.
- State assumptions and continue. Where a decision genuinely cannot be configured away, take it, mark it as an assumption, and say plainly what it costs to reverse. Do not stop and wait.
- Bring back what survives. The residue after the questions pass is what the client actually has to answer — model shape, environment facts, service commitments.