What a decision-ready demand actually contains

Every organisation that has been burned by a bad quarter eventually writes an intake template. It has fifteen fields. It is filled in badly, resented widely, and quietly abandoned within two quarters.

The problem is not that templates are bad. It is that a template asks for fields, and what a commitment needs is things established — which is a different bar, and one no field can enforce.

The six

1. The problem, stated as a problem. Most requests arrive as a solution: "we need a dashboard for X", "we should move off Y". The solution may well be right, but if the problem underneath it was never written down, the first time reality disagrees you have no basis for changing course. Test: can you state what is wrong without naming any technology?

2. The outcome, written so it can be checked. Not "improve the checkout" — "reduce mobile checkout drop-off from 34% to under 25% by end of Q3". The point is not the metric worship, it is that six months later somebody has to be able to say whether this happened, and "improve" cannot be answered.

3. One named owner. A person, not a team. A team name means the decision has no address: when the demand needs a judgement call, four people each assume one of the others has it. This is the field most often filled with something that looks like an answer and isn't.

4. Capacity the delivering team gave. Not a figure produced for them by someone reading a spec. The gap between an estimate the team owns and one they were handed is exactly the amount by which the commitment will slip — and it comes with a confidence level , or it is a guess wearing a number's clothes.

5. The dependencies, including the ones nobody volunteers. Asking "are there dependencies?" gets a no. Naming the usual suspects — security, legal, privacy, data protection, design, procurement, a shared platform team — gets a real answer. And a dependency counts as established only when the other side has agreed, which is a different thing from having logged it .

6. The open questions, written down as unknowns. Not blanks — questions. "We don't know which jurisdictions are in scope" is a plan input; an empty field is an absence you can't reason about. This is also where an honest "no material unknowns" belongs, because sometimes that is true and a process that can't accept it teaches people to invent.

What "missing" actually means

A demand short of the six is not blocked from being discussed, prioritised, argued about or worked on informally. It is blocked from one specific thing: being promised.

That distinction matters because the usual objection to any readiness bar is "this will slow everything down". It doesn't, if the bar is attached to the right event. Nothing about capture, shaping or debate needs the six. Only the moment where other people's time gets allocated does.

The three failure modes of a checklist

Having written one, here is what goes wrong with it.

It gets filled in rather than established. Someone types "Platform team" into Owner and the field is green. The counter is to make the fields describe evidence rather than intent — an owner who has been asked, an estimate the team gave, a dependency the other side confirmed.

It becomes a gate people route around. If clearing the bar is slower than escalating past it, escalation wins. The bar has to be a couple of minutes of work for a demand that genuinely is ready, and the honest answers — "no known dependencies", "no material unknowns" — have to be one click, not a justification.

It hardens into a ritual nobody reads. The defence is consequences: if a demand can be marked ready with three unresolved high-severity risks and nothing says so, the checklist is decoration. The bar has to be computed from the content, not from whether the boxes have text in them.

None of this replaces a ticket tracker — the six are established before work is planned, which is a different layer from Jira or Linear .

Where deadlines fit

Real dates exist that will not wait for the six. Regulatory deadlines, contracts, a customer escalation that has reached someone senior enough to end the debate.

The answer is not to lower the bar; it is to allow crossing it with a recorded exception — why it is early, what is missing, who accepts the risk, what would change the decision. Four fields, one minute , and the difference between an invisible gamble and a countable one.

How DeliverySheet enforces it

The six are what the Shape and Plan stages establish, and the commitment verdict is computed from them rather than from whether fields are non-empty. Leaving the Shape stage requires a title, a problem, an outcome, an impact or a reason it matters now, an owner, and unknowns — where an explicit "no material unknowns known" counts and an empty field does not. That rule lives on the server, so the client can't talk its way past it and neither can a direct API call.

At Plan, each of dependencies, decisions, capacity and risks carries three states — not assessed, none known, has items — so a clean demand reaches committable without anyone inventing a dependency. And an unready demand can still be committed: it just requires the four-field exception, which then shows up in its own report at quarter end.

The whole argument for why this layer is where dates are actually decided is in the overview on deciding what to commit to .