top of page
検索

Why AI Companies Are Turning to Lean 4-The Global Shift Toward Verifiable AI — and the Layer Responsibility OS Provides Next

AI's answers are moving from "explanation" to "inspection."

LLMs generate fluent text. But they cannot guarantee that what they produce is correct. "Plausible errors" — hallucinations — are a well-known characteristic of LLMs.

In response to this problem, a segment of leading AI companies and research organizations has begun moving in a clear direction.

Transforming AI-generated answers into propositions, proofs, and specifications that can be formally machine-checked.

The foundation increasingly used for this is Lean 4, the theorem proving system.

This article draws on primary sources, research papers, and selected reporting to survey the AI companies and research organizations adopting Lean 4 as a verification foundation, show what Lean 4 can and cannot handle, and then identify the layer that Responsibility OS provides next.

▼Responsibility OS Press Release（JP） https://prtimes.jp/main/html/rd/p/000000004.000182721.html


1. A Growing Number of Leading AI Companies and Research Organizations Are Adopting Lean 4

What Lean 4 Is

Lean is an open-source theorem prover and programming language that Leonardo de Moura began in 2013. The current Lean 4 serves as a verification foundation with the characteristics of a programming language as well. The official Lean site describes it as an "open-source programming language and proof assistant" that enables correct, maintainable, formally verified code. Lean FRO targets applications in mathematical research, software and hardware verification, and AI-assisted theorem proving.

What matters here is that Lean 4's checking is mechanical. Results are stored not as "explanations that convince a human" but as "proofs confirmed by the Lean kernel."

Selected Cases

Mistral AI / Leanstral

On July 2, 2026, Mistral AI published Leanstral 1.5, a model for Lean 4. It is positioned for Lean 4 proof engineering, theorem proving, autoformalization, real-world code verification, and bug discovery. This is direct evidence that a major AI company has begun deploying Lean 4 in the direction of "AI with built-in verification."

Harmonic / Aristotle

Harmonic's Aristotle API is described as being able to formalize and prove problems stated in English using Lean 4, and to work within Lean projects and code repositories. Reuters has also reported that Harmonic is moving toward having AI output its reasoning as Lean 4 code that can be checked for correctness, as a strategy against hallucination. This is the representative case of "using formal verification rather than natural language explanation to underpin AI reliability."

Axiom Math / AXLE

Axiom Math's AXLE is a cloud service for Lean 4 proof manipulation, extraction, and verification. It is described as targeting the scale required for RL pipelines in AI mathematics and agentic proving workflows. This is evidence that Lean 4 is becoming infrastructure for AI proof workflows.

Math Inc. / Gauss

Math Inc.'s Gauss is an AI-driven Lean formalization agent. It completed a Lean formalization of the strong prime number theorem in approximately three weeks, generating around 25,000 lines and over 1,000 theorems and definitions. This is a case of AI compressing research-level formalization work.

Logical Intelligence / Aleph Prover

Aleph is an AI prover that generates machine-checkable proofs in Lean 4. It has been used for verification of Ethereum Foundation zkEVM cryptographic libraries, showing that Lean 4 is extending from mathematical proofs into cryptographic library verification.

DeepSeek / DeepSeek-Prover-V2

DeepSeek-Prover-V2 is an open-source LLM designed for formal theorem proving in Lean 4, evaluated on MiniF2F and PutnamBench. This shows that major AI research teams like DeepSeek are also moving toward Lean 4 formal proofs — not just Mistral, but multiple significant players moving in the same direction.

Google DeepMind / AlphaProof

According to DeepMind's announcement and related publications, AlphaProof is an RL agent that explores formal proofs in a Lean theorem prover environment. Because natural language approaches can produce plausible errors, it connects to Lean 4 formal verification. This shows that formal verification is entering the core of frontier AI research.

AWS / Cedar

AWS has formally modeled core components of its authorization policy language Cedar in Lean, proved important correctness and security properties, and confirmed them through differential testing against the Rust implementation. The official Lean Cedar use case explains that Lean models and production Rust implementations are developed in parallel, with the Lean model serving as the specification. Lean 4 is being used not only for mathematical AI but for security verification of production software.

Rust-to-Lean Verification Pipeline

A 2026 report describes a pipeline for lifting production Rust cryptographic code into Lean 4, closing proof obligations using AI provers like Aristotle and Aleph, and then checking with the Lean kernel. Lean 4's application scope is expanding from mathematical proofs into production code verification.


2. Why Lean 4?

Leonardo de Moura, the creator of Lean, has written in "When AI Writes the World's Software, Who Verifies It?" that in a world where AI writes critical software, the verification layer should be separated from the AI generator — and that independent verification is not a philosophy but a security architecture requirement.

This is the core of it.

The layer that generates AI output and the layer that checks AI output must be separated.

LLMs generate fluent text, but whether the content is correct can only be claimed by the model itself. External checkers like Lean 4 verify generated propositions, proofs, and code mechanically — independently of the LLM.

From "the AI said so" to "the checker confirmed it." This is the transition that a segment of leading AI companies has begun making.


3. Lean 4 Alone Is Not Enough for Enterprise Decisions

But Lean 4 is not a complete solution. This is the critical point.

Only Formalized Propositions Can Be Checked

Lean 4 checks only propositions written in the Lean 4 language. The translation step — converting a natural language problem into a formal proposition — still involves hard parts.

A case study using the Aristotle API (arXiv:2605.20120) reports that while multiple auxiliary lemmas were verified, the main theorem was left with unresolved sorry (an unproven placeholder). "Partially verified" and "proven as a whole" are different things.

AI-Assisted Lean Proof Accuracy Still Has Limits

FormalProofBench reports that for graduate-level mathematics, the best-performing model achieved only 33.5% accuracy in Lean 4 formal proof generation.

SorryDB collects unsolved proof tasks from real Lean projects on GitHub, showing that competitive mathematics benchmarks alone are insufficient for measuring practical Lean proof capability. TheoremBench also points out that current provers still show bias and inefficiency on long, dependency-rich theorems.

Unverified Conditions Remain

Even in the Aleph case, when Lean 4-checkable formalizations are produced, external classical theorems, the formalization of the problem statement, the way specifications are framed, and assumptions in the toolchain remain as separate items to be confirmed.

In other words, even after Lean 4 has checked something, a separate layer is needed to manage what has been verified and what remains as an unverified condition.

Who Adopted the Decision and Under What Conditions Is Not Lean 4's Question

Lean 4 confirms whether a proposition is proven. But:

  • Who adopted a decision based on that proof into formal operations?

  • What unverified conditions remained at the time of adoption?

  • Can a third party confirm that adoption decision later?

These are not questions Lean 4 addresses. These are questions of enterprise accountability information.


4. The Regulatory Side Is Moving in the Same Direction

In parallel with Lean 4 on the technical side, regulatory pressure for verifiability is also growing.

ISO/IEC 42001 is the international standard for AI management systems, providing requirements and guidance for organizations developing, providing, and using AI — supporting risk management, trust, and accountability.

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 with phased application. For high-risk AI systems, it requires automatic logging throughout the lifecycle (Article 12) and human oversight — including the ability to understand and monitor AI output and to decide not to use, override, or reverse it (Article 14).

On the technical side, Lean 4 is pushing toward "inspectable AI." On the regulatory side, ISO 42001 and the EU AI Act are requiring "logging, auditing, and accountability."


5. The Layer Responsibility OS Provides

This is where Responsibility OS enters.

Responsibility OS is not a new term disconnected from formal verification, provenance, audit trail, or AI assurance. It builds on those existing lineages. The distinctive contribution lies in placing the accountability state of AI decision adoption — not the AI model itself — as the primary object of concern. Formal verification is used not only to check model performance or safety properties, but to confirm that accountability-relevant information, unverified conditions, decision ordering, and adoption state are preserved in a way that can be confirmed later. In this sense, Responsibility OS does not replace existing AI assurance or audit trail approaches. It is a responsibility information layer that connects them to the moment a company formally adopts an AI decision.

Specifically, Responsibility OS answers these questions:

  • What information did the AI look at when making its decision? (provenance)

  • Which conditions were satisfied? (adoption conditions)

  • What remained as unverified conditions? (unverified conditions)

  • Who verified how far? (accountable parties / verification state)

  • In what ordering were decisions made? (state transitions)

  • Can a third party confirm this later? (verifiability)

Accountability-Relevant Information refers to the information that must not be lost in order to verify, after the fact, the accountability state of an AI decision. It includes provenance, audit trail, traceability, verified conditions, unverified conditions, accountable parties, and the ordering of decisions — not only the result.

ADIC (Advanced Data Integrity by Ledger of Computation) is the technical foundation for fixing this accountability information as evidence that can be re-examined later — making it a re-verifiable record rather than an explanatory document.

ALS (Algorithmic Legitimacy Shift) is the theory addressing situations where relying solely on human confirmation is structurally insufficient to support an accountability state.

Lean 4 makes clear what has been proven. Responsibility OS preserves what has not been proven as unverified conditions, and manages whether the AI decision is in a state that the company can formally adopt into operations.

Lean 4 is not a competitor to Responsibility OS. As Lean 4 spreads, the need for Responsibility OS grows.


Summary

A segment of leading AI companies and research organizations is moving AI output from "plausible natural language explanations" toward "formalized, machine-checkable" results. The cases of Mistral, Harmonic, Axiom Math, Math Inc., Logical Intelligence, DeepSeek, DeepMind, and AWS clearly illustrate this trend.

But even after Lean 4 has checked something, a separate layer is needed to manage what has been verified and what remains as unverified conditions — and to make it possible to confirm, after the fact, who adopted what AI decision into formal operations under what conditions.

Responsibility OS provides that layer. It is the responsibility information layer that connects the technical Lean 4 trend and the regulatory ISO 42001 / EU AI Act trend to the adoption state of enterprise decisions.

Connecting machine-checked propositions to the accountability state in which a company can adopt them. That is the role of Responsibility OS.


References

Lean 4

AI Companies and Research Organizations

Benchmarks and Limitations

Regulation and Standards

Responsibility OS

GhostDrift Mathematical Institute, Inc. https://www.ghostdriftresearch.com

 
 
 

コメント

bottom of page