Roles & Responsibilities (RACI) Card

Appendices

A one-page reference for who owns what across the framework's six operational activities. Use it during the Intent Design Session (phases 3 and 6 in particular), in Proportional Governance reviews, and in onboarding new team members to a system that is already running.

RACI legend

The standard responsibility-assignment shorthand:

The framework's discipline is broken when A is unclear ("we're all accountable" = no one is) or when A is held by someone with no operational authority over the activity. Both failures are common; both produce the diffuse responsibility failure mode named in Calibrate Agency, Autonomy, Responsibility, Reversibility §"Responsibility."

The seven roles

The framework assumes seven roles. Two people may share a role; one person should not hold more than one role on the same system unless the system is small enough that a one-person practice is honest. The five roles required to run an Intent Design Session (spec author, architect, operator, domain owner, skeptic) are a subset of these seven.

Two roles intentionally absent from this matrix: executive sponsor (who funds the work and is Informed at major milestones — they show up in the project's parent governance, not in the per-system RACI) and end user (whose voice belongs in framing via the domain owner, not as a separate RACI row, because end users do not typically have operational authority over framework activities).

The six activities

Six operational activities, finer-grained than the four canvas activities. The mapping:

The canvas's four activities are the spine of the discipline; the RACI's six are the ownership-assignment grain. Both vocabularies are correct for their purpose.

The matrix

A = accountable (one per activity); R = responsible (does the work); C = consulted; I = informed.

Read across each row to find who does what for that activity. Read down each column to find a single person's responsibilities across the system's lifecycle.

How to read each row

Frame. Domain owner is accountable — the goal is theirs. Spec author and architect both do the work: the spec author captures the framing in §1–§2, the architect drives the archetype commitment and the dimensional calibration. Operator is consulted (operational implications); skeptic is consulted (failure modes that should be designed against, not against). Builder is informed; they will implement later.

Specify. Spec author is both accountable and responsible — they own the artifact. Architect, builder, operator, domain owner are all consulted because the spec encodes everyone's commitments. Reviewer is informed (will validate against this spec later). Skeptic is consulted on §6 invariants and §10 open questions.

Build. Builder is accountable for the implementation matching the spec; their team is responsible. Spec author is consulted whenever ambiguity surfaces (which should trigger a §10 entry, not a guess). Architect is consulted on adherence to the archetype's invariants. Operator is consulted on operational requirements (what the runtime needs from the implementation).

Oversee. Operator is accountable for the oversight model running. Reviewer is responsible for actually doing reviews when the gate fires. Spec author is consulted when reviewer judgment surfaces ambiguity in the spec — this is the input that drives spec evolution. Skeptic is consulted for periodic red-team passes.

Ship. Operator is accountable for the deployment surface — canary, rollback, versioning. Builder and reviewer are responsible for the mechanical execution. Spec author is consulted to confirm the deployment matches the spec version. Skeptic is consulted on go/no-go for high-stakes shipments.

Evolve. Spec author is accountable — spec evolution is theirs. Everyone is consulted because amendments may touch any role's commitments. Reviewer's findings during oversight are the primary input for evolution; skeptic's audits surface drift.

Common patterns

Two-Rs-and-an-A is normal. Most activities have one A and several Rs. RACI doesn't forbid this; it forbids no A or multiple As.

The same role can be A across multiple activities. Operator is A for Oversee and Ship. Spec author is A for Specify and Evolve. This is fine — it's the same human owning a coherent slice of lifecycle. What's not fine is changing A across activities without explicit handoffs.

Skeptic is C, never A. The skeptic's value comes from not having operational ownership. Making the skeptic A turns them into an operator with a contrarian's job description, which is structurally weaker than a non-owning critic with periodic review authority.

Domain owner accountability stops at Frame. After Frame, domain owner is C or I. The framework's discipline is that the domain owner commits to the goal during Frame and then defers operational decisions to the architect, builder, operator, and reviewer. Domain owners who try to stay A through Build or Oversee end up micromanaging implementation.

Anti-patterns

Everyone is A. "We're all accountable for shipping safely." This is the diffuse-responsibility failure mode named in the Calibration chapter. Diagnose by asking "if the system causes an incident at 3am, who gets paged?" The answer is the operator; that is the A for Oversee and Ship.

No one is consulted before action. Activities run with zero Cs — the work happens, then everyone is Informed. This is the retrofit anti-pattern from the discipline-health audit: consultation surfaces disagreement before the work, which is when disagreement is cheapest to resolve.

Reviewer is informed, not responsible. A common drift in oversight kabuki: the reviewer is listed in §11 of the spec as the human at the gate, but in the RACI they're shown as I. That contradiction means the gate is firing without anyone responsible for the judgment. Either promote the reviewer to R (with the time and authority to do real review) or downgrade the gate (move from Output Gate to Periodic).

Skeptic absent from the RACI entirely. Some teams forget to include a skeptic role at all. Their first incident reveals the failure mode the skeptic would have asked about during Frame. The skeptic's column in this matrix is mostly C — that is the role's correct shape, and it has to exist.

Sponsor as A. "The VP is accountable for this system." Operationally, the VP cannot be paged at 3am, cannot review the next spec amendment, cannot fire the oversight gate. They are informed of major milestones, not accountable for daily operation. If a sponsor wants accountability, they need to designate an operator and a spec author and accept that the operational A sits with them.

Connections

• The Intent Design Session — the IDS is where the RACI is enacted. Phase 1 establishes domain-owner accountability; phases 2–3 establish architect responsibility; phase 6 establishes operator accountability for oversight.
• Calibrate Agency, Autonomy, Responsibility, Reversibility — Responsibility as a calibration dimension is what this card operationalizes; the dimension names authorial / operational / validation sub-loci, and this RACI maps them to actual roles.
• Proportional Governance — the governance practice that runs against this RACI.
• Adoption Playbook — the adoption practice that introduces these roles to a team progressively, rather than all at once.
• Signs Your Architecture of Intent Is Degrading — the audit that catches RACI drift, particularly the oversight kabuki and diffuse-responsibility anti-patterns.

This card is intentionally short. If your team needs a finer-grained ownership matrix per system — for example, separating reviewer-of-Cat-1-failures from reviewer-of-Cat-2-failures — extend the matrix in your team's repertoire. The card here is the canonical baseline, not the only acceptable shape.