Stof Mission
Every interchange format we have — JSON, YAML, TOML, XML — describes a snapshot. The moment it crosses a wire, it's inert again on the other side, and whatever system receives it has to already know, out-of-band, what to do with it.
The logic that gives the data meaning lives somewhere else entirely: a separate codebase, a separate language, a separate deploy. That gap is where schema drift, versioning hell, and "the API changed and nobody told the client" all come from.
Stof exists to close that gap.
What Stof Is
Stof is a data runtime — not a data format, not a programming language, not a database.
The same way a JavaScript runtime executes JavaScript, a data runtime executes data. A Stof document doesn't just describe something; it validates itself, transforms itself, and acts, wherever the runtime lands.
Concretely: valid JSON is already valid Stof. You're not migrating to a new format — you're handing your existing data a place to keep the logic that used to live somewhere else.
Principles
These are the opinions the runtime is built around. They're not aspirational — they're constraints we design against.
Data and logic belong together. Splitting them across a data file and a separate codebase is where the gap comes from. Stof documents carry both, as one unit.
Portable means portable. The same document runs native, in WebAssembly, or embedded in another host, with the same behavior every time. If it doesn't run everywhere, it isn't portable — it's just convenient sometimes.
Sandboxed by default. A document can only see and manipulate itself unless you explicitly hand it more. Logic that arrives over the wire has to be safe to run without a review cycle first.
Documents should be able to grow. A running document parsing new fields, new types, even new functions into itself isn't an edge case — it's the model working as intended. Data that can only be replaced, never extended, is still just a snapshot.
Interop with all data formats. A superset of JSON that is compatible with every other data format, even ones that don't exist yet — binary, images, PDFs, DOCX, YAML, TOML, JSON, etc.
Where This Came From
Stof comes out of a decade spent building parametric and geometry formats for CAD and graphics systems — the kind of work where a document's structure and its behavior have to travel together and gets quite complex. That's where the core architectural insights come from: represent everything as a flat graph of nodes and data components, connected by pointers rather than nested copies, and moving or transforming part of the document stops being expensive.
Stof started as a solo project while trying to send wasm over the wire, and it's been running in production since — including as the policy engine underneath Limitr, where every plan, credit limit, and validation rule is a live Stof document.
Where This Is Going
Everything above — the graph, the sandboxing, the portability, the self-transformation — is domain-agnostic. None of it was built for one use case. What changes across contexts is only what the document is asked to describe.
Security
A scoped auth context modeled as a document instead of a token you have to look up elsewhere: something that can grant, check, and revoke its own permissions, expand temporarily for a single operation, and expire on its own — without a separate service tracking its lifecycle.
Graphics
A scene graph is already Stof's native shape. Geometry, materials, and animation curves as typed fields and functions on the nodes they describe — geometry defined by the function that generates it, not just the triangles it resolves to at one point in time — instead of a mesh format with behavior bolted on by reference.
AI Contexts
Portable memory for an agent: what it knows and what it's allowed to do, traveling together, handed off between services instead of reconstructed at each one. A tool surface a document can extend on itself at runtime. The further-out version — documents that discover and wire themselves into each other, forming a network without a central coordinator — is the reason the sandboxing model exists in the first place.
Distributed Systems
Configuration and coordination state that carries the logic that validates it. A service reading a config another service wrote doesn't have to trust it blindly — the document can check itself.
Plugins
A plugin as a sandboxed document instead of a compiled binary or an interpreted script with full host access: new behavior shipped into a running system as data, without a new deploy and without widening what that behavior is allowed to touch.
Data Unification
One graph that JSON, YAML, TOML, and binary sources all resolve into, so two services stop maintaining a translation layer just to agree on "the format we use" versus "the format they use."
Datasets
Evaluation logic, metadata, and transformation code living inside the dataset rather than in a notebook next to it — a dataset that can score its own outputs or validate its own rows.
Smart Configs
A config that enforces its own invariants: a value that can't be set outside its valid range, a field that recomputes a dependent value automatically — without a schema file living in a different repo that someone forgets to update.
This list isn't exhaustive, and it isn't a roadmap with dates attached. It's what falls out naturally from building one thing well: a document that carries its own data, its own logic, and its own boundaries, and runs the same way everywhere it lands.