"No known risks" has to be a valid answer

Open any planning template and you will find a Risks section, a Dependencies section, and an implicit instruction that both should have entries in them. A plan with an empty risk register looks lazy. So people write something.

What they write is usually true in the way a horoscope is true. "Timeline may be tight." "Requirements could change." "Dependency on the platform team." Nobody acts on any of it, nobody removes it, and it accumulates. Six months later the organisation has a risk register that is technically populated and practically inert.

Two states where there should be three

The root cause is a data model, not a discipline problem. Most tools give a dimension two states: it has items, or it is empty. That collapses two completely different situations into one:

• Nobody has looked yet. The section is empty because the work has not been done.
• Someone looked and found nothing. The section is empty because there genuinely is nothing.

These need opposite responses. The first is a gap that should block a commitment. The second is a completed step that should clear it. Rendered identically, the reviewer cannot tell them apart — and the person filling the form knows that, which is precisely why they type something rather than leave it blank. A fabricated entry is legible as diligence; an honest blank is not.

So add the third state explicitly. Not assessed. Assessed, nothing found. Assessed, here are the items. Three states, and the middle one is a first-class positive answer rather than the absence of an answer.

Why a fabricated entry is worse than a blank

It is tempting to treat filler as harmless — a bit of noise, no real cost. Three costs, all real:

It consumes the scarcest resource in the process, which is review attention. Whoever reads the plan has to read the generic risks to determine that they are generic. Do that across forty demands a quarter and the reviewer stops reading risk sections, at which point the one real risk someone wrote down is invisible.

It makes the register look trustworthy when it is not. An empty register invites the question "did anyone check?". A full one does not. The filler has removed the prompt that would have caught the omission.

It destroys the base rate. If you ever want to know whether demands with recorded risks slip more than demands without, you need the recorded risks to mean something. Filler makes that measurement impossible permanently and retroactively.

The obvious objection

"If I let people say no known risks, they will say it every time and skip the thinking."

Some will. But notice what has changed. With two states, the skipped step and the honest answer look identical and you can measure neither. With three states, "no known risks" is a recorded, attributed claim by a named person on a specific date. If a demand blows up on a risk that was obvious in advance, there is a row saying who declared it clean. That is a much stronger incentive than a blank field, and a much better artifact afterwards.

You can also ask for one line of rationale on the none-known answer. Not a form, one sentence: "single team, no external systems, no data migration." Cheap to write, and it either reads as considered or it does not.

Where the third state should not be allowed

This is the part that is easy to get wrong by being consistent. Not every dimension deserves the same treatment, because "none known" is not always a coherent claim.

Dependencies, decisions and risks can genuinely be absent. A small change to one team's own service really may have no external dependency and no meaningful risk.

Capacity cannot. Delivery work always consumes someone's time. "No capacity needed" for a real piece of delivery is not an honest assessment, it is a skipped step wearing the costume of one. If you allow the third state everywhere out of a desire for consistency, capacity is the dimension where it will be abused, and capacity is the one that determines whether the commitment was ever possible.

So the rule is asymmetric on purpose: none-known is available for the dimensions where absence is a real state, and unavailable for the one where it is not — except on genuinely lightweight paths where the work is small enough that a rough figure carries no information anyway.

How this works in DeliverySheet

Each of the four Plan dimensions — dependencies, decisions, capacity, risks — carries all three states, and "no known dependencies" satisfies the dimension rather than leaving it looking unfinished. A clean demand can reach a committable state without anyone inventing a single dependency.

Capacity is the deliberate exception, exactly as argued above. On the standard and initiative paths the none-known option is not offered at all; the choices are to estimate it, give a rough range, or say you need discovery before you can estimate. On the quick and discovery paths it is allowed, because the work is small enough that a number would be theatre. On the urgent path it can only be skipped through the early-commitment exception, which is recorded and countable.

The rule lives in one place in the code and the form, the verdict and the pipeline all read it, so the three surfaces cannot disagree about whether a demand is ready. That last part matters more than it sounds: a governance rule duplicated in three components is a governance rule that will be enforced in two of them.