Was Ihnen 30 Minuten mit Talonic zeigen würden.

Talonic akzeptiert 25+ Dateiformate über drei Verarbeitungswege. Reine Textformate: TXT, MD, HTML, XML, JSON, EML, CSV, werden direkt gelesen, ohne externe API-Aufrufe. Bildformate: PNG, JPG, GIF, WEBP, laufen über AI Vision zur visuellen Extraktion. Dokumentformate: PDF, DOCX, PPTX, XLSX, MSG, BMP, durchlaufen die OCR-Pipeline und entstehen als strukturiertes Markdown. ZIP-Archive werden rekursiv entpackt; die Ordnerstruktur bleibt 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 automatisch anhand einer 529-Typen-Ontologie klassifiziert. Der Klassifizierer arbeitet sprachübergreifend: Ein deutscher Arbeitsvertrag und ein englischer Employment Contract lösen sich zum selben kanonischen Typ auf. Dokumente, die keinem bekannten Typ entsprechen, landen in Unclassified statt zu scheitern: Die Registry erweitert sich, sobald neue Typen in Produktivumgebungen auftauchen.

Jedes in jedem Dokument entdeckte Feld löst sich in ein einheitliches kanonisches Registry auf. Felder organisieren sich in drei Stufen nach Häufigkeit. Tier-1-Felder sind Kernfelder: universell über viele Dokumenttypen hinweg, am zuverlässigsten. Tier 2 sind etabliert: befördert aus Tier 3, nachdem Häufigkeitsschwellen erreicht wurden. Tier 3 sind aufkommend: neu entdeckt, Kandidaten für eine Beförderung, sobald mehr Daten eintreffen.

Felder mit ähnlicher Bedeutung clustern automatisch mittels AI-Embeddings. Vendor Name, Supplier Name, und Company Name lösen sich zum selben Kanonischen auf, wobei die Quellvarianten als Aliase erhalten bleiben. Da dasselbe Feld aus vielen Dokumenten extrahiert wird, synthetisiert AI eine Master-Extraktionsanweisung: eine wiederverwendbare Direktive, die den besten Weg zur Extraktion dieses Feldes erfasst. Master-Anweisungen verbessern die Genauigkeit bei jedem weiteren Durchlauf.

Das Registry ist das Bindegewebe zwischen Erfassung und Auslieferung. Sobald ein Dokument, ein Fall oder ein Datensatz in den Field Graph strukturiert ist, bleibt er über jede Schema-Weiterentwicklung hinweg abfragbar: unbegrenzt.

Schemas definieren die Struktur Ihres Outputs. Es gibt zwei Arten. Generierte Schemas werden automatisch pro Dokumenttyp aus Tier-1- und Tier-2-Registry-Feldern erzeugt. Benutzervorlagen werden für spezifische Output-Anforderungen definiert: eine Lieferantenvertrag-Vorlage, die auf Ihr Ivalua-Schema zielt, eine Logistik-Vorlage, die auf TMW zielt.

Vorlagen unterstützen ein Workshop-System. Live ist die aktuell veröffentlichte Version, schreibgeschützt. Workshop ist ein veränderbarer Entwurf. Version History ist die vollständige Zeitleiste mit Diff-Zusammenfassungen. Das Befördern eines Entwurfs macht Breaking Changes sichtbar, Feldentfernungen, Typänderungen, bevor sie live gehen. Ein Test-Extraktionstool führt den Entwurf gegen eine Stichprobe von Dokumenten aus und zeigt Entwurf-gegen-Live-Ergebnisse nebeneinander, sodass die Auswirkung einer Schema-Änderung vor der Veröffentlichung sichtbar ist.

Jedes Feld unterstützt Formatbeschränkungen (Regex-Validierung), Modifikatoren (Datums- und Zahlenformatierung, Wertzuordnung, Kürzung), Constraints (Pflichtfeld, Enum, Länge, feldübergreifende Ausdrücke), Bypass-Strategien (konstanter Wert, deterministische ID, Referenztabellen-Lookup) und manuelle Anweisungen, die die Master-Anweisung des Registry überschreiben.

Phase 1 füllt 30% der Zellen aus der Registry: sofort, ohne KI-Aufrufe. Phase 2 schlussfolgert. Phase 3 validiert. Phase 4 füllt die Lücken. Sobald eine Zelle eine Konfidenz von 0.7 erreicht, kann keine spätere Phase sie überschreiben. Jede Zelle zeigt über die API ihre Phase, Konfidenz und Begründungsspur: So können Agenten und nachgelagerte Systeme selbst entscheiden, welchen Werten sie vertrauen.

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

Phase 1: Auflösen. Die schnellste Phase. ~30% der Zellen werden aus bestehenden Graph-Treffern gefüllt, ganz ohne KI-Aufrufe. Direkter Registry-Transfer, unscharfer Namensabgleich, Konzept-Synonym-Erweiterung (supplier → vendor.company_name), Nachschlagen in Referenztabellen, Beschreibungs-Scans. Werte werden beim Transfer normalisiert: Daten auf YYYY/MM/DD, Zahlen auf zwei Dezimalstellen, Strings getrimmt.

Phase 2: Agent. Ein KI-Agent prüft das Lückenmuster im Gitter und erzeugt eine typisierte Strategie: compute (berechnet aus vorhandenen Werten über einen sicheren Expression-Evaluator, niemals eval()), transfer (kopiert aus einem semantisch gleichwertigen Gitterfeld), extract (liest die Quelle mit spezifischen Anweisungen erneut, gebündelt zu 5 gleichzeitig), skip (mit Begründung).

Phase 3: Validierung. Feldübergreifende Plausibilitätsprüfungen. Datumsreihenfolge, Konsistenz zwischen Betrag und Laufzeit, fehlgeschlagene Nachschlagevorgänge, Ausreißer mit niedriger Konfidenz, unerwartet leere Felder. Markierungen sind rein informativ: Sie blockieren nie die Ausgabe, priorisieren aber die Prüfwarteschlange.

Phase 4: Gezieltes erneutes Lesen. Kontextbewusstes Füllen von Lücken. Für jede leere Zelle oder Zelle mit niedriger Konfidenz liest das System das Originaldokument erneut, mit der spezifischen Feldanweisung und dem vollständigen Gitter als Kontext. Findet häufig Werte, die in früheren Phasen übersehen wurden.

Das Konfidenz-Gate. Sobald eine Zelle mit einer Konfidenz ≥ 0.7 gefüllt ist, kann keine spätere Phase sie überschreiben. Diese Regel verhindert, dass ein Referenz-Lookup mit 0.95 Konfidenz aus Phase 1 durch eine Agenten-Extraktion mit 0.65 Konfidenz aus Phase 4 ersetzt wird. Die früheste verlässliche Antwort gewinnt.

Validierungsregeln auf Schema-Ebene laufen als Teil jedes Jobs. Regeltypen umfassen Feldformat-Prüfungen, Wertebereiche, feldübergreifende Konsistenz und von der KI vorgeschlagene Kohärenzregeln, die automatisch nach Abschluss eines Jobs vorgeschlagen und vor Aktivierung von einem Menschen geprüft werden. Kein KI-Vorschlag geht ohne ausdrückliche Freigabe live.

Golden Samples, manuell erstellte Referenzdatensätze mit bekannt korrekten Werten, treiben Benchmark-Läufe an. Jeder Benchmark-Lauf vergleicht Extraktionsergebnisse pro Feld mit Golden Data, wobei ein KI-Gutachter Urteile erstellt und ein Mensch diese überschreiben kann. So steigerte Bridgeway die Genauigkeit über POC-Zyklen hinweg von 75 % auf 92 %: Die Ausgabe jedes Zyklus wurde zum Benchmark des nächsten Zyklus.

Freigabe-Gates sind schwellenwertbasierte Regeln, die automatisch freigeben oder zur manuellen Prüfung weiterleiten. Konfigurierbar pro Schema mit Kriterien wie Mindest-Konfidenz, Validierungs-Erfolgsquote und Feldabdeckung. Ergebnisse, die alle Schwellenwerte erfüllen, werden automatisch freigegeben und lösen die nachgelagerte Zustellung aus. Ergebnisse, die durchfallen, gehen in eine Human-in-the-Loop-Prüfwarteschlange. Das gleiche result.approved Signal löst bei automatischer und manueller Freigabe gleichermaßen aus. Ihre nachgelagerten Systeme wissen nicht, welchen Weg der Datensatz genommen hat.

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, sondern der Fall.

Die meisten Enterprise-Workflows laufen nicht auf einzelnen Dokumenten, sondern auf Bündeln. Ein Vendor-Onboarding besteht aus einem Vertrag plus einem W-9 plus einer Versicherungsbescheinigung plus einem Bankdatenformular. Eine Logistiksendung besteht aus einem Frachtbrief plus einer Zollanmeldung plus einer Packliste. Ein Schadensfall besteht aus einer Police plus einem Schadensbericht plus drei Kostenvoranschlägen.

Talonic identifiziert gemeinsame Entitäten über Dokumente hinweg, wie Namen, Vertragsnummern, Projektcodes, Transaktionsreferenzen, und gruppiert zusammengehörige Dokumente zu Fällen. Verknüpfungsschlüssel werden automatisch klassifiziert als Identity (Entitätsnamen), Transaction (Nummern) oder Reference (andere gemeinsame IDs). Hochfrequente Entitäten, die in mehr als 30 % der Dokumente vorkommen, werden von der Fallbildung ausgeschlossen, um falsche Verknüpfungen zu vermeiden.

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 automatisch generierte KI-Beschreibung dessen, was der Fall zu sein scheint. Fallvorlagen werden automatisch erkannt, sobald drei oder mehr Fälle entstanden sind: Das System identifiziert wiederkehrende Dokumenttyp-Muster.

Extraktion zeigt Ihnen, was im Dokument steht. Matching zeigt Ihnen, was Sie damit tun sollen. Talonic unterstützt Feld-zu-Feld-Matching zwischen extrahierten Daten und Referenzdatensätzen: Ihrer Spediteurliste, Ihrem Lieferantenstamm, Ihrem Kontenplan.

Vier Matching-Strategien kombinieren sich zu gewichteten Scores. exact ist ein case-insensitiver String-Abgleich. fuzzy ist eine tokenbasierte Ähnlichkeit mit konfigurierbarem Schwellenwert. date_range gleicht Daten innerhalb eines konfigurierbaren Toleranzfensters ab. numeric_range gleicht Zahlen innerhalb einer prozentualen oder absoluten Toleranz ab. Die KI-Strategiegenerierung kann Mappings automatisch basierend auf Schema und Referenzstruktur vorschlagen.

Ergebnisse zeigen die Top 5 Kandidaten pro Dokument mit Nachweisen auf Feldebene: welche Strategien ausgelöst haben, was jede beigetragen hat, woher der Score stammt. Eine Referenztabelle mit einer korrekt geladenen Lieferantenliste liefert in einem einzigen Lauf typischerweise 90–100 % genaue Treffer.

Signal → Binding → Resolver → Serializer → Connector. Jeder Versuch wird protokolliert. Jeder Fehler ist wiederholbar. Nur anfügbarer Verlauf, Idempotenzschlüssel auf der Leitung und eine Dead-Letter-Queue, die Sie leeren können. Liefern Sie an Ihre Systeme der Aufzeichnung, Ihr Data Warehouse oder direkt in den Arbeitsspeicher eines Agenten: gleiche typisierte Pipeline, gleiche Signierung, gleiche 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 Deliverable-Typ, einem Ziel und einem Serializer. Der Binding-Picker prüft bei der Erstellung, ob alle vier Teile ein kompatibles Dreieck bilden, sodass Fehlkonfigurationen deutlich sichtbar scheitern statt still zu versagen.

Resolver. Der Deliverable-Resolver lädt die eigentliche Payload, etwa Dokument-Metadaten, einen Record-Snapshot oder einen Extraction-Run, zum Zeitpunkt der Zustellung und verwendet dabei nur Entity-IDs aus dem Signal. Zustandslose Abfrage bei jeder Zustellung, keine zwischengespeicherten Payloads, die veralten.

Serializer. Kodiert die Payload als json, ndjson, csv, csv_file, xlsx, rows, graph, raw, md, oder txt. Ein optionales field_map ermöglicht es, Felder umzubenennen, Felder zu entfernen oder statische Werte einzufügen, ohne Code zu schreiben.

Connector. Sendet die kodierten Bytes durch den TransportWrapper (SSRF-Schutz, Payload-Obergrenze, Rate Limit, Retry-Leiter). Standardleiter: sechs Versuche nach 5s, 30s, 2min, 10min, 1h. Slice-1-Connector ist Webhook mit HMAC-SHA256-Signierung, Idempotenzschlüsseln und einem 30-Sekunden-Timeout. S3, Google Sheets, Drive, SFTP und E-Mail folgen in späteren Slices.

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

Die Plattform stellt eine typisierte REST-API über zwanzig Namespaces bereit, ausgelegt für Produktionsintegrationen und agentengesteuerten Zugriff. Jede Primitive auf dieser Seite hat entsprechende Endpunkte: /v1/extract für synchrone und asynchrone Extraktion, /v1/schemas für Template-Verwaltung, /v1/jobs für Run-Tracking und N-Shot-Vergleiche, /v1/delivery für die gesamte Delivery-Oberfläche, /v1/linking für den Entity-Graph, /v1/cases für Case-Management, /v1/matching für Smart-Matching-Konfigurationen, /v1/quality für Golden Samples und Benchmarks, und mehr.

API-Schlüssel beginnen mit dem Präfix tlnc_live_ (Produktion) oder tlnc_test_ (Sandbox), übergeben als Authorization: Bearer, und im Ruhezustand SHA-256-gehasht. Der vollständige Schlüssel wird nur einmal bei der Erstellung angezeigt. Drei Scopes: extract (nur Extraktions-API), read (Dokumente, Extraktionen, Schemas, Jobs), write (Ressourcen erstellen und ändern). Alle List-Endpunkte verwenden Cursor-Pagination. Idempotency-Key-Header werden bei allen Schreib-Endpunkten berücksichtigt.

Wir sind zu Beginn langsamer als Anbieter, die zuerst aufs Parsen setzen, und pro Seite nicht immer die günstigste Option. Dafür erhalten Sie ein System, das sich aufbaut, prüft, validiert und liefert, statt eines Systems, das nur Text zurückgibt und stehen bleibt.

Wenn Sie den schnellsten Weg von PDF zu JSON suchen, ohne Konzept für Registry oder Kumulierung, ist Reducto ausgezeichnet. Wenn Sie die Schema-Schicht unter Ihrem Enterprise-Dokumenten-Workflow wollen, sind wir die richtige Wahl.