Frameworks · Resource 06 of 15

Decision Frameworks

Five configurations of one decision model — DACI, RAPID, DARE, RASCI, and CAIRO — plus Sociocracy, with AI augmentation layers for 2026 and beyond.

11 min readDACIRAPIDSociocracy

What this guide is — and what it isn't

DACI, RAPID, DARE, RASCI, and CAIRO are variations on the same underlying idea: role clarity. Each acronym assigns people to roles in a decision or task. What differs is which roles they distinguish and what problem each distinction solves.

Presenting them as five separate "frameworks" to collect is misleading. This guide treats them as five configurations of one tool, organized by the specific breakdown they fix. Use the decision tree to find the right one for your situation.

The real CoS superpower

It isn't knowing all the acronyms. It's knowing which one your organization actually needs right now — and having the credibility to introduce it without it becoming shelfware.

The most common failure mode isn't choosing the wrong configuration. It's treating any configuration as a one-time deliverable rather than a living agreement that reflects the current state of the team.

⚠

Why this matters more in 2026

Gartner predicts that 80% of project management tasks will be automated by AI by 2030 — status reporting, dependency tracking, meeting capture, matrix drafting. A 2025 Gartner CIO survey found 0% of IT work will be done by humans without AI by 2030. The administrative work a CoS once owned is being absorbed. What remains is the judgment work — and these frameworks are the structure that makes human judgment legible to an organization.

Source: Gartner, "Digitalization's Impact on PPM Practices and the PMO by 2030" & Gartner IT Symposium/Xpo, Oct–Nov 2025

The Foundation

One model. Five configurations.

Every framework in this guide — DACI, RAPID, DARE, RASCI, CAIRO — answers the same fundamental question: who does what in this decision or task? They differ only in which specific ambiguity they resolve.

The question is never "which configuration should we use?" The question is "what's breaking down in how we make decisions?" The answer tells you which to reach for.

Configuration	The problem it solves	The key role it adds or sharpens	When RACI already works fine
DACI	Decisions keep stalling because nobody has clear authority to call it	Approver — single person with final say, separate from the Driver doing the work	When accountability is already clear and one person genuinely owns both the work and the decision
RAPID	Large matrixed org — too many people feel entitled to decide, alignment fails	Separates Recommend (proposes with evidence) from Decide (has final authority); adds Agree (must formally concur)	Small, single-team projects where decision authority is obvious
DARE	Too many people have de facto veto power; bureaucracy is slowing strategic decisions	Advisors (heard, not voted) vs. Deciders (few, clear); reduces the decision circle deliberately	When the current sign-off structure is working and the team trusts it
RASCI	The person doing the work (Responsible) is overwhelmed; no one else knows they can help	Support — assists without owning; makes informal help-givers visible and accountable	When capacity is not a problem and roles are cleanly separated
CAIRO	Scope keeps expanding; stakeholders who shouldn't be involved keep inserting themselves	Omitted — explicitly names who is out of this decision or task	When scope is stable and stakeholder inclusion is not a recurring source of conflict

The CoS Tool

What problem are you trying to solve?

Answer the questions below. The tree walks you to the right configuration for your situation — and tells you exactly what to watch for when you implement it.

Decision Framework Finder

Answer each question based on what's actually happening in your organization right now.

"What's the core breakdown in how decisions are getting made here?"

Reference

Each configuration — in depth

Use the tree above to find your configuration. Use this section to go deeper once you've chosen one.

DACIUse when: decisions keep stalling · no clear authority to call it

DACI

Driver · Approver · Contributors · Informed

DACI's most important innovation is naming a single Approver — one person on record for the final decision. This forces clarity that RACI's "Accountable" role never quite achieves, because in RACI, Accountable can mean both "owns the outcome" and "makes the call," which are often different people. The Driver moves the work forward (often the CoS), the Approver owns the decision, Contributors give input without controlling it.

When to use

→Decisions loop without resolution
→High-stakes calls with cross-team input
→When you need one person on record
→Any initiative prone to "decision by committee"

Introduce it by

→Map roles before the next key decision meeting
→Name the Approver publicly — in writing
→Agree on decision deadline upfront
→Designate a deputy Approver for absence

Not right when

→Decision genuinely needs consensus
→The "Approver" isn't truly empowered
→The team doesn't trust the process yet

⚠

Primary failure mode

Approver becomes the new bottleneck. DACI replicates the stall under a new name if the Approver is unavailable or indecisive. Solve this before you implement, not after.

RAPIDUse when: matrixed org · alignment fails across functions · "who's the real decision-maker" is unclear

RAPID

Recommend · Agree · Perform · Input · Decide

Developed by Bain & Company for large, complex organizations. RAPID is the most sophisticated configuration here — and the most overhead-intensive. It earns that overhead only in genuinely cross-functional, high-stakes situations where alignment across functions matters as much as the decision itself. Do not use it for routine decisions. Its Agree role — those who must formally concur — is what creates real alignment rather than compliance, but it's also the role that most often becomes a veto chain when over-populated.

When to use

→Enterprise-wide strategic decisions
→M&A or major partnership discussions
→Budget allocation across divisions
→When undone decisions are the primary cost

Introduce it by

→Train the team — it's not intuitive
→Keep Agree to three people maximum
→Use on high-stakes decisions only
→Review the Agree list after each cycle

Not right when

→Speed matters more than alignment
→Small, single-team decisions
→The org doesn't have training capacity

⚠

Primary failure mode

Too many people in Agree turns RAPID into consensus with extra steps. The framework becomes more complex than the problem. If Agree has more than three people, cut it before you launch.

DAREUse when: too many effective vetoes · bureaucracy is slowing strategic decisions · sign-off chains are too long

DARE

Deciders · Advisors · Recommenders · Execution Stakeholders

McKinsey's explicit response to RACI's bureaucratic overhead. DARE's key innovation is the Advisor role: people who have relevant knowledge and should genuinely be heard, but who do not vote. This separates "voice" from "vote" — a distinction that most approval-heavy cultures have never made explicit. Fewer Deciders, more Advisors, better decisions. The political work of introducing DARE — explaining to people that they're being moved from effective Decider to Advisor — is as important as the framework itself.

When to use

→Strategic initiatives with urgency
→Orgs drowning in sign-off culture
→When "consensus" means "whoever objects last wins"
→Post-merger governance realignment

Introduce it by

→Don't announce it as a demotion
→Frame Advisor as valued and active
→Start with one initiative, not org-wide
→Have the exec visibly sponsor the change

Not right when

→The current approval structure is working
→You don't have exec sponsorship
→The team is already conflict-averse

⚠

Primary failure mode

People moved to Advisor feel excluded and become post-hoc obstructors. DARE requires relationship management alongside role clarification. The framework is correct but socially incomplete without that work.

RASCIUse when: Responsible person is overloaded · capacity is the constraint · informal help-giving needs to be formalized

RASCI

Responsible · Accountable · Support · Consulted · Informed

One addition over RACI — the Support role — solves a specific, common problem: the person doing the work is drowning, but others who could help don't know they should. Support assists without owning. It makes informal help-giving visible, named, and accountable. In CoS work, this role is often held informally — RASCI makes it formal and defensible. Important: Support is not a lesser Responsible. It is a distinct contribution with its own scope.

When to use

→Ops-heavy projects with shared resources
→When Responsible is chronically overloaded
→Teams where capacity is always the constraint
→Large initiatives — summits, launches, integrations

Introduce it by

→Add Support to one active initiative first
→Make clear Support ≠ Responsible-lite
→AI can flag when one person appears in both roles across too many streams

Not right when

→Capacity isn't the issue
→Roles are already clearly separated
→The team would experience it as administrative overhead

⚠

Primary failure mode

Support becomes a dumping ground — people assigned to Support on five projects simultaneously with no more capacity than before. The role name changes; the overload doesn't. Treat Support as a real capacity commitment.

CAIROUse when: scope keeps expanding · wrong people keep inserting themselves · territorial dynamics are structural

CAIRO

Consulted · Accountable · Informed · Responsible · Omitted

CAIRO's superpower is its Omitted column. Explicitly naming who is not involved in a decision is often as powerful as naming who is — especially in organizations where exclusion has historically been read as a political signal. A well-used Omitted column changes meeting attendance, reduces decision paralysis, and gives the CoS a documented basis for maintaining scope. It requires political intelligence to deploy, not just process knowledge.

When to use

→Post-merger integration with territorial dynamics
→Projects with habitual scope creep
→"Everyone owns it" = no one does
→Meetings that keep growing without reason

Introduce it by

→Frame Omitted as "not in scope for this"
→Brief the exec before naming anyone Omitted
→Manage relationships, not just roles
→Revisit when scope legitimately changes

Not right when

→The org culture is highly consensus-driven
→You don't have exec backing for exclusions
→Scope is stable and inclusion isn't contested

⚠

Primary failure mode

People in the Omitted column feel excluded from decisions that affect them, become post-hoc obstructors, and create more friction than the original scope-creep did. CAIRO is technically correct but socially sharp — deploy with relationship management, not just a matrix.

The Hard Question

AI, decision frameworks, and accountability

The obvious AI applications — status reports, meeting summaries, matrix drafting — are well-covered elsewhere. The genuinely hard question that practitioners face in 2026 is different.

The question most AI guides don't ask

What happens to decision accountability when AI-generated recommendations enter a RAPID or DARE chain?

In a RAPID framework, the Recommender proposes a course of action with supporting evidence. The Decider acts on that recommendation. If the Recommender uses an AI tool to generate the proposal — synthesizing data, drafting the document, identifying comparable precedents — and then approves and forwards it without genuinely interrogating it, the accountability chain has a silent break in it.

The framework says the human Recommender is accountable. In practice, if the human didn't do the analysis, they have limited ability to defend, refine, or take genuine ownership of the recommendation when it's challenged. This is not a hypothetical risk — it is a real pattern emerging in 2026 as AI recommendation tools become standard.

The same issue applies in DARE's Recommender role and DACI's Driver role when AI tools are used to generate options.

The working principle for CoS: AI can generate the draft. The human who holds the role must be able to explain every line of it, defend it under pressure, and own the outcome if it goes wrong. If they can't — the AI has become a silent, unaccountable participant in the decision chain. That's a governance risk that no framework is currently designed to catch.

What to do about it: When introducing AI into any RACI-variant framework, add an explicit review standard — the human role-holder must be able to articulate the reasoning behind the AI-generated output before it advances in the chain. Make this expectation explicit, not assumed.

A Different Category Entirely

Sociocracy — why it doesn't belong next to CAIRO

Governance Philosophy — Not a RACI Variant

Sociocracy requires organizational adoption, not framework selection

Sociocracy — consent decision-making with distributed authority and circle governance — belongs in this field guide, but in its own category. It answers a fundamentally different question than DACI, RAPID, DARE, RASCI, and CAIRO. Those frameworks ask: who has which role in this decision? Sociocracy asks: how should authority itself be structured across our organization?

You cannot introduce Sociocracy the way you introduce DACI. It requires: leadership genuinely committed to redistributing authority (not performing commitment), facilitation training for those running consent rounds, cultural readiness to surface and work through objections, and sustained organizational support over months, not meetings.

The most common misuse is introducing "consent rounds" as a technique in a traditionally hierarchical organization without genuine authority redistribution. People experience false participation followed by overrides. The result is more damaged trust than the original centralization produced.

If your organization is genuinely ready for it: Sociocracy is a powerful governance model, particularly for distributed, mission-driven, or progressive tech organizations. The resources to start with are the Sociocracy 3.0 practical guide and Gerard Endenburg's foundational work. This guide is not the place to start that journey — it's the place to understand why it's a different journey.

The Most Important Section

How frameworks fail — and what to do about it

Good framework guidance always covers how things go wrong. Most of it doesn't. Here's the pattern that applies to every configuration in this guide.

The shelfware problem — applies to every framework

The most common failure mode across all RACI variants is the same: the matrix is built at project kickoff, presented in the first meeting, and never updated again. By week four, team composition has changed, scope has shifted, two "Accountable" parties are in conflict, and the matrix is a historical document, not a working agreement.

The fix: Add a standing agenda item to your operating cadence — a monthly "is this still accurate?" review of any active framework. It takes five minutes when nothing has changed. It takes thirty minutes when something has, and those thirty minutes prevent a month of misaligned work.

"Consulted" becoming a veto in disguise

In practice, "Consulted" often operates as a soft veto — the person is consulted, objects, and the decision stalls waiting for their approval that was never formally theirs to give. This happens when "Consulted" is assigned to someone senior who interprets it as "must sign off."

The fix: When assigning Consulted, be explicit in writing about what it means: "Your input will be gathered and considered. It does not constitute approval. The Approver/Decider makes the final call." Do this before the framework is live, not after the first conflict.

The accountability gap when teams change

When the person holding a key role leaves or changes position mid-project, the framework often breaks silently — the matrix still shows their name, but no one has formally transitioned the role. Work continues under informal arrangements until a decision moment surfaces the gap.

The fix: Treat any role change as a formal framework update event. Name a successor explicitly, in the matrix, before the transition is complete — not after.

Introducing a framework without introducing the problem it solves

A CoS who introduces CAIRO without explaining why naming "Omitted" stakeholders matters will encounter resistance that looks like resistance to the framework. It's actually resistance to the implied message — "you're being excluded." The framework is the vehicle; the conversation about the problem it solves is the engine.

The fix: Before introducing any new configuration, name the specific breakdown it addresses. "We keep having the same stall at the decision point. DACI names a single Approver so that doesn't happen." Framework first, rationale never, is how frameworks become shelfware.

The Bottom Line

The framework is the shared language. You're the one who teaches it.

"The right framework isn't a spreadsheet. It's a shared language — and the CoS is the one who teaches the room to speak it."

Pick the configuration that fits your organization's specific breakdown. Make it visible. Update it when reality changes. And when AI begins absorbing the administrative overhead of tracking and drafting, use the time it returns to you for the work no AI can replicate: the conversation that gets a room to genuinely agree on who decides, and to mean it.

That's the work. These are the tools. The judgment about which to use, and when, is yours.

PreviousC-Suite ArchetypesExecutive Dynamics NextStrategic ThinkingFrameworks