Assumptions

Making assumptions explicit — one warehouse in V1 — so that when the requirement changes you know why the architecture has to.

Making Assumptions Explicit

"Only one warehouse in V1" is a fine simplification and a terrible secret. Written down with what depends on it, it becomes the reason you can later say exactly why "multiple warehouses" changes the inventory model, the checkout and the shipping estimate — instead of discovering it one bug at a time.

Q · Every design rests on things nobody checked. How do you find the ones yours rests on, and write them so that when one changes you know what has to change with it?
Assumption vs Requirement

A requirement is something somebody asked for. An assumption is something the design takes as true that nobody asked for. They look identical in a spec — "orders are in one currency" could be either — and confusing them means either building for a future that was never promised or treating a promise as if it could change.

Q · A sentence in the spec says the store handles one currency. Is that a requirement someone will hold you to, or an assumption you made to ship — and how do you tell, and why does it matter?
When Assumptions Change

"Multiple warehouses" arrives. If "one warehouse" was written down with its dependents, you know why the inventory model, the checkout and the shipping estimate all have to change, in what order, and which slice proves the new shape before the rest is rebuilt. If it was not, you find out one bug at a time.

Q · A requirement arrives that contradicts an assumption the design was built on. How do you turn "this changes everything" into a list of what changes, an order, and a first slice that proves the new shape?
The Assumption Register
▶ lab

A running list of what the system takes as true, when it was decided, why, what depends on it and what would make it false — kept beside the unknowns and the decisions, reviewed when a requirement arrives, and retired rather than deleted. The unknowns board is where it lives.

Q · You have learned to notice assumptions. Where do they go so that the team finds them at the moment a requirement changes — and how is the list kept alive without becoming another document nobody reads?
Dangerous Assumptions

Some assumptions are silently load-bearing: one currency, one timezone, one warehouse, users have accounts, the provider is up, a request arrives once. Each is reasonable for V1, each is invisible in the code, and each turns a requirement change into a redesign. Knowing the list is how you notice yours.

Q · Which assumptions are the ones that hurt — the ones that every V1 makes, that no code names, and that a single ordinary requirement turns into a redesign — and how do you find out which of them your system is standing on?