Where JSON Schema Actually Struggles​

It's a separate file that has to be kept in sync by hand. The schema and the data it validates live in different places, maintained by whoever remembers to update both. There's no mechanism that enforces the connection — just discipline, which is exactly the kind of thing that erodes under deadline pressure.

It has no concept of units. A field documented as "memory in MB, must be at least 256" is a string with a comment, not an enforced rule — JSON Schema can check that the value is a number, but has no way to know that "2GB" and 256000000 describe the same thing, or that a value in KB shouldn't be silently accepted where MB was intended.

Cross-field validation is awkward at best. Checking that one field's value is consistent with another's needs $data references or vendor-specific extensions that most tooling doesn't fully support — the schema starts working against its own format to express something that would be a one-line comparison in real code.

The validation logic usually gets duplicated anyway. Even with a schema in place, most teams end up writing the same checks again in application code — for error messages the schema can't produce, for logic too complex to express declaratively, or just because it's faster than fighting the schema format for an edge case.

None of this makes JSON Schema poorly designed for what it targets: validating the shape of arbitrary JSON, in a language-agnostic, toolable way. The problem is structural, not an implementation detail — it's what happens when validation has to live somewhere other than the data itself.

Validation as Part of the Data​

In Stof, #[schema(...)] is an attribute on the field it validates:

#[type]
Plan: {
    #[schema((target_value: str): bool => target_value.len() > 0)]
    str label: 'Growth Plan'

    #[schema((target_value: hr): bool => target_value > 0hr)]
    hr reset_inc: 1hr
}

schemafy(target) checks a target object against every field that has one, and the unit-typed field actually means something — 1hr and 60min are the same value as far as the rule is concerned, and a plain number with no unit doesn't silently pass as if it had the right one.

Beyond a Single Rule​

A field's #[schema(...)] doesn't have to be one function. A list runs as a pipeline, each check short-circuiting on the first failure:

#[schema((
    (target_value: unknown): bool => (typeof target_value) == 'str',
    (target_value: str): bool => target_value.contains('@'),
))]
email: 'someone@example.com'

A bare #[schema] with no function tells schemafy to recurse into that field if the target's value is an object — validating nested structure without hand-writing traversal logic. And schemafy(target, remove_invalid = true) doesn't just report a failure; it strips whatever didn't pass, turning validation into cleanup in the same step. remove_undefined = true does the same for fields the schema never mentioned at all — filtering and renaming as a batch, not a separate pass.

None of this requires a second file, a different syntax to learn on top of the data format, or a build step to keep generated types in sync. It's the same document, doing one more thing.

If you want to see this built into a complete, runnable example rather than isolated snippets, A Self-Validating Config walks through the whole thing end to end, and Prototypes & Schemas is the full reference.

FAQ​

Does Stof replace JSON Schema entirely? For validating a Stof document, yes — #[schema] is the built-in mechanism and doesn't need JSON Schema alongside it. If you're validating plain JSON from a system that isn't Stof-aware, JSON Schema is still a reasonable tool for that narrower job.

Can a Stof schema validate data that didn't originate as Stof? Yes. schemafy(target) works on any object in the graph, including one built from parse(json, target, 'json') — the target doesn't need to have been created as an instance of the schema's own prototype.

What happens when validation fails? schemafy returns false rather than throwing, so a failed validation is a value you check, not an exception you have to catch. Combined with remove_invalid, it can also actively clean up the target instead of just reporting the problem.

Is this the same idea as Zod, Yup, or io-ts? Similar goal — colocating validation with a type definition instead of a separate schema file — but those libraries validate data at the boundary of a TypeScript application. Stof's schemas live inside the document itself, portable to any host that runs Stof, not tied to one language's type system.

That's the whole definition. Everything below is what it actually means in practice, and why the category needed a name in the first place.

Not a Format, Not a Language, Not a Database​

It's worth being precise about what a data runtime isn't, since the three nearest neighbors all miss something specific.

It's not a data format. JSON, YAML, and TOML describe a snapshot — inert the moment it lands, meaning nothing on its own until some other program decides what to do with it. A data runtime document is still just data structurally (Stof is a strict superset of JSON), but it doesn't stop there.

It's not a programming language, at least not in the general-purpose sense. There's no separate compilation step, no standalone executable, no notion of a "program" independent of the data it operates on. The logic exists specifically to serve the data it's attached to.

It's not a database. There's no query engine, no storage layer, no schema migration tooling. A data runtime document is a single, self-contained unit — closer to an object with methods than a table with rows.

What Actually Runs​

Concretely, valid JSON is already valid Stof:

{ "host": "0.0.0.0", "port": 8080 }

Add types and a function, and it's still the same document:

str host: "0.0.0.0"
int port: 8080

fn url() -> str { `http://${self.host}:${self.port}` }

url() isn't a separate script that knows how to read this config. It's part of the document, callable the same way a field is readable — doc.call('url') returns a real value, computed from data that lives right next to the function that computes it.

Why This Category Needed a Name​

Every interchange format describes a snapshot. The moment it crosses a wire, it's inert again on the other side, and whatever receives it has to already know, out of band, what to do with it. That's where schema drift comes from — a validation rule living in a separate file, or a separate service, that quietly stops matching the data it's supposed to describe. It's where "the API changed and nobody told the client" comes from. It's why nearly every serious system ends up bolting a DSL onto JSON or YAML eventually: Terraform invented HCL, GitHub Actions grew a custom expression language inside YAML, OpenAPI is JSON Schema with extensions piled on top.

None of those projects were wrong to need more than plain data. They just didn't have a runtime designed to hold both halves at once, so they built one, ad hoc, specific to their own tool. A data runtime is the general version of that same instinct — sandboxed by default, so logic that arrives from somewhere you don't control is safe to execute; portable, so the same document behaves identically whether it's running natively, in WebAssembly, or embedded in a Python host; and extensible, so a document can grow — parsing new fields, new types, even new functions into itself while it runs, instead of being a fixed shape someone has to redeploy to change.

FAQ​

Is a data runtime the same thing as a database? No. A database manages persistent storage, queries, and multi-record relationships. A data runtime document is a single self-contained unit of data and logic — no query engine, no storage layer of its own.

How is this different from a templating engine or a DSL? A templating engine or DSL is a separate tool that reads a document and produces an output. A data runtime document is the executable thing — the logic lives inside it, not in a separate interpreter built to understand it.

Is it safe to run a data runtime document from an untrusted source? That's the specific problem sandboxing solves. A well-built data runtime — Stof included — restricts a document to touching only what it's explicitly handed: no filesystem, no network, unless a host deliberately provides one. Logic arriving over the wire is safe to execute precisely because of that boundary.

Do I have to migrate my existing data to use one? Not with Stof specifically — it's a strict superset of JSON, so valid JSON is already a valid Stof document. Adopting it is a decision to add logic where you need it, not a migration.

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.

Any experienced programmer knows what comes next.

Six months later you're hunting for a $ref in a sea of JSON, writing helper tools, trapped under a stack of legacy decisions, full of regret.

I've done it. You've done it. The entire industry has done it. GitHub Actions is YAML with a custom expression language bolted on. Terraform invented HCL because JSON wasn't expressive enough. OpenAPI is JSON Schema with extensions piled on top. Every AI framework has its own JSON-based tool definition format that's slightly different from the others.

The problem isn't the formats. JSON, YAML, TOML — they're all fine at what they do. The problem is that we keep asking them to carry logic they were never designed to hold, then building increasingly elaborate scaffolding when they inevitably buckle.

What if your data could just do what's needed?​

Here's the part that made me want to build a real data runtime — Stof.

import { stofAsync } from '@formata/stof';

const doc = await stofAsync`
    name: 'Stof'

    fn loaded() -> str {
        const stof = await Ext.fetch();
        parse(stof, self);
        self.say_hello()
    }
`;

doc.lib('Ext', 'fetch', async () => {
    return `fn say_hello() -> str {
        'Hello, ' + (self.name ?? 'World') + '!'
    }`;
});

console.log(await doc.call('loaded'));  // Hello, Stof!

The document starts without a say_hello function. It fetches more Stof from somewhere — an API, another service, an agent — then parses it into itself and calls the function that just arrived.

Stof runs in a WASM sandbox built in Rust and is just a document of data, like JSON (actually a superset of JSON). It can't touch your filesystem, network, or memory unless you explicitly bridge it to the host environment with doc.lib(). You control exactly what the context can reach.

This means a service can share its capabilities as Stof. Not a description of what it can do, but the actual logic. The consumer parses it into context and starts using it immediately — no client library, no SDK, no redeployment. Your system ships with certain capabilities and gains more at runtime.

The Whole Picture​

Stof is a superset of JSON, so your existing data is already valid — but with functions, types, unit conversions, and async execution built into the format itself, instead of a layer bolted on top.

Instead of trying to replace existing interchange formats, Stof is the glue layer that works with all of them. Parse JSON, YAML, TOML, Stof, or more into a single document at any time, add the logic that belongs, and send it anywhere. Export portions to whichever format your app expects internally.

const doc = await stofAsync`
#[type]
Server: {
    port: 8080
    host: 'localhost'
    secure: false
    MiB memory: 500GiB

    fn url() -> str {
        let url = self.secure ? 'https://' : 'http://';
        url += self.host + ':' + self.port;
        url
    }
}`;

// Parse JSON, YAML, TOML, binary, or more Stof into the same document
doc.parse(`Server "prod": {
    "host": "prod.example.com",
    "port": 443,
    "secure": true,
    "memory": "2GB"
}`);

console.log(await doc.call('prod.url')); // https://prod.example.com:443
console.log(doc.get('prod.memory'));     // ~1907 MiB (auto-converted from GB)

console.log(doc.stringify('toml', 'prod'));
/*
host = "prod.example.com"
port = 443
secure = true
memory = 1907.3486328124998   # MiB
*/

The Server type defines shape, defaults, and behavior. When you parse new data in — JSON, YAML, TOML, whatever — and cast it to that type, it gets the functions and validation for free.

Schemas That Don't Drift​

You know what's worse than writing a JSON Schema? Keeping it in sync with the thing it validates.

Here's the JSON Schema for a simple server config:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "port": {
      "type": "integer",
      "exclusiveMinimum": 1024,
      "maximum": 65536
    },
    "address": {
      "type": "string",
      "minLength": 1
    },
    "memory": {
      "type": "string",
      "description": "Memory in MB, must be at least 256"
    }
  },
  "required": ["address"]
}

That's a separate file, a separate format, a separate thing to maintain. And notice memory — because JSON Schema has no concept of units, the best you can do is write a comment and hope the person reading it notices. The validation logic for that field lives somewhere else entirely, probably in your application code.

In Stof, validation lives on the fields themselves — and because this part is pure Stof, no TypeScript host required, you can run it right here:

#[type]
Server: {
  #[schema((target_val: int): bool => target_val > 1024 && target_val <= 65536)]
  int port: 8080

  #[schema((target_val: str): bool => target_val != "")]
  str address: "localhost"

  #[schema((target_val: MiB): bool => target_val >= 256MB)]
  MiB memory: 2GB
}

#[main]
fn main() {
  const good = new { port: 8080, address: "prod.example.com", memory: "2GB" };
  pln(self.Server.schemafy(good));

  const bad = new { port: 80, address: "prod.example.com", memory: "2GB" };
  pln(self.Server.schemafy(bad));
}

A port between 1024 and 65536, a non-empty address, and at least 256MB of memory. The last one is meaningful because Stof understands units as types — pass "2GB" and it converts, pass "100MB" and it fails. The schema can't drift from the data, because it is the data. (More on this pattern in A Self-Validating Config, if you want to see it built out into a full recipe.)

A Real Production Use Case​

Limitr is an open source pricing and enforcement engine built on Stof. The entire policy — plans, credits, limits, validation logic — lives in a single Stof document. It's a good example of what "data that carries its own logic" looks like once it's past the toy stage.

Give It a Try​

The fastest way in is the playground — runs in your browser via WASM, no install needed. Every concept page in the docs has one built in too.

npm i @formata/stof      # TypeScript / JavaScript
pip install stof         # Python
cargo install stof-cli   # CLI

• Docs — install, the full standard library, and worked examples
• GitHub — source and issues
• Discord — come tell us about your use case

There's also a VS Code extension for Stof syntax highlighting.

Apache 2.0.