The Eight Entities Reference

DCP defines exactly eight entity types — Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, and Milestone — the closed set of nouns an Event.entity_type may name. Every entity object uses opaque identifiers, sets additionalProperties: false, and accepts an optional namespaced extensions map. No ninth entity exists in v1.

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

The vocabulary-not-machine rule

Every entity below carries a status (or equivalent) field described as a vocabulary of states, not a state machine (SPEC §6). DCP enforces no transitions between these values. A message asserting status: "completed" does not imply the record previously held status: "in_progress", and no DCP component checks, blocks, or rejects a transition as “invalid.” Producers state a status; consumers tolerate and pass through any value they don’t recognize. See Status Is a Vocabulary for the full rationale.

This framing matters because entity fields elsewhere read like workflow controls — approved, accepted, blocks — and DCP’s prime directive is that none of them are. The notes under each entity below spell out exactly what is and isn’t asserted.

Why eight, and why closed

entity_type is a closed enum, guarded at the major version. Adding a ninth entity is a breaking change under DCP’s versioning rules — unlike the verb vocabulary, which is open and forward-compatible, or rel in refs, which is closed for a different reason (routing-relation exclusion). Closing entity_type keeps every conformant consumer able to enumerate, statically, every shape of entity object it might ever receive. As of 2026-07-01 the repository ships 14 JSON Schemas (2020-12) covering the envelope, the Event, and these eight entities, backed by 70 passing tests and 18 worked examples.

Project

Schema: https://schemas.devcopro.org/v1/project.schema.json

The top-level unit of coordination that other entities scope themselves to via project_id.

Required: id, name, status Notable optional: description

status draws from a controlled vocabulary (proposed, active, paused, completed, archived, cancelled) — again, a label, not a lifecycle enforced by DCP.

{
  "id": "project_dcp",
  "name": "Development Coordination Protocol",
  "status": "active"
}

Task

Schema: https://schemas.devcopro.org/v1/task.schema.json

A unit of work within a project.

Required: id, project_id, title, status Notable optional: description, priority, milestone_id, responsible_party

Normative note: a Task carries no inline dependency list. Any statement that one task blocks, requires, or relates to another is expressed exclusively through a Dependency entity — never as a field on the Task itself. responsible_party is descriptive, untrusted project metadata; it conveys no identity, authority, or work assignment (see Carries No Trust). priority is likewise a descriptive label, not a scheduler directive.

{
  "id": "task_schema_validation",
  "project_id": "project_dcp",
  "title": "Implement DCP schema validation",
  "status": "todo",
  "priority": "high"
}

Dependency

Schema: https://schemas.devcopro.org/v1/dependency.schema.json

Required: id, from_id, to_id, dependency_type Notable optional: description

Normative note: Dependency is the only representation of inter-entity dependencies in DCP. It describes a stated relationship (vocabulary includes blocks, requires, relates_to, duplicates, supersedes); DCP performs, enforces, orders, or schedules nothing on the basis of it. A blocks dependency is a statement that one item is considered a prerequisite for another — not an instruction to a scheduler or orchestrator.

{
  "id": "dep_review_before_merge",
  "from_id": "task_merge_pr_42",
  "to_id": "review_pr_42",
  "dependency_type": "blocks"
}

ArchitectureImpact

Schema: https://schemas.devcopro.org/v1/architecture-impact.schema.json

A stated assessment of how a change affects a system’s architecture.

Required: id, subject_ref, impact_level, description Notable optional: affected_areas, migration_notes

impact_level draws from none, low, moderate, high, breaking — breaking subsumes any breaking-change flag, so there is no separate boolean to reconcile. affected_areas holds opaque component labels; they are descriptive only, never routing targets.

{
  "id": "arch_auth_token_format",
  "subject_ref": "task_rotate_auth_tokens",
  "impact_level": "breaking",
  "description": "Changes the token serialization format consumed by all downstream services."
}

Decision

Schema: https://schemas.devcopro.org/v1/decision.schema.json

An ADR-style record of a decision that was made.

Required: id, title, decision, status Notable optional: context, alternatives, consequences, supersedes, refs

Normative note: a Decision records an outcome; DCP grants no authority and gates nothing on it. A status of accepted is a record that an acceptance occurred — not an authorization token that some other system is obliged to honor. Whatever process decided to accept the decision happened outside DCP; DCP only carries the record of it.

{
  "id": "decision_use_json_schema_2020_12",
  "title": "Adopt JSON Schema 2020-12 for all DCP entities",
  "decision": "All entity and envelope schemas will target the 2020-12 draft.",
  "status": "accepted"
}

ReviewRequest

Schema: https://schemas.devcopro.org/v1/review-request.schema.json

A record that a review was requested and, over time, its outcome.

Required: id, subject_ref, status Notable optional: review_type, requested_reviewers, summary, finding_ids

Normative note: DCP grants no approval authority and gates nothing. A status of approved is a record that an approval event occurred, not an authorization to proceed — a separate system decides what, if anything, to do with that record. requested_reviewers is descriptive, untrusted metadata: free-form opaque labels, never authenticated principals and never a binding work assignment.

{
  "id": "review_pr_42",
  "subject_ref": "task_merge_pr_42",
  "status": "requested",
  "review_type": "code",
  "requested_reviewers": ["agent-reviewer-1"]
}

Finding

Schema: https://schemas.devcopro.org/v1/finding.schema.json

A stated finding — an issue, observation, or risk — about a subject.

Required: id, subject_ref, severity, title, status Notable optional: category, description, location

severity is an ordered vocabulary from info up to critical. Normative note: location.path is a descriptive locator only and MUST NOT be passed to filesystem, shell, or URL APIs without independent sanitization — it is not a file-access grant, and a producer’s claim about a path is not a safety guarantee for a consumer that dereferences it.

{
  "id": "finding_unsanitized_path_reference",
  "subject_ref": "task_schema_validation",
  "severity": "high",
  "title": "location.path treated as trusted filesystem input",
  "status": "open",
  "location": { "path": "src/handlers/finding.ts", "line": 42 }
}

Milestone

Schema: https://schemas.devcopro.org/v1/milestone.schema.json

A significant, stated checkpoint within a project.

Required: id, project_id, name, status Notable optional: description, target_date, criteria

Normative note: target_date is descriptive intent only. DCP derives no deadline state and performs no scheduling on the basis of it. A status of missed is a reported observation — something a producer chose to assert — not a DCP-computed verdict derived by comparing target_date to the clock.

{
  "id": "milestone_v1_schema_freeze",
  "project_id": "project_dcp",
  "name": "v1 schema freeze",
  "status": "reached",
  "target_date": "2026-06-30"
}

Shared shape across all eight

Every entity schema above follows the same structural rules, defined once in SPEC §3 and §6:

• Identifiers are opaque strings matching ^[a-z]+_[A-Za-z0-9._-]+$ (≤128 chars). The prefix (task_, finding_, …) is a readability convention only — never an authority, namespace claim, or routing token.
• additionalProperties: false on every entity object — no undeclared fields, ever.
• extensions is optional on every entity, keyed ^x-[a-z][a-z0-9-]*$, and MUST be ignorable by any consumer that doesn’t recognize a given key. There is no must-understand flag.
• Field-length bounds (e.g. title ≤256 chars, most free-text fields ≤4000 chars) are normative baselines — see the individual schemas for exact limits.

An entity object appears inside an Event’s entity field (full snapshot) or is referenced by id from a delta or via refs using the closed rel vocabulary. See worked examples for all eight entities appearing in complete envelope messages.