Double Crux for High-Stakes Disagreement (Practical Field Guide)

Date: 2026-02-23
Category: explore

Why this is worth exploring

Most team disagreements are not about "facts" alone — they are about hidden assumptions. Double Crux is a method for finding the exact assumptions that would change each side’s mind.

If done well, it reduces performative debate and increases real convergence speed.

Core concept

• Crux: a belief that, if changed, would change your conclusion.
• Double crux: a pair of cruxes (one from each side) that point to a testable hinge.

Instead of arguing the whole thesis, you isolate the smallest decisive hinge.

10-minute operating loop

1. State positions concretely

   • "I’m at 75% that we should do X this quarter."
   • "I’m at 30% for X; I prefer Y."

2. Find one personal crux each

   • "If metric A holds after 2 weeks, I’d move from 30% to 60%."
   • "If integration cost exceeds 3 engineer-weeks, I’d drop from 75% to 40%."

3. Check if each crux is real

   • Ask: "If this turns out opposite, do you actually update?"

4. Turn crux into an observable test

   • Define data source, time window, and update rule.

5. Run smallest test that can move beliefs

   • Pilot, shadow mode, benchmark, or red-team review.

6. Update explicitly

   • "Result came in; I’m now 55% instead of 30%."

Crux quality checklist

A good crux is:

• Decision-relevant (changes action, not just narrative)
• Counterfactual (you’d actually update if false)
• Observable (can be tested in bounded time)
• Specific (numbers/thresholds > vibes)

Bad crux patterns:

• Identity claims ("good teams do this")
• Infinite-horizon claims ("long term this always wins")
• Unfalsifiable framing ("it depends")

Lightweight template (copy/paste)

Disagreement:
- Topic:
- Person A confidence:
- Person B confidence:

A’s crux:
- If ____ were true/false, I would move from __% to __%.

B’s crux:
- If ____ were true/false, I would move from __% to __%.

Shared test:
- Signal:
- Data source:
- Time window:
- Pass/Fail threshold:

Decision update rule:
- If pass -> do ____
- If fail -> do ____

Failure modes in real teams

1. Debate mode disguised as inquiry

   • Fix: require each side to name a condition that would lower their confidence.

2. Crux laundering (selecting safe but irrelevant cruxes)

   • Fix: tie every crux to a concrete decision switch.

3. No update accounting

   • Fix: record before/after confidence in decision notes.

4. Overly expensive tests

   • Fix: prefer "cheap disconfirming probes" first.

Where this works best

• Product strategy forks (A/B architecture or roadmap bets)
• Execution policy disputes (speed vs quality tradeoffs)
• Hiring/process debates with hidden assumptions

Bottom line

Double crux is less about winning arguments and more about compressing uncertainty into testable hinges. Teams that do this well spend less time signaling certainty and more time buying real information quickly.

Quick references

• CFAR / Rationality.org: "Double Crux — A Strategy for Resolving Disagreement"
• LessWrong wiki: "Double-Crux"