Zwei Tage zu einem Drittel eines Workflows.

Wie CO2Calc gebaut wurde – und warum die eingefrorene Version existiert.

Diese Fallstudie handelt von einer realen Person, die reale Arbeit auf die harte Tour erledigt, von einem Workflow, der als Software existieren musste, und von einem Zwei-Tage-Build, der genug hervorbrachte, um Fördermittel zu beantragen und eine Methodik zu lehren.

Sie handelt außerdem davon, warum es zwei Versionen der Site gibt – und warum die ältere, kleinere die lehrreichere ist.

Die Person und das Problem

Der Kunde ist Umweltberater der Norwegian Dance Company. Seine Arbeit ist spezifisch und folgenreich: Er plant Tourneen so, dass der CO2-Ausstoß minimiert wird. Jeder Flug, jedes Hotel, jeder Transfer – all das muss abgewogen, entschieden und dokumentiert werden.

Genau an der Dokumentation bricht die Arbeit auseinander.

Jeder Beleg wird manuell gescannt. Jeder Datenpunkt landet per Hand in einer Tabelle. Tickets, Hotelbestätigungen, Transportrechnungen – jedes Dokument verlangt, dass ein Mensch es liest, relevante Zahlen extrahiert und korrekt in das Modell einträgt. Die Tabelle ist groß, die Tourneen sind komplex, und der gesamte Prozess ist langsam, fehleranfällig und unerquicklich für jemanden, dessen eigentliche Kompetenz Umweltstrategie ist und nicht Dateneingabe.

Gewünscht war, den gesamten Workflow so weit wie möglich zu modellieren und zu automatisieren. Ziel: Belege und Rechnungen hinein, CO2-Impact-Daten hinaus – ohne manuelle Transkription dazwischen.

HITM wurde für dieses Projekt nicht nachträglich gewählt. HITM war die Bedingung dafür, dass das Projekt überhaupt übernommen werden konnte.

Warum HITM die Ausgangsbedingung war

Eine Workflow-Automation dieser Art – multimodale Eingabe, n8n-Orchestrierung, mehrsprachiges Interface, strukturierter Datenausgang, ODS-Export für den Handoff – ist nichts, was eine nicht entwickelnde Person normalerweise als Zwei-Tage-Projekt vorschlagen würde. Die technische Oberfläche ist breit, die Integrationspunkte zahlreich, und der Spielraum für stille Fehler groß.

Vorschlagbar wurde das Projekt, weil HITM die Frage „Was muss das System tun?“ sauber von der Frage „Wie tut es das System?“ trennt. Die erste ist eine Produktfrage, beantwortbar aus einem tiefen Verständnis des Kundenworkflows. Die zweite ist eine Implementierungsfrage, delegierbar an KI, solange die Randbedingungen sauber gesetzt sind.

Der Workflow des Kunden war verstanden, bevor die erste Zeile Code entstand. Die beiden Intake-Modi – Tourplan-Daten und Beleg-/Rechnungsverarbeitung – waren als getrennte Systeme mit unterschiedlichen Datenformen definiert, bevor einer der beiden gebaut wurde. Die n8n-Webhook-Architektur stand als Integrationsschicht fest, bevor die Workflows gestaltet wurden. Die Dreisprachigkeit – Englisch, Norwegisch, Deutsch – war Randbedingung der Spezifikation und kein später hinzugefügtes Feature.

Struktur vor Ausführung. Genau das machte den Zwei-Tage-Zeitrahmen möglich.

Was in zwei Tagen gebaut wurde

Der eingefrorene Teaching Snapshot repräsentiert ungefähr ein Drittel des vollständigen Kundenworkflows. Er ist weder Mock-up noch Scheinprototyp. Er ist ein funktionierendes System – deployed, testbar und nachweislich lauffähig –, das den ersten großen Automationsbogen abdeckt.

Die Demo-Oberfläche ist ein dreisprachiges Webinterface mit Sprachumschaltung. Es unterstützt zwei Intake-Modi: Schedule Ingestion für Tourplandaten und Receipt/Invoice Ingestion für Reise- und Unterkunftsdokumente. Ein technisches Operator-Panel übernimmt den Review-Schritt (R05) und den ODS-Export (R08), also jenen Punkt, an dem verarbeitete Daten an die Downstream-Tools des Kunden übergeben werden.

Das Backend-Proxy sitzt zwischen UI und n8n-Workflows, löst CORS sauber und hält den Browser von direktem Kontakt mit den Webhook-Endpunkten fern. Das war eine frühe Architekturentscheidung und nicht etwas, das erst nach einem Produktionsfehler „nachgerüstet“ wurde.

Die n8n-Architektur übernimmt die eigentliche Verarbeitung: Payloads treffen an versionierten Webhook-Endpunkten ein, werden validiert, verarbeitet und liefern strukturierte Antworten zurück. Die Versionierungsdisziplin – /v1-9/, /v2-1/, /v2-2/, /v2-5/ – macht jede Iteration adressierbar. Rollback ist möglich. Paralleles Testen ist möglich. Nichts wird still überschrieben.

Der schwierigste Teil war die Beleg- und Rechnungsverarbeitung. Ein Tourplan ist strukturierte Datenlogik mit relativ vorhersehbarer Form. Ein Beleg ist das Gegenteil. Hotelrechnungen, Flugbestätigungen und Transportdokumente aus verschiedenen Ländern, Airlines und Hotelketten teilen kaum konsistente Struktur. Dieser Intake-Modus musste diese Varianz abfangen, ohne vom Kunden Vor-Normalisierung zu verlangen.

Das gelang nicht in der ersten Session. Es gelang über Iteration, dokumentierte Randbedingungen und klare Freigabepunkte. Genau wie in der editorischen Fallstudie wurde jeder Fehler zur Randbedingung, und jede neue Randbedingung verengte den Raum möglicher Fehlverarbeitung, bis das System verlässlich genug wurde.

Docker-Deployment war von Anfang an Teil der Spezifikation. Das System läuft containerisiert, die Webhook-URLs sind über Umgebungsvariablen konfigurierbar. Damit kann derselbe Build lokal, im Staging und in Produktion laufen, ohne Codeänderungen. Auch das ist eine Architekturentscheidung, kein späterer Betriebszusatz.

Warum es zwei Versionen der Site gibt

CO2Calc existiert in zwei Zuständen: als eingefrorener Teaching Snapshot und als live weiterentwickelte Version.

Der eingefrorene Snapshot ist der Zwei-Tage-Build. Er zeigt das System an dem Punkt, an dem es lehrbar wurde: Die Architektur ist lesbar, die Entscheidungen sind dokumentiert, die Randbedingungen sind sichtbar. Diese Version beschreibt die Fallstudie.

Die Live-Version ist weiter fortgeschritten. Die Receipt-Intake- und Verarbeitungsstrecke funktioniert vollständig, weitere Workflow-Stufen sind hinzugekommen, und das System hat sich dem vollständigen Kundenworkflow angenähert.

Der eingefrorene Stand bleibt erhalten, weil ein lebendiger, wachsender Codebestand ein schlechtes Lehrartefakt ist. Er verändert sich. Frühe Architekturentscheidungen verschwinden unter späteren Erweiterungen. Jene Momente, in denen die Methodik zu einem klaren strukturellen Ergebnis geführt hat, werden in einem weiterwachsenden Produkt zunehmend schwerer zu isolieren.

Der Snapshot hält diese Momente still. Er ist die Version, die man jemandem geben kann, der HITM lernen will, und sagen: Hier ist ein echter Build, an dem die Architektur am klarsten lesbar ist. Das ist es, was zwei Tage strukturiertes Bauen hervorbringen.

Was als Nächstes kommt

Der eingefrorene Snapshot ist die Grundlage für einen Förderantrag bei NLNet, jener europäischen Stiftung, die Open-Source- und Public-Benefit-Infrastruktur finanziert. Der Antrag wird gemeinsam mit dem Kunden gestellt.

Die Förderung würde für Hardening, Testing und Server-Infrastruktur genutzt. Langfristig ist geplant, eine NGO aufzubauen, die das Open-Source-Repository pflegt und erweitert. Ziel ist ein wiederverwendbares, offen lizenziertes Workflow-Automations-Framework für Umwelt-Impact-Tracking, anpassbar für weitere Kunden mit ähnlichen Dokumentationslasten.

Parallel dazu gibt es einen kommerziellen Pfad: angepasste Versionen des Workflows für Kunden, die dieselbe Automation für Tourneen, Logistik oder Eventbetrieb brauchen, ohne selbst ein Open-Source-Tool warten zu wollen.

CO2Calc ist gleichzeitig Kundendeliverable, Lehrartefakt, Förderantrag und Keim eines Open-Source-Projekts. Es ist das strukturell komplexeste Projekt im JBA-Fallstudienportfolio – und seine lehrbare Form wurde in zwei Tagen begonnen.

Was diese Fallstudie demonstriert

HITM macht Vorschläge möglich, die sonst unvorschlagbar wären. Eine nicht entwickelnde Person kann ein multi-systemisches Workflow-Automationsprojekt auf engem Zeitrahmen für einen realen Kunden nur dann glaubwürdig annehmen, wenn Produkt- und Implementierungsentscheidungen sauber getrennt bleiben. HITM macht diese Trennung vor dem Build explizit.

Versionierte Webhook-Endpunkte sind eine Architekturentscheidung, keine Namenskonvention. Die /v1-9/- und /v2-1/-Struktur spiegelt dieselbe Disziplin wie die eingefrorene und die lebendige Site-Version: Der Systemzustand an jedem relevanten Punkt bleibt adressierbar und erhalten. Nichts wird still überschrieben.

Das schwierigste Problem war der unregelmäßigste Input. Tourpläne haben vorhersehbare Form. Belege nicht. Gelöst wurde das Problem nicht durch einen „smarteren Parser“, sondern durch eine präzisere Spezifikation, die aus dokumentierten Fehlern gelernt hat.

Ein eingefrorener Teaching Snapshot ist ein Deliverable erster Klasse. Ihn bewusst zu bewahren, statt ihn späterer Entwicklung zu opfern, ist selbst eine HITM-Entscheidung. Er behandelt die Architektur dieses Moments als etwas, das nicht bloß Zwischenstand, sondern Lehrgegenstand ist.

Technische Referenz

Stack: FastAPI-Backend-Proxy, n8n-Workflow-Orchestrierung, schlichtes HTML/CSS/JS-Frontend, Docker-Deployment.

Intake-Modi: Schedule Ingestion für Tourplandaten, Receipt/Invoice Ingestion für Reise- und Unterkunftsdokumente.

Operator-Panel: R05-Review-Schritt, R08-ODS-Export.

API-Endpunkte: /health, /api/config, /api/ingest, /api/receipt/review, /api/receipt/export-ods.

Webhook-Versionierung: getrennte Test- und Produktionsendpunkte pro Workflow-Version, konfigurierbar über Umgebungsvariablen.

Sprachen: Englisch, Norwegisch, Deutsch.

Deployment: Docker-Container, Webhook-URLs über Umgebungsvariablen, lokal wie remote betreibbar.

Live-Versionen:

• eingefrorener Teaching Snapshot: co2calc-lab.schmidtpabst.com
• lebende weiterentwickelte Version: co2calc.schmidtpabst.com

Die Human-in-the-Middle-Methodik ist unter jba.schmidtpabst.com dokumentiert. Weitere Fallstudien: schmidtpabst.com/blog.