AI in Mathematics 🚀 $15M Initiative: Simons Foundation

The key difference: resources plus a process

A funding announcement can be judged by its grant pool. But that's only part of the story. Computing and tool access can lower the cost of trying new approaches. And workshops plus open proposals can help researchers compare what they learn - what works, what doesn't, and what kinds of evaluation actually make sense. If that feedback is shared, it can build into something like infrastructure: people test tools in research settings, report results, and use that evidence to adjust common practice.

Still, it won't happen automatically. Whether a real loop forms depends on which proposals get selected, who's able to participate, what evaluation methods are used, and how much information is shared beyond individual projects. It's possible to have resources without building something that becomes genuinely useful infrastructure. The design and transparency of the program will shape how broadly it benefits the research community.

Why a foundation-led model matters

The foundation describes the program as aimed at the mathematics community, with community members driving conversations about how tools are evaluated, adopted, and used. That's a meaningful starting point. Technology companies can supply models and compute, but researchers know the math well enough to judge whether a result is sound and whether a tool fits the norms of the field.

The partnership also builds on existing work. The Simons Foundation says it has supported machine learning for science, including funding development of the Lean proof assistant, and it has convened workshops and collaborations on AI's role in mathematics. So this doesn't feel like a blank-slate effort - it's more like an extension of an ongoing line of work.

Proof assistance is not the same as proof verification

Lean is a proof assistant: software that checks whether a formal proof follows from stated rules and definitions. Formal verification can make certain mistakes easier to catch, but it doesn't remove the need for human judgment. Researchers still need to decide what to formalize, make sure the definitions match the intended mathematical claim, and understand how the result fits into the bigger picture.

AI could help bridge the gap between informal mathematical writing and formal proof systems. But a system that proposes a proof step and a system that checks a fully formalized proof are doing different jobs. If you treat both cases as a generic "AI proved the theorem," you miss key details about how the result was produced and validated.

For background, see the Lean project, which develops the Lean theorem prover and its supporting community. The Simons Foundation's announcement notes that earlier funding supported Lean's development and helped make AI-assisted proofs possible. That history gives the current effort a practical foundation: mathematical AI isn't only about large language models - it also involves tools and workflows that make reasoning inspectable.

The trust problem is also a workflow problem

In research teams, trust comes from repeatable checks. A result might be reviewed by collaborators, tested against known cases, formalized, or challenged in peer review. AI adds another component to that chain. Researchers need to know which parts of the workflow involved a model, what checks happened independently, and where uncertainty still exists.

This isn't about documenting every keystroke. It's about provenance - enough information for another researcher to evaluate what was done. If AI use is hidden or described in vague terms, reviewers can struggle to assess a result. If disclosure requirements are too heavy or inconsistent, they may discourage experiments without improving verification. Shared standards can help the community find a workable middle ground.

Evaluate AI-assisted mathematical results

One useful outcome would be better, rigorous ways to assess model-generated claims. Researchers could compare outputs with established results, test whether AI-generated arguments tend to contain gaps, and examine how often a tool produces leads across different categories of problems. The goal shouldn't be a single scoreboard that reduces mathematical quality to a number. Evaluation needs to reflect the task: generating a conjecture, proposing a proof strategy, and checking a formal proof aren't interchangeable benchmarks.

A good evaluation process should also capture failures, not just successes. In real work, something that works once can be interesting; a method that keeps working across varied cases is usually more informative. Researchers also need to understand how much of a result depends on substantial human intervention. That context affects what the tool is actually contributing.

Build skills and shared practice

Tool access only helps if researchers have time - and support - to learn how to use it. Workshops can help mathematicians understand what systems are available, test them on real problems, and compare approaches across subfields. They can also create a forum for practical questions, like how to protect unpublished work, how to cite AI contributions, and when formal verification is worth the extra effort.

This isn't just a training issue. A field's day-to-day norms affect whether a tool gets used responsibly. If one group treats model output as a brainstorming aid and another treats it like evidence, collaboration gets harder. Shared discussion can clarify expectations without requiring every mathematician to use the same software or workflow.

Explore the value of compute and tool access

Computing resources can lower barriers, especially for researchers who don't have institutional access to expensive infrastructure. But access alone doesn't automatically produce better research. The program will still need clear information about eligibility, timing, usage limits, and how research data will be handled before recipients can plan around the support.

There's also a trade-off between convenience and dependency. If a project depends on one company's model, reproducing results could become difficult if access changes, prices rise, or the system gets updated. Researchers should think about preserving prompts, code, versions, and evaluation records where appropriate. These are ordinary operational concerns, not reasons to avoid commercial tools. They matter because research still needs to remain inspectable after the initial experiments.

What should researchers disclose?

Disclosure should help readers judge a result. At a minimum, a field may need guidance on whether AI tools were involved in problem selection, proof generation, formalization, code, or editing. How much detail is needed can depend on the role the system played. Using a tool to polish prose isn't the same thing as relying on it to propose a key step in a proof.

The risk is setting a rule that's either too vague to be helpful or too broad that it turns into boilerplate. If every paper includes a non-informative sentence, transparency doesn't really improve. A better approach is to describe substantive contributions and the checks that were performed, with standards that can evolve as tools and practices change.

How should results be verified?

There isn't one verification method that fits every claim. Formal proof checking may be appropriate in some cases, while expert review, independent derivation, or computational testing may matter more in others. A sound policy should separate the claim itself from the tool used to reach it.

Published responsibility still sits with the human authors. That doesn't mean they must redo every computational step by hand. It does mean they should be able to explain the evidence, point out the limits of the method, and respond to scrutiny. The standard should be accountability, not the assumption that any single tool automatically makes a result trustworthy.

Who gets access and influence?

Partnerships with technology companies can provide real infrastructure - but they can also raise issues about access and influence. The announcement presents the effort as community-driven and says no single company or institution should control how tools are evaluated and used. Whether that holds in practice will depend on who gets represented in funded workshops and proposal decisions, and whether researchers with fewer institutional resources can participate.

These concerns affect both research quality and fairness. If standards are set only by well-resourced labs - or by the people building the tools - they may not reflect the needs of smaller departments, independent researchers, or mathematical subfields with different workflows. Open calls and broad participation can help, as long as the process is accessible and decisions are clearly explained.