Datenvalidierung ohne Engineering-Ticket

Wenn Validierungs-Regeln in Code stehen, sind sie an der falschen Stelle. Domänen-Wissen — was ist ein plausibler Treibstoff-Verbrauch, eine plausible Wartezeit, eine plausible Vendor-Bewertung — gehört zu den Personen, die die Domäne kennen. Aber dort sitzt es selten, weil das Werkzeug fehlt.

Warum Regel-Logik im Code festnageln scheitert

Domänen-Drift ist schneller als Release-Zyklen. Luftfahrt-Standards wechseln, Wetlease-Partner kommen mit eigenen Regeln, Compliance-Frameworks bekommen Revisionen, Toleranz-Schwellen ändern sich nach saisonalen Beobachtungen. Wenn jede dieser Anpassungen einen Code-Change, ein Testing, einen Release-Zyklus auslöst, läuft das System dem Geschäft hinterher.

Domänen-Experten und Engineers sprechen verschiedene Sprachen. Eine Person, die weiß, welcher Treibstoff-Verbrauch noch realistisch ist, muss ihre Regel in Tickets formulieren, an einen Engineer schicken, das Ergebnis testen, Feedback geben — und drei Wochen später kommt die Regel in Produktion. Die Wartezeit ist nicht das Problem. Die Übersetzung ist.

Audit-Anforderungen verlangen Nachvollziehbarkeit. Wer hat wann welche Regel geändert, mit welcher Begründung. In klassischer Codebase: über Git-History rekonstruierbar, aber nicht ohne Engineering-Aufwand zu prüfen. In einem deklarativen Regelwerk: Frage von Sekunden.

Wie deklarative Regelwerke das verschieben

Regeln werden Konfiguration, nicht Code. Ein Validierungs-Check wie „Treibstoff-Verbrauch zwischen Quelle A und Quelle B darf maximal 5% abweichen" lebt nicht in einer Java-Klasse, sondern in einem deklarativen Regelwerk-Eintrag. Aktualisierung zur Laufzeit, ohne Deployment.

Domänen-Experten pflegen direkt. Mit einem domänen-fähigen Editor — kein Code, kein Engineering-Ticket — werden Toleranzen, Schwellwerte, Klassifikations-Logik direkt von der Person eingepflegt, die das Domänen-Wissen hat. Engineering bleibt zuständig für die Plattform-Mechanik. Die Regel-Logik liegt bei der Domäne.

Audit-Trail eingebaut. Jede Regel-Änderung ist versioniert, nachvollziehbar, kommentierbar. Die Frage „warum haben wir letzten Mai die Toleranz von 7% auf 5% gesenkt?" hat eine Antwort, nicht nur eine Geschichte.

Test-Mechanik vor Produktion. Eine Regel, die sich auf hunderttausende Datenpunkte auswirkt, will vorher gegen historische Daten getestet werden. Low-Code-Plattformen bringen das mit — Trockenlauf gegen Vergangenheits-Daten, Diff zur aktuellen Regel, dann Aktivierung.

Wo das im Luftfahrt-Betrieb produktiv läuft

Treibstoff-Plausibilisierung. Fünf Datenquellen liefern sechs Aussagen über denselben Wert. Das Regelwerk konsolidiert: welche Quelle ist wann führend, welche Toleranz gilt, wann ist eine Diskrepanz ein Auffälligkeits-Marker. Tausende Flüge pro Tag, ohne dass ein Engineer angesprochen wird.

Wetlease-Partner-Onboarding. Neue Partner liefern Daten in eigenen Formaten und Konventionen. Statt Custom-Code pro Partner: ein Parser-Template plus Validierungs-Regeln werden in Tagen aufgesetzt — von der Person, die die Datenkonvention versteht.

Compliance-Framework-Updates. Eine NIST-Revision oder eine neue NIS-2-Klausel ist eine Konfigurations-Aufgabe, keine Code-Migration. Die Engineering-Plattform bleibt unverändert; die Regel-Schicht ändert sich.

Was vorher Tickets-Backlog war, wird zu eigenständigem Domänen-Engineering. Engineers konzentrieren sich auf Plattform-Themen, Domänen-Experten auf die Domäne. Die Reibung an der Übergabestelle verschwindet.

Wenn Sie ein operatives System haben, dessen Regeln in Code festsitzen — das Tactical Assessment klärt, ob die Verschiebung der nächste Hebel ist.