What "complete" should mean

Ask a delivery system what is complete and it will tell you what stopped. Those are not the same set, and the difference is where most organisational memory goes missing.

Stopping is an event; completion should be a state

Work stops for many reasons. It shipped. It shipped partially. It was overtaken by a reorg. Someone left and nobody picked it up. The requester stopped asking.

A status field that marks all of those "done" is not recording completion, it is recording the absence of further activity. And an absence is exactly what you cannot learn anything from later.

A more useful definition: work is complete when two things have been written down — what the outcome was, and what was learned. Not when it stopped.

Why two, and not one

The outcome alone gives you the comparison against the promise, which is what tells you whether your commitments are worth anything. It is backward-looking and it is about this demand.

The lesson is forward-looking and about the next one. "The vendor sandbox doesn't support batch imports" is not a fact about the demand that just finished; it is a fact about every similar demand that follows.

Record only the first and you can audit yourself but not improve. Record only the second and the lessons float free of the evidence that produced them, which is how retrospective findings turn into folklore.

The cost is a minute; the objection is not really about cost

Two sentences per demand. The resistance it meets is much larger than a minute of work justifies, and it is worth naming why.

Recording an outcome means saying what actually happened, which for the common case — delivered, but not entirely what was promised — is mildly uncomfortable. Marking something Done is not. So the friction is not the typing, it is that the honest close requires an admission and the dishonest one does not.

Which is exactly why it has to be a required state rather than an encouraged habit. A process that relies on people volunteering the uncomfortable version will collect the comfortable one.

"Abandoned" deserves to exist

If complete means outcome-plus-lesson, then work that stopped without those is not complete. It needs its own visible state, and most systems refuse to give it one — so it either sits open forever, inflating the in-flight count, or gets quietly closed as done, corrupting the delivery record.

Both are worse than saying it plainly. Work abandoned for a good reason is a fine outcome and takes one sentence to record. Work that has been open for three quarters with nobody touching it is a finding, and hiding it inside a Done count is how it stays hidden.

What it buys a year later

The test for any completion model is what a person can answer twelve months on.

With stopped-equals-done: how many things you shipped. That is it.

With outcome-plus-lesson: what proportion of commitments landed as promised; whether the ones committed early missed more often; what a similar demand actually cost against its estimate; what somebody learned last time that the person estimating this time needs. Every one of those is a question that comes up in real planning, and every one is unanswerable from a Done flag.

How DeliverySheet defines it

Completion is derived, not a status somebody sets: a demand is complete when it is committed, the delivery outcome is recorded, and the lesson is written. There is no "mark as done" — you reach the state by writing the two things, or you do not reach it.

That has a visible consequence: Completed is its own bucket, kept distinct from Closed (declined or archived), and excluded from the active pipeline so the in-flight count stays honest. A demand that was abandoned shows as closed, not as completed, and the two are never summed.

Nothing is ever hard-deleted, so a year later the record is still there — including the demands that went badly, which are the ones worth reading.