CausalSmith · AI Causal Scientist

CausalSmith: a formally grounded, self-improving research pipeline

CausalSmith is an autonomous system that discovers a causal-inference result, formalizes it, proves it in Lean 4, and writes it up as a paper — with every formal statement machine-checked by the proof kernel and audited to mean what it says. This page walks through the pipeline end to end, mostly in pictures.

The problem

Machines write research faster than we can check it

Language models now generate conjectures, proofs, and whole papers far quicker than anyone can evaluate them. In theory work an incorrect theorem can look exactly like a correct one until it is verified — and the popular fix, letting one model review another, is not a reliable correctness oracle.

82% A calibrated board of LLM reviewers accepted deliberately fabricated papers up to 82% of the time, detecting the fabrication no better than chance. An LLM judge of "is this good research?" can be fooled. Jiang et al., BadScientist: Can a Research Agent Write Convincing but Unsound Papers that Fool LLM Reviewers?, arXiv:2510.18003 (2025).

Formal verification offers a different footing. When a proof is accepted by Lean's kernel, it is valid relative to a small trusted core — a guarantee no LLM reviewer can give. CausalSmith is built around making that guarantee cheap, and around the one thing the kernel still cannot check.

The idea

Separate three questions we usually blur together

"Is this good research?" bundles three very different questions. CausalSmith pulls them apart, and handles each where it can actually be handled.

Soundness

Is the proof valid?

Eliminated by construction: the Lean kernel mechanically checks every step against its trusted core.

settled by the Lean kernel
Faithfulness

Does the statement mean the intended claim?

The kernel does not give you this. It is audited node by node — a small, local, re-checkable comparison, not a certificate.

audited by the logic-graph audit (model + human)
Significance

Is a correct, faithful theorem interesting?

Not guaranteed by either of the above. It stays an explicit human judgment — the pipeline never pretends otherwise.

judged by a human

The whole design shrinks the residual judgment from the open-ended "is this valuable research?" to the bounded "does this Lean statement match this English claim?"

The pipeline

Discover → Formalize → Prove → Present

A result moves left to right through four stages, clearing a gate between each. Two feedback loops make the system improve itself: it reuses a verified library and grows it, and it records every run so the next proposal starts from what has already been tried.

novelty + soundness statement faithfulness convergence review Discover propose → solve Formalize plan → scaffold Prove fill → review kernel-checked Present assemble & link Causalean verified · 6,583 reusable lemmas reuse study mode Run bank every proposal & outcome — accepted, downgraded, or failed recon record

The pipeline. Amber pills are the gates a result must clear; the green library below feeds reuse into Formalize and receives proven lemmas back through study mode; the run bank records every run and feeds reconnaissance before the next proposal.

Discover
A proposer drafts a claim; a novelty gate checks it against the literature; a solver derives a formalizable core. It may narrow an over-strong claim, never weaken one to make a proof easy.
Formalize
The plan becomes a Lean scaffold of proof obligations. A review-and-fill loop resolves them, reusing library results; a lint flags any hypothesis the proof never uses.
Prove
Obligations are discharged against the live compiler. The kernel establishes soundness here — nothing with an open goal, sorry, or a smuggled axiom gets through.
Present
An accepted, audited result becomes a working paper in which every theorem, definition, and assumption links to its verified Lean source.
Under the hood

The full pipeline, stage by stage

Those four stages expand into a deterministic state machine. Each stage either advances or, through a gate (amber), returns work to the stage before it; four checkpoints (red) halt the run for an external decision. The inset zooms into the F2–F4 proof-and-faithfulness loop: a scaffold mismatch returns to F2, while a blocking lint or failed convergence review re-enters at F2.5; a genuinely false claim from F2.5 or F3 escalates out to the mathematics rather than being quietly rewritten to pass.

Discovery Formalization reject / revise sharpen: re-solve D–1.1recon D–1.2proposal + core D–0.5proposal gate D0derivation + note D0-maxsharpen? D0.5derivation gate frozen core ckpt D/Fcommit to F? F1plan + graph F1.5plan + reuse gate ckpt 1audit F2–F4proof + audit loop F5banking prep ckpt 2bank F2–F4 zoom mismatch → F2 lint block → F2.5 F4 fail → F2.5 pass F2Lean scaffold F2.5scaffold vs. spec F3proof-review loop F3.5lint + cheat scan F4convergence review false claim → D0 (via ckpt 1) work gate audit checkpoint escalate / revise bounded proof loop

The operational stage flow of one theorem run. Discovery (top) produces a proposal and typed core, frozen at D0.5 and handed through the D/F checkpoint to Formalization; amber gates return work to the preceding stage and red checkpoints mark run halts for external judgment. The green band details the bounded F2–F4 loop the kernel-checked proof runs inside.

The unit of audit

Every result is a graph of statements

A result is stored as a logic graph: nodes are statements — a setup, a definition, an assumption, a lemma, the headline theorem — and edges record dependencies. This turns the global question "is this proved and faithful?" into a per-node one, so a change re-opens only the nodes it touches instead of the whole paper.

setup def D₁ cited A₂ gated A₁ lemma L₁ lemma L₂ theorem T
matched drift unreviewed cited (borrowed) critical path statement-uses proof-uses

A logic graph (schematic). Fill encodes review status; a dashed blue border marks a borrowed cited node off the critical path. The green underlay traces the critical path of gated nodes the audit must clear before the result is banked.

What the kernel can't see

Four ways a proof can pass yet mislead

A development can be free of sorry and still be uninformative. The audit targets four families of failure — every one type-checks, so the kernel accepts them all.

Semantic-only

Type-checks but states the wrong proposition. Caught by a per-node statement ↔ claim match.

Vacuity

A concept defined as True, an unsatisfiable hypothesis, or a witness with no real obstruction — the theorem holds emptily. Caught by witness normalization and a hypothesis-satisfiability check.

Laundering

An unproven step slipped in as an axiom, sorry, or native_decide; or a load-bearing node mis-tagged as merely cited. Caught by a mechanical cheat-token scan and gated-vs-cited attestation.

Generality drift

A dropped hypothesis or a hardcoded constant leaves the theorem narrower than claimed. Caught by a statement gate and an unused-hypothesis lint.

Mechanical scans, an independent reviewer with fresh context, and a human adjudicator at load-bearing checkpoints keep the auditor from sharing the blind spots of whatever produced the statement.

The substrate

Causalean: a verified library agents build on

Formalizing from first principles is slow, so the pipeline composes a foundational Lean library of causal inference rather than re-deriving results. It layers from graphical and measure-theoretic foundations up to the estimation and design methods on top, with a retrieval index spanning the whole stack — the interface agents query to reuse a result instead of reinventing it.

Foundations Graph (DAG, d-separation, SWIG) · local Mathlib Models SCM & do-calculus · potential outcomes · asymptotic statistics Identification exact (ATE / DiD / LATE) · partial (Manski, Balke–Pearl) Methods estimation (DML, minimax) · panel · experimentation · discovery Retrieval 8,179 declarations concept · type goal · semantic

Causalean in layers: foundations support the model languages, which support identification, which supports the methods on top. One retrieval index over all declarations spans the stack and is what the pipeline queries.

Machine-checked declarations
8,179
Files
1,073
Lines of Lean
~303k
Clusters
10
Relying on sorry
0

Nothing in the library relies on sorry and it contains no hand-written axiom. A few flagship results give a sense of its depth:

backdoor_identifiable_ae frontdoor_identifiable_ae id_sound_discrete late_wald att_csdid balkePearl_sharp dml_ATE_attains_hahn_bound uStatisticOrder_clt localDependenceCLT_of_stein
The flywheel

The system grows what it knows and what it can reuse

Two feedback channels compound over time, so each run leaves the pipeline better equipped for the next.

record → recon

The run bank

Every run is stored — its proposal, typed core, verdicts, and disposition — whether accepted, downgraded, or rejected. A documented dead end stops a later run repeating it; reconnaissance mines the bank before the next proposal is drafted.

reuse → study mode

The library

When a run needs a load-bearing lemma the library lacks, study mode proves it, checks it is generic and sorry-free, and promotes it back into Causalean under verify-or-rollback — where the next run can simply reuse it.

Autonomous research systems usually close their loop with an LLM judge over the open-ended question "is this good research?" — and that judge can be fooled. CausalSmith instead makes the proof correct by construction and confines the remaining judgment to a small, local, re-checkable question: does this Lean statement mean the intended claim? Formal verification is the correctness evaluator automated theoretical research was missing.