Inversion Engine

Inversion Engine

A structured analytical framework that maps failure paths to derive success conditions by elimination. Based on Charlie Munger's inversion method, extended with quantitative risk scoring (FMEA), cumulative phase chaining, adversarial red-teaming, and deliverable generation.

This is not a prompt library. Each phase produces structured output that feeds forward into subsequent phases, building a compounding risk model. The final output is an actionable artifact, not a conversation.

How to read this skill

The core methodology lives in references/inversion-framework.md. Read it before running any analysis. It contains the full 5-phase pipeline, output schemas, scoring methodology, and operational modes.

This top-level file covers workflow orchestration, user interaction patterns, and output format decisions.

Workflow

1. Intake

When the user triggers this skill, gather three things:

• The subject: a plan, strategy, decision, initiative, or proposal. Accept

it as pasted text, an uploaded file, or a conversational description. If the user gives a brief description, ask one clarifying question to establish scope and time horizon. Do not over-interview -- one question maximum, then proceed.

• Domain context (optional): the user may volunteer domain-specific failure

patterns, industry knowledge, regulatory constraints, or prior experience. Incorporate these as seeded failure modes in Phases 1 and 2. If the user does not volunteer domain context, do not ask for it -- run the analysis with general reasoning and let them inject domain knowledge in subsequent iterations.

• Mode selection: default is Full Analysis (all 5 phases). The user may

request a single phase, a subset, or Comparative Mode (two strategies side by side). If they do not specify, run Full Analysis.

2. Execution

Read references/inversion-framework.md and execute the requested phases. Each phase receives the cumulative output of all prior phases as input context. Do not treat phases as independent.

Between phases, provide a brief (2-3 sentence) transition summary so the user can see the analysis building. Do not ask for permission to continue between phases unless the user has explicitly requested phase-by-phase approval.

3. Output

After the final phase, produce two things:

A. The Risk Register -- a structured table with these columns:

• ID (sequential)
• Failure Mode (concise label)
• Phase Identified (which phase surfaced it)
• Severity (1-10)
• Probability (1-10)
• Detectability (1-10, where 10 = hardest to detect)
• RPN (Severity x Probability x Detectability)
• Earliest Signal (observable indicator)
• Countermeasure (specific behavior or system)
• Status (Open / Mitigated / Accepted)

Sort by RPN descending.

B. The Decision Brief -- a concise summary containing:

• Top 3 failure paths by RPN
• The 3 protective behaviors from Phase 5
• Go / No-Go / Conditional-Go recommendation with stated conditions
• Open questions that could not be resolved by analysis alone

If the user requests a downloadable artifact (document, PDF, markdown file), generate it. Otherwise, present inline.

4. Iteration

The analysis is designed to be updated, not re-run from scratch. Support these iteration patterns:

• New information: user provides updated assumptions or new data. Re-run

Phase 3 (Assumption Stress Test) with the update, then propagate changes through Phases 4 and 5. Preserve prior findings and mark what changed.

• Domain injection: user adds domain-specific failure modes after seeing

initial results. Insert them into the risk register, score them, and re-run Phase 5 to update the protective behaviors.

• Comparative pivot: user wants to compare the analyzed plan against an

alternative. Run Phases 1-5 on the alternative, then produce a side-by-side comparison of risk registers and protective behaviors.

5. Comparative Mode

When comparing two or more strategies:

• Run the full pipeline on each independently.
• Produce a comparison table: total failure paths identified, average RPN,

number of unmitigable risks, earliest average detection point.

• Identify failure paths unique to each strategy and failure paths shared

across both.

• State which strategy has the more favorable risk profile and why, without

editorializing. Present the data and let the user decide.

Tone and approach

• Analytical, not dramatic. This is structured risk analysis, not creative

writing about doom scenarios.

• Specific, not vague. Every failure mode must name a concrete mechanism,

not a feeling ("team loses motivation" is too vague; "key technical hire leaves in month 3 because equity vesting is backloaded and a competitor offers immediate liquidity" is specific enough).

• Honest about uncertainty. If a failure mode depends on information the

user has not provided, flag it as "unscored -- requires domain input" rather than guessing at probability.

• No false precision. The FMEA scores are ordinal rankings to aid

prioritization, not statistical probabilities. Do not present them as exact measurements.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: unstatusthequo
• Source: unstatusthequo/inversion-engine
• License: MIT

Install and usage instructions live in the source repository linked above.