FIDIC.uz: ein Betriebssystem für Vertragswissen gestalten
Zurück
RESEARCH / 2026

FIDIC.uz: ein Betriebssystem für Vertragswissen gestalten

Die Aufgabe war keine weitere Broschüre, sondern eine navigierbare professionelle Plattform für dichtes Infrastruktur-Vertragswissen.

01

Content als Produktarchitektur

Vertragsbücher, Klauseln, Glossarbegriffe, Zertifizierungsmaterial und Fachartikel brauchen je eigene User Journeys bei einem gemeinsamen Wissensmodell. Die Datenebene ist typisiertes TypeScript statt eines CMS: Jede Klausel, jeder Begriff und jede Testfrage hält alle drei Sprachvarianten in der eigenen Struktur — eine fehlende Übersetzung bricht den Build, statt eine halbleere Seite auszuliefern. 117 Artikel, 27 aufgeschlüsselte Klauseln und 26 Glossarbegriffe liegen auf diesem Modell.

02

Werkzeuge statt nur Lesestoff

Das Unterscheidende sind nicht die Artikel, sondern sechzehn funktionierende Werkzeuge, die rechnen statt beschreiben: die 28-Tage-Frist nach Sub-Clause 20.2, EOT- und Delay-Modelle, Vertragsstrafen gegen die Obergrenze, Interim Payment nach Clause 14, DAAB-Verfahrensfristen, ein Claim-Readiness-Fragebogen mit Punktwertung über zwölf Kontrollpunkte. Alle Berechnungen laufen im Browser — nichts, was ein Nutzer über einen laufenden Streit eingibt, verlässt sein Gerät.

03

Eine Datenebene, die sich selbst pflegt

Ein täglicher Job führt Ausschreibungen der Weltbank zu einem kumulativen Archiv von mehr als 2.900 Einträgen aus acht Ländern zusammen, zurück bis 2019. Die Quell-API liefert immer nur ein gleitendes Fenster — eine herausgefallene Ausschreibung ist endgültig weg. Deshalb führt die Pipeline zusammen statt zu überschreiben und endet bei einem Ausfall mit Fehlercode, statt still einen leeren Snapshot zu speichern. Jeder Bot-Commit trägt den Stand offener zu gesamter Ausschreibungen — der Zustand des Archivs ist allein aus dem Git-Log ablesbar.

04

Search auf Plattformniveau

429 statische Seiten brauchen eine Struktur, mit der ein Crawler umgehen kann: stabile Routen mit einer einzigen Trailing-Slash-Regel, überall ein Canonical, vollständige hreflang-Cluster und zweiunddreißig verschiedene schema.org-Typen, die beschreiben, was eine Seite wirklich ist. Eine bewusste Ausnahme ist dokumentiert: Eine georgische Landingpage bleibt absichtlich außerhalb des Drei-Sprachen-Clusters, damit sie kein widersprüchliches Signal darüber sendet, welche Version wem dient.

05

Vertrauen, das prüfbar sein muss

Schulungszertifikate werden per CLI-Skript in ein versioniertes Register mit QR-Code eingetragen, prüfen kann sie jeder auf einer öffentlichen Seite. Zertifikatsseiten sind zwingend noindex, damit personenbezogene Daten nie in Suchergebnisse geraten, und die Prüfung bleibt unabhängig vom Rest der Website erreichbar — wer ein Dokument hält, sollte für den Nachweis nicht vom Veröffentlichungsstatus des Portals abhängen.

06

Performance als Redaktionsentscheidung

Vier Three.js-Szenen, Smooth Scroll und ein eigener Cursor gingen live und wurden dann gemessen. Smooth Scroll fiel auf Mobilgeräten weg, weil er LCP kostete; Seiten-CSS wird inline ausgeliefert, damit ein fehlgeschlagener Request keine Seite entkleidet; die Reveal-Logik liegt außerhalb des Build-Bundles, damit Inhalte ein defektes Asset überleben. Die Tender-Tabelle baut sich auf dem Telefon als Karten neu auf. Der größte Teil des Engineerings war Weglassen.

07

Solo-Auslieferung mit AI-Assistenz

Creative Direction, Scope und finale Abnahme blieben menschlich — bei Fachinhalten ist das keine Vorliebe, sondern Voraussetzung: Ein generierter Absatz über eine FIDIC-Klausel klingt genauso überzeugt, wenn er falsch ist. Das Modell liefert den Entwurf, entschieden wird mit Fachwissen. Rund 48.000 Zeilen Code über 2.512 versionierte Dateien, ausgeliefert und gepflegt von einer Person.

PASSENDE LEISTUNGDigital Marketing in Wien, als ein System gebaut.