Observation:
“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.