Overview

The Decision Clarity Analysis Framework (DCA) handles the case where producing a confident answer would mislead — where the underlying problem is genuinely wicked in Rittel and Webber’s sense, with contested problem definitions across stakeholder groups, fundamental value conflicts that cannot be resolved by more information, no objective stopping condition, and irreversibility of intervention. DCA does not solve the problem. It produces a Decision Clarity Document that makes the structure of the dilemma legible to whoever holds decision authority — so that any decision taken is taken with eyes open about what is being chosen and what is being sacrificed. The framework was renamed from “Wicked Problems Framework” in 2026-05-01 per Decision H of the architectural lock; the analytical content split into a Decision Clarity Analysis mode (decision-maker-output-shaped) and a Wicked Problems Analysis mode (integrated multi-perspective synthesis).

The framework runs in four stages. Stage 1 — Problem Space Mapping documents the contested problem definitions held by different stakeholder groups, without reconciling them; the multiple definitions are recorded as legitimate framings, not as positions to be picked between by the framework. Stage 2 — Value Conflict Identification classifies stakeholder value conflicts into fundamental (both values cannot be fully honored simultaneously regardless of information available) versus resolvable (the conflict could close with better information or negotiation); the explicit classification refuses synthesis-language that pretends fundamental conflicts can be dissolved. Stage 3 — Consequence Landscape Modeling models the direct, second-order, and third-order effects of each available intervention across multiple time horizons, with explicit attention to who benefits and who bears costs (consumes Cui Bono mode for distributional analysis). Stage 4 — Tradeoff Transparency and Decision Clarity translates each intervention into a tradeoff statement: “this intervention prioritizes X and subordinates Y; the following stakeholders cannot be satisfied by this choice; the following consequences are being accepted in exchange.” Red Team passes in advocate stance per subordinated stakeholder group are run against the leading interventions to surface what the chosen path costs.

The framework’s load-bearing intellectual content is the four-condition trigger, the fundamental vs. resolvable classification discipline, and the refusal-to-recommend rule. The four-condition trigger says DCA is invoked when a problem meets at least three of: definition shifts under perspective change; solutions generate new problem dimensions; no objective stopping condition; value conflicts are fundamental. Fewer than three conditions means the problem has partial complexity and routes to ordinary analysis (PEF, Constraint Mapping). The fundamental-vs-resolvable classification is Stage 2’s load-bearing methodology — without it, the framework would silently let value conflicts get treated as information failures, which is the central failure mode of conventional analysis on wicked problems. The refusal-to-recommend rule is the framework’s discipline against advisor-overreach: DCA does not recommend an intervention as “best.” Reconciliation of competing definitions, dissolution of fundamental conflicts, and intervention selection are decision-maker prerogatives, not analytical outputs. The framework’s job is to make the decision maximally legible; the judgment is the user’s.

The framework’s epistemological posture deliberately resists four patterns that fail wicked problems. Premature closure on a single problem framing — counteracted by Stage 1’s competing-hypotheses pass that documents multiple framings. Synthesis-as-resolution of fundamental value conflict — counteracted by Stage 2’s explicit classification. Optimism about consequence prediction — counteracted by Stage 3’s multi-horizon scenario planning and distributional analysis. Sycophantic framing of a chosen intervention — counteracted by Stage 4’s Red Team passes in advocate stance per subordinated stakeholder.

The framework answers questions like: I have a decision to make where every option harms someone, and “balance” feels like dishonest framing — can you help me see clearly what I’d be trading? My organization is facing a choice that involves stakeholders with genuinely incompatible values — can you produce something that makes the dilemma legible to the people who’ll decide? My initial framing of this problem keeps slipping; every time I propose a solution, new dimensions appear — am I in wicked-problem territory?

Systemic context

Decision Clarity Analysis is the wicked-problem handler of the Information Lifecycle System (paired with PFF, PIF, CFF, OFF, and TMF; the system view is in [[Paper — Information Lifecycle System]]). DCA is invoked from three paths. User invocation — the user invokes the decision-clarity mode directly when they recognize they’re facing a wicked problem. PEF handoff — [[Framework — Problem Evolution]]‘s wicked-problem detection check has fired and PEF hands off a structured package with the four-condition evaluation, stakeholder information, Excluded Outcomes (Lock-protected), and Constraints. Cui Bono escalation — the cui-bono mode has produced output showing wicked-problem indicators (incompatible benefit structures, no net-positive intervention, fundamental value conflicts in distribution) and surfaced an escalation prompt offering DCA analysis. DCA also fires automatically from [[Framework — Process Coherence]] on multi-owner conflict patterns per Operations Manifest Stress Test 8 — when a Coordinated Corpus’s primary curator is contested between multiple Operations and the contention cannot be resolved by the Coordination Layer alone, DCA produces the Decision Clarity Document for the user to resolve the contention deliberately. The framework consumes other analytical modes (Competing Hypotheses, Cui Bono, Steelman Construction, Systems Dynamics, Scenario Planning, Red Team) at specific stages where each mode’s epistemic posture matches the analytical work required.

Ora’s output

Example question: Our open-source project’s largest corporate sponsor just announced they’re forking the codebase under their own brand and offering paid support. Several core contributors have moved to the fork because of the better compensation. Should we do nothing, fight the fork, or negotiate? Every option seems to hurt someone we care about.

Ora’s response (running DCA on the named problem):

Let me first verify this meets the wicked-problem threshold — three of four conditions. (1) Definition shifts under perspective change: yes — to the corporate sponsor this is a market move; to the remaining contributors it’s a betrayal; to project users it may be an upgrade or a downgrade depending on which side captures their workflow; to the project’s foundation board it’s a governance crisis. (2) Solutions generate new problem dimensions: yes — fighting the fork creates licensing-strategy and contributor-loyalty problems; negotiating creates appearance-of-capture problems; doing nothing creates morale-and-momentum problems. (3) No objective stopping condition: yes — “the problem is solved” means radically different things to each stakeholder. (4) Value conflicts are fundamental: yes — open-source community values vs. commercial sustainability values; loyalty to existing contributors vs. fairness to those who left for compensation. All four conditions fire. The problem is genuinely wicked. DCA proceeds.

Stage 1 — Problem Space Mapping. Documenting the contested problem definitions without reconciling them.

Foundation board’s framing. “A corporate sponsor has fragmented the project ecosystem and we need to restore community cohesion.”

Departed contributors’ framing. “We finally got fair compensation for work the foundation refused to fund; the project benefits because our contributions continue elsewhere.”

Remaining contributors’ framing. “Our peers were poached; the foundation’s failure to fund us is the load-bearing failure; the corporate fork is a symptom.”

Corporate sponsor’s framing. “We invested heavily in this project for years; we have a legitimate commercial interest; the fork honors the open-source license.”

Users’ framing (split). “We just need the software to keep working — whoever ships fastest with the best support is who we’ll use.” (One subset.) “We chose this project because it was community-led; we’d switch away if it becomes corporate-captured.” (Another subset.)

Five framings, none reconciled. The framework records them as legitimate; the decision-maker (presumably the foundation board) sees the full landscape.

Stage 2 — Value Conflict Identification. Classifying fundamental vs. resolvable.

Conflict A (fundamental). Open-source-community values vs. commercial-sustainability values. The foundation values community-led governance; the corporate sponsor values commercial optionality. These cannot both be fully honored — community-led governance has structural limits on commercial control; commercial control has structural limits on community-led governance. No amount of information closes this.

Conflict B (fundamental). Loyalty to existing contributors vs. fairness to those who left for compensation. Loyalty asks the foundation to favor remaining contributors in resource allocation, governance positions, public credit; fairness asks the foundation to recognize that departed contributors had legitimate reasons and remain part of the project’s history. The two values cannot be fully honored simultaneously.

Conflict C (resolvable). Foundation funding model. The current funding model failed to compensate contributors competitively; the conflict over whether the funding model could change is resolvable — better information about funding alternatives (revenue-sharing licensing; sponsored maintenance contracts; foundation-managed contributor-compensation pools) closes it. This is genuinely an information problem layered on top of the fundamental value problems.

Two fundamental conflicts; one resolvable. Stage 2’s discipline matters here — the foundation board may want to treat Conflict A and B as resolvable (the optimistic synthesis-language temptation: “we just need to find a balance”). DCA refuses that framing; the conflicts are structural.

Stage 3 — Consequence Landscape Modeling. Three intervention candidates: do nothing; fight the fork; negotiate. Each modeled across three time horizons (1 year, 3 years, 10 years) with distributional analysis.

Do nothing. Year 1 — community fragments further; remaining contributor morale degrades; users start migrating to the fork because it ships faster. Year 3 — foundation project becomes a legacy stewardship operation; corporate fork becomes the de facto standard. Year 10 — foundation project either survives as a minority alternative or dissolves; foundation’s broader portfolio loses credibility as a governance model. Beneficiaries: the corporate sponsor, departed contributors. Cost-bearers: remaining contributors, users who valued community-led governance.

Fight the fork. Year 1 — public dispute about licensing and trademarks; foundation invests in legal action; community sympathizes but action drags. Year 3 — outcome depends on legal posture; if foundation prevails the corporate sponsor exits open-source entirely (loss of investment); if corporate sponsor prevails the foundation’s authority is diminished. Year 10 — open-source ecosystem becomes more cautious about corporate sponsorship broadly. Beneficiaries: future open-source projects (better-defined corporate-sponsor expectations), some users. Cost-bearers: current corporate sponsor relationships across the ecosystem; foundation’s resources.

Negotiate. Year 1 — foundation enters formal discussions; corporate sponsor agrees to a co-stewardship model with revenue-sharing; departed contributors return part-time. Year 3 — co-stewardship works or fails depending on governance details; either way, the foundation’s posture has shifted from independent to partnership-based. Year 10 — open-source ecosystem watches the experiment; either co-stewardship becomes a model others adopt, or the foundation’s authority is permanently diminished. Beneficiaries: corporate sponsor (validated commercial model), users who want unified ecosystem. Cost-bearers: foundation’s independence; community’s sense of community-led governance.

Stage 4 — Tradeoff Transparency. Each intervention as a tradeoff statement.

Do nothing. Prioritizes the foundation’s principled refusal to engage with the corporate move; subordinates the project’s continued vitality. Stakeholders not satisfied: remaining contributors (their work loses momentum); users who want continued community-led innovation. Consequence accepted: the project may become a legacy alternative within three years.

Fight the fork. Prioritizes the foundation’s authority and the long-term integrity of community-led governance norms; subordinates the current corporate relationship and the foundation’s resources. Stakeholders not satisfied: the corporate sponsor (and others who would have invested similarly); users who just want the software to work without governance drama. Consequence accepted: significant resource expenditure with uncertain legal outcome.

Negotiate. Prioritizes the project’s continued vitality and the relationship with the corporate sponsor; subordinates the foundation’s full independence. Stakeholders not satisfied: contributors and users for whom community-led governance was the load-bearing reason to participate. Consequence accepted: the foundation’s posture shifts permanently from independent to partnership-based.

Red Team passes (Stage 4). Each intervention is challenged in advocate stance per the subordinated stakeholder. Subordinated stakeholders for “negotiate”: the community-purist subset. Red Team in their advocate stance argues that negotiation is capture by another name; that the precedent will be cited every time another corporate sponsor wants concessions; that the foundation’s identity is the load-bearing asset and protecting it justifies short-term project decline. The Red Team argument is recorded; it does not change the framework’s output, but it is preserved in the Decision Clarity Document so the decision-maker confronts it before deciding.

Decision Clarity Document assembled. Executive summary names the problem as wicked (four-condition trigger fired); two fundamental value conflicts identified; three interventions modeled; framework recommends nothing — the decision is the foundation board’s.

That is what DCA produces. The board now sees the full structure of the decision, the fundamental conflicts that no amount of additional analysis will resolve, the three interventions with their tradeoffs and distributional consequences explicitly named, and the Red Team challenges to whichever path they lean toward. They can pick any of the three (or invent a fourth) with eyes open about what they are trading away. The framework’s job is done; the judgment is theirs.

Commercial AI comparison

Comparison content auto-populates when the comparison-refresh framework runs against this question. Drafters do not author this section.

Brief comparison commentary

Auto-populates with the comparison content above.

How to use this framework

You can run the Decision Clarity Analysis pattern with any AI of your choice. The composition is single-pass against the four-stage protocol.

The prompt:

[Paste the framework specification]

Run DCA on this problem.

Problem: [Plain prose description.]

Stakeholder landscape (optional): [Named stakeholder groups and their positions if known.]

Stance toward stakeholders (optional, if you are one): [Your own position, declared up front so it does not silently bias the analysis.]

The AI runs the four-condition trigger first; if fewer than three conditions fire, the AI declines DCA and recommends an alternative framework or mode. If three or four fire, the AI proceeds through Stage 1 → 4. The output is a Decision Clarity Document with executive summary plus four labeled stage sections.

For best results:

  1. Provide the stakeholder landscape if you can. Stage 1’s competing-framings pass needs the stakeholder set. Without it, the framework infers stakeholders from the problem description, which works but is slower.
  2. Declare your stance if you have one. If you’re a stakeholder rather than an external decision-maker, declaring your position up front lets Stage 4’s Red Team passes treat your stance as one of the framings rather than a hidden bias the framework has to detect.
  3. Don’t ask DCA for a recommendation. The framework’s discipline is the refusal-to-recommend rule — that discipline is what makes the output trustworthy. If you find yourself wanting the framework to pick for you, that may be a signal that the decision is harder than wicked-problem analysis can make easier.

The framework is deliberately tool-agnostic. The four-condition trigger, the fundamental-vs-resolvable classification discipline, and the refusal-to-recommend rule are conceptual disciplines that survive the lift to any environment. The Decision Clarity Document is plain markdown.

Other examples

  • A career decision involving meaning vs. financial security. A user has been offered a role that pays significantly more but moves them away from work they find deeply meaningful. The four-condition check fires (definition shifts under perspective — family vs. self vs. current colleagues; new dimensions emerge — relocation, partner’s career, future-self regret; no objective stopping condition — “the right choice” varies by stakeholder; value conflict is fundamental — financial security and meaningful work cannot be fully honored simultaneously when the offer requires moving). DCA produces the Decision Clarity Document. The user picks; the document records that they picked with full awareness of what they traded. Demonstrates DCA on a personal-scale wicked problem where the temptation is to ask an advisor to pick.

  • An organizational structure decision involving incompatible cultures. A company is considering merging two acquired teams that have incompatible work cultures (one consensus-driven, one fast-decision-driven). Three options: keep separate, merge with one culture dominant, design a new culture. DCA’s Stage 2 identifies the fundamental conflict: consensus values and decision-velocity values cannot be fully honored simultaneously at the team scale; either culture’s dominance subordinates the other; designing a new culture imposes change on both. The Decision Clarity Document makes the tradeoffs explicit; leadership picks; the dissatisfied subset of either team has visibility into why the choice was made. Demonstrates DCA on an organizational decision where the tradeoffs would otherwise be glossed with synthesis-language (“we’ll find a balance”).

  • A technical-architecture decision involving stakeholder value conflicts. A technical lead is choosing between two architecture options for a system that serves multiple internal teams with different priorities (one team values throughput; one values data correctness; one values feature velocity). DCA’s Stage 1 documents each team’s framing; Stage 2 identifies which conflicts are fundamental (throughput vs. correctness at the architecture scale is fundamental; the velocity team can be partly satisfied either way). Stage 3 models consequences. Stage 4 produces the tradeoff statement with explicit naming of which team cannot be satisfied by each option. The technical lead picks; the dissatisfied team understands why; future architecture decisions inherit the recorded reasoning. Demonstrates DCA in technical decision-making where the tradeoffs are real but commonly hidden behind technical-merits language.

Citations

The Decision Clarity Analysis Framework draws explicitly on Rittel and Webber’s wicked-problems literature (1973, “Dilemmas in a General Theory of Planning”), Russell Ackoff’s distinction between problems and “messes,” and the Problem Structuring Methods literature (Mingers, Rosenhead) that developed methodology for wicked-problem analysis without falling into the technical-rationality trap that conventional decision analysis perpetuates. The fundamental-vs-resolvable value-conflict classification draws on Isaiah Berlin’s value-pluralism work — incommensurable values cannot be ranked on a single scale; the structural feature of pluralism is that some conflicts are real, not artifacts of insufficient information.

The refusal-to-recommend rule draws on Churchman and Ulrich’s boundary-setting tradition in critical systems thinking — the analyst’s job is to make the value choices visible, not to make them on the decision-maker’s behalf. The four-condition trigger is internal to Ora and is the operationalization of Rittel’s ten properties of wicked problems into a fast-firing detection check (the full ten properties produce the same classification but are too long to evaluate in routing contexts).

The framework was renamed from Wicked Problems Framework v1.0 (2026-04-24) to Decision Clarity Analysis v2.0 (2026-05-01) per Decision H of the architectural lock; the analytical work split into the decision-maker-output-shaped DCA mode and the integrated multi-perspective Wicked Problems Analysis mode. The framework consumes other analytical modes (Competing Hypotheses, Cui Bono, Steelman Construction, Systems Dynamics, Scenario Planning, Red Team) at specific stages.

Downloads

  • Framework specification (PDF) — link to ora-ai.org canonical artifact when published
  • Framework specification (plain text) — link to ora-ai.org canonical artifact when published
  • Full white paper (PDF) — link when published