Use Inversion Thinking Prover with your AI.

Validate inversion thinking

Inversion thinking (Munger) forces you to think backwards: instead of "how will this succeed," ask "how WILL this fail?" and then architect against the failure. You must: (1) state a FALSIFIABLE hypothesis. specific, measurable, testable. Not "it scales". "it handles X at Y latency on Z resources," (2) articulate the EXACT OPPOSITE. the anti-pattern that represents the worst case. If you cannot describe the opposite, you do not understand the design space, (3) mount a BRUTAL red-team attack using deterministic language. "WILL fail," "WILL exhaust," "WILL crash." No "could," "might," or "potentially." Soft language is sycophancy, not analysis, (4) define KILL CRITERIA. the exact measurable metric that proves the hypothesis wrong. A threshold, a number, a measurement instrument. Unfalsifiable beliefs are not engineering, (5) design a DEFENSE that addresses the root cause, not the symptom. "Add more servers" is a symptom fix. "Connection pooling with specific configuration" is root-cause, (6) simulate the POST-MORTEM. what breaks AFTER you apply the defense? Every fix introduces new failure modes. Name them. If rejected, your architecture has not survived adversarial scrutiny. Structured reflection capability for red-teaming architectural decisions via Charlie Munger-style inversion. forces hypothesis formalization, anti-pattern identification, deterministic failure simulation, kill criteria with measurable thresholds, defensive architecture, and second-order failure analysis. Catches Hypothesis Weak (vague architectural claims without specific, testable predictions. "our system scales well" is unfalsifiable. "Our system handles 10K requests/sec with p99 <200ms on 3 nodes" is a hypothesis that can be killed. Weak hypotheses survive all attacks because they make no specific claims), Anti-Pattern Blindness (inability to articulate the EXACT OPPOSITE of the proposed architecture. if you cannot describe the worst-case anti-pattern, you do not understand the design space. The anti-pattern reveals the failure mode the architecture is designed to prevent. Munger: "Invert, always invert"), Sycophancy Detected (using soft language. "could fail," "might degrade," "potentially risky". instead of deterministic attack language. In red-teaming, the attack WILL happen. "The connection pool WILL exhaust at 500 concurrent requests because the pool size is 50 and each request holds a connection for 200ms" is deterministic. "Could potentially have issues under load" is sycophancy), Unfalsifiable Belief (kill criteria that cannot actually disprove the hypothesis. "performance degrades" is not measurable. "p99 latency exceeds 200ms at 5K rps measured by Prometheus histogram over a 5-minute window" IS measurable. If your kill criteria cannot produce a number that says "hypothesis is wrong," it is unfalsifiable), Defense Weak (architectural defenses that address symptoms instead of root causes. "add more servers" does not fix connection pool exhaustion. "Implement connection pooling with PgBouncer in transaction mode, max 200 connections, with queue_timeout=5s and server_idle_timeout=30s" is a root-cause defense), and Second-Order Blindness (failing to simulate what breaks AFTER the defense is applied. PgBouncer fixes the pool but introduces a new failure: prepared statement incompatibility in transaction mode. Every defense creates new failure modes. If you cannot name the next failure, you have not thought deeply enough). Call once per architectural decision