Decision Rights in 2026: Frameworks, Governance Tools, and the Layer That’s Missing

Decision rights is one of the most established concepts in organisational design. The premise is straightforward: when it’s clear who has the authority to make which decisions, organisations move faster and with less friction. When it’s unclear, decisions stall, get relitigated, or get made by whoever happens to be in the room.

The premise is correct, and the gap between necessary and sufficient is where most organisations lose more than they realise.

The decision rights landscape

Over the past two decades, the decision rights space has developed three distinct layers. The first assigns authority through frameworks. The second operationalises decision processes through governance tools. The third logs outcomes through capture tools. All three are useful. None of them are sufficient. And the gap between the third and reality is where decision failures accumulate.

Layer 1: Frameworks (defining who decides)

RACI (Responsible, Accountable, Consulted, Informed) was one of the first decision rights frameworks to gain traction. It maps decisions across a matrix, assigning each role a letter. It’s intuitive and portable. Every organization understands what it means to be “accountable” for a decision.

DACI (Driver, Approver, Contributors, Informed), popularized by Atlassian, updated the framework for modern teams. DACI treats driving to closure as a distinct role: not just being responsible, but actively moving the decision forward. It has been adopted widely in tech organizations where velocity matters.

RAPID (Recommend, Agree, Perform, Input, Decide), developed by Bain, focuses on the sequence of decision-making. It maps who recommends, who agrees, who performs, who provides input, and who decides. It’s particularly useful for organizations wrestling with delegation and consensus.

OVIS (Own, Veto, Influence, Support), BCG’s more recent contribution, addresses the reality that in matrix organisations, decision authority is rarely binary. It acknowledges that multiple stakeholders have legitimate but different levels of influence, and tries to make those gradations explicit.

SPADE (Setting, People, Alternatives, Decide, Explain) developed at Square and spread across the tech sector. Its differentiator is that it’s a process, not just a role assignment. It requires the decision-maker to document the setting (context and constraints), identify alternatives, make the call, and explain the reasoning.

These frameworks reduce ambiguity. They make it possible to have a conversation about how a particular decision should be made before you’re in the middle of trying to make it. They are blueprints, not execution.

Layer 2: Governance tools (operationalising decision processes)

Holaspirit (by Talkspirit) enables dynamic role mapping and transparent decision processes across 450+ organizations in 30 countries. It gives structure to how roles are assigned, decisions are tracked, and authority flows through organizations in real time.

Loomio originated in New Zealand’s civic movement as a tool for participatory democracy. It’s open source, GDPR-compliant, available in 30+ languages, and designed for groups that need to move from discussion to decision with genuine input. It operationalizes the participatory aspects of decision-making.

Murmur and similar tools implement the “advice process”: a lighter-weight decision-making model where anyone can make a decision as long as they’ve sought advice from those affected and those with expertise.

These governance tools solve a real problem: they operationalize decision processes so they’re not just ideas, but workflows. They log who was involved, what the timeline was, what the decision was. They create an artifact where before there was only conversation.

Layer 3: Capture tools (logging what was decided)

Atlassian Confluence lets teams embed DACI templates in their decision documentation, creating a searchable archive of who decided what and when.

Fellow turns meeting notes into decision logs, capturing action items, owners, and due dates alongside the decisions those meetings produced.

Hypercontext (acquired and rebranded as Spinach AI) automatically processes meeting outcomes and logs them alongside the organizational structures that own different decisions.

Notion decision logs let organizations maintain single sources of truth for decisions: who decided, when, what changed, what the decision was based on.

These capture tools solve the documentation problem. They answer: “What did we decide?” They create accountability through visibility. And they are valuable.

The structural gap

All three layers (frameworks, governance tools, and capture tools) share the same blind spot. They instrument the authority structure, not the coordination quality.

DACI says Sarah is the Driver. It doesn’t show whether Sarah actually drove to closure, or whether she let the meeting get hijacked by whoever spoke loudest. It doesn’t show whether she was exercising judgment or deferring to whoever sounded most confident.

The governance tool records that consensus was reached with no objections. It doesn’t show whether the absence of objections means genuine agreement, or whether people disengaged because they’d already decided the outcome was predetermined.

The decision log records the choice. It doesn’t show whether the decision held through the next sprint, or whether it was quietly reversed in a Slack thread two days later because new information emerged, or because the decision owner lost confidence, or because the shallow execution problem meant nobody ever actually committed to it.

Where decisions actually fail

Research from the Collective Intelligence Labs at the Stockholm School of Economics studied teams across 22 organisations. The research found that the teams whose coordination goes unobserved degrade. And the teams most at risk overrate their coordination quality.

Is the Driver actually driving? Is the Approver exercising judgment, or rubber-stamping because they’re busy and trust the Driver has done their homework? Are the Contributors actually contributing, or are they sitting in meetings waiting for the decision they know has already been made? Are the people marked Consulted actually getting consulted, or is that a formality?

These are coordination quality questions. No framework answers them. No governance tool surfaces them. No decision log captures them.

The verification layer

Decision reliability infrastructure addresses this. It instruments the coordination layer, making visible whether the decision rights architecture is actually functioning in practice.

The questions it asks are different in kind from the ones frameworks and governance tools ask. Who is accountable becomes: are the accountable people actually exercising that accountability? Was there consensus becomes: did the team genuinely integrate diverse perspectives, or did someone check the box? What did we decide becomes: what did we decide, and is it holding?

It completes the stack rather than replacing any part of it. Frameworks, governance tools, and capture processes all remain. What changes is whether you can trust them.

The AI governance dimension

Regulators are now asking the same question. The EU AI Act goes into enforcement in August 2026. CCPA ADMT regulations are expanding. Both require that human decision rights be genuinely exercised, not just formally assigned.

Alan Knox argues that regulators will increasingly distinguish between the checkpoint (the moment where a human has to approve something) and the decision owner (the person actually making the call). A DACI chart that says Sarah is the Approver satisfies the checkpoint requirement. Whether Sarah actually decided, or simply authorized what the Driver recommended, is a different question entirely.

Regulators won’t accept a DACI chart as evidence of genuine human oversight. They’ll want to see that the decision owner was actually present in the decision. That they integrated input. That they exercised judgment. That they were willing to override the recommendation if their judgment diverged.

The complete decision rights stack

Define → Operationalise → Capture → Verify

Define: Assign authority through frameworks (RACI, DACI, RAPID, OVIS, SPADE). Make it clear who decides what.

Operationalise: Use governance tools (Holaspirit, Loomio, Murmur) to make decision processes repeatable. Build them into workflows, not conversations.

Capture: Log decisions (Confluence, Fellow, Hypercontext, Notion). Create accountability through documentation.

Verify: Instrument the coordination layer. Show whether the authority structure is actually being exercised.

Without the fourth layer, the first three are aspirational. With it, they become trustworthy.