MACP Examples
This repository includes illustrative transcripts for each standards-track mode and for policy-governed sessions.
Status: Non-normative (explanatory). In case of conflict, RFC-MACP-0001 is authoritative.
This repository includes illustrative transcripts for each standards-track mode and for policy-governed sessions.
Available example transcripts
| File | Mode | What it shows |
|---|---|---|
examples/decision-mode-session.json | macp.mode.decision.v1 | initialization, SessionStart, proposal, evaluations, objection, votes, and terminal Commitment |
examples/proposal-mode-session.json | macp.mode.proposal.v1 | offer, counteroffer, dual acceptance, and bound agreement |
examples/task-mode-session.json | macp.mode.task.v1 | bounded delegation, progress, completion, and bound task outcome |
examples/handoff-mode-session.json | macp.mode.handoff.v1 | responsibility transfer with context handoff and acceptance |
examples/quorum-mode-session.json | macp.mode.quorum.v1 | threshold approval leading to a final commitment |
examples/policy-decision-session.json | macp.mode.decision.v1 | policy-governed Decision Mode with supermajority voting, quorum, and critical-severity veto (RFC-MACP-0012) |
examples/policy-registration-exchange.json | N/A (gRPC exchange) | dynamic policy registration request and response (RFC-MACP-0012 Section 7) |
Single-envelope examples
Standalone Envelope examples, one per Core message type, each validating against its
$defs entry in schemas/json/macp-envelope.schema.json:
| File | Message type | $defs entry | RFC |
|---|---|---|---|
examples/json/signal.json | Signal | SignalPayload | RFC-MACP-0001 §6 |
examples/json/progress_ambient.json | Progress (ambient form) | ProgressPayload | RFC-MACP-0001 §6 |
examples/json/session_start.json | SessionStart | SessionStartPayload | RFC-MACP-0001 §7.1 |
examples/json/session_suspend.json | SessionSuspend | SessionSuspendPayload | RFC-MACP-0001 §7.5 |
examples/json/session_resume.json | SessionResume | SessionResumePayload | RFC-MACP-0001 §7.5 |
examples/json/session_cancel.json | SessionCancel | SessionCancelPayload | RFC-MACP-0001 §7.3 |
examples/json/commitment.json | Commitment | CommitmentPayload (whose optional supersedes/CommitmentRef fields are described in RFC-MACP-0001 §7.3.1) | RFC-MACP-0001 §7.3 |
SessionSuspendPayload/SessionResumePayload, CommitmentPayload's supersedes/
CommitmentRef fields, and SessionStartPayload.max_suspend_ms (not exercised by the example
above, which relies on the runtime default) were all added to the envelope schema this
reconciliation window (#162/#172, #161/#171, #156/#163 respectively).
Discovery, lifecycle, and runtime examples
Single-document examples that exercise non-transcript schemas:
Example shape
The canonical field mapping and payload encoding for every Envelope in these transcripts is
defined in RFC-MACP-0001 §10.1 (Field Mapping), §10.2 (Payload Encoding) —
this document does not restate it. The one repository-local convention: each transcript's
messages array is ordered, and that order is the replay order.
Note: The policy-governed examples (
policy-decision-session.json,policy-registration-exchange.json) use a simplifiedtranscriptarray with sequence numbers (seq) and condensed message representations. This format is intended to illustrate governance evaluation flow rather than serve as a wire-format reference. For canonical Envelope structure, refer to the standard mode transcripts. The simplification is cosmetic only for the Envelope framing: these two examples'rulesobjects are still validated in CI againstdecision-rules.schema.jsonby the policy-rules extractor (see docs/policy.md), so the governance rules themselves are held to the same standard as everywhere else.
What the examples demonstrate
Across the transcripts, the examples demonstrate:
- explicit initialization and capability negotiation,
- explicit
SessionStart, - session-scoped mode messages,
- version binding suitable for replay,
- a terminal
Commitmentthat resolves the Session, - policy resolution, governance evaluation, and deterministic commitment decisions (RFC-MACP-0012).
The important property is not the specific business scenario in each example. It is that every bound coordination event exists as a bounded transcript with a start, a lifecycle, and a terminal message.
Related: conformance fixtures
The examples above are illustrative. For machine-checked message sequences with per-message accept/reject expectations — consumed by SDK projection harnesses and the runtime conformance suite — see the canonical fixture pack in schemas/conformance/. Fixtures exist for every standards-track mode plus the ext.multi_round.v1 extension mode, and CI validates each fixture against the fixture-format schema and lints it for internal consistency.