Structured data without JSON bloat
Trakside sisse peidetud arve
JSON võitis, sest see on igav just õigel moel. Inimesed saavad seda lugeda. Masinad saavad seda parssida. Igal keelel on selle jaoks teek. Kui kahel süsteemil on vaja vahetada objekti ja keegi ei taha standardite koosolekut pidada, lõpeb vestlus tavaliselt JSON-iga. Olgu. On hullemaid kompromisse. Paljudel neist on nimi ettevõte.
Probleem pole JSON-is kui veebivormingus. Probleem on selles, mis juhtub, kui surume JSON-i keelemudelite töövoogudesse ja teeselme, et kulu on tasuta. Mudel ei näe korralikku objekti nii, nagu rakenduse parser seda näeb. See näeb tokenid. See loeb samu võtmeid ikka ja jälle. See kulutab konteksti kirjavahemärkidele, korduvatele väljanimedele, ümbristele, pesastatud tellingutele ja kuju meeldetuletustele, mis olid teada juba enne esimese kirje saabumist.
See raiskamine oli varem kergelt tüütu. AI-süsteemidega muutub see tooteprobleemiks. Iga korduv võti konkureerib tõendite, juhiste, näidete, tsitaatide ja tegeliku kasutaja sisuga. Iga üleliigne struktuuritoken on väike maks kasuliku töö pealt. Arve ei ütle tarbetud traksid, sest arvetel puudub luule. See ütleb tokenid.
HEDL algab lihtsast tähelepanekust: kui skeem on teada, on skeemi kordamine igas kirjes rumal. Kuuluta struktuur välja üks kord. Kodeeri kirjed positsiooniliselt. Hoia semantika täpne. Teisenda tagasi vormingutesse, mida olemasolevad süsteemid juba ootavad. See ei ole anti-JSON ideoloogia. See on keeldumine maksta mudelile, et see loeks iga kümne meetri tagant sama teeviita uuesti.
See on oluline, sest struktureeritud AI-töö ei ole lihtsalt vestlus. See on ekstraheerimine, klassifitseerimine, tööriistakutsed, andmete teisendamine, ülevaatepaketid, tõendikogumid, MCP-kutsed, töövood ja agendid, kes terve päeva üksteisele objekte edastavad. Mida tõsisemaks süsteem muutub, seda rohkem struktuuri see vajab. Kui struktuuri väljendatakse kõige sõnaohtramal võimalikul moel, maksab süsteem oma distsipliini eest.
JSON ei ole kaabakas
Oleks lihtne ja laisk kirjutada see JSON-i kaebusena. JSON-il on tõelised tugevused. See on kõikjal levinud, silutav, lihtne olemasolevate tööriistadega torustada ja piisavalt hea tohutu hulga rakendustöö jaoks. Asi pole selles, et JSON on halb. Asi on selles, et JSON-i kasutatakse sageli kohtades, kus vastuvõttev pool juba teab kuju, ja seal lakkab kordamine olemast selgus ja hakkab olema last.
Mõelge struktureeritud ekstraheerimisülesandele. Skeem ütleb, et igal vastusel on nimi, allikas, väärtus, enesekindlus ja põhjendus. Kujutage nüüd ette, et saadate mudelile sadu ridu või saate ühelt sadu ridu tagasi. JSON kordab neid väljanimesid iga objekti jaoks. Rakenduse parser ei pahanda. Mudeli kontekst pahandab. Kontekstiaken muutub kohaletoimetamise kaubik, mis on täis silte, mitte kaupa.
HEDL kohtleb skeemi lepinguna. See nimetab väljad ja tüübid üks kord. Seejärel kannavad kirjed väärtusi järjekorras. See kõlab ilmselgelt, sest see ongi. Paljud tõhusad vormingud on aastakümneid sarnaseid kompromisse teinud. Erinevus on selles, et HEDL on suunatud LLM-ile suunatud struktureeritud töövoogudele, kus inimese silutavus, teisendamine ja tööriistaühilduvus on endiselt olulised. See ei ole binaarne klomp, mis on üle müüri visatud koos sedeliga, millel on kirjas edu.
HEDLi implementatsioon hõlmab Rusti teegi tuge, CLI kasutust, MCP-serveri ja puhverserveri liideseid, WASM-i, FFI-d ja sidemeid ning teisendust levinud vormingutest ja nendesse. See kombinatsioon on oluline. AI-töövoogude vorming ei saa olla ainult kompaktne. See peab sisenema ja väljuma segasest maailmast ilma, et sellest saaks privaatne kultus. Olemasolevad API-d tahavad endiselt JSON-i. Inimesed vaatavad andmeid endiselt. Tööriistad vajavad endiselt ringteekondi. Vorming peab olema tihe ilma, et muutuks ebameeldivaks.
Struktuur kui leping
Enamik AI-tõrkeid struktureeritud andmete ümber ei ole dramaatilised. Need on pisiasjad, mis muudab nende austamise raskemaks, kuni need hakkavad päris raha maksma. Väli triivib. Väärtus pannakse vale võtme alla. Mudel väljastab usutava objekti, millel puudub valikuline väli. Parser aktsepteerib kuju, mille oleks pidanud tagasi lükkama. Allavoolu tööriist saab peaaegu õige asja, kõige ohtlikuma asja tarkvaras.
HEDLi skeemipõhine lähenemine on kasulik, sest see muudab struktuuri selgesõnaliseks enne, kui kirjed liikuma hakkavad. Skeem ei ole lahtine soovitus. See on see, mis ütleb lugejale, kuidas väärtusi tõlgendada. Kirje on kompaktne, sest see ei pea end pidevalt ise jutustama. Ümbritsev tööriistastik saab siiski valideerida, teisendada ja andmeid edastada süsteemidele, mis eelistavad JSON-i, YAML-i, XML-i, CSV-d või muid tavapäraseid vorme.
Ringteekonnad on test, kas vorming on abiks või lihtsalt nutikas. Kui JSON siseneb, HEDL liigub läbi töövoo ja JSON väljub samade semantikatega, saavutab süsteem tiheduse ilma ühilduvust kaotamata. Kui tähendus kaob vaikselt, on vorming ebaõnnestunud. Õige käitumine surve all ei ole õlgu kehitada ja objekt allavoolu edasi anda. See on blokeerida, teatada ja sundida ebaselgus avalikuks tulema.
Siin sobib HEDL kenasti ülejäänud Dweve virna kõrvale. Ledger hoolib sellest, et operatiivsed sündmused jääksid kontrollitavaks. AION hoolib sellest, et otsuste tõendeid saaks kontrollida. Trace hoolib sellest, et arvutust saaks taasesitada. HEDL hoolib sellest, et struktureeritud andmeid saaks tihedalt esitada ja täpselt taastada. Need tööd puutuvad kokku, kuid need ei ole sama töö. Jällegi: vähem sooja-supi sõnu, rohkem kasulikke piire.
Võrdlusnäitaja ei ole kaunistus
AI-infrastruktuuri jõudlusväited on sageli kirjutatud nagu kalalood. Arv muutub iga ümberjutustusega suuremaks. HEDLil on konkreetne võrdlusnäitaja väide: 571 struktureeritud väljavõtu ülesannet seitsme andmestiku peal, 56 protsenti vähem tokeneid kui JSON ja 10,3 protsendipunkti täpsuse kasv JSON-i ees.
Neid numbreid tuleks lugeda võrdlusnäitaja väitena, mitte universaalse füüsikaseadusena. Need kirjeldavad võrdlusnäitaja seadistust. Need ei tähenda, et iga töövoog saab maagiliselt sama tulemuse. Kuid need selgitavad, miks vorming eksisteerib. Tokenite arv ei ole LLM-süsteemide rakenduse joonealune märkus. See on osa liidesest. Kui kaks esitust kannavad sama tähendust ja üks põletab palju rohkem konteksti, ei ole raskem neutraalne.
The accuracy gain is especially interesting. It suggests the benefit is not only cheaper prompts. A cleaner representation can also make the task easier for the model. That should not be surprising. If the model spends less attention on repeated syntactic clutter, it has more room for values and relations. This is the same reason good forms beat messy forms in human work. The human may be smart, but do not hand them a tax form written by a printer having a difficult childhood.
There is a broader design lesson here. AI interfaces should not be judged only by whether the model can cope. Models can cope with many bad interfaces. People can also carry furniture up stairs with poor grip and no plan. That does not make it architecture. A good AI interface reduces avoidable work, exposes structure, preserves meaning, and fails loudly when the structure is wrong.
Why proxy surfaces matter
A format rarely wins by being pure. It wins by fitting the ugly middle. HEDL's MCP and proxysurfaces matter because most organisations cannot simply announce that everything now speaks a new representation. They have existing APIs, data stores, validation rules, dashboards, notebooks, and export formats. Replacing all of that to save tokens would be aheroic way to lose friends.
The proxy pattern is more practical. Let models and tools benefit from dense structured representation where it matters. Convert at the boundary. Validate before data leaves the controlled path. Keep downstream JSON compatibility. Let systems that expect JSON receive JSON, but stop forcing the model to haul the full JSON shape through every internal step.
This is also where governance enters, quietly and usefully. If the proxy validates structure, it can reject malformed objects before they become business facts. If it preserves a lossless round trip, it can prove that conversion did not change the meaning. If it keeps compatibility with existingsystems, it can be adopted without turning every integration into a migration programme. We are European. We have enough migration programmes. Some of them still have steering committees from 2014.
For agent systems, the proxy is even more important. Agents pass structured calls and results across boundaries. They call tools, receive outputs, update memory, produce artifacts, and hand state to other agents. A dense representation with validation keeps those handoffs less wasteful and less ambiguous. It does not make the agent wise. It makes the envelope less stupid. That is a respectable engineering outcome.
Where HEDL should not be used
Every useful tool has a place where it should not be used. HEDL is not a replacement for every JSON file on earth. If asmall config file is read once by a human and edited twice a year, JSON or TOML will survive the tragedy. If a public API needs maximum familiarity and the payloads are tiny, JSON is fine. If the schema is genuinely unknown and ad hoc, schema-once encoding is not the right starting assumption.
HEDL becomes interesting when structure is repeated, volumes are meaningful, model context is expensive, round trips matter, and tools need compatibility at the edges. That is why LLM workflows are such a good fit. They sit precisely at the intersection of structured intent and token economics. They also tend to grow from prototype to production faster than anyone planned, because apparently nobody has learned this lesson despite the entire history of software looking mildly offended in the corner.
The practical adoption path should therefore be narrow. Do not rewrite the organisation. Pick a structured extraction workflow. Pick an agent tool-call path. Pick an MCP proxy boundary. Measure token use, failure rate, validation outcomes, and round-trip fidelity. If the numbers hold, expand. If they do not, keep the boring thing. The goal is not to worship a format. The goal is to stop paying for avoidable structure.
The lesson
The lesson of HEDL is that structure is not free just because it is useful. In ordinary software, repeated keys are mostly an annoyance. In AI workflows, they are context, money, attention, and failure surface. If the schema is known, repeating it in every record is often the least imaginative option available.
HEDL makes a simple trade: declare structure once, encode records densely, preserve semantics, convert back when needed, and validate at the proxy boundary. It is not a replacement for JSON as the common language of the web. It is a better internal envelope for structured AI work where the model should be spending its context on meaning, not on reading the same field names until the heat death of the budget.
That is the useful standard for AI infrastructure. Not cleverness for its own sake. Not novelty tax.Not a format that requires everyone else to suffer. A good layer removes waste, keeps the contract explicit, and lets the rest of the system keep working. HEDL earns its place when the object becomes smaller without the meaning becoming softer.
JSON can stay. It has done nothing wrong. It can even have a cup of coffee. It just does not need to sit inside every model call carrying the same set of keys like a man moving house one spoon at a time.