Kollege Codex — Ein Digitaler Produktpass in 8 Tagen (Die Theben-Challenge)
Kollege Codex — Ein Digitaler Produktpass in 8 Tagen (Die Theben-Challenge)
Wie aus heterogenen Produktdaten eine belastbare Grundlage für den Digitalen Produktpass wird — und warum wir bei jeder Entscheidung das solide Fundament der schnellen Demo vorgezogen haben.
Heute, am 8. Juli 2026, findet bei Theben in Haigerloch das Finale der "Kollege Codex"-Challenge statt — Teil der Innovationstage Zollernalb, die die IHK Reutlingen seit 2008 in der Region Neckar-Alb ausrichtet.
Theben baut intelligente Gebäudetechnik: KNX- und DALI-Geräte, Präsenzmelder, Zeitschaltuhren. Die Aufgabe, die das Unternehmen stellte, ist deswegen kein akademisches Konstrukt, sondern ein Problem, das heute jedes Produktunternehmen hat.
Das Interessante an dem, was wir gebaut haben, ist nicht die Feature-Liste. Es ist die Reihenfolge der Architekturentscheidungen, die aus einer Wegwerf-Demo eine erweiterbare Plattform gemacht hat. Genau darum geht es in diesem Artikel.
Teams, Jury und Organisatoren der Kollege-Codex-Challenge.
1. Die Aufgabe — und warum sie ausgerechnet jetzt kommt
Die Information, die man braucht, um ein modernes Produkt vollständig zu beschreiben, liegt verstreut: in ERP- und PLM-Systemen, in Datenblättern, Tabellen, Datenbanken und externen Portalen. Unterschiedliche Produktfamilien haben unterschiedliche Attribute und Datenstrukturen. Eine konsistente, vollständige, nachvollziehbare Sicht darauf zu halten, ist schwer — und wird gerade jetzt zum Problem, weil Regulatorik, Compliance und Transparenzanforderungen steigen.
Der Treiber heißt ESPR — die EU-Ökodesign-Verordnung für nachhaltige Produkte. Sie führt den Digitalen Produktpass (DPP) ein: einen maschinenlesbaren Datensatz pro Produkt, abrufbar über einen QR-Code, mit Angaben zu Materialien, Herkunft, Reparierbarkeit und Lebensende. Bis zum 19. Juli 2026 muss die EU-Kommission das DPP-Register bereitstellen; die produktspezifischen delegierten Rechtsakte rollen zwischen 2026 und 2030 aus, jeweils mit rund 18 Monaten bis zur verbindlichen Anwendung. Parallel verschärft der Cyber Resilience Act die Dokumentationspflichten für vernetzte Geräte. Für einen Hersteller wie Theben treffen beide Wellen zusammen.
Die Aufgabe war entsprechend breit: ein skalierbares, erweiterbares Produktinformationssystem — ein Data Warehouse —, das
- ▸Produktdaten aus heterogenen Quellen einsammelt,
- ▸sie in ein gemeinsames, flexibles Datenmodell normalisiert, das mit neuen Vorschriften und Produkttypen mitwachsen kann,
- ▸sie über eine interaktive Web-Oberfläche und eine dokumentierte REST-API durchsuchbar, filterbar, editierbar und visualisierbar macht,
- ▸und als Grundlage für die DPP-Erzeugung dient.
Die Leitprinzipien der Organisatoren: Abstraktion, generisch, informativ, interaktiv. Und eine harte Randbedingung: Das Ergebnis musste eine laufende Anwendung sein — keine bloße Datenbank und kein bloßes Frontend —, als containerisiertes, per Docker Compose deploybares System mit persistenter Speicherung.
Gebaut haben wir das in einem Sprint von acht Tagen, dem 1. bis 8. Juli 2026. Die folgenden vier Entscheidungen haben den Unterschied gemacht.
Das Team im Sprint: acht Tage von der Aufgabe zur lauffähigen Plattform.
2. Semantik vor Schema — Standards als Bausteine, nicht als Wahl
Die erste echte Arbeit war weder UI noch Datenbank. Es war die Frage, wie Produktdaten überhaupt beschrieben werden sollen.
Zwei der in der Industrie am weitesten verbreiteten Klassifikationsstandards sind ETIM und ECLASS — längst nicht die einzigen, aber ein naheliegender Ausgangspunkt. Statt uns für einen zu entscheiden, haben wir in der frühen Designphase beide geladen und empirisch gegen die echten Theben-Daten verglichen. Das Ergebnis war aufschlussreich: ETIM (rund 5.700 Klassen mit reichen Merkmalsvorlagen) war die stärkere Quelle für Wertevorlagen — welche Felder ein Produkt tragen sollte. ECLASS (rund 63.700 Klassen, im frei verfügbaren Datensatz aber attributarm) war die bessere Klassifikationstaxonomie.
Die entscheidende Konsequenz war nicht "welcher gewinnt", sondern eine Ebene höher: Ein Standard wurde in der Plattform zu einem austauschbaren Baustein. ETIM und ECLASS sind lediglich die ersten beiden, die wir registriert haben — nicht fest verdrahtet, sondern Einträge in einem dynamischen System, das beliebig viele weitere aufnehmen kann. Ein Produkt kann in ETIM und ECLASS gleichzeitig klassifiziert sein; einzelne Eigenschaftswerte referenzieren den einen oder den anderen — auf Datenbankebene mit einer XOR-Check-Constraint erzwungen, damit ein Wert nie in beiden Welten gleichzeitig hängt.
Die Lektion: Wer die semantischen Optionen früh im Code ausprobiert statt sie am Whiteboard zu entscheiden, findet nicht nur die richtige Antwort auf die gestellte Frage — er findet die bessere Frage. In unserem Fall war das nicht "ETIM oder ECLASS", sondern "wie mache ich beliebige Standards steckbar".
3. Die eigene Datenbank als Wahrheit — BaSyx nur als veröffentlichtes Read-Model
Die folgenschwerste Entscheidung fiel im DPP-Subsystem.
Ein etabliertes, interoperables Format für einen Digitalen Produktpass ist die Asset Administration Shell (AAS) — die Verwaltungsschale des Industrial Digital Twin und für unseren Fall die naheliegende Wahl. Und mit Eclipse BaSyx existiert eine fertige AAS-Laufzeitumgebung. Die naheliegende Abkürzung wäre gewesen, BaSyx zum Backend zu machen — dann hätte man den Standard "geschenkt".
Wir haben bewusst das Gegenteil getan. Unser Architecture Decision Record beschreibt es als Trennung von "DPP-Fabrik" und "AAS-Runtime":
- ▸Die eigene PostgreSQL-Datenbank ist die Autoren-Wahrheit (Source of Truth): Produkte, Behauptungen (Claims), Belege (Evidence), Review-Status und unveränderliche veröffentlichte Snapshots liegen alle dort.
- ▸BaSyx ist nur eine veröffentlichte, lesende Laufzeit: Es empfängt geprüfte, versionierte AAS-Snapshots über seine HTTP-API und wird niemals direkt beschrieben.
- ▸Ein Resolver besitzt die stabile öffentliche DPP-URL, sodass QR-Codes auf die Anwendung zeigen und nicht auf BaSyx-Interna.
Der Grund ist Beständigkeit und Kontrolle. Das Autoren-System bleibt ein veränderlicher Workflow; die Veröffentlichung erzeugt unveränderliche, gehashte Snapshots — mit Rücklese-Verifikation gegen BaSyx, damit veröffentlicht wirklich heißt, was drinsteht. BaSyx bleibt austauschbar. Und, entscheidend: Ein BaSyx-Ausfall blockiert das Veröffentlichen, nicht das Editieren. Das ist der Unterschied zwischen einer Demo, die an einem Server hängt, und einem System, in dem das interoperable Format ein Exportziel ist — nicht die Datenbank selbst.
4. Modularität durch Kataloge und DPP-Profile
Der Baustein-Gedanke aus Abschnitt 2 zieht sich durch die ganze Plattform. Jedes Datenvokabular — ETIM, ECLASS und die AAS-Teilmodelle (Nameplate, Technical Data, Product Carbon Footprint, Materials, Bill of Materials, Handover Documentation, das IDTA-02099-DPP-Teilmodell) — ist als steckbarer "Standard" mit einer katalog-gestützten Eigenschaftsvorlage modelliert. Ein neues Teilmodell aufzunehmen ist eine Daten- und Registrierungsaufgabe, kein Umbau. In der Commit-Historie sieht man das als stetiges Anwachsen von Teilmodell-Standards statt als Monolith.
Darüber liegen DPP-Profile — etwa ein generisches, ESPR-orientiertes und ein pragmatisches Theben-spezifisches. Ein Profil erklärt, welche Claims für einen bestimmten Passtyp verpflichtend, empfohlen oder optional sind, und auf welcher Zugriffsebene (öffentlich / Behörde / Reparateur / Recycler).
Der Clou: Profile entkoppeln "welche Daten es geben kann" (Kataloge) von "was ein konformer Pass enthalten muss" (Anforderungen). So kann sich der regulatorische Umfang weiterentwickeln, ohne das Datenmodell anzufassen — genau die Eigenschaft, die man braucht, wenn zwischen 2026 und 2030 im Halbjahrestakt neue delegierte Rechtsakte erscheinen.
Der AAS-Assembler projiziert einen Snapshot schließlich in eine AAS pro Produkt mit mehreren Teilmodellen (nicht eine Schale pro Teilmodell) — treu zu den IDTA-Vorlagen und den AAS-Constraints.
5. KI-gestützte Erfassung — menschlich kontrolliert und belegt
Eine der Schwierigkeiten ist, die unordentlichen Quelldokumente überhaupt in dieses saubere Modell zu bekommen. Genau dafür ist die jüngste Schicht da: ein KI-Erfassungsassistent, den wir — in Anlehnung an die Challenge selbst — "Kollege Codex" getauft haben.
Die bewusste Designentscheidung: Statt eine maßgeschneiderte Extraktions-Pipeline zu bauen, nutzt der Assistent eine gemeinsame Werkzeugoberfläche für den Agenten:
- ▸hierarchische Katalognavigation — Sektoren durchsuchen, Kandidaten eingrenzen, vergleichen und nur die Finalisten vollständig lesen, um im Token-Budget zu bleiben,
- ▸Lesen von Sitzungsdateien (die hochgeladenen Datenblätter, Tabellen, PDFs),
- ▸Websuche.
Dieselben Werkzeuge treiben sowohl die Klassifizieren- und Ausfüllen-Buttons des Assistenten als auch den freien Chat. Ein Werkzeugsatz, zwei Bedienoberflächen.
Zwei Leitplanken definieren das Ganze:
- ▸Die KI schreibt immer nur Entwürfe — vorgeschlagene Klassifikationen und Werte, niemals das finale Produkt. Ein Mensch prüft und committet.
- ▸Werte sind belegt — jeder Claim trägt sein Quelldokument und einen Konfidenzwert, nicht bloß eine Modellbehauptung.
6. Ein Blick in die Anwendung
Die Architektur aus den vorigen Abschnitten wird erst in der laufenden Anwendung greifbar. Ein kurzer Rundgang — von der Produktdatenbank über den KI-gestützten Erfassungs-Wizard bis zum veröffentlichten Produktpass in der AAS-Laufzeit:
1 / 6Unter der Oberfläche läuft alles durchgängig per Docker Compose: ein FastAPI-Backend mit PostgreSQL 17, ein Frontend aus Next.js 16 / React 19 / Tailwind / shadcn mit 3D-Produktgraph und 7-stufigem Wizard, Eclipse BaSyx als AAS-Laufzeit und der eingebettete Agent auf dem Codex App Server. Als Testdaten dienten echte Theben-Geräte: DALI-Gateways und KNX-Präsenzmelder wie thePixa und die SELEKTA-Zeitschaltuhren.
Fazit
Vier Entscheidungen, ein Prinzip: nicht die schnellste Demo, sondern das tragfähigste Fundament. Standards als Bausteine statt einer festen Wahl. Ein eigenes Datenmodell statt der Abhängigkeit von einem fremden Server. Steckbare Kataloge und Profile statt fest verdrahteter Felder. Und eine KI, die vorschlägt, während der Mensch entscheidet.
Diese Reihenfolge ist kein Zufall — jede Schicht ruht auf einer belastbaren darunter. Wer bei der Semantik anfängt und Interoperabilität als Exportziel behandelt statt als Datenbank, baut etwas, das den nächsten delegierten Rechtsakt übersteht, nicht nur die Vorführung am Finaltag.
Denn genau darum geht es beim Digitalen Produktpass: nicht um ein hübsches Interface, sondern um eine Quelle, der Behörden, Reparaturbetriebe und Recycler vertrauen können. Dass acht Tage genügen, um dafür ein ehrliches Fundament zu legen, hat uns die Theben-Challenge gezeigt — und uns den ersten Platz gebracht.
Der Moment der Entscheidung — Applaus bei der Siegerehrung.