HEDL och strukturerad data utan JSON-uppsvällning
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.
HEDL-implementeringen omfattar Rust-biblioteksstöd, CLI-användning, MCP-server och proxyytor, WASM, FFI och bindningar, samt konvertering till och från vanliga format. Den kombinationen är viktig. Ett format för AI-arbetsflöden kan inte bara vara kompakt. Det måste kunna ta sig in i och ut ur den stökiga verkligheten utan att bli en privat kult. Befintliga API:er vill fortfarande ha JSON. Människor inspekterar fortfarande data. Verktyg behöver fortfarande rundresor. Formatet måste vara tätt utan att bli antisocialt.
Struktur som kontrakt
De flesta AI-misslyckanden kring strukturerad data är inte dramatiska. De är småaktiga, vilket gör dem svårare att ta på allvar tills de kostar riktiga pengar. Ett fält glider. Ett värde hamnar under fel nyckel. En modell genererar ett trovärdigt objekt med ett saknat valfritt fält. En parser accepterar en form den borde ha avvisat. Ett nedströmsverktyg får nästan rätt sak, den farligaste typen av sak inom mjukvara.
HEDL:s schema-först-strategi är användbar eftersom den gör strukturen explicit innan posterna börjar röra på sig. Schemat är inte ett löst promptförslag. Det är det som talar om för läsaren hur värdena ska tolkas. Posten är kompakt eftersom den inte behöver berätta om sig själv upprepade gånger. Den omgivande verktygsutrustningen kan fortfarande validera, konvertera och lämna över data till system som föredrar JSON, YAML, XML, CSV eller andra konventionella former.
Rundresor är testet på om ett format är hjälpsamt eller bara listigt. Om JSON går in, HEDL rör sig genom arbetsflödet och JSON kommer ut med samma semantik, vinner systemet täthet utan att förlora kompatibilitet. Om innebörd går förlorad tyst har formatet misslyckats. Rätt beteende under press är inte att rycka på axlarna och skicka objektet vidare nedströms. Det är att blockera, rapportera och tvinga fram tvetydigheten i ljuset.
Det är här HEDL passar fint bredvid resten av Dweve-stacken. Ledger bryr sig om att operationella händelser förblir inspekterbara. AION bryr sig om att beslutsbevis kan kontrolleras. Trace bryr sig om att beräkningar kan spelas upp. HEDL bryr sig om att strukturerad data kan representeras tätt och återställas exakt. Dessa uppgifter rör vid varandra, men de är inte samma uppgift. Återigen: färre luddiga ord, fler användbara gränser.
Riktmärket är inte dekoration
Prestandapåståenden kring AI-infrastruktur skrivs ofta som fiskesägner. Siffran blir större varje gång den återberättas. HEDL har ett konkret riktmärkespåstående: 571 strukturerade extraheringsuppgifter över sju dataset, 56 procent färre token än JSON och en noggrannhetsförbättring på 10,3 procentenheter jämfört med JSON.
Dessa siffror ska läsas som ett riktmärkespåstående, inte som en universell naturlag. De beskriver en riktmärkesuppsättning. De betyder inte att varje arbetsflöde magiskt får samma resultat. Men de förklarar varför formatet finns. Tokenantal är inte en implementationsfotnot i LLM-system. Det är en del av gränssnittet. Om två representationer bär samma innebörd och den ena förbrukar mycket mer kontext, är den tyngre inte neutral.
Vinsten i träffsäkerhet är särskilt intressant. Den tyder på att fördelen inte bara är billigare uppmaningar. En renare representation kan också göra uppgiften lättare för modellen. Det borde inte förvåna. Om modellen ägnar mindre uppmärksamhet åt upprepad syntaktisk oreda har den mer utrymme för värden och relationer. Det är samma anledning till att bra formulär slår dåliga formulär i mänskligt arbete. Människan kan vara smart, men ge dem inte ett skatteformulär skrivet av en skrivare med en svår barndom.
Det finns en bredare designläxa här. AI-gränssnitt bör inte bedömas enbart utifrån om modellen klarar av dem. Modeller klarar av många dåliga gränssnitt. Människor kan också bära möbler uppför trappor med dåligt grepp och utan plan. Det gör det inte till arkitektur. Ett bra AI-gränssnitt minskar onödigt arbete, blottlägger struktur, bevarar mening och misslyckas högljutt när strukturen är fel.
Varför proxyytor spelar roll
Ett format vinner sällan genom att vara rent. Det vinner genom att passa in i den fula mitten. HEDL:s MCP och proxyytor spelar roll eftersom de flesta organisationer inte bara kan tillkännage att allt nu talar en ny representation. De har befintliga API:er, datalager, valideringsregler, instrumentpaneler, notebook-filer och exportformat. Att ersätta allt detta för att spara tokens vore ett heroiskt sätt att förlora vänner.
Proxymönstret är mer praktiskt. Låt modeller och verktyg dra nytta av tät strukturerad representation där det spelar roll. Konvertera vid gränsen. Validera innan data lämnar den kontrollerade vägen. Behåll JSON-kompatibilitet nedströms. Låt system som förväntar sig JSON få JSON, men sluta tvinga modellen att släpa hela JSON-formen genom varje internt steg.
Det är också här styrningen kommer in, tyst och användbart. Om proxyn validerar struktur kan den avvisa felformade objekt innan de blir affärsfakta. Om den bevarar en förlustfri rundresa kan den bevisa att konverteringen inte ändrade innebörden. Om den behåller kompatibilitet med befintliga system kan den antas utan att varje integration blir ett migreringsprogram. Vi är européer. Vi har nog av migreringsprogram. Några av dem har fortfarande styrkommittéer från 2014.
För agentsystem är proxyn ännu viktigare. Agenter skickar strukturerade anrop och resultat över gränser. De anropar verktyg, tar emot utdata, uppdaterar minne, producerar artefakter och överlämnar tillstånd till andra agenter. En tät representation med validering gör dessa överlämningar mindre slösaktiga och mindre tvetydiga. Den gör inte agenten vis. Den gör kuvertet mindre dumt. Det är ett respektabelt ingenjörsresultat.
Där HEDL inte bör användas
Varje användbart verktyg har en plats där det inte bör användas. HEDL är inte en ersättning för varje JSON-fil på jorden. Om en liten konfigurationsfil läses en gång av en människa och redigeras två gånger om året överlever JSON eller TOML tragedin. Om ett offentligt API behöver maximal igenkänning och nyttolasterna är små är JSON bra. Om schemat är genuint okänt och ad hoc är schema-vid-encoding inte rätt utgångsantagande.
HEDL blir intressant när struktur upprepas, volymerna är betydande, modellkontext är dyr, rundresor spelar roll och verktyg behöver kompatibilitet i kanterna. Det är därför LLM-arbetsflöden passar så bra. De sitter precis i skärningspunkten mellan strukturerad avsikt och tokenekonomi. De tenderar också att växa från prototyp till produktion snabbare än någon planerat, för tydligen har ingen lärt sig den läxan trots att hela mjukvaruhistorien ser lätt förolämpad ut i hörnet.
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.