The Consensus Decision Helper App determines whether you need consensus at all, and which kind of consensus procedure fits the situation. Every recommendation includes a short, built-in playbook, the concrete steps to run that procedure.

How the app works?

The app implements a decision tree described below.

Q1 — Are implementers interdependent?

Idea: If successful execution depends on cross-unit cooperation, you usually need buy-in; if not, you can rely on authority.

• NO → “No consensus necessary.”
  Use direct authority or a simple vote; the app still gives steps (assign accountable owner, document rationale, communicate, monitor).
• YES → go to Q2.

Q2 — Is the decision costly to reverse?

Idea: The more irreversible the decision, the more care you need in building agreement.

• LOW (reversible/experimental) → “Rough consensus.”
  Time-boxed discussion; aim for ~70–80% agreement or facilitator closure; good for pilots and annual cycles.
  App outputs: steps to time-box, round-robin options, test for “no strong reasoned objection,” record unresolved issues, set a review date.
• HIGH (irreversible/strategic) → go to Q3.

Q3 — How uncertain/contested is the information?

Idea: If facts are stable and shared, consent is feasible; if evidence is disputed, use structured, multi-round methods.

• LOW → “Consent-based consensus.”
  Discuss and address reasoned objections; proceed once none are sustained (stand-asides allowed).
  App outputs: steps to separate facts/values, surface objections, amend proposals, record rationale and stand-asides.
• HIGH → go to Q4.

Q4 — How large is the decision-making group?

Idea: Method scales with group size to manage participation, dominance, and information processing.

• SMALL (≤15) → “Facilitated consensus meeting.”
  Round-robin, visible criteria, neutral facilitation; closure at ≥80% consent or no reasoned objection.
  App outputs: agenda prep, criteria grid, synthesis & closure steps, minutes and follow-through.
• MEDIUM (16–50) → “Modified Delphi / Nominal Group Technique.”
  Multi-round (idea generation → clarification → anonymous scoring), with stability as closure rule.
  App outputs: round designs, feedback summaries, median/IQR scoring, stability thresholds.
• LARGE (51+) → go to Q5.

Q5 — Do participants share a professional/technical domain?

Idea: Large groups with shared expertise suit Delphi; value-diverse groups need public deliberation.

• YES → “Delphi or computational consensus.”
  Anonymous expert rounds; quantitative agreement (e.g., median & IQR) drives closure.
  App outputs: panel setup, round scripts, quantitative thresholds, publication of rationales.
• NO → “Consensus conference / deliberative forum.”
  Evidence presentations + moderated deliberation; include dissent; supermajority fallback.
  App outputs: forum design, balanced recruitment, session flow, consensus statement, dissent handling.

Q6 — Is time pressure severe?

Modifier, not a selector.
The app compresses whichever method you reached:

• Under pressure: use “rough-consensus” thresholds, fewer rounds, and record unresolved objections for follow-up.
• No pressure: run the full procedure with multiple feedback rounds.

One-screen cheat sheet (inputs → output)

• Q1 = No → No consensus necessary (direct authority/simple vote).
• Q1 = Yes; Q2 = Low → Rough consensus (quick, reversible).
• Q1 = Yes; Q2 = High; Q3 = Low → Consent-based consensus (address objections).
• Q1 = Yes; Q2 = High; Q3 = High; Q4 = Small → Facilitated consensus meeting.
• …; Q4 = Medium → Modified Delphi / NGT (anonymous scoring; stability).
• …; Q4 = Large; Q5 = Yes → Delphi / computational consensus (quant metrics).
• …; Q4 = Large; Q5 = No → Consensus conference / deliberative forum (public deliberation).

(At the end, Q6 annotates the chosen method with compressed vs. full execution guidance.)

What the app outputs

For your chosen path it shows:

1. Recommended consensus type + a short headline (why this fits).
2. Key bullets summarizing the logic.
3. Implementation playbook — numbered, actionable steps specific to the method.
4. Time-pressure note — how to compress or extend the method responsibly.