"Delivered" is not an outcome

The commitment said: reduce mobile checkout drop-off from 34% to under 25% by the end of Q3, three FTE-months, owned by the payments lead.

What shipped: a faster payment step, drop-off at 29%, in Q4, having consumed four and a half FTE-months, with the address-validation work dropped along the way.

In most systems this closes as Done.

What the checkbox destroys

The comparison between the promise and the outcome is the only data that tells you whether your commitments are worth anything — and a binary close is exactly the operation that discards it.

Once a quarter of work has closed as Done, you cannot answer the questions that matter: do our estimates run 20% light or 50%? Do demands that were committed early miss more often than ones that were ready? Does this team's "high confidence" mean something different from that team's? Every one of those needs the delta, and the delta was thrown away at close.

There is also a slower cost. If closing is binary, the pressure at the end of a commitment is to make the box tickable — narrow the scope quietly, redefine the target, ship something adjacent. Nobody decides to do this; the format simply makes it the path of least resistance.

Three closes, not one

Delivered as committed. What was promised, roughly when and at roughly the size promised. Rare enough to be worth celebrating and worth recording precisely so you know how rare.

Delivered with exclusions. The common case. Something shipped and it was not everything. The useful field is not "what shipped" — people remember that — it is what was dropped and why, because that is what the next estimate for similar work needs.

Not delivered. The one systems avoid modelling, so it gets recorded as cancelled, or stays open forever, or is quietly renamed. It deserves a close of its own: work stopped, here is why. A commitment that was abandoned for a good reason is a good outcome, and one that has been open for three quarters is not, and a status field that cannot tell them apart is hiding the more important one.

Ask for the difference, not the story

The question that produces useful records is narrow: how did this differ from what was promised?

Not "how did it go" — that produces narrative, and narrative is written for the reader's mood rather than the next planner's needs. The difference is factual, short, and the thing a person estimating similar work in six months actually opens the record for.

One consequence worth accepting: this should be required when the outcome is not clean, and skippable when it is. A form that demands an explanation for a perfect delivery teaches people that the form is bureaucracy, and they stop reading its questions.

Which is also why the check-in that precedes it has to carry a reason rather than a colour — a green that meant nothing produces a close that means nothing.

Reopening is a feature

Outcomes get recorded wrongly. Someone closes as delivered, and a week later the rollout is reverted.

The record has to be correctable, or people stop recording carefully — but not silently, because an outcome that can be edited without trace is not a record at all. Reopening should take a deliberate second step and leave the fact of the reopen visible.

How DeliverySheet closes a commitment

Delivery closes with an explicit outcome rather than a status change: the result is delivered, delivered with exclusions, or not delivered; what shipped is recorded; and for anything other than a clean delivery the difference is required — you cannot close as partial without saying what differed. That rule is a server-side predicate, so the client cannot talk its way past it.

The vocabulary follows the honesty: the section is "Delivery outcome" and the action is "Record outcome", not "Confirm delivery", because "confirm" reads wrong when the truthful answer is that it was not delivered. Re-opening a recorded outcome after the retrospective is possible and takes an explicit two-step confirmation, so a correction is always deliberate and never invisible.

All of it lands in the commitment ledger next to the original baseline and any re-baselines, which is what makes the quarter-end question — did we miss because we committed early , or because the bar is wrong — answerable with evidence rather than memory. What you learn from it belongs in the retrospective .