Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Assumption vs requirement
They look identical on a requirements list, because both are sentences about what the system must do. "Customers have accounts" may be something the founder said or something the engineer needed to be true to design the cart, and six weeks later nobody remembers which. The cost is a design that depends on a thing nobody agreed to — and the discovery of that comes when the guest-checkout requirement arrives and the cart model cannot hold it. The fix is not to eliminate assumptions, which would stop all work; it is to mark them, so that each one has a source, a dependent design decision, and a moment to be checked.
As the basis of the design and the tests; it can be pointed at when the design is questioned.
Deliberately, to keep moving when the person is unavailable — written in the register with what depends on it and how it would be checked.
| Aspect | Requirement — something a person who can confirm it has confirmed | Assumption — something you decided in their absence, to keep moving |
|---|---|---|
| Source | A person who can confirm it | The engineer, in their absence |
| What it licenses | A design decision and a test | Continued work, provisionally |
| What happens when it is wrong | The requirement changed; renegotiate | The design was built on air; find what depended on it |
| Where it lives | The requirements list | The assumption register, with dependents |
| Example | "Founder confirmed: one warehouse in V1" | "Assumed one warehouse; the stock model depends on it" |
| Typical mistake | Requirement never confirmed but treated as one | Assumption never written, so nobody knows the design depends on it |