Episteme and techne in AI for science
I want to argue that the same point about understanding holds in the natural sciences and engineering, where it also has intrinsic value and, in addition, acquires instrumental value when predictions must be trusted before they can be verified empirically. One role of science is what ancient philosophers called episteme [ἐπιστήμη], roughly explanatory understanding; here, understanding is the goal itself. Another role is techne [τέχνη], roughly the craft of predicting and making: forecasting how natural or engineered systems will behave under circumstances not yet observed. […] Episteme and techne become inseparable when predictions must be acted upon, and hence trusted, before they can be empirically verified, because verification is too slow, costly, or dangerous, as in projecting climate change decades ahead or designing an aircraft.
Music to my ears.
Despite the mathematical singularity, nothing infinite happens physically: the incompressible equation stops being valid once energy concentrates at very small scales, where compressibility and molecular effects take over, as has long been known. By contrast, in turbulence, viscosity dissipates energy at a small but finite scale (the Kolmogorov scale), and the continuum description is valid across all scales of motions.
This seems to be saying that what mathematicians find interesting in the Navier–Stokes equation, singularity or not, isn’t very interesting to physicists, while turbulence is: even if you can have a singularity in a solution, that tells you the model is breaking down at that scale, not about the physics. It is the Wilsonian view from the Navier–Stokes post: at the molecular scale the continuum equation breaks down. It can still be interesting to physicists for a different reason: when a model breaks, it often tells you about new physics the current model hasn’t included.
An end-to-end model can learn the day-to-day evolution of weather states in today’s climate, but it contains no pathway through which greenhouse gases alter this evolution; their concentrations are typically not among its inputs, and if they were, no observations exist to learn about the response.
This is the typical ML problem of generalizing to an out-of-sample region: there is no data on the response to greenhouse gases to train on, so no good signal for the model to generalize from, and that is why they are dropped from the inputs.
We would not currently trust them to project how the climate system responds to previously unobserved changes in the concentration of greenhouse gases over decades. Nor would we trust an AI surrogate of CFD simulations to certify an aircraft of novel shape. AI surrogates are used to explore and narrow down design spaces quickly, but the final assessment returns to established CFD methods or wind tunnel experiments, whose errors are controlled and whose steps are auditable.
This draws out the cooperative relationship between the traditional numerical method and the ML-trained surrogate model, which can for example be bootstrapped from the former. The former is for correctness, understanding, and therefore a calibrated credible interval, in the statistical sense: an error bar grounded by actual statistics, so that a 95% interval really contains the truth 95% of the time; the latter is for speed. The latter enables rapid prototyping, and when a solution is found, it can be verified by the slow but trustworthy method. This has some parallels in how LLMs solve problems: reasoning in natural language gets them an answer quickly, but only through the “traditional method”, formal proving in this case (e.g. Lean 4), can we establish trust.1
Then use numerical methods with controlled errors to solve, e.g., the Navier-Stokes equation on the resolved large scales, while learning closure models for the unresolved subgrid scales from data, where some universality assumptions are defensible and individually testable. The rationale, in the case of the climate system, is that the large scales are where climate change moves the system out of the current distribution, whereas small-scale physics obeys the same local laws in a warmer or colder climate as in today’s.
This is describing a hybrid modeling approach, where ML models are used where the generalization problem is much milder.
This closed loop is similar to how AI is used in mathematics. In both cases, a verifier is used for checking: Lean for proofs; high-resolution simulations, observations, or experiments for turbulence closures. In the case of mathematics, the checks are complete; in the case of turbulence closures, they are limited to the conditions covered, so trust is restricted to the tested conditions. […] In this way, understanding (episteme) and prediction (techne) improve together and reinforce each other, with humans, for now, remaining essential for extracting understanding and building trust in the end result: for writing the story behind the headline.
Schneider closes by drawing the parallel between how AI is affecting math and simulation modeling. But I think it actually puts a spotlight on the main difference, and on what is unique about AI proofs: while extracting understanding remains a very human activity, building trust is largely solved. Lean pushes what a human needs to verify to a small boundary.
By the way, I think Schneider mostly uses AI as a synonym for ML. Not everywhere: the “AI agents” running the closure search in a closed loop are presumably built on LLMs. That is not the main focus of his comparison, so I leave it aside.
The post seems to be drawing the line, in applying ML to science, between episteme (~understanding) and techne (~prediction), and asks when you can trust a prediction. If you can check it before acting on it, techne can stand on its own, and an ML model is fine. If you can’t, you can only trust it if you understand it, which is where traditional modeling comes in. These words sound very much like the debate in math & AI (understanding, answer, trust, etc.), but seem to mean completely different things. Trust in this article mostly means uncertainty quantification: it is not even about large vs. small error, but whether you can reliably quantify the amount of uncertainty (error) for the conditions you are predicting. If you can, then you can trust it.
Understanding (episteme) in this case then actually means a model that compresses and generalizes better: compresses in the sense that it is distilled down to a small set of equations, generalizes in the sense that its region of validity is much wider.
Such predictions earn trust not by end-to-end verification but by being the output of an auditable chain stretching from inputs (design parameters, atmospheric composition) to outcomes, whose links have known limits of validity and can be tested individually.
Schneider’s parallel is between ML on physics simulation and AI on math, since AI as in agents built on top of LLMs is not the main focus of his post, ML is. In my opinion, a closer parallel between science and math under the influence of AI is (research) software engineering. Coding agents in each case are writing something: software in the scientific software case, and a mathematical proof in the math case. For the latter there’s a way to make us trust it without reading through every line: a Lean proof. It can be a dark factory, where no human looks at the code the agents produce (Willison 2026): we read the boundary, the theorem statement and what it assumes, and trust everything else. In scientific software we still can’t establish trust like this, so generating the code and not looking at it is not an option.2 Hence we cannot eliminate a close, almost line-by-line, inspection of the resulting code. That makes understanding even more important in scientific software, as this is how you build trust.
References
Footnotes
Formal proving is also slower, as it traditionally is compared to “just” proving. To be fair, we should compare the same proof verified by an LLM directly in natural language vs. translated to Lean by an LLM and run. Running a Lean proof is known to be quite slow too: I don’t have the numbers, but in one case I heard of, running it took about half as long as the AI took to generate it. Another fair comparison would be asking the LLM to reason in Lean directly, which is slower still. But slowness is not the point here.↩︎
Research software is diverse, though. A research software for the humanities, visualizing some artifacts, may well be OK to be dark.↩︎