Data for machine readers: a proposal to test a notation built for agents

Mzizi is a language built for machine authors. The data those machines read is still written for people.

JSON was designed so a person could read it. A model pays for that. Every key is repeated on every row, every string is quoted, every level is bracketed. When an agent reads a list of records, much of what it is billed for is structure it already knows.

This is a proposal to find out whether a notation designed for machine readers and authors can do measurably better, and if it can, to make it an open standard anyone can use. It is a proposal, not a result. Nothing below has been built or measured yet.

Where the cost shows up in our own work

Three things we already publish are written in JSON and read by agents:

• mz harness definition prints the whole Mzizi language as one JSON document, so an agent can read the language instead of guessing it.
• mz check --agent prints diagnostics as newline-delimited JSON.
• vocab.bundu.org serves the Bundu vocabulary as JSON-LD.

All three are mostly lists of records with the same fields. That is the shape where JSON's overhead is largest, and where a better notation should show it first. They are our first test corpora.

What already exists

The closest prior work is TOON (Token-Oriented Object Notation). It encodes the JSON data model compactly, declaring field names once per array instead of on every object. Its maintainers report retrieval accuracy close to JSON's with roughly 40% fewer tokens, with savings that shrink as data becomes less uniform.

An independent benchmark (Matveev, 2026, arXiv:2603.03306) tested the other direction: models writing the format. Plain JSON produced the most accurate output. TOON's advantage was often cancelled by the instructions needed to teach it in short contexts.

That is the problem we take seriously. Models have seen enormous amounts of JSON and none of a new notation. Our own September pilots for the Mzizi language showed the same effect in code: a small model did worse in a language it had never seen. A new notation has to beat that, not ignore it.

What we would test

The design starts from what Mzizi already does: contracts on everything.

1. Contract first, positional data. A payload names its contract by hash, and records carry values in contract order, with no keys. The contract is read once; the data many times.
2. Built for prompt caching. Contracts are stable, so they sit in the cached part of a prompt. Only the payload is billed at full rate. No format we know of is designed around this.
3. A grammar with every contract. Each contract generates a formal grammar, so constrained decoding makes model output valid by construction. This is aimed directly at the generation weakness the benchmark found.
4. Delimiters chosen by measurement. Each candidate separator is checked to be one stable token across the major tokenizers, not assumed to be.
5. Each line stands alone. Every record parses on its own and arrays declare their length, so a truncated or streamed payload is detectable.
6. Lossless to JSON. Anything in the notation converts to JSON and back without loss. Existing tools keep working.
7. One contract, three forms. Naming a contract by hash needs exactly one byte sequence per contract, and text cannot promise that: whitespace, key order and number formatting all vary. So each contract has a canonical binary form, in deterministic CBOR as defined in RFC 8949, and that is what gets hashed. Models and people read a text form, because a model cannot read binary, and binary passed to it as base64 costs more tokens than JSON. Existing tools read a JSON Schema export. All three come from one definition, and the conformance suite proves they convert into each other without loss. WebAssembly works the same way, with a binary format and a text format that map one to one.

How it will be measured

• Formats: JSON, minified JSON, TOON, CSV where the data allows, YAML, and the new notation.
• Data shapes: flat tables, nested records, graphs as node and edge lists, and long text.
• Tasks: reading (answer questions from the data) and writing (produce valid records to a contract), with and without constrained decoding.
• Models: several, including small open models, because small models are where the Mzizi pilots struggled.
• Costs counted: total tokens including the instructions a format needs, with and without prompt caching.

The harness, the data and the raw results will be public, so anyone can rerun them.

The kill criterion

We state it before the work begins. If, across the corpora, the new notation does not use at least 25% fewer total tokens than TOON at equal or better reading accuracy, and match JSON's validity when writing with a grammar, we stop. We adopt TOON where it helps and publish why.

The result will be published whichever way it falls.

Open from the first draft

A notation only one organisation uses is a private format. If this one earns its place, it should belong to everyone who reads and writes data with models, the way JSON does. So it is designed in the open from the start:

• The specification, grammar, benchmark and reference code are public from the first draft, under the Apache License 2.0.
• Changes go through the public RFC process, the same one the Mzizi language uses.
• A conformance suite ships with the specification, so anyone can build an encoder or decoder in any language and show it is correct. A standard is only as open as it is possible to implement without asking us.
• No features that only work with our tools. Mzizi and the Bundu vocabulary are early users, not owners.

Openness also answers the training-data problem honestly. Models learn the formats they see written down. A notation with a public specification, public examples and public corpora is one future models can learn. A closed one never will be.

What this proposal does not claim

• Not that JSON is wrong. JSON stays the format for storage and tools, and every contract exports to JSON Schema. This is about what an agent reads and writes.

• Not a speed claim. Parsing speed is not the cost being measured. Tokens and accuracy are.

• Not a standard yet. The intent is an open standard anyone can implement. It becomes one through evidence and adoption by others, not by our announcing it.

• Mzizi: mzizi.dev

• Design and RFCs: github.com/mzizi-dev/mzizi

• TOON vs JSON benchmark: arXiv:2603.03306