Why I keep ending up between solvers and models

Scientific machine learning, probabilistic risk, and real-time data platforms look like three unrelated fields. Working across them, they rhyme more than they differ.

Three of the places I've worked look, on paper, like they have nothing to do with each other. The MIT Julia Lab is a numerical computing group. Akro builds probabilistic risk models for critical infrastructure. InterSystems builds real-time data platforms.

Having now spent time in all three, the surprise is how much the same instinct carries across them: be precise about what you are actually measuring, and be honest about the error you are carrying.

Solvers force you to be honest

Scientific machine learning lives in the gap between two traditions. Numerical analysts have spent decades quantifying exactly how wrong a differential equation solver is at each step. Machine learning, by comparison, grew up measuring performance almost entirely by held-out loss.

Put them in the same system and the numerical tradition wins the argument, because an unstable solver produces garbage loudly:

using OrdinaryDiffEq
 
# A stiff system: the explicit method will crawl or blow up.
function rober!(du, u, p, t)
    y₁, y₂, y₃ = u
    k₁, k₂, k₃ = p
    du[1] = -k₁ * y₁ + k₃ * y₂ * y₃
    du[2] =  k₁ * y₁ - k₂ * y₂^2 - k₃ * y₂ * y₃
    du[3] =  k₂ * y₂^2
    return nothing
end
 
prob = ODEProblem(rober!, [1.0, 0.0, 0.0], (0.0, 1e5), (0.04, 3e7, 1e4))
sol  = solve(prob, Rodas5P(), abstol = 1e-8, reltol = 1e-8)

Swap Rodas5P() for a non-stiff explicit method and it doesn't quietly get worse, it stops being usable. That failure mode is a gift. You cannot ship a result you don't understand, because the solver won't let you.

Risk models have the opposite problem

Probabilistic risk modelling is where I noticed the contrast most sharply. A badly calibrated model does not throw. It returns a number with a confidence interval attached, in the right units, on the right scale, and the plausibility is precisely what makes the failure hard to catch.

So the work becomes calibration and evaluation design. Some things I have come away believing:

A single expected value hides almost everything. Two models with the same mean can disagree entirely about the tail, which is the part anyone actually acts on.
Group the failures before you count them. The interesting unit is the class of scenarios a model is wrong about, not the individual scenario.
A result you cannot regenerate is a result you cannot trust. If the pipeline isn't reproducible, neither is the claim.

None of that is exotic. It is the numerical analyst's instinct, quantify the error rather than just reporting the mean, pointed at a system that does not come with error bars built in.

Latency is the same discipline with a stopwatch

Real-time data systems add a third framing: the correct answer, delivered late, is the wrong answer. Tail latency behaves like numerical error. The average tells you nothing useful, and the distribution's tail is where all the actual information lives. It is the reason the matching engine I've been building instruments every stage rather than timing the loop end to end.

Field	Failure signal	What it costs to ignore
SciML	Solver diverges	Wrong physics, loudly
Probabilistic risk	Tail is miscalibrated	Confident number, quietly wrong
Real-time data	p99 blows out	Right answer, too late

The middle row is the dangerous one, and it's why risk work needs the most deliberate instrumentation of the three.

What I'm working on next

More of the same seam: modelling tools that treat uncertainty with the seriousness numerical software already takes for granted. If you work on any of this, I'd genuinely like to hear from you.