“Done” is not a technical property. It is an operational verdict, and its definition depends on who is making the call.

To the engineer, done means the component runs without error in at least one environment. To the QA team, it means the component passes the agreed tests. To the project manager, it means the component is listed on the delivery manifest. To the client, it means the component produces the expected result in their context. To the sponsor, it means the component has crossed the threshold for invoicing.

Each definition is coherent internally. At handoff, they collide (FN-0024).

Arguments about delivery quality at this moment look like disagreement but are often dictionary collisions. Nobody is wrong on their own terms. Everyone is wrong on the others’ terms.

Implication:

Acceptance criteria in project plans are meant to bridge these vocabularies. They rarely cover all five definitions, because writing them out surfaces ambiguity that the plan assumed was already resolved.

The cost of the vocabulary gap arrives precisely at the moment of delivery: disputes, rework, or the quiet relabeling of “done” as “demo-able,” of “demo-able” as “shipped,” of “shipped” as “invoiced.” Each relabel is small. The accumulated drift is the delivery.

Part of the Field Notes series documenting operational patterns observed in real-world platform architectures.

The engineer reports that the component is “mostly working.”

The project manager translates “mostly working” into “ready for testing.”

The manager translates “ready for testing” into “ready for demo.”

The sponsor hears “ready for demo” and prepares to communicate “ready to ship.”

At every translation step, ambiguity collapses in the direction of progress. Nobody deliberately inflates status. The inflation is structural: each party’s cautious signal is read by the next party as a confident one, because that is the reading that lets the project move forward.

By delivery day, the gap between assumed and actual readiness materializes at once. The same mechanism that reveals the true state of a platform during its first major incident (FN-0015) reveals the true state of the assumption chain during its first external commitment.

Implication:

The asymmetry is structural, not dishonest. Nobody escalates “we are not ready yet” as aggressively as they escalate “we are ready.”

Review rhythms that preserve the original vocabulary at every layer are safer than rhythms that translate at every step. The cost of ambiguity is paid once, at the source. The cost of translation is paid several times, on the day the delivery contract comes due.

Part of the Field Notes series documenting operational patterns observed in real-world platform architectures.