Skip to content

Carries No Trust

DCP carries no trust. DCP describes project-state changes only.

That is the prime directive of the Development Coordination Protocol, and every design decision in the spec flows from it.

A DCP message is untrusted data carried by a transport. The transport — a message queue, an HTTP endpoint, a secure mesh like AgentixMesh — is responsible for delivery, identity verification, and access control. DCP is responsible only for the semantic payload: what changed in the project.

DCP never:

  • Authenticates a sender
  • Authorizes an action
  • Routes a message to a recipient
  • Plans or schedules work
  • Orchestrates agents
  • Executes anything

These responsibilities belong to the transport layer. DCP lives one layer up: the semantic layer.

LayerResponsibility
TransportSecure channel, identity, permissions, trust, discovery, routing, agent wake-up, message delivery
DCP (semantic)Project status, tasks, dependencies, architecture impact, decisions, review requests, findings, milestones — and the events that record their changes

A message arriving over an authenticated, encrypted channel is still an untrusted DCP payload. The receiver decides what to do with the information. DCP makes no claims about who sent it or whether the described change should be acted upon.

Several DCP fields look like they convey authority. They do not:

  • attributed_to — records who (or what) is associated with the change in project terms. It is descriptive metadata, not a verified identity claim. The transport must authenticate; DCP merely notes.
  • responsible_party on a Finding — the team or role named as responsible in project terms. Not an authorization.
  • requested_reviewers on a ReviewRequest — a list of who was asked, in project terms. It does not route the message to those parties; that is the transport’s job.

None of these fields convey identity, authority, routing obligation, or authorization. They are project metadata — the same kind of information you might write in a ticket tracker.

  • A ReviewRequest with approved status is a record that approval occurred — not an authorization token to proceed. The system consuming the event decides whether to act on that record.
  • A Decision with accepted status is a record — not a credential that authorizes downstream changes.

This distinction matters for security. If your system acts on a DCP event without independent verification, you are extending trust to the transport, not to DCP.

The refs vocabulary is intentionally limited

Section titled “The refs vocabulary is intentionally limited”

The refs.rel field uses a closed vocabulary. The permitted values are:

relates_to, part_of, references, caused_by, derived_from, supersedes, concerns, blocks

Notably absent: routes_to, approved_by, authorized_by, assigns_to. DCP has no routing or permission relations because DCP carries no trust.

The Finding.location.path field describes where in a codebase a finding was located — it is a string for human and tool consumption. It MUST NOT be passed directly to filesystem, shell, or URL APIs without independent sanitization. A malicious or malformed message could contain a path designed to escape expected directories. Treat it as untrusted user input.

For full treatment of security considerations, see SECURITY.md in the repository.

Separating trust from semantics makes DCP genuinely vendor-neutral. You can adopt the protocol with any agent runtime, any message broker, any access-control system. The protocol never forces you to adopt a particular identity model or trust topology. The meaning of “task_42 completed” is the same regardless of how the message was delivered or who delivered it — but whether to act on that meaning is entirely up to your system and your transport.