Governance

DCP governance defines who decides what the protocol is, and how changes are proposed, reviewed, and recorded. Stewardship sits with the TokonoMix project, but DCP has no technical dependency on TokonoMix or any other system. Every proposal is measured against one non-negotiable rule: DCP defines only the structure of project communication.

By Mesut Kalkan · InterIP Networks · Last updated 2026-07-06.

Stewardship, not coupling

DCP was initiated by the TokonoMix project and is currently hosted under the TokonoMix GitHub organization. That is stewardship, not coupling — the specification is vendor-neutral and has no dependency on TokonoMix, AgentixMesh, or any other system, and it never will require them. As adoption grows, stewardship may move to a neutral organization (for example, a dedicated dcp-spec organization). GitHub redirects would keep old repository URLs working, so such a move is non-breaking. Whoever stewards the project, the single-responsibility and vendor-neutrality rules below stay binding. See what “vendor-neutral” means in practice for the related design boundary.

The three governing principles

1. Single responsibility is non-negotiable. DCP defines only the structure of project communication. Any proposal that adds transport, trust, identity, routing, permissions, planning, scheduling, workflow-engine, orchestration, or execution semantics is out of scope by definition — and will be declined regardless of technical merit, because that responsibility belongs to another layer.
2. Vendor-neutral. DCP must remain usable with no dependency on any specific vendor, transport, or product. Decisions are made in the interest of DCP as an open, vendor-neutral protocol, not any single implementation.
3. Backwards compatibility is a promise. Within a major version, changes are additive and optional. Anything breaking requires a new major version — see how versioning and compatibility work for the full policy.

What “normative” means

Text using RFC 2119 keywords (MUST, SHOULD, MAY, and related terms) in SPEC.md, together with the JSON Schemas under schemas/, is normative: conformant implementations must obey it. Everything in docs/, README.md, worked examples, and commentary is informative — useful context, but not binding. If the two ever disagree, the schemas and the normative SPEC text win.

Roles

• Maintainers review and merge changes, cut releases, and safeguard the single-responsibility boundary. Until the project formally elects a broader group, founding maintainer Mesut Kalkan (InterIP Networks) acts in this role.
• Contributors are anyone who opens an issue or pull request.
• Spec editors are maintainers specifically responsible for keeping SPEC.md, the schemas, and the conformance corpus consistent with one another.

The RFC-style change process

1. Issue or proposal. Changes start as an issue. Anything touching schemas, vocabularies, or normative text is written up RFC-style: motivation, proposal, alternatives considered, backwards-compatibility impact, and security/SRP impact.
2. Review. At least one maintainer reviews every change. Proposals with design or security weight get an architecture- and security-oriented review focused on the SRP boundary; independent, cross-checked review is encouraged for high-impact changes.
3. Decision of record. Accepted, significant decisions are recorded — an ADR under docs/ and/or the issue or pull-request thread — so the rationale survives beyond the discussion that produced it.
4. Implementation. A schema or vocabulary change must land with a worked example, conformance fixtures (both accept and reject cases), and a green test suite before merge.
5. Release. Versioning follows the spec’s compatibility rules and is recorded in CHANGELOG.md.

This process is why the reference implementation currently ships 14 JSON Schemas, 18 worked examples, and a conformance corpus of 25 cases (7 accept / 18 reject) backed by 70 passing tests, as of 2026-07-03 — every schema change on record had to clear that bar.

Versioning authority

Only a major-version bump may introduce breaking changes, including changing the closed entity_type or rel vocabularies, or removing or retyping a field. Additive, optional fields and new controlled-vocabulary values are minor changes; editorial or documentation fixes are patch changes. No maintainer, individually, can ship a breaking change outside a major release — that authority is structural, not personal.

Where to go next

• Read the prime directive behind the single-responsibility rule to see why scope decisions come out the way they do.
• Review the compatibility guarantees a major version protects before proposing a schema change.
• Learn more about the project on the about page.
• File an issue or open a pull request against the DCP source repository. Prefer a conversation first? Reach the maintainers through the DCP Assistant on the About page.