Hauptgedanke

Eine fachliche Ontologie, die automatisch aus dem Code aktualisiert wird, hat einen Mangel, der das Spiegelbild der alternden Dokumentation ist: Ändert sie sich systematisch, um dem Code zu folgen, prüft sie nichts mehr. Führt ein Agent einen Fehler ein, verwandelt ein zweiter Agent, der die Ontologie aktualisiert, um ihn annehmbar zu machen, die Drift in eine Regel. Das Modell wird zu einer laufend neu erzeugten Dokumentation.

Das umgekehrte Extrem ist nicht besser: Ein Modell, das jede Weiterentwicklung verbietet, die seinen aktuellen Regeln widerspricht, hindert das Produkt daran, sich zu verändern.

Der Weg dazwischen besteht darin, jede Weiterentwicklung des Modells ausdrücklich zu behandeln. Ist die Weiterentwicklung beabsichtigt und klar, bereitet man eine versionierte Änderung der Ontologie vor, die gegebenenfalls vor der Freigabe in einem Arbeitsbranch angewendet wird. Wirkt die Codeänderung der Absicht zuwider, korrigiert man den Code statt des Modells. Ist die Absicht mehrdeutig, fordert man eine Entscheidung an, statt eine Regel zu erfinden.

Warum das wichtig ist

Das Modell wird zu einem sich weiterentwickelnden Vertrag zwischen Absicht und Implementierung, nicht zum Abbild des letzten Codestands. Das ist die Bedingung dafür, dass es als Sicherheitsnetz taugt: Der Code darf nicht automatisch recht haben.

Das erfordert eine Historie. Ein umbenanntes Konzept darf nicht zu zwei unabhängigen Konzepten werden, und eine entfernte Regel muss mit der Entscheidung verknüpft bleiben, die ihr Verschwinden begründet hat — etwa in einem kleinen Entscheidungsregister nach dem Vorbild der ADR.

Nuancen und Grenzen

Jede ausdrücklich behandelte Weiterentwicklung kostet menschliche Aufmerksamkeit. Läuft jede Weiterentwicklung über eine Entscheidung, bremst die Vorrichtung die Entwicklung, die sie absichern sollte.

Offene Fragen

• Ab welcher Menge freizugebender Weiterentwicklungen hören Teams auf, die Änderungsvorschläge am Modell zu lesen, und winken sie standardmäßig durch?