DCP FAQ
Straight answers to the questions that come up most when people first encounter the Development Coordination Protocol (DCP) — what it is, what it deliberately refuses to do, and how to work with it correctly.
What is DCP in one sentence?
Section titled “What is DCP in one sentence?”DCP is an open, vendor-neutral, machine-readable semantic protocol that defines the structure of project-coordination messages — status, tasks, dependencies, architecture impact, decisions, review requests, findings, milestones — exchanged between AI agents and humans. It does not define transport, identity, trust, or execution; see why a coordination vocabulary exists at all.
How is DCP different from A2A, which already has a Task lifecycle?
Section titled “How is DCP different from A2A, which already has a Task lifecycle?”A2A models agent-to-agent interaction: a Task lifecycle and Artifacts for exchanging work products between two agents. DCP models a different, broader problem — project coordination across eight entities (Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone) that A2A has no vocabulary for, such as recording a Decision, a Finding, or a Milestone. At the payload-semantics layer the two are complementary rather than competing: an A2A Task can carry a DCP event as its payload. See the full breakdown at DCP vs A2A.
Does DCP carry trust or authenticate anyone?
Section titled “Does DCP carry trust or authenticate anyone?”No — this is DCP’s prime directive: “DCP carries no trust. DCP describes project-state changes only.” Every field in a DCP message is untrusted data, and DCP itself never authenticates a sender, authorizes an action, routes a message, or executes anything. Identity, permissions, and delivery guarantees are the transport layer’s job, not DCP’s. Read the full treatment at carries no trust.
What transport does DCP use?
Section titled “What transport does DCP use?”Any transport, or none — DCP is transport-neutral by design. A DCP message can travel over a message queue, an HTTP endpoint, a secure mesh such as AgentixMesh, a file, or a database row, and it remains independently readable and validatable outside that envelope. Moving a DCP message between transports is a transport swap, not a rewrite: the message body is never rewritten at the boundary. See the event reference for what travels inside that envelope.
Is message_type authoritative?
Section titled “Is message_type authoritative?”No — the body is. message_type is a denormalized convenience copy of <entity_type>.<verb>, included for human and operator readability. A conformant validator MUST check that message_type equals body.entity_type + ”.” + body.verb; on a conflict, the body wins and the message is treated as malformed. This is a rule plain JSON Schema cannot express on its own — a conformant implementation has to add it as a separate cross-field check. A transport MUST NOT route, authorize, or trust anything on the basis of message_type alone.
Can I add my own fields?
Section titled “Can I add my own fields?”Yes, through the extensions object — never as new top-level fields on the core schema, which is intentionally closed. Every extension key must match the pattern x-<vendor> (for example x-tokonomix or x-github), extensions are always optional with no “must-understand” flag, and a conformant consumer must be able to ignore any extension it doesn’t recognize. Extensions must never be used to smuggle transport, trust, identity, or routing data — reserved-looking keys like x-auth-* or x-signed-* carry no authority even if present.
Does a status like “approved” authorize anything?
Section titled “Does a status like “approved” authorize anything?”No. A ReviewRequest with status approved is a record that an approval occurred — not an authorization to proceed. The same logic applies to a Decision marked accepted: it is a record of what was decided, not a credential that unlocks downstream changes. DCP’s status enumerations are a vocabulary of states, not a state machine, and DCP enforces no transitions and gates nothing. Whether to act on the record is entirely up to the consuming system.
What license is DCP under?
Section titled “What license is DCP under?”DCP is dual-licensed to fit each part’s purpose. Source code, the 14 JSON Schemas, the reference validator, worked examples, and the conformance corpus are licensed under Apache License 2.0, which adds an explicit patent grant for implementers building commercial products. The specification text (SPEC.md) and the rest of the documentation are licensed under CC BY 4.0, so the spec can be freely quoted, translated, and republished with attribution.
What version is DCP at, and is it stable?
Section titled “What version is DCP at, and is it stable?”DCP is at v1.0.0-draft. Within a major version, only additive and optional changes are permitted — new optional fields, new values in open vocabularies like status or verb — so an older validator keeps accepting newer-but-compatible messages. Breaking changes, such as altering the closed entity_type or rel sets, require a new major version published under its own schema namespace. The schema $id host, https://schemas.devcopro.org/v1/, is canonical and permanent for v1 and will not be rebased within this major version. Governance of what counts as additive versus breaking is described at governance.
How do I validate a DCP message and check conformance?
Section titled “How do I validate a DCP message and check conformance?”Two steps, because one alone is insufficient. First, validate the message against the JSON Schema 2020-12 dcp-message schema (one of 14 schemas covering the envelope and all eight entities). Second, separately enforce the cross-field rule that message_type equals entity_type.verb — JSON Schema cannot express that check by itself. To self-certify an implementation in any language, run it against the language-neutral conformance corpus: 25 cases, 7 that must be accepted and 18 that must be rejected, as of 2026-07-03. The quickstart walks through composing and validating a first message end to end.
By InterIP Networks · Last updated 2026-07-01.
