Separate the facts from the assumptions before you plan anything

Here is a request, of the kind that arrives every week:

Finance needs the new export by end of Q3. It's basically the same as the existing CSV export, just with the tax fields added. Their team already has the field mapping. Should be small.

Four sentences. Read quickly it sounds like a well-specified small job. Read carefully, exactly one of those sentences is a fact.

The three categories

Every request is a mixture of three things, written in one voice so you cannot tell them apart:

• Known facts — someone can point at the evidence. A dated email, a ticket, a regulation, a line in a contract.
• Assumptions — believed, plausible, unverified. Often true. Sometimes load-bearing.
• Open questions — nobody knows, and nobody has been asked.

Run the request above through it:

• Finance needs the new export by end of Q3 — probably a fact, if you can find who said it and why the date is Q3. If you cannot, it is an assumption wearing a date.
• Basically the same as the existing CSV export — an assumption, and the one carrying the whole estimate. "Basically the same" is the phrase that precedes most re-scopes.
• Their team already has the field mapping — an assumption about someone else's readiness, made by someone who is not on that team.
• Should be small — a conclusion inherited from the two assumptions above, being presented as an input.

The request has not become worse under this reading. It has become honest. And "one fact, two assumptions, one inherited conclusion" is a materially different thing to plan around than "small job, clear spec".

Why the blend is the problem, not the assumptions

Assumptions are unavoidable and mostly fine. You cannot verify everything, and an organisation that tried would never ship. The damage is done by the formatting: when an assumption is written in the same tone as a fact, every subsequent reader treats it as a fact, and nobody ever consciously decided to accept it.

Follow the chain. The estimate is built on "basically the same as the existing export". The commitment is built on the estimate. The quarter plan is built on the commitment. Four weeks later the tax fields turn out to need a different rounding treatment per jurisdiction, and the "small job" is six weeks. At the retrospective it will be called a scope change. It was not. The scope was always that; the request was formatted so nobody could see it.

An assumption you have written down as an assumption is a completely different object. It is visible, someone can challenge it, and — this is the part people miss — it can be cheaply verified. "Basically the same as the existing export" is a twenty-minute conversation with the person who built it. Nobody has that conversation, because from the outside it does not look like there is anything to check.

Your assumptions list is your risk register

Most teams find the risk section of a plan hard to fill in, and then fill it with generic filler. But you already generated a good risk list without noticing: it is the assumptions.

For each one, ask a single question — what happens to the plan if this turns out to be false? Most answers are "not much". A few are "the estimate doubles" or "we cannot start". Those few are your real risks, they are specific, they name a condition, and each one comes with an obvious mitigation: go and check.

This is a far better route to a risk register than staring at a blank Risks field, because it starts from something you actually wrote rather than from an invitation to imagine bad outcomes in the abstract.

Doing it without adding a process

This does not need a template or a meeting. It needs about five minutes and a willingness to be slightly annoying:

• Take the request as written and split it into the three lists. Do not rewrite, just sort.
• For anything in the fact list, name the evidence. If you cannot, move it to assumptions. This step demotes more than you expect, and it is where most of the value is.
• For each assumption, ask what breaks if it is false. Verify the ones where the answer is expensive.
• Write the open questions down as questions, not as blanks. "We don't know which jurisdictions are in scope" is a plan input; a blank field is not.

One warning: this reads as pedantry the first few times you do it in a room. The way through is to do it on the request and not on the requester — the phrasing that keeps it collaborative is "let me write down what we know versus what we're assuming, so we can check the risky ones", and it stays collaborative as long as you actually go and check them.

How DeliverySheet handles it

This split is the product's central artifact rather than a nice extra. When a demand is shaped, the AI produces a clarification brief that separates known facts from assumptions from open questions, and flags contradictions between them — and it is explicitly a draft for a human to correct, not an answer.

Two design choices matter here and both were learned the hard way. Unknowns are a required part of leaving the Shape stage: a demand cannot move on with the unknowns field empty, though an explicit "no material unknowns known" counts — because sometimes that is the truth, and a system that refuses to accept it just teaches people to type filler. And the raw text you pasted is stored immutably; anything added later lives alongside it rather than being folded in, so you can always see what was actually asked for versus what was interpreted.

The AI is genuinely useful at this specific job, because sorting statements into three buckets is verifiable in seconds by the person who read the original. It is not deciding anything. That distinction is the subject of another post .