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.
Known vs unknown vs assumed
The three columns collapse into one in the engineer's head, and everything feels known. "Customers have accounts" (assumed), "the provider confirms payment by webhook" (unknown, never checked), "one warehouse" (known — the founder said so) all sit in the same plan with the same confidence. The cost arrives in the week the assumption fails and nobody can say what depended on it. The board — Known / Unknown / Assumed / Need to verify — costs ten minutes and converts feelings into columns; the honest complication is that Known is not permanent either, which is why the fourth column exists.
Known: build on it. Unknown: sharpen into a specific question, attach the smallest experiment, run it, move the answer to Known.
Deliberately and visibly, with the design decisions that depend on it listed, and a moment scheduled to check.
| Aspect | Known — confirmed, with a source you could point at; Unknown — a question not yet answered | Assumed — taken as true to keep moving, without a source |
|---|---|---|
| Has a source | Known: yes. Unknown: not yet | No — the engineer is the source |
| What to do with it | Known: build on it. Unknown: sharpen, experiment | Register it, list dependents, schedule a check |
| Failure when mislabelled | An unknown treated as known is a surprise | An assumption treated as known is a redesign |
| Example | "Founder confirmed one warehouse" / "How does the provider confirm payment?" | "Customers will have accounts" |
| Moves to Known when | The experiment returns | Someone who can confirm it does |