inversion

name: inversion description: "Use when a goal, plan, design, strategy, or assumption should be examined by reversing it: ask how to guarantee failure, how the opposite could be true, or what would have to happen for the desired outcome not to occur. Covers objective reversal, failure-path enumeration, obstacle-first planning, opposite-hypothesis testing, and prevention design. Do NOT use for decomposing a problem to irreducible premises (use first-principles-thinking), post-failure root-cause analysis (use debugging), recurring failure clustering (use pattern-recognition), or claim/source grounding (use epistemic-grounding). Do NOT use for Break this pricing model down to irreducible assumptions. Do NOT use for This incident already happened; find the root cause. Do NOT use for Score every webhook failure mode with severity, occurrence, and detectability. Do NOT use for Facilitate a team pre-mortem session with independent written generation." license: MIT allowed-tools: Read Grep metadata: relations: "{"related":["pattern-recognition","debugging","first-principles-thinking","epistemic-grounding"],"suppresses":["first-principles-thinking"],"verify_with":["epistemic-grounding","first-principles-thinking"]}" subject: reasoning-strategy public: "true" scope: "Use when a goal, plan, design, strategy, or assumption should be examined by reversing it: ask how to guarantee failure, how the opposite could be true, or what would have to happen for the desired outcome not to occur. Covers objective reversal, failure-path enumeration, obstacle-first planning, opposite-hypothesis testing, and prevention design. Do NOT use for decomposing a problem to irreducible premises (use first-principles-thinking), post-failure root-cause analysis (use debugging), recurring failure clustering (use pattern-recognition), or claim/source grounding (use epistemic-grounding)." taxonomy_domain: foundations/reasoning stability: experimental keywords: "["inversion thinking","invert the goal","reverse the problem","failure path","opposite hypothesis","obstacle first","what would make this fail","avoid failure","anti-goal","reverse reasoning"]" triggers: "["invert this plan","how could this fail","what would guarantee failure","reason from the opposite","avoid the worst outcome"]" examples: "["We want activation to improve. Invert the goal and identify what would make users abandon onboarding.","Before we commit to this launch plan, ask how it could fail and what safeguards follow.","Test the opposite hypothesis: what if the metric increase is actually bad?","What actions would guarantee this project misses the deadline?"]" anti_examples: "["Break this pricing model down to irreducible assumptions.","This incident already happened; find the root cause.","Score every webhook failure mode with severity, occurrence, and detectability.","Facilitate a team pre-mortem session with independent written generation."]" mental_model: "|" purpose: "|" concept_boundary: "|" analogy: "Inversion is like checking a bridge design by asking where it would snap first, not because you want it to snap, but because that is where reinforcement matters." misconception: "|" skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph" skill_graph_project: Skill Graph skill_graph_canonical_skill: skills/reasoning-strategy/inversion/SKILL.md skill_graph_export_description_projection: anti_examples

Concept Card

What it is: Inversion is a reasoning technique that examines a desired outcome by reversing it: ask how to cause failure, how the opposite claim could be true, or what would prevent the goal from happening.

Mental model: A plan has a success path and a failure surface. Forward reasoning maps the success path. Inversion maps the failure surface first, then turns that map into safeguards, tests, and constraints.

Why it exists: People over-plan the route to success and under-plan the ways they can sabotage it. Inversion makes hidden blockers, perverse incentives, ignored constraints, and false assumptions easier to see.

What it is NOT: It is not cynicism, not post-incident debugging, not first-principles decomposition, not FMEA scoring, and not the full facilitated pre-mortem protocol.

Adjacent concepts: first-principles thinking, pre-mortem, FMEA, debugging, epistemic grounding, pattern recognition.

One-line analogy: Inversion is stress-testing a plan by first drawing the map of how it breaks.

Common misconception: The trap is treating inversion as "be negative." The point is not to dwell on failure; the point is to convert failure paths into prevention.

Inversion

Concept of the skill

Inversion has three primitives: desired outcome, opposite outcome, and causal path. The method temporarily replaces "How do we get X?" with "How would we guarantee not-X?" or "What would have to be true for the opposite of our claim to hold?" The output is not pessimism; it is a map of blockers, failure paths, perverse incentives, hidden assumptions, and avoidable behaviors. The agent then translates the inverted map back into prevention, constraints, tests, or decision changes.

Replaces one-direction optimism with obstacle-first reasoning. Forward planning tends to over-focus on actions that might create success and under-examine the behaviors, constraints, and assumptions that would reliably destroy it. Inversion forces the negative space into view: instead of asking only how to win, it asks how to lose, how to be wrong, or how the opposite could be true, then uses those answers to remove avoidable failure paths.

Distinct from first-principles thinking, which decomposes a problem into primitives and rebuilds forward; inversion reverses the target state and reasons backward from failure or negation. Distinct from debugging, which investigates a failure that already occurred; inversion is prospective and can be used before action. Distinct from FMEA, which systematically enumerates component-level failure modes and scores them; inversion is lighter-weight and starts from the goal or claim. Distinct from pre-mortem, which is a facilitated team process using assumed future failure; inversion is a general reasoning move usable by one agent on a plan, claim, or design. Inversion is like checking a bridge design by asking where it would snap first, not because you want it to snap, but because that is where reinforcement matters. The common misconception is that inversion is negativity or risk avoidance. It is not. Inversion is a search strategy. It finds the constraints and behaviors that forward optimism misses, then converts them into action: remove the blocker, add a guardrail, test the opposite hypothesis, or change the plan.

Coverage

Inversion covers the deliberate reversal of goals, claims, plans, and designs. It includes goal inversion, opposite-hypothesis testing, obstacle-first planning, anti-goal definition, failure-path enumeration, success-sabotage analysis, and conversion of inverted findings into concrete safeguards.

Use this skill when the question sounds like:

• "How could this fail?"
• "What would make the opposite true?"
• "What should we avoid doing?"
• "What would guarantee this project misses?"
• "How might this metric improvement backfire?"

Philosophy of the skill

Forward reasoning is naturally attractive because it aligns with desire: define the goal, list actions, execute. That shape is useful, but it hides the negative space. Many plans fail because of one avoidable blocker, one untested assumption, one incentive that rewards the wrong behavior, or one condition that would have been obvious if the team had asked how to lose.

Inversion is a compact antidote. It does not replace planning; it improves planning by forcing the plan to survive its own opposite. If the inverted analysis produces no changes, either the plan is unusually robust or the inversion was too generic.

Good inversion ends in action. A list of scary possibilities is not the deliverable. The deliverable is a changed plan, sharper test, added guardrail, removed anti-pattern, or explicit accepted risk.

The Workflow

1. State the forward goal or claim

Name the target precisely. Vague goals produce generic failure lists.

Bad frame: "Make the product better."

Better frame: "Increase first-week activation without increasing support burden."

2. Invert the target

Choose the inversion that fits the task.

3. Enumerate failure paths without filtering

List specific causes, not broad categories.

Weak: "Bad communication."

Strong: "The owner changes the API contract but the integration test still mocks the old response, so the failure ships."

Look for:

• ignored constraints
• stale assumptions
• perverse incentives
• missing feedback loops
• hidden dependencies
• success metrics that can be gamed
• irreversible steps
• delayed detection
• human attention limits

4. Convert each failure path into a control

Every material failure path needs one of these outcomes.

5. Re-run the forward plan

Apply the controls and restate the plan. If the plan still depends on avoiding obvious failure paths by luck, it is not ready.

Inversion Patterns

Anti-goal inversion

Ask: "If we wanted the worst plausible result, what would we do?"

Useful for behavior design, operations, and product workflows. The answer exposes what to forbid, monitor, or design away.

Opposite-hypothesis inversion

Ask: "What evidence would make the opposite conclusion true?"

Useful for strategy, research, metrics, and arguments. This prevents a favored hypothesis from becoming unfalsifiable.

Metric inversion

Ask: "How could this metric improve while the real system gets worse?"

Useful when optimizing engagement, conversion, productivity, quality scores, or model evals. The answer exposes Goodhart risk and proxy misuse.

Constraint inversion

Ask: "Which constraint, if violated, would break the whole plan?"

Useful for architecture, launches, compliance, and reliability. The answer identifies load-bearing assumptions.

Anti-Patterns

Verification

After applying this skill, verify:

• The forward goal or claim is specific.
• The inversion prompt matches the target type.
• Failure paths are concrete causal paths, not generic categories.
• The list includes mundane and high-consequence failures.
• At least one opposite-hypothesis or metric-backfire check was considered when claims or metrics are involved.
• Every material failure path maps to prevent, detect, buffer, rehearse, accept, or redesign.
• The forward plan, claim, or design changed or the accepted-risk rationale is explicit.
• The output does not pretend inversion is a post-failure root-cause method.

Do NOT Use When

Key Sources

• Carl Jacobi is widely associated with the maxim "invert, always invert" in mathematical problem solving; the practical lesson is to transform hard forward problems into easier reverse ones.
• Charlie Munger popularized inversion as a general decision-making mental model: identify what would produce failure, then avoid it.
• Karl Popper's falsification frame supports opposite-hypothesis testing: a claim becomes stronger when the conditions that would refute it are made explicit.
• Gary Klein's pre-mortem method applies a group-process version of inversion by assuming future failure and reasoning backward to causes.
• Reliability methods such as FMEA are adjacent formalizations: they convert possible failure modes into prioritized mitigation work.

Skill Graph context

Classification

• Subject: reasoning-strategy
• Public: true
• Domain: foundations/reasoning
• Scope: Use when a goal, plan, design, strategy, or assumption should be examined by reversing it: ask how to guarantee failure, how the opposite could be true, or what would have to happen for the desired outcome not to occur. Covers objective reversal, failure-path enumeration, obstacle-first planning, opposite-hypothesis testing, and prevention design. Do NOT use for decomposing a problem to irreducible premises (use first-principles-thinking), post-failure root-cause analysis (use debugging), recurring failure clustering (use pattern-recognition), or claim/source grounding (use epistemic-grounding).

When to use

• We want activation to improve. Invert the goal and identify what would make users abandon onboarding.
• Before we commit to this launch plan, ask how it could fail and what safeguards follow.
• Test the opposite hypothesis: what if the metric increase is actually bad?
• What actions would guarantee this project misses the deadline?
• Triggers: invert this plan, how could this fail, what would guarantee failure, reason from the opposite, avoid the worst outcome

Not for

• Break this pricing model down to irreducible assumptions.
• This incident already happened; find the root cause.
• Score every webhook failure mode with severity, occurrence, and detectability.
• Facilitate a team pre-mortem session with independent written generation.

Related skills

• Verify with: epistemic-grounding, first-principles-thinking
• Related: pattern-recognition, debugging, first-principles-thinking, epistemic-grounding

Concept

• Mental model: |
• Purpose: |
• Boundary: |
• Analogy: Inversion is like checking a bridge design by asking where it would snap first, not because you want it to snap, but because that is where reinforcement matters.
• Common misconception: |

Keywords

• inversion thinking, invert the goal, reverse the problem, failure path, opposite hypothesis, obstacle first, what would make this fail, avoid failure, anti-goal, reverse reasoning