Worked Examples

A worked example is a complete, schema-valid DCP message — the DcpMessage envelope plus its body, copied verbatim from the repository. These nine messages are language-neutral: no SDK, client library, or transport is required to read or produce them. Each one validates against the schemas at https://schemas.devcopro.org/v1/ and can be re-checked locally with node reference/validate.mjs examples/v1/<file> — part of the suite of 70 passing tests as of 2026-07-03.

Every example below also satisfies the rule that pure JSON Schema cannot express on its own: message_type must equal <entity_type>.<verb> from the body. A validator has to check this cross-field equality explicitly: on conflict, the body is authoritative and the message is malformed. See the Event reference for why this rule exists and entities and verbs for the full vocabularies each example draws from.

The gallery opens with decision.recorded and finding.raised — the two entities that a comparable protocol like A2A has no dedicated model for — then moves through the task lifecycle, milestone, dependency, review request, project, and architecture-impact examples. If you are new to DCP, read the quickstart first, or start with why a coordination vocabulary exists at all.

decision.recorded

Captures an architectural decision — including its context, the chosen option, rejected alternatives, and consequences — as a durable, referenceable record.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0DECISION0001",
  "message_type": "decision.recorded",
  "issued_at": "2026-06-29T10:12:00Z",
  "body": {
    "event_id": "evt_01HZ0DECISION0001",
    "entity_type": "decision",
    "verb": "recorded",
    "entity_id": "decision_thin_envelope",
    "attributed_to": "dcp-working-group",
    "entity": {
      "id": "decision_thin_envelope",
      "title": "Use a thin, semantics-only DCP envelope",
      "context": "DCP must remain a pure semantic layer, fully separated from the transport layer.",
      "decision": "The DcpMessage envelope carries only semantic fields (version, ids, type, correlation) and exactly one Event. Transport, trust, identity, and routing remain entirely in the transport layer.",
      "status": "accepted",
      "alternatives": [
        {
          "summary": "Entity-only messages with no envelope",
          "rejected_reason": "Two parties could not interoperate on DCP alone without first agreeing a transport."
        },
        {
          "summary": "A full REST-style hypermedia document model",
          "rejected_reason": "Heavier than v1 needs and drifts toward an API contract rather than a communication protocol."
        }
      ],
      "consequences": "DCP stays independently readable and validatable; overlap with transport ids is allowed because the purpose differs."
    }
  }
}

finding.raised

Reports an issue discovered during review — here, a naming concern about the envelope’s attributed_to field — and links it back to the decision it concerns via refs.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0FINDINGRAIS1",
  "message_type": "finding.raised",
  "issued_at": "2026-06-29T10:20:00Z",
  "correlation_id": "msg_01HZ0REVIEWREQ001",
  "body": {
    "event_id": "evt_01HZ0FINDINGRAIS1",
    "entity_type": "finding",
    "verb": "raised",
    "entity_id": "finding_actor_rename",
    "attributed_to": "security-reviewer",
    "entity": {
      "id": "finding_actor_rename",
      "subject_ref": "review_envelope_design",
      "severity": "medium",
      "category": "security",
      "title": "Rename 'actor' to 'attributed_to' to avoid identity confusion",
      "description": "The term 'actor' reads as an authenticated principal; a name that signals unverified attribution reduces trust-confusion.",
      "location": { "ref": "schemas/v1/event.schema.json" },
      "status": "resolved"
    },
    "refs": [
      { "rel": "concerns", "ref": "decision_thin_envelope" }
    ]
  }
}

task.created

Announces a new unit of work, scoped to a project via entity.project_id, with a todo status and a priority.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0TASKCREATED1",
  "message_type": "task.created",
  "issued_at": "2026-06-29T10:01:00Z",
  "correlation_id": "msg_01HZ0PROJECT0001",
  "body": {
    "event_id": "evt_01HZ0TASKCREATED1",
    "entity_type": "task",
    "verb": "created",
    "entity_id": "task_schema_validation",
    "attributed_to": "agent-builder",
    "entity": {
      "id": "task_schema_validation",
      "project_id": "project_dcp",
      "title": "Implement DCP schema validation",
      "description": "Author the JSON Schema 2020-12 documents for the envelope, event, and eight entities.",
      "status": "todo",
      "priority": "high"
    }
  }
}

task.completed

Reports a state transition on that same task using delta rather than a full entity snapshot — only the status field’s before/after values are carried.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0TASKDONE0001",
  "message_type": "task.completed",
  "issued_at": "2026-06-29T12:30:00Z",
  "correlation_id": "msg_01HZ0TASKCREATED1",
  "body": {
    "event_id": "evt_01HZ0TASKDONE0001",
    "entity_type": "task",
    "verb": "completed",
    "entity_id": "task_schema_validation",
    "occurred_at": "2026-06-29T12:29:30Z",
    "attributed_to": "agent-builder",
    "delta": {
      "status": { "from": "in_progress", "to": "completed" }
    }
  }
}

milestone.reached

Signals that a set of completion criteria for a project checkpoint has been satisfied, listing each criterion that was met.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0MILESTONE001",
  "message_type": "milestone.reached",
  "issued_at": "2026-06-29T13:00:00Z",
  "body": {
    "event_id": "evt_01HZ0MILESTONE001",
    "entity_type": "milestone",
    "verb": "reached",
    "entity_id": "milestone_v1_schemas",
    "occurred_at": "2026-06-29T12:55:00Z",
    "attributed_to": "dcp-working-group",
    "entity": {
      "id": "milestone_v1_schemas",
      "project_id": "project_dcp",
      "name": "v1 schemas complete",
      "description": "All envelope, event, and entity schemas authored and validating.",
      "status": "reached",
      "target_date": "2026-06-29",
      "criteria": [
        "Ten schemas exist and load",
        "All examples validate",
        "Conformance corpus passes"
      ]
    }
  }
}

dependency.created

Declares an ordering constraint between two tasks — from_id requires to_id — using the dependency_type field rather than the closed rel vocabulary, since this is an entity in its own right, not a reference.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0DEPCREATED01",
  "message_type": "dependency.created",
  "issued_at": "2026-06-29T10:05:00Z",
  "body": {
    "event_id": "evt_01HZ0DEPCREATED01",
    "entity_type": "dependency",
    "verb": "created",
    "entity_id": "dep_examples_need_schemas",
    "entity": {
      "id": "dep_examples_need_schemas",
      "from_id": "task_write_examples",
      "to_id": "task_schema_validation",
      "dependency_type": "requires",
      "description": "Examples can only be authored once the schemas they validate against exist."
    }
  }
}

review_request.created

Requests review of the thin-envelope decision, naming the reviewers and the subject under review via subject_ref.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0REVIEWREQ001",
  "message_type": "review_request.created",
  "issued_at": "2026-06-29T10:15:00Z",
  "correlation_id": "msg_01HZ0DECISION0001",
  "body": {
    "event_id": "evt_01HZ0REVIEWREQ001",
    "entity_type": "review_request",
    "verb": "created",
    "entity_id": "review_envelope_design",
    "attributed_to": "dcp-working-group",
    "entity": {
      "id": "review_envelope_design",
      "subject_ref": "decision_thin_envelope",
      "review_type": "architecture",
      "status": "requested",
      "requested_reviewers": ["security-reviewer", "architecture-reviewer"],
      "summary": "Please review the thin-envelope decision for single-responsibility correctness."
    }
  }
}

project.snapshot

Publishes the current state of a project as a whole, rather than a single field change — the DCP project itself, named and described.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0PROJECT0001",
  "message_type": "project.snapshot",
  "issued_at": "2026-06-29T10:00:00Z",
  "body": {
    "event_id": "evt_01HZ0PROJECT0001",
    "entity_type": "project",
    "verb": "snapshot",
    "entity_id": "project_dcp",
    "occurred_at": "2026-06-29T09:59:00Z",
    "attributed_to": "dcp-working-group",
    "entity": {
      "id": "project_dcp",
      "name": "Development Coordination Protocol",
      "description": "An open, vendor-neutral semantic protocol for exchanging project-coordination information between agents and humans.",
      "status": "active"
    }
  }
}

architecture_impact.assessed

Records the assessed impact of the thin-envelope decision on the codebase’s architecture, including affected areas and migration notes.

{
  "dcp_version": "1.0",
  "message_id": "msg_01HZ0ARCHASSESS01",
  "message_type": "architecture_impact.assessed",
  "issued_at": "2026-06-29T10:10:00Z",
  "body": {
    "event_id": "evt_01HZ0ARCHASSESS01",
    "entity_type": "architecture_impact",
    "verb": "assessed",
    "entity_id": "arch_envelope_split",
    "attributed_to": "architecture-review",
    "entity": {
      "id": "arch_envelope_split",
      "subject_ref": "decision_thin_envelope",
      "impact_level": "moderate",
      "affected_areas": ["dcp-message", "event"],
      "description": "Keeping the DCP envelope thin (semantics only) preserves the transport/semantic layering invariant.",
      "migration_notes": "None; this is the initial v1 design."
    }
  }
}

Validating these examples yourself

Every message above ships in the repository under examples/v1/ and is exercised by the project’s test suite. To validate any one of them locally, run node reference/validate.mjs examples/v1/<file> from the repo root — the same check that keeps all 70 tests passing. If you are building a producer or consumer, start from the quickstart and cross-reference the entities and verbs each message uses.

Vendor-domain worked examples: the AgentsWeaver job lifecycle

Beyond the nine core examples above, the repository ships nine job-lifecycle examples (examples/v1/job.*.json) from the first ratified external consumer agreement: a job broker mapping created / leased / completed / failed / requeued / cancelled / quarantined onto task events with a stable entity_id and the registered x-agentsweaver extension namespace. They are deliberately kept separate from the core set: they demonstrate a vendor-domain pattern, not core vocabulary. The full pattern — including the consumer-side reading rules and the requeue-versus- resubmission decision rule — is documented in How to Emit Job-Lifecycle Events.

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