Verb Vocabulary Reference
A DCP verb describes what happened to an entity in a single Event. It is an open string (^[a-z][a-z_]*$, ≤64 characters) with a controlled vocabulary — not a closed enum — and combines with entity_type to form message_type as <entity_type>.<verb>.
Schema: https://schemas.devcopro.org/v1/event.schema.json
Open vocabulary, not a closed set
Section titled “Open vocabulary, not a closed set”Unlike entity_type (eight fixed nouns) and rel (the eight-value relation vocabulary in Event Schema Reference), verb is deliberately open. Producers may mint new verbs. Consumers MUST tolerate unknown verbs and pass them through rather than rejecting the message. This forward-compatibility posture lets the vocabulary grow — new task or finding verbs, for instance — without breaking existing consumers on a minor version bump. See Versioning and Compatibility for how that plays out across dcp_version changes, and Status Is a Vocabulary for the parallel design applied to entity status fields.
The v1 controlled vocabulary
Section titled “The v1 controlled vocabulary”The verbs below are the ones defined in SPEC §7. They are recommendations for interoperability, not an exhaustive whitelist a validator enforces against verb itself (the schema only enforces the lowercase-with-underscores pattern and length).
Universal
Section titled “Universal”Apply to any of the eight entities in Entity Reference.
| Verb | Meaning |
|---|---|
created | The entity was newly recorded. |
updated | One or more fields changed. |
status_changed | The entity’s status field changed value. |
snapshot | A full current-state snapshot of the entity is being shared. |
deleted | The entity was removed from the producer’s record. |
| Verb | Meaning |
|---|---|
completed | The task was marked done. |
blocked | The task became blocked. |
unblocked | A prior block was cleared. |
assigned | The task’s responsible_party was set or changed. |
Finding
Section titled “Finding”| Verb | Meaning |
|---|---|
raised | A new finding was reported. |
resolved | The finding was addressed. |
acknowledged | The finding was seen and accepted as valid, without yet being resolved. |
Decision
Section titled “Decision”| Verb | Meaning |
|---|---|
recorded | A decision was captured. |
accepted | The decision’s status moved to accepted. |
rejected | The decision was turned down. |
superseded | The decision was replaced by a later one (often paired with a supersedes ref — see Event Schema Reference). |
ReviewRequest
Section titled “ReviewRequest”| Verb | Meaning |
|---|---|
requested | A review was asked for. |
approved | The review concluded with approval. |
changes_requested | The review concluded asking for changes. |
rejected | The review request was declined. |
Milestone
Section titled “Milestone”| Verb | Meaning |
|---|---|
reached | The milestone was hit. |
missed | The milestone’s target was not met — a reported observation, not a DCP-computed verdict. |
ArchitectureImpact
Section titled “ArchitectureImpact”| Verb | Meaning |
|---|---|
assessed | An architectural change or risk was evaluated and recorded. |
Dependency
Section titled “Dependency”| Verb | Meaning |
|---|---|
created | A dependency between tasks or entities was declared. |
removed | A previously declared dependency no longer holds. |
A verb records, it does not authorize
Section titled “A verb records, it does not authorize”SPEC §7 states the key normative point plainly: a verb communicates that a change was recorded; it MUST NOT be interpreted as authorization for a transition. A review_request.approved message is a record that an approval occurred — it is not a signal that DCP gates any downstream action on. A decision.accepted message records that a decision was made — it is not an authorization token. DCP carries no trust and executes nothing; see the entity notes in Entity Reference for how this applies to each of the eight nouns.
message_type examples
Section titled “message_type examples”message_type is built by joining entity_type and verb with a dot. Three real examples, drawn from the repo’s worked examples:
task.completed— a Task moved to a completed state.decision.recorded— a Decision was captured.finding.raised— a new Finding was reported.
message_type must equal entity_type.verb
Section titled “message_type must equal entity_type.verb”Per SPEC §4.1, message_type is a denormalized convenience copy of <body.entity_type>.<body.verb> — it exists for human and operator readability, not as an independent source of truth. A validator MUST check that message_type equals <entity_type>.<verb> from the body; on conflict, the body wins and the message MUST be treated as malformed. This is the one rule plain JSON Schema cannot express on its own: enforcing equality between a top-level envelope field and two nested body fields is a cross-field constraint that a conformant DCP implementation must add on top of schema validation. See Event Schema Reference for the full Event field list that verb and entity_type belong to.
By InterIP Networks · Last updated 2026-07-01.
