Separate outcome from solution
Rewrite the intent as an outcome hypothesis: the signal, the affected users and the business condition that should change, without naming a mechanism.
Outcome hypothesis
From a requested solution to the condition it was meant to change
The hypothesis states a condition that could be observed to be false.
Sibling repository../payments-validation-fixture836a75dShared with course 301. You work from specs/product/payments.md rather than the diff.
Why this stage exists
Requirements arrive as solutions. "Add an idempotency key" is a design, and accepting it as the requirement forecloses the decision you are accountable for.
The outcome counterparty owns client intent. Intent is the condition that should change, not the mechanism someone proposed for changing it.
What you start from
Work from these inputs only. Anything not on this list is either a later stage’s concern or a decision you do not own.
- Requirement risk map
- Your completed diagnosis from stage 1.
- Outcome signal
- The condition operations reported, in their words.
- Domain input
- Payments operations on how clients retry in practice.
From a requested solution to the condition it was meant to change
One worked pass, so the shape of the work is visible before you do it on your own.
- State the business condition that should change, and for whom.
- Strip the proposed mechanism out of the sentence.
- State the observation that would show the hypothesis was wrong.
- Check it against how retries actually happen, not how the spec assumes they do.
What this turns onA hypothesis that cannot be false is not a hypothesis, and accepting it later is a formality rather than a decision.
Do the work
- Write the outcome hypothesis for the refund slice.
- Remove every implementation noun.
- Name the observation that would falsify it.
- Challenge another pair for mechanisms smuggled in as intent.
You produce
Outcome hypothesis
- Signal
- Affected users
- Condition that should change
- What would falsify it
- Mechanisms excluded
Challenge your own result
The client asked for an idempotency key by name. Do you still write an outcome?
Show how this resolves
Yes. The key may be right, but taking a mechanism as intent means nobody ever decided what a repeated submission should do. Record the request as a constraint, not as the outcome.
Ready to continue when
- The hypothesis states a condition that could be observed to be false.
- No implementation mechanism appears in the statement.
What transfersAny request phrased as a solution can be read back for the condition it was meant to change.
Source · 05 Organizational handshake