TOON as a Prompt Compression Format (Not a Storage Format)

People sometimes ask whether YJTOON stores data in TOON. The honest answer is no. We store data in JSON and emit TOON at the prompt boundary. The distinction is small but useful.

Storage vs prompt

Storage formats optimize for write throughput, query speed, and durability. Prompt formats optimize for token count and the model's ability to read them. The two rarely coincide.

What "emit at the boundary" means

A request to /api/dataset/<slug>?format=toon is read from JSON, encoded to TOON on the fly, and returned. The encoding is cheap (a few milliseconds for a 10KB dataset). The savings on the model side are large.

Why not store in TOON

Because then we would have two sources of truth. TOON encodes the same data as JSON, and our conformance tests round-trip every dataset through a decoder to prove it, so the reason is practical rather than about fidelity: JSON has a parser in every language and every database. Keep the universal format as the canonical store; derive TOON at read time.

The mental model

TOON is the CSS of data. CSS is a presentation layer over HTML. TOON is a presentation layer over JSON. Reach for it at the prompt boundary, not in your database.