Status Is a Vocabulary, Not a State Machine

In the Development Coordination Protocol, status enumerations are a vocabulary of states, not a state machine — DCP enforces no transitions. A field like Task.status or Decision.status records what a producer asserts happened; it never checks whether that change was a “legal” move from the prior value. Enforcing allowed transitions is workflow-engine territory, and that is explicitly outside DCP’s scope.

A verb records, it does not authorize

Every DCP event pairs an entity_type with a verb (together forming message_type, e.g. task.completed or decision.accepted). A verb communicates that a change was recorded; it MUST NOT be interpreted as authorization for a transition. A review_request.approved event is a record that an approval occurred — not a green light for anything downstream to act on. That interpretation stays consistent with the protocol’s prime directive: DCP carries no trust, so a status change carries no permission either.

This is a deliberate omission, not a gap. DCP defines no notion of “from this status you may only go to that status.” A Task can move from blocked straight to completed in one message, and a conformant consumer accepts it without complaint, because DCP is not the layer that decided whether that jump made sense. Some other system — a project tracker, an orchestration engine, a human process — owns that judgment.

Growable fields are open tokens, not closed enums

Seven classification fields across the entity model are open tokens with a controlled vocabulary rather than closed enums: status, verb, priority, severity, impact_level, dependency_type, and review_type. The v1 spec ships a starting vocabulary — universal verbs like created, updated, status_changed, snapshot, deleted, plus entity-specific ones such as Task.completed, Finding.raised, Decision.superseded, Milestone.reached — but that list is not exhaustive by design.

Because these fields are open, adding a new value to the vocabulary is not a breaking change. A producer can start emitting task.escalated next month, and existing consumers must not reject the message just because they have never seen that verb before. The versioning rules are explicit about this: consumers MUST tolerate-and-pass unknown values — accept the message, keep the unrecognized token intact, and let a downstream system that understands it act accordingly. Silently dropping or erroring on an unfamiliar status defeats the purpose of an open vocabulary.

What stays closed, and why

Only two vocabularies in DCP are closed sets: entity_type (the eight nouns — Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone) and the rel vocabulary used in refs (relates_to, part_of, references, caused_by, derived_from, supersedes, concerns, blocks). These stay closed because they are structural, single-responsibility guards on the shape of the protocol itself, not descriptive project state. Changing either is a major-version concern, published under a new schema namespace, exactly like any other breaking change.

The asymmetry is the point: structure is closed so the envelope stays predictable and machine-parseable; vocabulary is open so the protocol can describe whatever states real teams actually use, including ones nobody anticipated at v1.0.

Why not just build a state machine?

A workflow engine that enforces allowed transitions is a legitimate, useful thing — it just is not DCP’s job. DCP’s non-goals are explicit: no planner, no scheduler, no approval engine, no orchestration or execution engine. If DCP hard-coded which status could follow which, it would be quietly imposing one team’s workflow on every team that adopts the protocol, and every workflow variation would force a protocol change instead of a configuration change in some other layer.

By staying a pure vocabulary, DCP remains a description of what happened rather than a gatekeeper of what is allowed to happen next. A Finding can go raised → resolved → raised again if reality actually looped that way; DCP records the sequence faithfully instead of rejecting it as invalid. That is what “no trust, no transitions” buys you: a protocol thin enough to sit under any team’s actual process, described with real numbers as of 2026-07-03 across 8 entities, 14 JSON Schemas, and 25 conformance cases in the reference implementation.

By InterIP Networks · Last updated 2026-07-01.