A decision point in a meeting. Multiple valid paths exist, and each carries a different cost.

The facilitator summarizes one path in a sentence. Nobody objects strongly. The sentence becomes the minutes. The minutes become the record.

Weeks later, the record is cited as “we agreed on X.”

The room was not agreement. The room was nobody wanting to spend the air to object. Silence was read as consent, wording was read as choice, and the artifact was promoted from transcript to decision (FN-0009).

Implication:

Minutes are artifacts, not reality. They record what was said, not what was concluded, and the distance between those two is usually bigger than it looks at the moment of writing.

Treating minutes as decision artifacts creates phantom consensus. A shared fiction that everyone aligns to, even though nobody chose it explicitly, and nobody feels responsible for it later when the cost comes due.

In long-running projects, the mechanism accumulates. Each meeting contributes a few phantom agreements. The project carries an ever-larger load of commitments that were never deliberately made, and by the end, the project is governed more by its record than by its decisions.

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

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

Ask the engineer where the project is, and the answer is in terms of components: what builds, what passes tests, what is still uncertain.

Ask the project manager, and the answer is in terms of milestones: what is on track, what slipped, what changed scope.

Ask the manager, and the answer is in terms of commitments: what was promised, what is at risk, what is green, yellow, or red.

Ask the sponsor, and the answer is in terms of outcomes: what was delivered, what was paid for, what the project demonstrates about the decision to fund it.

Ask the client, and the answer is in terms of experience: what they can use today, what they were told to expect, what is still missing.

Each answer is defensible from its role’s perspective. Each answer is internally consistent. Collectively, they do not compose a single map (FN-0009).

Implication:

“Status” is not a shared object. It is a set of views that never fully overlap, each shaped by the vocabulary of the role that produced it.

Alignment is not achieved by informing stakeholders. It is achieved by reconstructing a composite view across the roles, and this reconstruction is itself a deliverable that rarely has an owner.

Projects fail less often because stakeholders disagree about where the project is, and more often because no one notices they are reading different maps.

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