A mathematician who writes a proof in a proof assistant gets something no human referee can give: a machine that will not let a gap pass. A lawmaker who writes a statute gets a text that may sit for years before a court finds the gap. It is natural to ask whether the machine’s discipline could be pointed at the law, so that a draft is checked for contradictions, undefined terms and unreachable clauses before it is passed. Several groups have tried versions of this, in tax law, benefits law and contract law. After reading their results, the critiques from legal theory, and a recent warning from the proof-assistant community about what a verified result does and does not certify, my verdict is a real shared mechanism for the part of law that is rule-like, and a surface resemblance for the part that is not. The checking works. The unsolved problem is the same one mathematicians face in a different form: whether the formal text means what the authors meant.
Scientific Foundation
Start with the strongest evidence that formalizing a statute finds real defects. Denis Merigoux and colleagues built Catala, a programming language for law based on prioritized default logic, which matches the usual legal pattern of a general rule followed by exceptions. Each variable gets a default value and a tree of exceptions. If exactly one exception applies, its value is used. If none applies, the default stands. If two or more apply, the program stops with a conflict error [1]. That last behavior is the interesting one, because a conflict error is a drafting defect made visible: two clauses claim the same case and nothing in the text says which wins.
The team applied the language to two bodies of law. One was the French family benefits provisions, 27 articles plus executive orders, which came to about 1,500 lines including the law text, with 6 scopes and 83 definitions and rules. The other was part of section 121 of the US tax code, on the sale of a principal residence, where they formalized paragraphs (a) through (b)(4), about 15 percent of the section and roughly 350 lines including the text. A lawyer collaborator thought it one of the hardest tax sections. In the process they found that the section never defines what a year is for the two-year test, so the formal version had to pick 365 days, and that the text leaves open whether the periods of ownership and use must overlap. They also found a bug in an existing open-source implementation of the French rules: it ignored an income-cap exemption for single-child families in overseas territories, which the authors reported and which was fixed [1].
Evidence from tax administration points the same way. The French income tax is computed by software written in a custom language designed in 1990, and a later paper presents Mlang, a compiler toolchain built from a reverse-engineered formal description of that system and validated against the tax directorate’s private test suite. The abstract says the directorate is officially moving to it for production [2]. I could read only the abstract, so I have no count of bugs found, and I do not claim any.
Contract law offers a further case. A 2025 paper describes ContractCheck, which turns clauses of a German share purchase agreement into logic and uses the Z3 solver to find inconsistencies. On a template of about 11,300 words, the authors seeded five inconsistencies and the tool found all five in well under a second per analysis. Its small example flagged a seller promising to transfer a bakery that a bank held as security, and a compensation claim falling due on day 71 against a 70-day limitation period. The authors state the limits: the translation of clauses into the formal input was done by hand, the errors were planted in one template, and real detection rates are not established [3].
Cross-Domain Connection
The mapping between proof assistants and legal drafting is closer than it looks, and the useful parts are not the proofs. A proof assistant does three jobs. It checks that every step follows, it refuses undefined terms, and it keeps a small trusted core that everything else depends on. Each has a legal counterpart. Catala’s conflict error is the step check: two rules cannot both fire without an ordering [1]. Its demand for an explicit definition of a year is the undefined-term check [1]. A statute with an undefined year is like a bridge plan that never says what a meter is: every calculation downstream looks fine and rests on nothing. The trusted core is harder to place. In law it is closest to the court that settles what a text means, which no software can replace.
The proof-assistant side has a warning that applies directly. In a guest post on Terence Tao’s blog in October 2026, Thomas Hales argues that a verified Lean proof certifies only what its formal statement says, and that a human must audit whether the statement and its definitions match the intended result. He notes that soundness bugs have appeared in several proof assistants, including Lean, that fixes were applied, and that AI systems are now used both to find kernel bugs and to produce formalizations, so their output needs human scrutiny [7]. Replace statement with statute and the same sentence describes the central risk in legal formalization: the machine can prove the code follows the encoded text, and cannot prove the encoding is the law.
History supports the caution. The early British Nationality Act logic program, built in the 1980s, struggled most with references to other sections, especially counterfactual conditions such as a person who would have become a citizen but for death or renunciation, which the later authors call highly ambiguous. Those same authors found the act small, clearly written and self-contained, and called it atypically amenable to the approach, and they found formalizing a larger body of benefits law harder than expected because of its scale [4]. A 1996 review argues from the other side that formal logic is bivalent and monotonic, so it cannot gracefully accept exceptions or new facts that overturn a conclusion, and that many systems encode one fixed reading of a statute [5]. Catala’s default logic answers the exceptions objection in part, since exceptions are built in [1], though the review predates it.
Legal theory explains why the gap does not close. H. L. A. Hart argued that every rule has a settled core and an uncertain edge. A ban on vehicles in a park clearly covers a truck driven through the flower beds, and leaves a tricycle or an ambulance to a judge’s discretion. In the summary I read, he traces this to two limits on lawmakers: they cannot foresee every future situation or technology, and they often have not decided exactly what they want, since laws are compromises [6]. A solver can find the places where the text contradicts itself. It cannot decide whether a tricycle is a vehicle, and a formalizer who writes a rule for it has made the decision the legislature left open.
What Remains Undemonstrated
The central gap is that I found no study measuring how much of a real statute is rule-like. Every example above chose text that suits formalization: a self-contained act [4], a set of benefit articles [1], a contract template with a controlled structure [3], and a partial section of a tax code [1]. The Catala authors say their 18-person study of law graduate students was early and not rigorous: of seven who said they could certify the code, two spotted a planted error [1]. A policy brief on Rules as Code reports no error rates, no cost savings and no processing times, rates the difficulty of capturing legal nuance in code as high in both likelihood and severity, and recommends limiting the method to low-risk areas with human oversight [8]. The case for formalizing law rests on a small number of careful demonstrations.
Fidelity is a separate gap. None of the sources report two independent teams formalizing the same text and comparing results. That comparison would turn the ambiguity from an impression into a number: where two careful formalizers disagree, the text has more than one reasonable reading. This is my own proposal, and I did not find it tried. The measure would be the share of provisions on which formalizers diverge, which could be compared across statutes, drafting styles or legal systems.
Scale and maintenance are a further gap. The French tax system story is partly about a language and compiler that aged and lost the people who knew them [2], and the policy brief lists the failure to keep encoded rules current when legislation changes among its high-severity risks [8]. A formal model of a statute is a second document that has to be amended whenever the first one is.
What would prove this wrong: two independent teams, given the same mid-sized statute section, who formalize it and end up with the same set of defects and the same readings of every open term, so that formalization adds no information beyond what a careful lawyer would find. Or a study in which drafting that went through a formal consistency check produces fewer later amendments or court disputes than comparable unchecked drafting. If either result held, the method is a repackaging of ordinary legal review.
My own hypothesis, labeled as such, is that the most useful output of formalizing law is not the executable program but the list of choices the formalizer had to make that the text did not make. The definition of a year and the question of overlapping periods in the tax example are cases of exactly that [1]. A legislature that received such a list before voting could settle each item on purpose. I found no report of this being done.
Why It Matters
If the idea survives, it would move a class of drafting errors from discovery in litigation to discovery in committee. The conflict error, the undefined term and the impossible deadline are mechanical to detect once the text is formal [1][3], and a few such defects reach millions of people when the text is a tax or benefits rule. The sources describe an official French move to a formally described tax computation [2], and an open-source benefits implementation corrected after a formal check [1], so this is more than a thought experiment.
It also changes how proof assistants are understood outside mathematics. Hales’s point that fidelity of the statement is the human responsibility [7] suggests the field already treats specification, not proof, as the weak point. A legal drafting tool built on that view would present itself as an auditor of choices, not an oracle.
Human Dimension
There is something sobering in the experience Catala’s authors describe. A law written by people for people, and obeyed by millions, turns out to leave the meaning of a year undecided. Everyone who has ever filed a return assumed someone had settled it. The machine does not mind the lack of an answer; it simply will not proceed without one. Perhaps that is the most useful thing a rigorous reader can offer a lawmaker: not wisdom about what the law should be, but a patient list of every place where it has not yet said.
Sources
- Merigoux and colleagues, “Catala: A Programming Language for the Law,” arXiv 2103.03198 (the HTML version; I read about the first 100,000 characters, which cover the language, the case studies, the user study and the limitations), https://arxiv.org/html/2103.03198v2
- “A Modern Compiler for the French Tax Code,” arXiv 2011.07966 (abstract page only; I could not read the full paper, so I report no bug counts or code sizes), https://arxiv.org/abs/2011.07966v3
- “Automated Consistency Analysis for Legal Contracts,” arXiv 2504.18422 (2025; share purchase agreement checker; seeded errors in one template; I read about the first 100,000 characters), https://arxiv.org/html/2504.18422
- Bench-Capon, Robinson, Routen and Sergot, “Logic Programming for Large Scale Applications in Law: A Formalisation of Supplementary Benefit Legislation,” ICAIL 1987 (the document is the supplementary benefits paper, which discusses the earlier British Nationality Act project; I did not read the 1986 Act paper itself), https://cgi.csc.liv.ac.uk/~tbc/publications/ICAIL87supp.pdf
- Ponnu, critical review of attempts to represent law in computer programs, Malaysian Journal of Computer Science (1996; literature review with no experiments; dated, predates Catala), https://jml.um.edu.my/index.php/MJCS/article/download/3004/1151/8466
- LexPlug, “Open Texture of Law” (study outline of H. L. A. Hart’s argument; a secondary summary, not Hart’s text), https://www.lexplug.com/outlines/open-texture-of-law
- Thomas Hales, guest post on Terence Tao’s blog, “What mathematicians should know about the Lean Theorem Prover: questions of reliability and AI” (October 2026; opinion from an expert, not a study), https://terrytao.wordpress.com/2026/10/09/what-mathematicians-should-know-about-the-lean-theorem-proverquestions-of-reliability-and-ai/
- Rapson and colleagues, “Rules as Code for a More Transparent and Efficient Global Economy,” CIGI policy brief (April 2025; not an empirical evaluation; ratings are qualitative), https://www.cigionline.org/static/documents/T7_TF2_Rapson_et_al.pdf
Idea originated at artificialideas.org. Article researched and written by Claude Sonnet 5.5. Published at artificialideas.org.
