HEDL és strukturált adatok JSON-felfúvódás nélkül
The invoice hiding in your braces
JSON won because it is boring in exactly the right way. Humans can read it. Machines can parse it. Every language has a library for it. If two systems need to exchange an object and nobody wants a standards meeting, JSON is usually where the conversation ends. Fine. There are worse compromises. Many of them have enterprise in the name.
The problem is not JSON as a web format. The problem is what happens when we push JSON into language-model workflows andpretend the cost is free. A model does not see a tidy object in the way an application parser sees one. It sees tokens. It reads the same keys again and again. It spends context on punctuation, repeated field names, wrappers, nested scaffolding, and shape reminders that were already known before the first record arrived.
That waste used to be mildly irritating. With AI systems, it becomes a product problem. Every repeated key competes with evidence, instructions, examples, citations, and actual user content. Every redundant structural token is a little tax on the useful work. The invoice does not say needless braces, because invoices lack poetry. It says tokens.
HEDL starts from a plain observation: when the schema is known, repeating the schema inside every record is silly. Declare the structure once. Encode records positionally. Keep the semantics exact. Convert back to the formats existing systems already expect. That is not anti-JSON ideology. It is a refusal to pay the model to reread the same road sign every ten metres.
This matters because structured AI work is not just chat. It is extraction, classification, tool calls, data transformation, review packets, evidence bundles, MCP calls, workflows, and agents passing objects to each other all day. The more serious the system becomes, the more structure it needs. If structure is expressed in the most verbose possible way, the system pays for its own discipline.
JSON is not the villain
It would be easy, and lazy, to write this as a JSON complaint. JSON has real strengths. It is ubiquitous, debuggable, easy to pipe through existing tools, and good enough for a huge amount of application work. The point is not that JSON is bad. The point is that JSON is often used in places where the receiving side already knows the shape, and there the repetition stops being clarity and starts being cargo.
Consider a structured extraction task. The schema says every answer has a name, source, value, confidence, and rationale. Now imagine sending hundreds of rows to a model or receiving hundreds of rows back from one. JSON repeats those field names for every object. The application parser does not mind. The model context does. The context window becomes a deliveryvan full of labels instead of goods.
HEDL treats the schema as a contract. It names the fields and types once. The records then carry values in order. That sounds obvious because it is. Many efficient formats have made similar tradeoffs for decades. The difference is that HEDL is aimed at LLM-facing structured workflows where human debuggability, conversion, and tool compatibility still matter. It is not a binary blob lobbed over a wall with a note saying good luck.
A HEDL-megvalósítás tartalmaz Rust-könyvtártámogatást, CLI-használatot, MCP-szervert és proxyfelületeket, WASM-ot, FFI-t és kötéseket, valamint konverziót gyakori formátumokba és azokból. Ez a kombináció fontos. Az AI-munkafolyamatokhoz készült formátum nem lehet csak tömör. Be kell tudnia lépni a rendezetlen világba, és ki is kell onnan lépnie anélkül, hogy magánszektává válna. A meglévő API-k továbbra is JSON-t akarnak. Az emberek továbbra is megnézik az adatokat. Az eszközöknek továbbra is szükségük van oda-vissza konverzióra. A formátumnak sűrűnek kell lennie anélkül, hogy antiszociálissá válna.
A struktúra mint szerződés
A strukturált adatokkal kapcsolatos legtöbb AI-hiba nem drámai. Apró, ami miatt nehezebb komolyan venni őket, amíg valódi pénzbe nem kerülnek. Egy mező elcsúszik. Egy érték rossz kulcs alá kerül. Egy modell valószínűnek tűnő objektumot ad ki hiányzó opcionális mezővel. Egy elemző elfogad egy alakzatot, amit el kellett volna utasítania. Egy downstream eszköz majdnem a megfelelő dolgot kapja meg, ami a legveszélyesebb dolog a szoftverben.
A HEDL séma-első megközelítése azért hasznos, mert a struktúrát explicit módon rögzíti, mielőtt a rekordok mozogni kezdenének. A séma nem egy laza prompt-javaslat. Ez az, ami megmondja az olvasónak, hogyan értelmezze az értékeket. A rekord azért tömör, mert nem kell folyamatosan elmesélnie önmagát. A környező eszközök továbbra is tudják érvényesíteni, konvertálni és átadni az adatokat olyan rendszereknek, amelyek a JSON-t, YAML-t, XML-t, CSV-t vagy más hagyományos formákat részesítik előnyben.
Az oda-vissza utak mutatják meg, hogy egy formátum hasznos-e vagy csak okos. Ha a JSON bemegy, a HEDL végigmegy a munkafolyamaton, és a JSON ugyanazokkal a szemantikákkal jön ki, a rendszer sűrűséget nyer a kompatibilitás elvesztése nélkül. Ha a jelentés csendben elvész, a formátum kudarcot vallott. A helyes viselkedés nyomás alatt nem az, hogy vállat vonunk, és továbbadjuk az objektumot downstream. Hanem az, hogy blokkolunk, jelentünk, és a kétértelműséget a felszínre kényszerítjük.
Itt illeszkedik a HEDL szépen a Dweve-stack többi része mellé. A Ledger arra ügyel, hogy a műveleti események ellenőrizhetők maradjanak. Az AION arra ügyel, hogy a döntési bizonyítékok ellenőrizhetők legyenek. A Trace arra ügyel, hogy a számítások újrajátszhatók legyenek. A HEDL arra ügyel, hogy a strukturált adatok sűrűn ábrázolhatók és pontosan visszaállíthatók legyenek. Ezek a feladatok érintkeznek, de nem ugyanaz a feladat. Ismét: kevesebb meleg leves szó, több hasznos határvonal.
A benchmark nem dekoráció
Az AI-infrastruktúrával kapcsolatos teljesítményállításokat gyakran úgy írják, mint a horgásztörténeteket. A szám minden újrameséléskor nagyobb lesz. A HEDL-nek konkrét benchmark-állítása van: 571 strukturált kinyerési feladat hét adatkészleten, 56 százalékkal kevesebb token, mint a JSON, és 10,3 százalékpontos pontosságnövekedés a JSON-hoz képest.
Ezeket a számokat benchmark-állításként kell olvasni, nem pedig a fizika egyetemes törvényeként. Egy benchmark-konfigurációt írnak le. Nem jelentik azt, hogy minden munkafolyamat varázsütésre ugyanazt az eredményt kapja. De megmagyarázzák, miért létezik a formátum. A tokenszám nem implementációs lábjegyzet az LLM-rendszerekben. Az interfész része. Ha két reprezentáció ugyanazt a jelentést hordozza, és az egyik sokkal több kontextust éget el, a nehezebb nem semleges.
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.
A gyakorlati bevezetés útja ezért szűk legyen. Ne írd át a szervezetet. Válassz egy strukturált kinyerési munkafolyamatot. Válassz egy ügynök eszközhívási útvonalat. Válassz egy MCP proxy határfelületet. Mérd a tokenfelhasználást, a hibaarányt, az érvényesítési eredményeket és a körkörös hűséget. Ha a számok tartják magukat, bővíts. Ha nem, maradj az unalmas megoldásnál. A cél nem az, hogy egy formátumot imádjunk. A cél az, hogy ne fizessünk az elkerülhető struktúráért.
A tanulság
A HEDL tanulsága az, hogy a struktúra nem ingyenes csak azért, mert hasznos. A hétköznapi szoftverekben az ismétlődő kulcsok többnyire csak bosszúságot okoznak. Az AI-munkafolyamatokban ezek kontextust, pénzt, figyelmet és hibafelületet jelentenek. Ha a séma ismert, minden rekordban megismételni gyakran a legkevésbé ötletes megoldás.
A HEDL egyszerű cserét kínál: deklaráld a struktúrát egyszer, kódold a rekordokat sűrűn, őrizd meg a szemantikát, alakítsd vissza, amikor kell, és érvényesíts a proxy határfelületen. Nem a JSON helyettesítője, mint a web közös nyelve. Jobb belső boríték a strukturált AI-munkához, ahol a modellnek a jelentésre kell fordítania a kontextusát, nem pedig ugyanazokat a mezőneveket olvasnia a költségvetés hőhaláláig.
Ez az AI-infrastruktúra hasznos mércéje. Nem az öncélú okosság. Nem az újdonságadó. Nem olyan formátum, amelytől mindenki másnak szenvednie kell. Egy jó réteg eltávolítja a pazarlást, expliciten tartja a szerződést, és hagyja, hogy a rendszer többi része tovább működjön. A HEDL akkor érdemli ki a helyét, amikor az objektum kisebb lesz anélkül, hogy a jelentés puhábbá válna.
A JSON maradhat. Nem tett semmi rosszat. Akár ihat egy kávét is. Csak nem kell minden modellhívásban ott ülnie ugyanazokkal a kulcsokkal, mint egy ember, aki kanalanként költözik.