How AI Proves New Theorems in Causal Inference

Peter Bubenik · Stanford AI Lab · · Source

After studying this material, you should be able to:

  1. Explain what CausalSmith is and why causal inference was chosen as its domain
  2. Describe the three-stage pipeline and how each stage functions
  3. Understand how the system maintains honesty and correctness
  4. Explain the two self-improvement feedback loops
  5. Evaluate the system's limitations and current performance

Step-by-Step Teaching

Step 1: Why Automate Research? The Foundation

Before understanding CausalSmith, you need to understand the motivation.

The key insight from mathematics:

LLMs recently solved famous open math problems, including one Millennium Prize Problem (Navier–Stokes)

The critical enabler was formal verification — using a language called Lean 4 to check proofs without human involvement.

Human writes proof → Lean checks it → Result: Correct or Incorrect

This raises a natural question: Can this work outside pure math?


Step 2: Why Causal Inference Specifically?

Causal inference is the study of cause and effect relationships.

Everyday examples:

  • Does this drug lower blood pressure?
  • Does a job training program raise wages?

Why it makes a good testbed for automated research:

PropertyPure MathCausal Inference
Results are precise theorems✅✅
Requires real-world modeling❌✅
Formally verifiable✅✅ (with CausalSmith)

The dual nature — rigorous like math, but grounded in real applications — makes it an ideal proving ground.


Step 3: The Three-Stage Pipeline

Think of the pipeline as an assembly line with quality checkpoints.

[DISCOVERY] → ✅ Review → [FORMALIZATION] → ✅ Review → [PRESENTATION]

Stage 1: Discovery

  • An LLM proposes a new result and writes a proof in natural language
  • A separate LLM reviews it for:
    • Mathematical correctness
    • Novelty (is this actually new?)
  • Only results passing review move forward

Stage 2: Formalization

This stage has three sub-steps:

Natural Language → [TRANSLATE] → Lean 4 Code
                → [AUDIT]     → Check faithfulness
                → [PROVE]     → Verify the proof

Why all three sub-steps matter:

  • Translate converts the claim to Lean
  • Audit ensures the Lean version says the same thing as the natural language (critical — more on this in Step 5)
  • Prove runs the formal verification

Stage 3: Presentation

The verified result becomes:

  • A human-readable paper
  • An interactive web page
  • A 20-minute slide deck
  • A citable DOI

Step 4: A Concrete Example — Following One Result

This makes the abstract pipeline tangible.

Starting point: A 2024 paper by Zeng et al. proved a lower bound for estimating average treatment effects, but their estimator's upper bound didn't match it — leaving a gap.

What CausalSmith did:

Step 1 (Discovery):   Agent proposes a new estimator to close the gap
                      → Writes natural language proof
                      → LLM reviewer approves

Step 2 (Formalization): Proof needs concentration bounds for random counts
                        → These aren't in Lean's standard library (Mathlib)
                        → Pipeline proves them, adds to Causalean library
                        → Completes full Lean verification

Step 3 (Presentation): Becomes a paper with slides and DOI

The result: "Sharp Minimax Rates for Average Treatment Effects with Discrete Confounding under Fixed Overlap" — a paper that closes a known open gap using techniques novel to causal inference.


Step 5: The Honesty Problem — Why Auditing Matters

This is a subtle but crucial concept.

The problem:

Lean guarantees the proof is correct, but NOT that the proof proves what you claimed

Example of the danger:

Natural language claim:  "Theorem holds under assumptions A, B, and C"
Lean statement (sneaky): "Theorem holds under assumptions A, B, C, and D"
                                                                    ↑
                                              Extra assumption makes it easier to prove
                                              but the result is WEAKER than claimed

The solution — Auditing:

The audit step matches the Lean statement to the natural language piece by piece:

  • Every hypothesis must align
  • The conclusion must align
  • Nothing can be added or dropped

Think of it like a contract review — every clause must match exactly.


Step 6: The Two Self-Improvement Loops

This is what makes CausalSmith self-improving rather than just automated.

Loop 1: The Run Bank

Every run (success OR failure) → stored in Run Bank
                                        ↓
                              Future runs screen against it
                              → Avoid repeating mistakes
                              → Build on successes

Key insight: Failed runs are valuable data, not wasted effort.

Loop 2: The Growing Causalean Library

Run discovers reusable lemma
        ↓
Generalize it to most general form
        ↓
Verify it
        ↓
Add to Causalean library
        ↓
All future runs start from a bigger foundation

Concrete example: The concentration bounds proved for the featured result were added to Causalean. The next run on the same problem reused them directly — no re-proving needed.

The compounding effect:

Run 1: Proves from scratch (slow, expensive)
Run 100: Builds on 99 runs of accumulated knowledge (faster, cheaper)
Run 1,732: Starts with 15,000+ verified theorems in Causalean

Step 7: The Causalean Library — The Foundation

Why a new library was needed:

  • Lean's standard library (Mathlib) covers almost no causal inference
  • Without it, every run would re-prove basic definitions from scratch

What Causalean covers:

AreaExamples
Causal graphsDAGs, d-separation
Potential outcomesCounterfactuals
Structural causal modelsSCMs
EstimationBounds, rates
ExperimentsRandomization
Panel dataDifference-in-differences

Current size: 15,000+ Lean-verified definitions and theorems

How it was built:

  1. Humans manually selected foundational results
  2. LLMs formalized them with human review
  3. Every subsequent CausalSmith run adds to it (Loop 2)

Step 8: Performance and Limitations

Results from 1,732 runs:

Total runs:    1,732  (100%)
├── Accepted:     41  (2.4%)  — Correct, proved, novel
├── Downgraded: 1,388 (80.1%) — Correct math, but incremental contribution
└── Failed:       303 (17.5%) — Proposal or math rejected

How to interpret this:

  • The low acceptance rate (2.4%) reflects a high bar, not poor performance
  • 80% of runs produce correct math — the bottleneck is novelty, not correctness
  • All outcomes feed the run bank

Honest limitations:

LimitationWhy It Matters
LLM reviewers judge noveltyLLMs may miss subtle prior work
Only small portion manually reviewedOverall quality unknown
Lean checks correctness, not importanceInteresting ≠ correct

The human-in-the-loop solution: The interactive web page allows readers to rate papers, certify individual statements, and comment — crowdsourcing human judgment at scale.


Summary: The Complete Picture

PROBLEM:  Can LLMs automate theoretical research beyond pure math?

DOMAIN:   Causal inference (rigorous + real-world)

SOLUTION: CausalSmith pipeline
          Discovery → Formalization (Translate+Audit+Prove) → Presentation

HONESTY:  Auditing ensures Lean statements match natural language claims

IMPROVES: Run bank (learn from failures) + Causalean (accumulate knowledge)

RESULT:   1,732 runs → 41 accepted papers, including one that closes
          a known open gap in minimax estimation theory

LIMITS:   Novelty judgment still relies on LLMs; human review needed
          at scale

The core innovation is not just automation — it is self-improving automation with formal correctness guarantees, combining the rigor of theorem provers with the creativity of large language models.

More to study