HEDL und strukturierte Daten ohne JSON-Aufblähung
Die Rechnung, die in Ihren geschweiften Klammern steckt
JSON hat sich durchgesetzt, weil es genau auf die richtige Weise langweilig ist. Menschen können es lesen. Maschinen können es parsen. Jede Sprache hat eine Bibliothek dafür. Wenn zwei Systeme ein Objekt austauschen müssen und niemand ein Standards-Meeting will, endet das Gespräch meist bei JSON. Gut so. Es gibt schlechtere Kompromisse. Viele davon haben Enterprise im Namen.
Das Problem ist nicht JSON als Webformat. Das Problem ist, was passiert, wenn wir JSON in Workflows mit Sprachmodellen einbringen und so tun, als wäre das kostenlos. Ein Modell sieht kein aufgeräumtes Objekt so, wie es ein Anwendungsparser sieht. Es sieht Tokens. Es liest dieselben Schlüssel immer wieder. Es verbraucht Kontext für Satzzeichen, wiederholte Feldnamen, Wrapper, verschachtelte Gerüste und Formhinweise, die schon bekannt waren, bevor der erste Datensatz eintraf.
Diese Verschwendung war früher leicht ärgerlich. Bei KI-Systemen wird sie zu einem Produktproblem. Jeder wiederholte Schlüssel konkurriert mit Belegen, Anweisungen, Beispielen, Zitaten und tatsächlichen Nutzerinhalten. Jedes redundante Struktur-Token ist eine kleine Steuer auf die nützliche Arbeit. Die Rechnung sagt nicht überflüssige geschweifte Klammern, denn Rechnungen fehlt die Poesie. Sie sagt Tokens.
HEDL geht von einer einfachen Beobachtung aus: Wenn das Schema bekannt ist, ist es albern, das Schema in jedem Datensatz zu wiederholen. Deklarieren Sie die Struktur einmal. Kodieren Sie Datensätze positionsbasiert. Behalten Sie die Semantik exakt bei. Konvertieren Sie zurück in die Formate, die bestehende Systeme bereits erwarten. Das ist keine Anti-JSON-Ideologie. Es ist eine Weigerung, das Modell dafür zu bezahlen, alle zehn Meter dasselbe Straßenschild erneut zu lesen.
Das ist wichtig, weil strukturierte KI-Arbeit nicht nur Chat ist. Es ist Extraktion, Klassifikation, Tool-Aufrufe, Datentransformation, Prüfpakete, Belegbündel, MCP-Aufrufe, Workflows und Agenten, die den ganzen Tag Objekte austauschen. Je ernsthafter das System wird, desto mehr Struktur braucht es. Wenn Struktur auf die ausführlichste mögliche Weise ausgedrückt wird, bezahlt das System für seine eigene Disziplin.
JSON ist nicht der Bösewicht
Es wäre einfach und bequem, das als Beschwerde über JSON zu schreiben. JSON hat echte Stärken. Es ist allgegenwärtig, debugbar, leicht durch bestehende Tools zu leiten und gut genug für eine enorme Menge an Anwendungsarbeit. Es geht nicht darum, dass JSON schlecht ist. Es geht darum, dass JSON oft dort verwendet wird, wo die empfangende Seite die Form bereits kennt, und dort hört die Wiederholung auf, Klarheit zu sein, und wird zu Ballast.
Betrachten Sie eine strukturierte Extraktionsaufgabe. Das Schema besagt, dass jede Antwort einen Namen, eine Quelle, einen Wert, eine Konfidenz und eine Begründung hat. Stellen Sie sich nun vor, Sie senden Hunderte von Zeilen an ein Modell oder empfangen Hunderte von Zeilen von einem. JSON wiederholt diese Feldnamen für jedes Objekt. Der Anwendungsparser stört das nicht. Der Modellkontext schon. Das Kontextfenster wird zu einem Lieferwagen voller Etiketten statt Waren.
HEDL behandelt das Schema als Vertrag. Es benennt die Felder und Typen einmal. Die Datensätze tragen dann die Werte in Reihenfolge. Das klingt offensichtlich, weil es das ist. Viele effiziente Formate haben seit Jahrzehnten ähnliche Kompromisse gemacht. Der Unterschied ist, dass HEDL auf LLM-orientierte strukturierte Workflows abzielt, bei denen menschliche Debugbarkeit, Konvertierung und Tool-Kompatibilität immer noch wichtig sind. Es ist kein binärer Datenklumpen, der über eine Mauer geworfen wird, mit einem Zettel, auf dem viel Glück steht.
Die HEDL-Implementierung umfasst Rust-Bibliotheksunterstützung, CLI-Nutzung, MCP-Server- und Proxy-Oberflächen, WASM, FFI und Bindings sowie die Konvertierung von und in gängige Formate. Diese Kombination ist wichtig. Ein Format für KI-Workflows kann nicht nur kompakt sein. Es muss in die unordentliche Welt hinein- und wieder hinausgelangen, ohne zu einem privaten Kult zu werden. Bestehende APIs wollen weiterhin JSON. Menschen prüfen Daten weiterhin. Tools brauchen weiterhin Roundtrips. Das Format muss dicht sein, ohne ungesellig zu werden.
Struktur als Vertrag
Die meisten KI-Fehler bei strukturierten Daten sind nicht dramatisch. Sie sind kleinlich, was es schwerer macht, sie ernst zu nehmen, bis sie echtes Geld kosten. Ein Feld driftet. Ein Wert wird unter den falschen Schlüssel gesetzt. Ein Modell erzeugt ein plausibles Objekt mit einem fehlenden optionalen Feld. Ein Parser akzeptiert eine Form, die er hätte ablehnen sollen. Ein nachgelagertes Tool erhält fast das Richtige, die gefährlichste Art von Ding in der Software.
Der schema-first-Ansatz von HEDL ist nützlich, weil er die Struktur explizit macht, bevor die Datensätze sich zu bewegen beginnen. Das Schema ist kein lockerer Prompt-Vorschlag. Es ist das, was dem Leser sagt, wie die Werte zu interpretieren sind. Der Datensatz ist kompakt, weil er sich nicht wiederholt selbst erzählen muss. Die umgebende Tooling kann weiterhin validieren, konvertieren und Daten an Systeme übergeben, die JSON, YAML, XML, CSV oder andere konventionelle Formen bevorzugen.
Roundtrips sind der Test dafür, ob ein Format hilfreich oder nur clever ist. Wenn JSON hineingeht, HEDL durch den Workflow wandert und JSON mit derselben Semantik herauskommt, gewinnt das System an Dichte, ohne Kompatibilität zu verlieren. Wenn Bedeutung still verloren geht, ist das Format gescheitert. Das richtige Verhalten unter Druck ist nicht, zu zucken und das Objekt nachgelagert weiterzureichen. Es ist, zu blockieren, zu melden und die Mehrdeutigkeit ins Offene zu zwingen.
Hier passt HEDL gut neben den Rest des Dweve-Stacks. Ledger kümmert sich darum, dass operative Ereignisse prüfbar bleiben. AION kümmert sich darum, dass Entscheidungsnachweise überprüft werden können. Trace kümmert sich darum, dass Berechnungen wiederholbar sind. HEDL kümmert sich darum, dass strukturierte Daten dicht dargestellt und exakt wiederhergestellt werden können. Diese Aufgaben berühren sich, sind aber nicht dieselbe Aufgabe. Nochmals: weniger warme-Suppe-Wörter, mehr nützliche Grenzen.
Der Benchmark ist keine Dekoration
Leistungsbehauptungen rund um KI-Infrastruktur werden oft wie Angelgeschichten geschrieben. Die Zahl wird bei jedem Nacherzählen größer. HEDL hat eine konkrete Benchmark-Behauptung: 571 strukturierte Extraktionsaufgaben über sieben Datensätze, 56 Prozent weniger Tokens als JSON und eine Genauigkeitssteigerung von 10,3 Prozentpunkten gegenüber JSON.
Diese Zahlen sollten als Benchmark-Behauptung gelesen werden, nicht als universelles Naturgesetz. Sie beschreiben ein Benchmark-Setup. Sie bedeuten nicht, dass jeder Workflow magisch dasselbe Ergebnis erhält. Aber sie erklären, warum das Format existiert. Die Token-Anzahl ist in LLM-Systemen keine Implementierungs-Fußnote. Sie ist Teil der Schnittstelle. Wenn zwei Darstellungen dieselbe Bedeutung tragen und eine davon weit mehr Kontext verbrennt, ist die schwerere nicht neutral.
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.
Der praktische Einführungsweg sollte daher schmal sein. Schreiben Sie die Organisation nicht um. Wählen Sie einen strukturierten Extraktions-Workflow. Wählen Sie einen Agenten-Tool-Call-Pfad. Wählen Sie eine MCP-Proxy-Grenze. Messen Sie Token-Verbrauch, Fehlerrate, Validierungsergebnisse und Round-Trip-Treue. Wenn die Zahlen halten, erweitern Sie. Wenn nicht, behalten Sie die langweilige Sache. Das Ziel ist nicht, ein Format zu verehren. Das Ziel ist, aufzuhören, für vermeidbare Struktur zu zahlen.
Die Lektion
Die Lektion von HEDL ist, dass Struktur nicht nur deshalb kostenlos ist, weil sie nützlich ist. In gewöhnlicher Software sind wiederholte Schlüssel meist eine Belästigung. In KI-Workflows sind sie Kontext, Geld, Aufmerksamkeit und Fehlerfläche. Wenn das Schema bekannt ist, ist es oft die am wenigsten einfallsreiche verfügbare Option, es in jedem Datensatz zu wiederholen.
HEDL macht einen einfachen Tausch: Struktur einmal deklarieren, Datensätze dicht kodieren, Semantik bewahren, bei Bedarf zurückkonvertieren und an der Proxy-Grenze validieren. Es ist kein Ersatz für JSON als gemeinsame Sprache des Webs. Es ist ein besserer interner Umschlag für strukturierte KI-Arbeit, bei der das Modell seinen Kontext für Bedeutung ausgeben sollte, nicht dafür, dieselben Feldnamen zu lesen, bis zum Hitzetod des Budgets.
Das ist der nützliche Standard für KI-Infrastruktur. Nicht Klugheit um ihrer selbst willen. Keine Neuheitssteuer. Kein Format, das von allen anderen verlangt zu leiden. Eine gute Schicht entfernt Verschwendung, hält den Vertrag explizit und lässt den Rest des Systems weiterarbeiten. HEDL verdient seinen Platz, wenn das Objekt kleiner wird, ohne dass die Bedeutung weicher wird.
JSON kann bleiben. Es hat nichts falsch gemacht. Es kann sogar eine Tasse Kaffee trinken. Es muss nur nicht in jedem Modellaufruf sitzen und denselben Satz Schlüssel tragen, wie ein Mann, der umzieht, einen Löffel nach dem anderen.