Einmal lesen. Jede Frage danach ist nur noch ein Nachschlagen.

Talonic akzeptiert über 25 Dateiformate über drei Verarbeitungspfade. Reine Textformate (TXT, MD, HTML, XML, JSON, EML, CSV) werden direkt gelesen, ohne Modellaufruf. Bildformate (PNG, JPG, GIF, WEBP) gehen an Vision. Dokumentformate (PDF, DOCX, PPTX, XLSX, MSG, BMP) durchlaufen den OCR-Pfad und werden zu strukturiertem Markdown; trägt eine Seite komplexe Bildelemente wie gedruckte Kurven, wird sie an das Vision-Modell weitergeleitet, das für dieses Element am besten abschneidet. ZIP-Archive werden rekursiv entpackt, und die Ordnerstruktur bleibt erhalten als source_file_path Feld in jedem darin enthaltenen Dokument erhalten. SHA-256-Deduplizierung läuft beim Hochladen, sodass dieselbe Datei nie zweimal ins System gelangt.

Jedes Dokument wird anhand einer Ontologie mit 529 Typen klassifiziert, auf Deutsch, Englisch, Französisch und Spanisch in Produktionsqualität: Ein deutscher Arbeitsvertrag und ein englischer Employment Contract werden demselben kanonischen Typ zugeordnet. Ihre eigenen Dokumenttypen legen sich über die Ontologie, sodass jedes Dokument auf beiden Achsen klassifiziert wird. Alles, was auf nichts passt, landet in Unclassified statt zu scheitern.

Jedes Feld, das in jedem Dokument gefunden wird, löst sich in ein kanonisches Register auf, den Schema Graph. Felder befinden sich je nach Häufigkeit in drei Tiers. Tier 1 ist grundlegend: universell über viele Dokumenttypen hinweg, am zuverlässigsten. Tier 2 ist etabliert, aus Tier 3 befördert, nachdem Häufigkeitsschwellen erreicht wurden. Tier 3 ist neu entstehend: neu entdeckt, ein Kandidat für die Beförderung, sobald weitere Dokumente eintreffen.

Felder mit derselben Bedeutung gruppieren sich automatisch. Vendor Name, Supplier Name und Company Name lösen sich zu einem kanonischen Konzept auf, wobei die Quellvarianten als Aliasse erhalten bleiben. Da dasselbe Konzept aus vielen Dokumenten gelesen wird, synthetisiert Talonic dafür eine Masteranweisung: eine wiederverwendbare Direktive, die die beste Art erfasst, dieses Feld zu lesen. Masteranweisungen verbessern jeden nachfolgenden Lauf.

Deshalb bedient ein einziger Lesevorgang jede spätere Frage. Die Datenbank enthält, was die Dokumente sagen, nicht was der erste Anfragende verlangt hat. GETEC benötigte 75 Felder; die ersten fünftausend Dokumente ergaben 1,042,665 Quellbeobachtungen, organisiert in 52,937 Konzepte, und der gesamte Bestand ist etwa zehnmal so groß. In einem schema-first Extraktionsprojekt wird dieser Überschuss verworfen. Hier ist er das Kapital.

Eine Spezifikation definiert die Form eines Outputs. Es gibt zwei Arten. Generierte Spezifikationen werden automatisch pro Dokumenttyp aus Stufe-1- und Stufe-2-Konzepten erzeugt. Ihre eigenen Vorlagen zielen auf ein System: eine Lieferantenvertragsvorlage für Ivalua, eine Lane-Vorlage für TMW, ein Vertragsdatensatz für Microsoft Dynamics.

Vorlagen verfügen über einen Workshop. Live ist die veröffentlichte Version, schreibgeschützt. Workshop ist der veränderbare Entwurf. Der Versionsverlauf ist die vollständige Zeitachse mit Diff-Zusammenfassungen. Das Hochstufen eines Entwurfs deckt Breaking Changes, entfernte Felder und Typänderungen auf, bevor sie ausgeliefert werden. Eine Testextraktion führt den Entwurf gegen eine Stichprobe aus und zeigt Entwurf und Live nebeneinander, sodass die Auswirkung einer Änderung vor der Veröffentlichung sichtbar ist.

Jedes Feld unterstützt Formatbeschränkungen (Regex), Modifikatoren (Datums- und Zahlenformatierung, Wertzuordnung, Kürzung), Constraints (Pflichtfeld, Enum, Länge, feldübergreifende Ausdrücke), Bypass-Strategien (konstanter Wert, deterministische ID, Nachschlagen in Referenztabellen) und manuelle Anweisungen, die die Masteranweisung überschreiben. Kohärenzregeln können vom System nach Abschluss eines Jobs vorgeschlagen werden. Nichts Vorgeschlagenes geht live, ohne dass eine Person es genehmigt.

Phase 1 füllt Zellen direkt aus der Datenbank: kein Modellaufruf, keine Credits. Phase 2 schlussfolgert. Phase 3 validiert. Phase 4 füllt die Lücken. Sobald eine Zelle einen Konfidenzwert von 0.7 erreicht, überschreibt keine spätere Phase sie mehr. Jede Zelle gibt ihre Phase, Konfidenz und Begründung über die API preis, sodass Agenten und nachgelagerte Systeme selbst entscheiden, was sie als vertrauenswürdig einstufen.

Ein Job durchläuft vier Phasen. Jede Phase füllt weitere Zellen im Ausgaberaster. Frühere Phasen erzeugen Werte, die sich davor schützen, von späteren, weniger sicheren Werten überschrieben zu werden.

Phase 1 · Auflösen. Die schnellste Phase. Zellen werden aus bestehenden Graph-Treffern ohne KI-Aufrufe befüllt: direkte Registry-Übertragung, unscharfer Namensabgleich, Konzept-Synonym-Erweiterung (supplier bis vendor.company_name), Nachschlagen in Referenztabellen, Beschreibungs-Scans. Werte werden bei der Übertragung normalisiert: Daten auf YYYY/MM/DD, Zahlen auf zwei Nachkommastellen, Strings getrimmt. Über die Registry aufgelöste Zellen werden mit null abgerechnet.

Phase 2 · Agent. Ein Agent prüft das Lückenmuster im Raster und erzeugt eine typisierte Strategie: compute (berechnet aus vorhandenen Werten über einen sicheren Ausdrucksauswerter, niemals eval()), transfer (kopiert aus einem semantisch gleichwertigen Feld), extract (liest die Quelle mit spezifischen Anweisungen erneut, in Fünferbatches), skip (mit seiner Begründung).

Phase 3 · Validierung. Feldübergreifende Plausibilitätsprüfungen: Datumsreihenfolge, Betrag gegen Laufzeit, fehlgeschlagene Lookups, Ausreißer mit niedriger Konfidenz, unerwartet leere Felder. Flags sind informativ. Sie blockieren die Ausgabe nie und ordnen die Prüfwarteschlange.

Phase 4 · Gezieltes erneutes Lesen. Für jede leere Zelle oder Zelle mit geringer Konfidenz liest das System das Originaldokument mit der spezifischen Feldanweisung und dem gesamten Raster als Kontext erneut. Es erfasst regelmäßig Werte, die frühere Phasen übersehen haben.

Das Konfidenz-Gate. Sobald eine Zelle mit einer Konfidenz von 0.7 oder höher gefüllt ist, kann keine spätere Phase sie überschreiben. Ein Referenzabgleich mit einer Konfidenz von 0.95 in Phase 1 wird nie durch eine Extraktion mit einer Konfidenz von 0.65 in Phase 4 ersetzt. Die früheste zuverlässige Antwort gewinnt.

Eine Regel beginnt als Satz. Jemand tippt, was er meint, in eigenen Worten: eine Laufzeit, die endet, bevor sie beginnt, eine Verlängerung ohne Kündigungsfrist, ein vereinbarter Beitrag ohne zugehörigen Betrag. Talonic kompiliert den Satz in eine Prüfung mit einem benannten Gegenstand, den Feldern, die sie liest, und der Bedingung, die fehlschlägt. Der Satz bleibt erhalten. Er ist das, was ein Prüfer liest, wenn die Prüfung ausgelöst wird.

Jede Regel legt ihre Wirkung fest. Bei Halten stoppt der Datensatz und wartet auf einen Menschen. Bei Kennzeichnen gelangt der Wert mit einer Markierung in die gelieferten Daten. Bei Protokollieren existiert das Ergebnis nur im Ledger. Eine Regel liefert eines von vier Ergebnissen: bestanden, fehlgeschlagen, nicht zutreffend oder unbestimmt, wenn eine benötigte Eingabe fehlte. Eine fehlende Eingabe zählt nie als Bestehen oder Fehlschlag.

Freigabe-Gates sind spezifikationsgemäße Schwellenwertregeln: Mindestkonfidenz, Validierungs-Erfolgsquote, Feldabdeckung. Ergebnisse, die jeden Schwellenwert erfüllen, geben sich selbst frei und lösen die Auslieferung aus. Ergebnisse, die das nicht tun, gehen in eine Prüfwarteschlange, in der ein zurückgehaltener Datensatz mit der Regel ankommt, dem Satz, den ihr Autor geschrieben hat, dem Wert, der fehlgeschlagen ist, und der Seite, von der er stammt. Das gleiche result.approved Signal löst auf beiden Pfaden aus, sodass nachgelagerte Systeme nie wissen, welchen Weg ein Datensatz genommen hat.

Golden Samples, Referenzsätze mit bekannt korrekten Werten, treiben Benchmark-Läufe an. Jeder Lauf wird pro Feld von einem KI-Gutachter bewertet, wobei ein Mensch die Möglichkeit zum Eingreifen hat. So kam Bridgeway zu einer Messung statt eines Versprechens: 96 Prozent gegenüber den 78 des bisherigen OCR-Anbieters, auf denselben manuell annotierten Dokumenten, nach derselben Methode bewertet.

Identitäts-, Transaktions- und Referenzschlüssel verknüpfen zusammengehörige Dokumente zu Fällen. Das System findet sie. Sie prüfen sie. Die Arbeitseinheit ist nicht das Dokument. Es ist der Fall.

Die meisten Unternehmens-Workflows laufen nicht mit einzelnen Dokumenten. Sie laufen mit Bündeln. Ein Lieferanten-Onboarding besteht aus einem Vertrag plus einem W-9 plus einer Versicherungsbescheinigung plus einem Bankformular. Eine Sendung besteht aus einem Frachtbrief plus einer Zollanmeldung plus einer Packliste. Ein Vertrag besteht oft aus sechs Dokumenten: dem Rahmenvertrag, den Nachträgen und den Schreiben, die sie ersetzen.

Talonic identifiziert gemeinsame Entitäten über Dokumente hinweg (Namen, Vertragsnummern, Projektcodes, Transaktionsreferenzen) und gruppiert zusammengehörige Dokumente zu Fällen. Verknüpfungsschlüssel werden klassifiziert als Identität (Entitätsnamen), Transaktion (Nummern) oder Referenz (andere gemeinsame IDs). Entitäten, die in mehr als 30 Prozent der Dokumente vorkommen, werden von der Fallbildung ausgeschlossen, sodass eine gemeinsame Bank oder eine gemeinsame Stadt nie alles mit allem verknüpft.

Jeder Fall zeigt die beteiligten Dokumente, die gemeinsamen Entitäten, die sie verbunden haben, die Beweiskette (welche Felder welche Verbindungen erzeugt haben), eine Zeitleiste und eine KI-Erzählung dessen, was der Fall zu sein scheint. Fallvorlagen werden erkannt, nachdem sich drei oder mehr Fälle um dasselbe Dokumenttyp-Muster gebildet haben.

Das Lesen zeigt Ihnen, was im Dokument steht. Der Abgleich zeigt Ihnen, was damit zu tun ist. Talonic gleicht extrahierte Daten mit Referenzdatensätzen ab: Ihrer Frachtführerliste, Ihrem Lieferantenstamm, Ihrem Kontenplan, Ihren offenen Sendungen.

Vier Strategien werden zu gewichteten Werten kombiniert. exact ist ein Zeichenkettenabgleich ohne Berücksichtigung der Groß- und Kleinschreibung. fuzzy ist eine tokenbasierte Ähnlichkeit mit einem konfigurierbaren Schwellenwert. date_range gleicht Daten innerhalb eines Toleranzfensters ab. numeric_range gleicht Zahlen innerhalb einer prozentualen oder absoluten Toleranz ab. Das System kann anhand der Spezifikation und der Referenzstruktur eine Strategie vorschlagen, die eine Person bestätigt.

Die Ergebnisse zeigen die fünf besten Kandidaten pro Dokument mit Belegen auf Feldebene: welche Strategien ausgelöst wurden, was jede davon beigetragen hat, woher der Wert stammt. Eine Referenztabelle mit einer korrekt geladenen Lieferantenliste liefert bei einem einzigen Durchlauf typischerweise 90 bis 100 Prozent korrekte Treffer. Bridgeway führt dies gegen sieben- bis zehntausend offene Sendungen aus, und das System enthält sich, wenn es sich nicht sicher ist.

Signal, Binding, Resolver, Serializer, Connector. Jeder Versuch wird protokolliert. Jeder Fehler ist wiederholbar. Nur anfügbare Historie, Idempotenzschlüssel bei der Übertragung, eine Dead-Letter-Queue, die Sie leeren können. Liefern Sie nach Dynamics, Ivalua, Salesforce, in ein Data Warehouse oder direkt in das Arbeitsgedächtnis eines Agenten: dieselbe typisierte Pipeline, dieselbe Signierung, dieselbe Wiederholung.

Die Ausgabe durchläuft eine fünfstufige Zustellungspipeline. Jede Stufe ist typisiert und beobachtbar.

Signal. Ein Producer sendet ein typisiertes Ereignis, document.extracted, result.approved, run.structuring.completed, in die Outbox. Producer sind zustandslos. Sie veröffentlichen nur.

Binding. Ein Poller leert die Outbox und gleicht jedes Ereignis mit aktiven Bindings ab. Ein Binding verknüpft einen Signalfilter mit einem Zustellobjekttyp, einem Ziel und einem Serializer. Die Binding-Auswahl prüft beim Erstellen, ob alle vier ein kompatibles Dreieck bilden, sodass Fehlkonfigurationen deutlich scheitern statt unbemerkt zu bleiben.

Resolver. Der Zustellobjekt-Resolver lädt zum Zeitpunkt der Zustellung den tatsächlichen Payload (Dokumentmetadaten, einen Datensatz-Snapshot, einen Extraktionslauf) unter ausschließlicher Verwendung von Entitäts-IDs aus dem Signal. Zustandslose Abfrage bei jeder Zustellung, sodass kein zwischengespeicherter Payload veraltet.

Serializer. Kodiert die Payload als json, ndjson, csv, csv_file, xlsx, rows, graph, raw, md oder txt. Ein optionales field_map benennt Felder um, entfernt Felder oder fügt statische Werte ein, ohne Code zu schreiben.

Connector. Sendet die kodierten Bytes durch den TransportWrapper: SSRF-Schutz, Payload-Obergrenze, Rate Limit, Retry-Staffelung. Die Standardstaffelung umfasst sieben Versuche über etwa zehn Stunden (0s, 30s, 2min, 8min, 30min, 2h, 8h), pro Binding überschreibbar. Webhooks werden mit HMAC-SHA256 signiert und enthalten in ihren Headern einen Idempotenzschlüssel, einen Versuchszähler und eine Ereignis-ID. Der Zielkatalog umfasst Webhook, SFTP, Amazon S3, Azure Blob, Google Drive, Google Sheets, OneDrive, SharePoint, Gmail und Outlook.

Jeder Versuch wird protokolliert in delivery_items. Endgültige Fehler eskalieren zu delivery_dead_letter. Beide sind wiederholbar; eine Wiederholung reiht einen neuen Versuch mit einem neuen Idempotenzschlüssel ein. Das Verlaufsprotokoll ist strikt nur anfügbar.

Retrieval liest bei jeder Frage den gesamten Korpus erneut, verbraucht erneut Tokens und kann morgen anders antworten. Eine Datenbank antwortet einmal, immer gleich, mit einer Zeilennummer.

Drei Wege hinein. POST /v1/documents/filter liefert typisierte Zeilen über materialisierte Feldwerte, ohne Modellaufruf. POST /v1/ask nimmt eine Frage in natürlicher Sprache entgegen, plant über die Feldebene, führt schreibgeschütztes SQL über die extrahierten Zellen aus, liest bei Bedarf zur Abfragezeit ein fehlendes Feld nach und verankert jede tragende Aussage in einer exakten Quellstelle. Der MCP-Server stellt Claude, Cursor oder jedem MCP-Client dieselbe Oberfläche bereit.

A scope kompiliert bei jeder Anfrage zu einem gebundenen SQL-Prädikat, das auf jeder Retrieval-Ebene angewendet wird: diese Dokumente, diese Spezifikation, diese Pipeline, nichts sonst. Das ist die Grundlage, auf der die Agenten im nächsten Abschnitt aufbauen.

Geben Sie einem Agenten genau das: diese Verträge, diese Referenztabelle, nichts sonst. Er fragt die Datenbank ab, jeder Lesezugriff wird protokolliert, jede Antwort trägt ihre Quelle. Sie entscheiden, was er sieht. Sie können belegen, was er gesehen hat.

Drei laufen heute produktiv bei Kunden. Jeder liest nur, wofür er freigegeben wurde, entscheidet nach Regeln, die eine Person in ihren eigenen Worten geschrieben hat, und schreibt jede Entscheidung in einen Datensatz, den niemand bearbeiten kann. Der Status ist das eigene Vokabular des Produkts, vier Wörter und keine Adjektive: running, shadow run, on request, authored.

367 Endpoints über 46 Namespaces: eine typisierte REST-Oberfläche für Produktionsintegrationen und Agentenzugriff gleichermaßen. Jede Primitive auf dieser Seite verfügt über Endpoints. /v1/extract für synchrone und asynchrone Lesevorgänge, /v1/ask für zitierte Antworten, /v1/documents/filter für typisierte Zeilen, /v1/schemas für Spezifikationen, /v1/structuring/gates für Freigabe-Gates, /v1/cases, /v1/matching, /v1/data-products, /v1/delivery für die gesamte Auslieferungsoberfläche, und /v1/credits für Kosten.

API-Schlüssel beginnen mit dem Präfix tlnc_, übergeben als Authorization: Bearer, und im Ruhezustand SHA-256-gehasht; der vollständige Schlüssel wird einmal angezeigt, bei der Erstellung. Sechs Scopes: extract, read, write und operations standardmäßig, billing und delivery explizit hinzugefügt. Eine Anfrage außerhalb des Scopes eines Schlüssels liefert 403 mit insufficient_scope und dem benötigten Scope. List-Endpoints paginieren per Cursor. Jeder Write-Endpoint berücksichtigt einen Idempotency-Key.

Dieselbe Oberfläche wird auch als Node SDK und als MCP-Server ausgeliefert: elf Tools und zwei Resources, gelistet in der offiziellen MCP Registry, lokal über stdio ausgeführt oder unter mcp.talonic.com mit OAuth gehostet, sodass Claude.ai überhaupt keinen Schlüssel benötigt. Jede Antwort enthält typisierte Felder, Konfidenz und Herkunft, und jeder synchrone Lesevorgang liefert seine Kosten in den Headern zurück.

Wir sind langsamer am Start als Anbieter, die zuerst parsen, und nicht immer die günstigsten pro Seite. Beim numerischen Lesen mit einer Frage pro Dokument liegen strukturbasierte Ansätze und Retrieval in unseren eigenen Tests gleichauf, das sagt auch die Benchmark-Seite. Was Sie für den langsameren Start bekommen, ist ein System, das sich aufbaut, prüft, validiert und liefert, statt eines, das Text zurückgibt und dann stoppt.

Wenn Sie den schnellsten Weg von PDF zu JSON suchen, ohne Vorstellung von einer Datenbank oder Kumulierung, ist Reducto hervorragend. Wenn Sie die Datenbank hinter Ihrem Enterprise-Dokumenten-Workflow suchen, sind wir das.