Decision Rights Clarification¶
Clarify who has authority to decide what, under which constraints, with which escalation paths.
Essence¶
Decision Rights Clarification is the archetype for turning fuzzy authority into usable decision structure. It asks a practical governance question: for this recurring kind of decision, who may decide, who must provide input, who can approve or veto, when must the case escalate, and how will the decision remain accountable?
The archetype is not a RACI chart or an approval workflow. Those are mechanisms. The archetype is the underlying intervention that makes authority specific enough for action and bounded enough for legitimacy, risk control, and accountability.
Compression statement¶
When responsibility and authority are ambiguous, clarify decision rights by mapping decision categories, assigning owners, distinguishing input/approval/veto roles, defining authority boundaries, and attaching escalation and accountability records.
Canonical formula: decision category + owner + participation roles + authority boundary + escalation path + accountability record + review trigger -> usable decision authority
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
People are unsure who can decide, approve, override, veto, consult, or escalate a recurring category of decisions, causing delay, conflict, duplicated work, shadow authority, or accountability gaps.
What this problem means
The structural problem is a mismatch between responsibility, authority, participation, and accountability. A system may say that a team is responsible for an outcome while withholding decision authority. Or it may give multiple actors partial authority without clarifying who has final say. Or it may rely on informal influence paths that everyone knows but nobody records.
When this mismatch persists, the organization develops defensive behavior. People escalate routine choices, seek informal pre-approval, avoid ownership, or blame others for decisions that were structurally ambiguous. The cost appears as delay, rework, conflict, inconsistent decisions, and weak accountability.
Applicability expression6 distinct conditions
′ context guard? connective not recorded∅ no catalog witness yet
groundedpartly groundedopen
6 conditions, all required.
6Required in every casenumbered 1–6
These hold no matter which pattern applies.
Cross-role recurring decisions · grounded · any one of 2
Work requires recurring decisions that affect multiple roles, teams, units, stakeholders, or risk domains.
People are unsure who can decide, approve, override, veto, consult, or escalate a recurring category of decisions, causing delay, conflict, duplicated work, shadow authority, or accountability gaps. The narrower requirement in this condition set is: Work requires recurring decisions that affect multiple roles, teams, units, stakeholders, or risk domains.
domainIncident Objectives— The short ordered list of specific, measurable, owned, time-bounded aims an Incident Commander sets each operational period, re-aiming the response periodically under uncertainty and driving the planning cycle's assignments, tactics, and period-end verification.
domainCollaborative Maintenance— Keep a shared knowledge artifact current through an open community working under five documented-and-exercised governance pathways — proposal, review, dispute resolution, deprecation, and attribution — rather than a single custodian.
How this was matched — 4 shared + 5 branches
Work requires recurring decisions that affect multiple targets of a listed type.
All of
- roleWork is the activity that requires decisions.
- modalityThe work requires the decisions.
- quantifierThe required decisions recur.
- quantifierThe decisions affect multiple targets of the selected type.
…and any one of
- domainMultiple roles are affected.
- domainMultiple teams are affected.
- domainMultiple units are affected.
- domainMultiple stakeholders are affected.
- domainMultiple risk domains are affected.
Permission-seeking ambiguity · open
People routinely ask for permission, seek backchannel approval, or defer decisions because formal authority is unclear.
Use this archetype when decisions stall or become political because authority is unclear. The narrower requirement in this condition set is: People routinely ask for permission, seek backchannel approval, or defer decisions because formal authority is unclear.
Unspecified category ownership · open
Formal titles, org charts, or policies do not specify who owns specific decision categories.
People are unsure who can decide, approve, override, veto, consult, or escalate a recurring category of decisions, causing delay, conflict, duplicated work, shadow authority, or accountability gaps. The narrower requirement in this condition set is: Formal titles, org charts, or policies do not specify who owns specific decision categories.
Recurring approval dysfunction · needs review
Decision delay, duplicate approvals, conflicting approvals, or after-the-fact overrides are recurring rather than exceptional.
People are unsure who can decide, approve, override, veto, consult, or escalate a recurring category of decisions, causing delay, conflict, duplicated work, shadow authority, or accountability gaps. The narrower requirement in this condition set is: Decision delay, duplicate approvals, conflicting approvals, or after-the-fact overrides are recurring rather than exceptional.
Overlapping authority boundaries · grounded
A matrix, cross-functional, regulated, or multi-agency setting creates overlapping authority boundaries.
It is especially useful in matrix organizations, cross-functional programs, public agencies, shared governance bodies, regulated operations, platform teams, crisis response, and partnerships where authority crosses role or unit boundaries. The narrower requirement in this condition set is: A matrix, cross-functional, regulated, or multi-agency setting creates overlapping authority boundaries.
domainUnity-of-Command Breakdown— The command-and-control failure in which one subordinate node in the authority graph carries two or more binding in-edges for the same task at the same time, so that when the supervisors' orders diverge the actor cannot comply with both.
context guardThe converging binding authority edges arise from dual reporting lines in a matrix organization.
suppliesAn organizational or governance setting is the causal context. · The setting creates the boundary overlap. · The causal context is a matrix setting.
How this was matched — 4 shared + 4 branches
A listed organizational setting causes authority boundaries to overlap.
All of
- roleAn organizational or governance setting is the causal context.
- roleAuthority boundaries are the affected objects.
- causalityThe setting creates the boundary overlap.
- relationThe authority boundaries overlap.
…and any one of
- domainThe causal context is a matrix setting.
- domainThe causal context is a cross-functional setting.
- domainThe causal context is a regulated setting.
- domainThe causal context is a multi-agency setting.
Bounded localized delegation · grounded
Authority needs to be delegated or localized, but only within explicit risk, cost, policy, safety, or strategic constraints.
The design problem is to make authority clear enough for action while bounded enough for legitimacy, accountability, and risk control. The narrower requirement in this condition set is: Authority needs to be delegated or localized, but only within explicit risk, cost, policy, safety, or strategic constraints.
primeDelegation of Authority— Assign responsibility.
Other requirements and context (1)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Supporting contextDecision consequences are large enough that accountability, auditability, or legitimacy matter.
The design problem is to make authority clear enough for action while bounded enough for legitimacy, accountability, and risk control. In this archetype, the relevant contextual consideration is: Decision consequences are large enough that accountability, auditability, or legitimacy matter. It helps interpret the situation or strengthens the practical case for examining the archetype.
Coverage
3 of 6 conditions grounded · 2 open · 1 needing review.
When to Use This Archetype¶
Use this archetype when decisions stall or become political because authority is unclear. Common signals include repeated permission-seeking, contradictory approvals, hidden vetoes, shadow sponsors, meetings that end without a decision owner, and people being held accountable for outcomes they were not empowered to decide.
It is especially useful in matrix organizations, cross-functional programs, public agencies, shared governance bodies, regulated operations, platform teams, crisis response, and partnerships where authority crosses role or unit boundaries.
Do not use it as the first diagnosis when the decision owner is already clear but lacks capacity, information, agreement, or incentives. In those cases, nearby archetypes such as Oversight Span Calibration, Structured Sensemaking, Goal Congruence Alignment, or Task Interdependence Mapping may be closer.
Structural Problem¶
The structural problem is a mismatch between responsibility, authority, participation, and accountability. A system may say that a team is responsible for an outcome while withholding decision authority. Or it may give multiple actors partial authority without clarifying who has final say. Or it may rely on informal influence paths that everyone knows but nobody records.
When this mismatch persists, the organization develops defensive behavior. People escalate routine choices, seek informal pre-approval, avoid ownership, or blame others for decisions that were structurally ambiguous. The cost appears as delay, rework, conflict, inconsistent decisions, and weak accountability.
Intervention Logic¶
The intervention starts by naming recurring decision categories. Instead of asking vaguely “who is responsible,” it asks “for this kind of decision, what authority is needed?” The draft then assigns a decision owner, distinguishes participation roles, defines authority boundaries, and adds escalation and exception handling.
The critical move is to separate roles that are often collapsed. A person may recommend without deciding, be consulted without approving, approve without owning implementation, or be informed without holding veto power. When those roles become explicit, participation can improve without destroying ownership.
The final move is maintenance. Decision rights decay as roles, risks, work processes, and informal influence change. A rights design should therefore include review triggers such as repeated escalations, shadow approvals, delays, contested overrides, or changed operating context.
Key Components¶
Decision Rights Clarification converts fuzzy authority into a maintainable structure by separating roles that ambiguity tends to collapse. It begins with a Decision Category — a named recurring class of decision such as launch approval, budget exception, or rollback authorization — which prevents the common failure where people agree on authority in general but disagree about every concrete case. Within each category, the Decision Owner is the actor, role, or body empowered to decide, paired with enough mandate, information, and answerability for the ownership to be real rather than nominal. The Authority Boundary then defines where that ownership starts and ends — through budget limits, risk thresholds, time windows, or strategic scope — so delegated autonomy is bounded and safe. Decision Participation Roles distinguish recommending from consulting, approving, vetoing, executing, or being informed, which is where many authority failures originate when consultation is mistaken for approval or affected parties are silently excluded.
Three components keep the structure usable and adaptive. The Escalation Path defines where cases go when they exceed the owner's boundary, when risk crosses a threshold, or when authority conflicts cannot be resolved locally — exceptional and threshold-based rather than a default substitute for ownership. The Decision Exception Rule handles emergencies, overrides, and conflicts of interest, because without explicit exception logic unusual cases either freeze the system or carve informal bypasses that gradually become the real authority structure. The Accountability Record captures who decided, under what authority, using which rationale, supporting learning and repair without becoming a blame ledger for actors who lacked real authority. Finally, the Rights Review Trigger — repeated escalations, shadow vetoes, audit findings, or changed operating conditions — keeps the design adaptive, because decision rights decay as work, risks, and informal influence shift around them.
| Component | Description |
|---|---|
| Decision Category ↗ | A decision category names the recurring class of decision to which authority applies. Examples include launch approval, budget exception, clinical escalation, vendor selection, policy interpretation, rollback authorization, and hiring approval. This component prevents the common failure where people agree on authority in general but disagree about every concrete case. |
| Decision Owner ↗ | The decision owner is the actor, role, body, or office empowered to make a decision within a defined category. Ownership must include enough mandate, information access, and answerability to be real. A named owner without usable authority is a false resolution. |
| Authority Boundary ↗ | The authority boundary defines where the owner’s authority starts and ends. It may include budget limits, risk thresholds, legal constraints, safety conditions, time windows, reversibility, geography, customer impact, or strategic scope. Boundaries make delegated autonomy safe. |
| Decision Participation Roles ↗ | Participation roles specify who recommends, consults, approves, vetoes, executes, audits, or is informed. This component is essential because many authority failures arise when consultation is mistaken for approval or when affected parties are silently excluded from consequential decisions. |
| Escalation Path ↗ | The escalation path defines where a case goes when the decision is outside the owner’s boundary, when risk exceeds a threshold, or when authority conflicts cannot be resolved locally. Escalation should be exceptional and threshold-based, not a default substitute for ownership. |
| Accountability Record ↗ | The accountability record captures who decided, under what authority, using which rationale, with which consultation or approvals, and with what follow-up obligations. It supports learning and repair, but it should not become a blame ledger that punishes actors who lacked real authority. |
| Decision Exception Rule ↗ | Exception rules define how emergencies, overrides, conflicts of interest, and unusual cases are handled. Without exception logic, exceptional cases either freeze the system or create informal bypasses that gradually become the real authority structure. |
| Rights Review Trigger ↗ | A rights review trigger keeps the design adaptive. Repeated escalations, delayed approvals, frequent overrides, shadow vetoes, audit findings, or changed operating conditions are signs that the rights map should be revised. |
Common Mechanisms¶
9 catalogued mechanisms: 8 documented across 5 implementation forms; 1 awaits an authored page and reviewed form classification.
The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.
Assessment, Review & Assurance · 1 mechanism
- Authority Boundary Review — Periodically compares actual decision delays, conflicts, overrides, exceptions, and outcome quality against the current rights map, and fires a revision where the two have drifted apart.
Protocol, Workflow & Routine · 1 mechanism
- Escalation Protocol — Defines the threshold at which an agent's ordinary discretion runs out and the decision must be routed up to a higher or different authority.
Record, Log & Register · 2 mechanisms
- Decision Log — Captures each significant decision as a linked record — its rationale, the alternatives weighed, who approved it, and the artifacts it affects — so a choice can later be traced back to why it was made and forward to what it touched.
- Decision Registry — A searchable system of record for decision rights — look up any decision category and get its current owner, approval requirements, threshold, and escalation path on demand.
Representation, Specification & Plan · 2 mechanisms
- Decision-Rights Matrix — Maps each class of decision to who may decide, approve, be consulted, or merely be informed — fixing the agent's authority before any single choice arises.
- RACI / RAPID-Style Tool — Assigns a single, unambiguous participation label — recommend, decide, approve, consult, or inform — to each role for a given decision, prying apart the roles that ambiguity collapses together.
Rule, Policy & Commitment · 2 mechanisms
- Delegation Charter — A standing document that grants a bounded envelope of authority to one delegate — a role, team, project, or unit — stating what it may decide alone, the limits on that autonomy, and where cases outside the envelope must go.
- Governance Charter — A constitution for a collective decision body — a committee, board, council, or steering group — defining which decision categories it owns, who sits on it in what role, how it decides by vote or consent, and how it resolves authority conflicts.
Not Yet Form-Classified · 1 mechanism
- Approval Workflow — Routes access requests, exception requests, or privilege changes through accountable review before activation.
Parameter / Tuning Dimensions¶
The most important tuning dimension is granularity. A rights map that is too coarse leaves ambiguity unresolved; one that is too detailed becomes brittle and bureaucratic. Decision categories should be specific enough to guide action but not so specific that every unusual case requires a new row.
Risk threshold is another tuning dimension. Low-risk, reversible, routine decisions can usually sit closer to the work. High-risk, irreversible, costly, legally sensitive, or legitimacy-sensitive decisions need tighter boundaries, stronger review, or more explicit escalation.
Participation depth also needs tuning. Some decisions need only notification; others require consultation, independent approval, veto power, or affected-party voice. Over-inclusion creates delay; under-inclusion creates knowledge gaps and legitimacy failures.
Finally, the review cadence should match volatility. Stable domains may need periodic review. Fast-changing, high-risk, or politically contested domains need rights review triggered by exceptions, incidents, or repeated escalations.
Invariants to Preserve¶
Authority and accountability must remain paired. No actor should be answerable for decisions they could not make, and no actor should exercise authority without a record of responsibility.
Decision ownership must remain distinguishable from consultation, approval, veto, execution, and notification. Blurring those roles is the fastest path back to ambiguity.
Escalation must preserve local autonomy for in-scope decisions. If every decision escalates, the rights design has become centralized control rather than clarified authority.
Formal rights must remain connected to actual practice. If informal influence determines outcomes, the formal design is either incomplete or decorative.
Target Outcomes¶
A successful draft reduces decision delay, approval conflict, and shadow authority. Actors know when they can decide, when they need input, when they need approval, and when they must escalate.
It also improves accountability. Decision records become meaningful because they connect choices to legitimate authority, constraints, rationale, and follow-up obligations.
At the system level, clarified decision rights support faster action without removing all safeguards. Routine decisions move closer to the work; high-risk or boundary-exceeding decisions move through explicit escalation.
Tradeoffs¶
The main tradeoff is clarity versus flexibility. Clear rights help people act, but overly rigid rights can block judgment in novel cases. Exception rules and review triggers help preserve flexibility without returning to ambiguity.
Another tradeoff is speed versus review. More approvals can reduce some risks, but they can also create bottlenecks and decision avoidance. The design should reserve approval for cases where independent review adds real value.
There is also a power tradeoff. Clarifying decision rights may expose informal authority, remove hidden vetoes, or shift control from senior actors to local owners. This is often desirable, but it can generate resistance.
Failure Modes¶
One failure mode is paper authority with shadow override. The formal rights map says one role decides, but another actor still controls the outcome through backchannels. This requires informal authority diagnosis and reconciliation.
A second failure mode is approval bureaucracy. The organization responds to ambiguity by adding approvals everywhere. Decisions become slower, but not necessarily safer or more legitimate.
A third failure mode is accountability without authority. A role is named accountable but lacks the budget, mandate, access, or permission needed to decide. This creates blame without control.
A fourth failure mode is escalation erosion. Local owners escalate in-scope decisions to avoid blame, or higher authorities override too easily. Over time, ownership disappears.
A fifth failure mode is stale authority. The rights design remains fixed after the work, risks, people, or strategy changes. Review triggers are necessary to prevent decay.
Neighbor Distinctions¶
Informal Structure Mapping reveals how work and influence actually operate. Decision Rights Clarification may use that diagnosis, but its own intervention is assigning and maintaining authority boundaries.
Oversight Span Calibration addresses the capacity of a supervisor or governance body to monitor, coach, or review. Decision Rights Clarification addresses who may decide and when escalation is needed.
Task Interdependence Mapping focuses on dependency, handoff, and coordination among tasks. Decision Rights Clarification focuses on authority over choices, even when those choices occur at handoffs.
Goal Congruence Alignment redesigns objectives, metrics, and incentives so local success supports system success. Decision Rights Clarification can assign who resolves conflicts, but it does not itself align incentives.
Procedural Fairness Design focuses on fair process for affected parties. Decision Rights Clarification can support fairness by clarifying who decides and who gets voice, but fairness requires additional principles such as notice, reasons, impartiality, and review.
Accountability Chain Design focuses on answerability, records, consequences, and repair. Decision Rights Clarification focuses on legitimate authority before and during the decision, while preserving records that make accountability possible.
Cross-Domain Examples¶
In software platform governance, decision rights can clarify who may approve breaking API changes, who must review security exceptions, and who can authorize rollback during an incident.
In a hospital, decision rights can clarify which clinical, operational, and administrative roles may make bed allocation, discharge exception, or surge-capacity decisions.
In public administration, decision rights can separate routine permit approvals from discretionary exceptions and policy interpretations, improving both speed and legitimacy.
In education governance, decision rights can separate school-level discretion, district administration, board authority, and compliance obligations.
In a coalition or partnership, decision rights can prevent one partner from informally vetoing shared decisions without an agreed governance role.
Non-Examples¶
An org chart is not this archetype. It may show formal reporting relationships, but decision authority often cuts across reporting lines.
A copied RACI template is not this archetype unless it changes actual decision ownership, boundaries, participation roles, and escalation behavior.
A meeting agenda is not this archetype unless it defines who may make which decisions and under what constraints.
A decision log is not this archetype by itself. It records decisions; it does not necessarily clarify authority.
A one-time leadership choice is not this archetype unless it creates a reusable rights structure for a recurring decision category.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Accountability: Responsibility for actions.
- Delegation of Authority: Assign responsibility.
- Formal vs. Informal Structures: Official vs actual systems.
Also references 9 related abstractions
- Boundary: Defines system limits.
- Checks and Balances: Distributed power.
- Hierarchy: Organizes elements into levels or ranks.
- Legitimacy: Accepted authority.
- Local Autonomy & Tiered Escalation: Escalate when needed.
- Oversight Capacity: Limits of supervision.
- Procedural Fairness (Due Process): Due process.
- Role Conflict: Conflicting roles.
- Separation of Powers: Divide authority.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Delegated Authority Envelope · governance variant · promote to full archetype candidate
Defines the scoped envelope within which a delegated actor may decide, act, spend, approve, or escalate.
- Distinct from parent: Decision Rights Clarification maps decision categories and rights across a system; this variant focuses on the boundary of one delegated authority relation.
- Use when: A higher-level authority wants to grant autonomy without losing constraints, oversight, or escalation control; Local actors need freedom to decide quickly, but only within bounded risk, budget, policy, or strategic scope; The same delegated role will recur across cases and needs a stable authority envelope rather than ad hoc permission.
- Typical domains: public administration, product management, healthcare operations, incident response
- Common mechanisms: Decision Rights Matrix, Delegation Charter, Decision Log
Approval Boundary Clarification · governance variant · recognized
Clarifies which decisions require approval, which only require consultation or notification, and which can be made independently.
- Distinct from parent: The parent clarifies all decision rights; this variant narrows the question to approval requirements and approval-role boundaries.
- Use when: Work stalls because actors are unsure whether approval is required; Approvers are overloaded by low-risk decisions while high-risk decisions bypass review; Consultation, sign-off, veto, and notification are being conflated.
- Typical domains: procurement, software release management, clinical governance, capital budgeting
- Common mechanisms: Decision Rights Matrix, Approval Workflow
Escalation Rights Clarification · governance variant · recognized
Clarifies who may escalate a decision, what triggers escalation, where it goes, and what authority remains with the original owner.
- Distinct from parent: The parent covers the whole rights map; this variant focuses on thresholded transfer of decision authority.
- Use when: Cases repeatedly bounce between levels because no one knows when escalation is legitimate; Local owners are bypassed too easily, or high-risk cases remain local too long; Escalation is used as conflict avoidance rather than boundary management.
- Typical domains: incident response, clinical triage, customer support, security operations
- Common mechanisms: Escalation Protocol, Decision Log
Shadow Authority Reconciliation · governance variant · candidate
Reconciles official decision rights with the informal influence, vetoes, and approval paths that actually control decisions.
- Distinct from parent: The parent can clarify documented rights; this variant begins by diagnosing and reconciling hidden authority.
- Use when: The formal rights map says one actor decides, but everyone knows another actor must approve informally; Decisions are delayed by hidden vetoes, sponsor signals, backchannel approvals, or unofficial authority; A formal decision owner cannot be held accountable because real authority sits elsewhere.
- Typical domains: large organizations, universities, coalition governance, matrix teams
- Common mechanisms: Actual-vs-Formal Authority Map, Decision Rights Matrix
Emergency Decision Authority · risk or failure variant · recognized
Predefines who may decide under urgent, high-risk, or degraded conditions when normal consultation and approval paths are too slow.
- Distinct from parent: The parent covers routine and exceptional rights; this variant narrows to urgent degraded-mode authority.
- Use when: A system needs fast decisions under safety, security, crisis, or operational disruption conditions; Normal approval paths are reliable in routine cases but too slow during incidents; Emergency authority must be bounded so it does not become a permanent informal override.
- Typical domains: incident response, healthcare, aviation operations, cybersecurity
- Common mechanisms: Incident Command Authority Protocol, Decision Log
Near names: Decision Authority Clarification, Decision Ownership Design, Authority Mapping, Decision Rights Matrix, RACI Matrix, RAPID Tool, Approval Matrix, Delegation Charter.
Editorial Notes¶
Problem Classification¶
Classification: Authority, Accountability, Legitimacy & Fair-Process Failure → Authority Scope, Decision Rights & Continuity
Problem kernel: recurring decisions lack explicit rights and escalation paths
Rationale: Actors cannot tell who may decide, approve, veto, consult, or override, producing delay, shadow authority, duplication, and accountability gaps.
Independent corroboration: The earliest necessary condition in the frozen evidence is: People are unsure who can decide, approve, override, veto, consult, or escalate a recurring category of decisions, causing delay, conflict, duplicated work, shadow authority, or accountability gaps. That is a authority scope decision rights and continuity problem because Legitimate action is impaired because deciding, vetoing, overriding, delegating, or succeeding authority is unclear, nominal, externally subordinated, or functionally vacant.
Review outcome: Independent reviewer agreement; high confidence.