Open questions
Take any list of questions assembled for a client and sort every entry — most are configuration, and the residue is what the client actually has to answer.
The pass that pays for itself. Take any list of questions assembled for a client and sort every entry into one of four buckets:
| Bucket | What to do |
|---|---|
| Configuration | Delete the question. Shape the record to hold the value, and put the value in a configuration artefact. Whether it also gets an administration screen is a separate call. |
| Model shape | Keep it. Cardinality, whether an act exists, whether a state exists. |
| Environment fact | Keep it. Existing directory, legal obligation, hosting constraint. |
| Service commitment | Keep it. Acceptable loss, recovery time, retention. |
On the worked example, 15 of 28 questions were configuration — just over half. Expect that order of magnitude, not a guarantee.
A list that survives the pass is short, and every entry earns its place.
The two tests that do the sorting
Is it configuration?
Would this statement be false if the client reorganised next year?
Yes → there is a value, and you do not need the client to design the shape that holds it. Delete the question.
Is it genuinely blocking?
If I take this decision myself and I am wrong, what does reversing it cost?
Cheap to reverse → take it, record it as an assumption with an owner and an expiry, and continue. Costs a migration, a disclosure or money → it blocks.
Put each question at the scope that owns it
Open questions are living sections inside the canonical references:
| Scope | Owner |
|---|---|
| One module can settle or contain the answer | that module reference |
| The answer changes several modules or their boundary | the product reference |
| The question is about an expensive-to-reverse technical means | a proposed decision record |
A temporary interview list may exist while discovery is active. It is an inbox, not another authority. Sort its entries into the product or module reference and remove the duplicates.
Every entry carries:
| Field | Why |
|---|---|
| The question, in one sentence | If it takes a paragraph, it is two questions |
| Who decides | Without this it is not a decision, it is a worry |
| Open since | An age is what makes a stalled question visible |
| What the answer changes | In behaviour, not in effort. If nothing changes, it is not a question |
| The assumption held meanwhile | With its reversal cost, so the gate downstream can be judged |
An entry with no what the answer changes is not a question — it is curiosity, and it costs the client time to satisfy.
Where entries come from, and go
brief block 9 ─┐
panel findings ─┼─→ product or module open questions ─→ resolved requirement
spec drafting ─┘ └─→ work-register gate- The brief block 9 raises them; the reference at the affected scope then owns them.
- Panel findings that only the client can settle land here, marked panel-derived.
- The module reference keeps module-local open decisions beside the domain they affect.
- The work register describes the dependency in the affected epic's delivery gate; it does not copy the question.
Working method
The three habits this pass depends on are stated once, on the method page: reach for the configuration artefact before the question list, state assumptions and continue, and bring back only what survives.
A question asking the client to decide a value your own engine already makes changeable is a red flag, not diligence.