SIMPLIFIED

Unknowns Board

Four columns — known, unknown, assumed, need to verify — and a button that turns every unknown into a specific question and the tiny experiment that would answer it. Below it, an assessor that reads one question and says, in eight signals, why it is vague, researchable or decisive.

Problem→Understand→Requirements→Constraints→Unknowns→Decomposition→Smallest Step→Model→Experiment→Observe→Debug→Learn→Iterate
"I don't understand payments" is a feeling, and a feeling cannot be researched. The board's job is to make you write the feeling down, put it in the right column, and then watch it become a sentence with a question mark and an experiment. The assessor's job is narrower and more useful than it sounds: it does not know whether your question is good, but it can tell you whether it names a component, sits on a boundary, and asks for a decision — and those three are what separate a question a doc page can answer from one that changes what you build.

The board

Load an example, then replace it with your own project. Items are kept in this browser.

Known · 3

What you can state and would bet on. If it turns out to be wrong you would be surprised.

  • We need products, orders and payment
  • A customer browses products, adds them to a cart and checks out
  • An order must never be paid twice
Unknown · 3

What you do not understand yet. Not a blocker — each one becomes a specific question and a tiny experiment.

  • How payment authorization works
  • How inventory reservation works
  • How images should be stored
Assumed · 3

What you are taking as true without checking — one warehouse, one currency, one region. Written down so the architecture can be revisited when it changes.

  • One warehouse in V1
  • One currency and one country in V1
  • Prices do not change while a customer is checking out
Need to verify · 2

What you believe but have not observed. A claim from a doc, a colleague or a memory; the experiment that would confirm it is usually small.

  • The payment provider will call our webhook within seconds of a charge
  • A single PostgreSQL instance handles V1 traffic
Every item in the Unknown column becomes a question and an experiment.

The question assessor

Type a question. Eight signals, a level and a rewrite, all from the text alone.

level
vague
signals
3 / 8
a sharper form — a template picked by keyword
What sequence of requests happens between my backend and the payment provider when a customer checks out, and which system should be authoritative for whether an order has actually been paid?
  • ✓Has a verb — "How" makes this a question rather than a topic.
  • ✓Not a bare topic — 4 words and a question mark — a sentence, not a label.
  • ✗Names a component — Names no backend, database, browser, provider, request or other concrete part; there is nothing to point at.
  • ✗Names a boundary — Mentions at most one party, so there is no interface for the answer to sit on.
  • ✗Asks for a mechanism — Asks how something "works" rather than what sequence, step or fact you need; "works" has no end.
  • ✗Scoped to my system — Could be asked about any system; nothing says my, our, the store, in V1 or a particular order.
  • ✗Asks for a decision — The answer would be information only; nothing in the question would decide anything.
  • ✓Is answerable — Ends with "?", 4 words, asks for one thing.
The same need asked three ways — click a rung to assess it
Question quality · payments
vague“How do payments work?”
better“What sequence of requests occurs between my backend and a payment provider when a customer checks out?”
best“Which system should be authoritative for whether an order has actually been paid?”

why The first has no end. The second can be answered by a doc page and a test-mode charge, and gives you the sequence — but the sequence does not tell you what to trust. The third decides the design: the order is paid when the provider says so, not when the browser returns.

The Question Quality Ladder →

How to read this page honestly

What the tool does, and what it deliberately refuses to do.

SIMPLIFIED
The eight signals are text heuristics, and they can be gamed: write "should my backend own this between A and B?" about anything and it scores decisive. The `why` lines say what the text did, not what you meant. A researchable question is not a failure — the assessor never demands a decision from a question that is honestly asking how something works; it only refuses to call it decisive. The rewrite is one of fourteen keyword templates or a generic fallback, and the fallback grades itself as merely researchable, because a tool that could make any topic decisive would be pretending to understand your project.

Take it further

Unknown to Specific Question →

The move the sharpen button imitates, done by hand.

The Question Quality Ladder →

Vague, researchable, decisive — and what each one makes answerable.

I Don't Know Where to Start →

The unknowns question in the middle of the nine.