Software has a problem. Not a technical problem. A philosophical one.
Every few months something newer arrives. A faster framework. A better API. A shinier abstraction. The industry responds by patching the old thing until it barely works, or rewriting everything until the new thing barely works. Either way — the knowledge accumulated over decades gets buried under layers of compatibility fixes, deprecated calls, and institutional memory that lives only in the heads of people who are retiring.
We asked a different question.
Not what is the newest way to do this — but what is this, at its core, and how do we make sure it survives the next 40 years of change?
Separation
The answer is separation.
Separate what a thing is from how it is currently built.
A Gaussian blur is a convolution with a Gaussian kernel. That has been true since the 1960s. It will be true in 2060. The implementation changes — C, Fortran, CUDA, HIP, whatever comes next. The primitive does not.
Every function has an address. Every address points to an implementation. Change the implementation by changing one pointer. The rest of the system never knows.
This is not a new idea. It is a very old idea that the software industry keeps forgetting.
On Resistance to Change
On resistance to change.
The institutions we serve — national labs, research centers, universities — are not resistant to change because they are slow. They are resistant to change because they have seen too many systems arrive with promises and leave with broken workflows and lost data.
We do not ask them to change how they work.
We ask only that they tell us what they need — and we find the math underneath it that was always there.
A 1985 Fortran simulation is not obsolete. It was written by someone who understood the physics deeply and was constrained only by the hardware of the time. We do not replace that knowledge. We recover it.
On Staying Running
On staying running.
A system stays running when it is built on things that do not change.
Mathematics does not change. Physics does not change. The index changes. The implementations change. The hardware changes. But the primitive — the actual operation being performed — that is stable.
The question answers itself: because it is not coupled to what it runs on.
The Why
The why.
Because somewhere there is a researcher with a box of floppy disks and a notebook full of equations that ran for two weeks on an IBM and found something nobody has seen since — because the grid was too small to show it.
That work deserves to run again. At full scale. On modern hardware. Rendered in a way that lets the next generation see what the previous generation was reaching toward.
That is what we are building.