The Origin of Stof: From CAD Software to a Data Runtime

Stof wasn't designed as a product. It came out of roughly a decade spent building parametric and geometry formats for CAD and graphics systems — Siemens, Lockheed Martin, Configura, Anark — work that has almost nothing to do with web APIs or config files on the surface, and everything to do with them underneath.

What CAD Software Teaches You About Data

A parametric CAD model isn't really a static shape. It's a set of constraints and relationships — this face stays perpendicular to that one, this length depends on that parameter — that the software has to recompute continuously as a designer drags something around. The geometry is downstream of the logic, not a separate thing from it. A solid model that couldn't recompute its own constraints wouldn't be a CAD model at all; it'd just be a picture of one.

Spend long enough building systems like that, and you stop thinking of "data" and "the logic that operates on data" as naturally separate concerns. They were never separate in the systems I was working on. The industry convention of splitting them — a data file here, an application that interprets it over there — started to look less like a law of nature and more like an artifact of which tools happened to get popular for which jobs.

The specific architectural insight that came out of that work: represent everything as a flat graph of nodes and data components, connected by pointers rather than nested copies. Not a deep tree where moving a subtree means recursively copying everything underneath it — a flat structure where a node is just an entry in a list, and its relationships to other nodes are pointers, cheap to redirect. Once geometry, constraints, and the functions that maintain them are all just data components on that same graph, moving or transforming any part of the document stops being an expensive, special operation. It's just updating a pointer.

Trying to Send WASM Over the Wire

Stof itself started as a solo project, well before it needed to be anything more than an experiment — I was trying to send WebAssembly over the wire, and kept running into the same wall: wasm binaries are way too big, and whatever format carried the data had no way to also carry the logic that made the data useful once it arrived. Every option meant picking a lane. Either the payload was inert data that the receiving end had to already know how to interpret, or it was executable code with no natural place to keep the structured data it needed to operate on. There's also all of the tooling and dependencies to deal with.

The flat-graph model from the CAD work combined with wasm was the thing that made a different answer feel obvious: if functions are just another kind of data component — no different in kind from a field, just a different type of thing attached to the same node — then a single document can carry both without one being bolted onto the other. Fields, functions, and later on richer data like images and PDFs all became the same kind of citizen on the graph: data components, some of which happen to be callable. Let function-type components manipulate the graph they're attached to, sandbox what they're allowed to reach, and the rest of what Stof is followed from there — a superset of JSON specifically because JSON was already the shape of "plain data," and nothing about adding logic required breaking that.

From Solo Project to Production

Stof has been running in production for a while now, including as the policy engine underneath Limitr — every plan, credit limit, and validation rule there is a live Stof document, not a config file that Limitr's application code separately has to interpret. That's the same idea from the CAD work, just pointed at billing policy instead of geometry: the rule and the data it governs are the same object, so they can't quietly drift apart the way a schema and the thing it validates so often do.

None of this was originally in service of a thesis about "data and logic belong together." It came from a decade of watching what happens when you build systems where that was already true, and noticing that most of the software industry had, for understandable historical reasons, ended up somewhere else.

If you want the more structured version of where this is headed — the actual technical claims, not the origin story — What Is a Data Runtime? is the place to start.