CASE STUDY

Chelaro

Ein lokaler Finanzarbeitsplatz, in dem die KI genau acht typisierte Werkzeuge hat und mit keinem davon einen bestätigten Finanzwert überschreiben kann: Jede Änderung ist ein sichtbarer Vorschlag, den der Owner annimmt oder ablehnt.

Rolle: Produkt, Architektur, Umsetzung und Veröffentlichung
Status: Öffentliche Source Preview, source-available, nicht produktionsreif

Finanzüberblick von Chelaro mit synthetischen Demonstrationsdaten: Einnahmen, Ausgaben, Netto-Cashflow und offene Forderungen — Screenshot der Anwendung mit synthetischen Demonstrationsdaten.

AUSGANGSLAGE

Problem

Wer eine KI an Finanzdaten lässt, hat bisher zwei schlechte Optionen. Entweder das Modell darf schreiben, dann steht irgendwann ein Betrag in der Datenbank, den niemand mehr auf ein Dokument zurückführen kann. Oder es darf nichts, dann spart es auch keine Arbeit. Darunter liegt das ältere Problem der Belegarbeit selbst: Sobald eine Zahl einmal abgetippt ist, ist die Verbindung zu ihrem Original weg.

SO FUNKTIONIERT ES

Lösung & Architektur

Grenze

Acht Werkzeuge, kein Schreibrecht

Das Modell bekommt keinen Shell-, Datei-, Prozess-, Netzwerk- oder Browserzugriff, sondern genau acht typisierte Finanzwerkzeuge über einen isolierten Router. Vier davon lesen. Die anderen vier schreiben nichts, sondern legen einen prüfpflichtigen Vorschlag an, der eine Begründung und die erwartete Version des betroffenen Datensatzes enthalten muss. Stimmt die Version nicht mehr, wird der Vorschlag abgewiesen statt angewendet.

Vier lesende und vier vorschlagende Werkzeuge, jedes mit striktem JSON-Schema
Jeder Vorschlag braucht eine Begründung, sonst wird er nicht angenommen
Änderungen nennen die erwartete Version; ein veralteter Stand läuft in einen Konflikt
Argumente sind auf 16 KiB begrenzt, unbekannte Felder werden abgewiesen

Schematische Darstellung: das KI-Modell erreicht acht typisierte Werkzeuge. Lesezugriffe gehen direkt zu den Finanzdaten, Schreibvorschläge nur über die Prüfung durch den Owner. — Schematische Darstellung, kein Screenshot.

Herkunft

Das Original wird nie überschrieben

Jedes hochgeladene PDF, PNG und JPEG wird unverändert abgelegt und über seinen SHA-256-Hash adressiert; das Format dieses Hashes erzwingt die Datenbank selbst. Alles, was daraus entsteht, ist eine getrennt versionierte Ableitung: extrahierte Werte, Korrekturen, Zuordnungen. Wird eine abgeleitete Zeile entfernt, bleibt das Original bestehen.

Unveränderliche Ablage mit Content Hash und Duplikaterkennung
Abgeleitete Werte ersetzen nie die hochgeladene Datei
Alle gezeigten Belege, Namen und Beträge sind synthetische Demonstrationsdaten

Dokumentenarchiv von Chelaro mit synthetischen Belegen, Content Hash und Statusspalte — Screenshot der Anwendung mit synthetischen Demonstrationsdaten.

Prüfung

Jede Korrektur bleibt sichtbar

Forderungen, Teilzahlungen und das typisierte Rechnungs-Workbook werden nicht überschrieben, sondern versioniert. Eine Stornierung ist ein eigener, sichtbarer Vorgang statt eines stillen Löschens, und jede angenommene wie jede abgelehnte Änderung landet als Eintrag im Audit Ledger. Wer später fragt, warum eine Zahl so aussieht, bekommt die Kette und nicht nur den Endstand.

Versionierte Forderungen mit Teilzahlungen und sichtbarer Korrekturhistorie
Storno statt stillem Löschen
Angenommene und abgelehnte Vorschläge stehen beide im Audit Ledger

Rechnungs-Workbook von Chelaro mit synthetischen Daten, tabellarischen Beträgen und sichtbarer Änderungshistorie — Screenshot der Anwendung mit synthetischen Demonstrationsdaten.

ARCHITEKTUR

Vom Beleg zur Zahl, die man zurückverfolgen kann

Original

PDF, PNG oder JPEG, unverändert mit SHA-256

Vorschlag

Regel oder KI, immer mit Begründung

Prüfung

der Owner nimmt an oder lehnt ab

Version

erwartete Version, sonst Konflikt

Kanonisch

übernommen, mit Eintrag im Audit Ledger

Gesperrt
kein Shell-, Datei-, Prozess-, Netzwerk- oder Browserzugriff für das Modell
Getrennt
eigene Principals für Owner, Agent und Finanzassistent

Öffentliche Source Preview unter PolyForm Noncommercial 1.0.0. Keine Releases, kein Produktivbetrieb.

Vom Originalbeleg zum kanonischen Finanzdatensatz

Ergebnisse

typisierte Finanzwerkzeuge, mehr bekommt das Modell nicht: 8typisierte Finanzwerkzeuge, mehr bekommt das Modell nicht
davon dürfen kanonische Finanzdaten überschreiben: 0davon dürfen kanonische Finanzdaten überschreiben
getrennte Principals: Owner, Agent, Finanzassistent: 3getrennte Principals: Owner, Agent, Finanzassistent
Konflikt statt stiller Überschreibung bei veraltetem Stand: 409Konflikt statt stiller Überschreibung bei veraltetem Stand

NACHWEIS & EINORDNUNG

Was belegt ist – und wo die Aussage endet

Die vier Felder trennen meinen Beitrag, den Projektkontext, die Messgrundlage und die Grenzen der Ergebnisse.

Mein Anteil: Alleiniger Autor: Produktentscheidung, Architektur, Implementierung in allen vier Anwendungen des Monorepos, Marken- und Lizenzstrategie sowie die Veröffentlichung als Source Preview.
Team & Kontext: Einzelprojekt ohne Auftraggeber. Die öffentliche Git-Historie ist ein bewusst zusammengefasster Stand nach einer Secrets- und PII-Prüfung und deshalb kein Maß für Arbeitsumfang oder Dauer. Logo, Hero und Screenshots entstanden in einem Codex-Agent-Workflow; ihre Herkunft ist im Repository mit Hashes dokumentiert.
Messgrundlage: Geprüft ist die Struktur, nicht die Wirkung: acht typisierte Werkzeuge im Werkzeugvertrag, davon vier ausschließlich vorschlagend, 35 Testdateien, lokale Gates grün. Es gibt keine Nutzerzahlen, keine Laufzeitmessung und keine Zeitersparnis, weil das System nicht im Einsatz ist.
Grenzen: Source Preview, nicht produktionsreif. OCR, Transaktionsimport, der Live-FinTS-Adapter, die sichere lokale Credential-Ablage sowie Backup und Restore fehlen; Signierung und Notarisierung sind nicht abgeschlossen, es gibt keine Releases. Die Lizenz ist source-available (PolyForm Noncommercial 1.0.0) und nicht Open Source. Zu GoBD, Revisionssicherheit oder steuerlicher Eignung wird nichts behauptet.

GEBAUT MIT