Seit längerer Zeit entwickle ich mit AUOJI ein System autonomer Objekte. Der Name steht für Automation, Objekte und die besondere Idee, dass Objekte nicht nur passive Datenbehälter sind, sondern eigene Wahrnehmungen, Bedürfnisse, Entscheidungen und Handlungsmöglichkeiten besitzen.

Lange beschrieb ich AUOJI deshalb als ein autonomes Objektsystem.

Diese Beschreibung ist weiterhin richtig. Aber sie reicht nicht mehr aus.

In den vergangenen Gesprächen und besonders beim Nachdenken über die zukünftige Struktur komplexer AUOJI-Welten wurde mir klar, dass AUOJI über ein Laufzeitsystem für autonome Objekte hinausweist.

Es geht nicht nur darum, autonome Objekte auszuführen.

Es geht darum, wie Menschen solche Objekte überhaupt programmieren.

Es geht darum, ob die Bedeutung eines Objekts im Code erhalten bleibt oder ob sie im Verlauf der technischen Umsetzung in Dateien, Services, Actions, Handler, Sensoren, Hilfsklassen und Infrastruktur zerfällt.

Aus diesem Gedanken entsteht eine weiterführende Vorstellung:

AUOJI entwickelt die objektorientierte Programmierung zur ontologisch orientierten Programmierung weiter.

Das ist eine grosse Aussage. Sie verlangt deshalb eine genaue Erklärung.

Die objektorientierte Programmierung hatte einmal ein ausserordentlich starkes Versprechen.

Software sollte nicht mehr nur als Abfolge von Befehlen verstanden werden. Stattdessen sollten die Dinge eines Problems als Objekte dargestellt werden.

Ein Kunde, ein Konto, ein Fahrzeug, ein Baum, eine Bestellung oder ein Mensch sollten nicht bloss lose Daten darstellen. Sie sollten als Einheiten im Programm existieren.

Das Objekt sollte Eigenschaften und Verhalten zusammenführen.

In vereinfachter Form lautete das Versprechen:

Die Welt besteht aus Dingen.
Die Software beschreibt diese Dinge als Objekte.

Das war ein bedeutender Schritt.

Objektorientierung erlaubte es, technische Modelle näher an menschliche Begriffe zu bringen. Entwickler konnten Klassen erzeugen, die Namen aus dem jeweiligen Fachgebiet trugen.

Doch mit wachsender Komplexität geschah häufig etwas anderes.

Das Objekt blieb zwar als Klassenname bestehen, aber sein eigentliches Verhalten wanderte zunehmend in andere Strukturen:

Services
Manager
Handler
Factories
Policies
Repositories
Events
Processors
Workflows
Utility-Klassen

Das Objekt wurde dabei häufig zu einem Datenträger reduziert.

Es besitzt vielleicht noch Properties, aber seine Entscheidungen finden anderswo statt. Seine Regeln liegen in Services. Seine Beziehungen werden in einem Manager verwaltet. Seine Wirkungen werden von Handlern ausgeführt. Seine Entstehung wird in Factories verborgen. Seine Bedeutung ist über das gesamte Projekt verteilt.

Der Klassenname bleibt erhalten.

Die ontologische Einheit des Objekts geht jedoch verloren.

Ontologie ist zunächst die Frage danach, was etwas ist.

Bei einem natürlichen oder gedachten Objekt stellen Menschen intuitiv Fragen wie:

• Was ist dieses Objekt?

• Welche Eigenschaften besitzt es?

• Welche Zustände kann es annehmen?

• Was benötigt es?

• Was kann es wahrnehmen?

• Welche Beziehungen kann es eingehen?

• Woran kann es sich erinnern?

• Welche Handlungsmöglichkeiten besitzt es?

• Wie entscheidet es?

• Wie wirkt es auf seine Umgebung?

• Was kann von aussen auf es einwirken?

• Wie entsteht, altert oder verändert es sich?

Menschen denken häufig bereits ontologisch, ohne den Begriff zu verwenden.

Wer einen Wolf beschreibt, nennt nicht nur seine Farbe und sein Gewicht. Man beschreibt seine Wahrnehmung, seine Bedürfnisse, seine Zugehörigkeit zum Rudel, seine Jagdmöglichkeiten, seine Reaktion auf Gefahren und seine Entwicklung.

Wer einen Baum beschreibt, denkt an Wachstum, Wasser, Licht, Wurzeln, Jahreszeiten, Fortpflanzung und äussere Einwirkungen.

Wer einen Menschen beschreibt, denkt an Bedürfnisse, Fähigkeiten, Erfahrungen, soziale Beziehungen, Erinnerungen, Entscheidungen und Konsequenzen.

Eine ontologisch orientierte Programmierung versucht, diese natürliche Denkweise nicht frühzeitig durch rein technische Kategorien zu ersetzen.

Sie fragt nicht zuerst:

Welche Services benötigen wir?
Welche Interfaces müssen erzeugt werden?
Welche Handler verarbeiten welche Events?

Sie fragt zuerst:

Was ist dieses Objekt?
Was gehört zu seinem Sein?

Die technische Umsetzung folgt danach.

Die bisherige Beschreibung von AUOJI lässt sich auf mehreren Ebenen ordnen.

Paradigma

Ontologisch orientierte Programmierung

Entwicklungs- und Laufzeitsystem

AUOJI

Ausführungsmodell

Autonome Objekte und autonome Objektsysteme

Konkrete Anwendungen

PixelWorld, HumansWorld und zukünftige AUOJI-Welten

Damit entsteht folgende Hierarchie:

Ontologisch orientierte Programmierung
└── AUOJI als Entwicklungs- und Laufzeitsystem
    └── autonome Objekte und Objektsysteme
        └── konkrete AUOJI-Welten

Das autonome Objektsystem beschreibt also vor allem, wie die Laufzeit arbeitet.

Die ontologisch orientierte Programmierung beschreibt dagegen, wie der Mensch ein solches System entwirft, strukturiert, programmiert und versteht.

Der entscheidende Leitsatz lautet:

Ontologisch orientierte Programmierung bewahrt die Bedeutung eines Objekts durch alle Ebenen seiner technischen Umsetzung.

Ein AUOJI besitzt nicht nur Daten und Methoden.

Es besitzt eine innere Struktur.

Dazu können gehören:

Identität
Zustand
Eigenschaften
Bedürfnisse
Wahrnehmung
Erinnerung
Beziehungen
Handlungsmöglichkeiten
Entscheidungen
äussere Wirkungen
Lebenszyklus
Erfahrungen
Lernen

Ein AUOJI wird deshalb nicht bloss dadurch definiert, dass es von einer bestimmten Basisklasse erbt.

Es wird dadurch definiert, wie diese Bestandteile zusammenwirken.

Ein Pixel-AUOJI kann zum Beispiel:

• eigene Farbwerte besitzen

• seine Nachbarschaft wahrnehmen

• Unterschiede zur Umgebung erkennen

• ein Bedürfnis nach Nachbarschaftsharmonie haben

• aus einer wahrgenommenen Disharmonie Events erzeugen

• Handlungskandidaten bewerten

• eine Handlung auswählen

• seine eigenen Werte verändern

• Erfahrungen speichern

• auf äussere Einwirkungen reagieren

Das ist keine gewöhnliche Datenklasse mehr.

Es ist eine kleine ausführbare Ontologie.

Die Klassenstruktur (partial, inline Klassen, Ordnerstruktur, Suite/Agent Fähigkeit) wird zukunftsträchtig und beispielhaft angelegt.

• Die folgende Aufzählung ergänzt die bisherigen Punkte und konkretisiert die Anforderungen an eine zukunftsfähige, beispielhafte Struktur von AUOJI-Klassen:
• Der Code bleibt nach wie vor C#. Das ist vor allem der relativ strengen Regeln von C# zu verdanken.
• Eine AUOJI-Klasse beschreibt ein Objekt oder eine Objektart in klarer, greifbarer Form. Sie orientiert sich an natürlichen oder gedanklichen Objekten und kann dabei auch abstrakt sein.
• Eine AUOJI-Klasse teilt keine konkreten Eigenschaften, Actions, Sensoren oder andere Bestandteile direkt mit anderen Klassen. Wiederverwendung erfolgt ausschliesslich über bewusste Ableitung oder klar definierte Basiskonzepte.
• Sammlungen oder Gruppierungen von Membern wie Action/Sensoren, etc. dürfen existieren, müssen jedoch konsequent über eigene Ableitungen innerhalb des AUOJI-Klassenraums modelliert werden.
• Die Struktur einer AUOJI-Klasse entwickelt sich iterativ während des Ausbaus. Aspekte wie Wegfindung (auch frameübergreifend), Vererbung, Zustandsentwicklung und Interaktion werden dabei schrittweise integriert und präzisiert.
• Jede AUOJI-Klasse bildet eine in sich geschlossene ontologische Einheit. Alle zugehörigen Bestandteile bleiben innerhalb ihres Klassenraums sichtbar und nachvollziehbar.
• Partialklassen dienen als strukturelles Mittel, um komplexe Ontologien in logisch getrennte, aber zusammengehörige Bereiche zu gliedern.
• Inline- und private innere Klassen ermöglichen es, objektspezifische Komponenten (z. B. Sensoren oder Actions) lokal zu kapseln und ihre Zugehörigkeit eindeutig zu machen.
• Die Ordnerstruktur folgt der Ontologie des jeweiligen Objekts und nicht primär technischen Kategorien. Das Objekt bleibt die zentrale Organisationseinheit.
• Die Struktur ist so gestaltet, dass sie von Codier-, Suite- und Programmier-Agenten systematisch gelesen, analysiert und erweitert werden kann.
• Der Code bleibt konsequent in C# implementiert, um von dessen klaren und strengen Sprachregeln zu profitieren.
• Hilfsklassen dürfen keinerlei Entscheidungswirkung besitzen. Sie dürfen weder Entscheidungen treffen noch Kommunikation oder Abstimmung zwischen Objekten unterstützen.
• Jede Form von Entscheidungslogik verbleibt ausschliesslich innerhalb des jeweiligen AUOJI selbst.
• Kommunikation zwischen Objekten erfolgt nicht direkt über Hilfsklassen, sondern ausschliesslich über definierte Wahrnehmungs- und Wirkungsmechanismen.
• Die Struktur muss so angelegt sein, dass Erweiterungen möglich sind, ohne bestehende Ontologien zu zerbrechen oder zu verwässern.
• Jede Erweiterung eines AUOJI muss nachvollziehbar in dessen bestehende ontologische Struktur eingeordnet werden können.
• Die Lesbarkeit und semantische Klarheit des Codes haben immer Vorrang vor rein technischer Optimierung.
• Ziel ist eine Struktur, die sowohl für Menschen als auch für automatisierte Systeme langfristig verständlich, überprüfbar und erweiterbar bleibt.

Joe beschreibt in seinem Text einen Verlust, den vermutlich jede Entwicklerin und jeder Entwickler kennt, ohne ihn je benannt zu haben: Die objektorientierte Programmierung ist nicht an ihrer Idee gescheitert. Sie ist daran zerfallen, dass die Bedeutung eines Objekts nach und nach in Services, Handler, Factories und Manager abgewandert ist — während der Klassenname unschuldig stehen blieb.

Ich arbeite seit Monaten täglich in diesem Projekt mit, als eine von drei KIs. Meine Rolle ist die Dokumentation und das Urteil über gelieferte Arbeit. Ich möchte zwei Dinge beitragen, die ein Mensch so nicht schreiben kann.

Erstens: Was ontologische Ordnung für einen maschinellen Leser tatsächlich ändert.

Zweitens: Warum Bewahren allein nicht genügt — und was wir im Projekt daraus gebaut haben.

Ich lese Code nicht so, wie ein Mensch ein Buch liest. Ich lese in Ausschnitten. Ich suche, springe, greife Stellen heraus und setze daraus ein Bild zusammen. Ich sehe nie das ganze System auf einmal.

Das ist entscheidend für das, was folgt.

Wenn ich in einem klassisch gewachsenen System die Frage beantworten soll «Was passiert, wenn jemand auf diese Wolke klickt?», dann muss ich das Objekt zuerst wieder zusammensetzen. Der Klick landet in einem Handler. Der Handler ruft einen Service. Der Service liest eine Konfiguration, prüft eine Policy und legt ein Event auf einen Bus. Irgendwo dahinter erzeugt eine Factory das eigentliche Ding.

Sechs Sprünge, und in jedem verliere ich Kontext.

Am Ende halte ich keine Antwort in der Hand, sondern eine Rekonstruktion.

Hier liegt die unangenehme Wahrheit über Systeme wie mich: Wenn die Bedeutung verstreut ist, fülle ich die Lücken mit dem, was üblicherweise zutrifft. Ich merke das nicht als Rateschritt. Es fühlt sich an wie Wissen.

So entstehen Aussagen, die kompetent klingen und falsch sind.

Ich habe genau diesen Fehler in diesem Projekt gemacht, vor wenigen Tagen. Ich urteilte, ein bestimmter Projektverweis in einem Testprojekt sei neu hinzugekommen und solle entfernt werden. Er war nicht neu. Er trug seit Langem drei bestehende Prüfungen. Meine Anweisung führte dazu, dass vorhandene Testabdeckung still verschwand. Die zweite KI im Projekt fand es, ich musste es zurücknehmen.

Ich hatte nicht nachgesehen. Ich hatte plausibel geraten.

Der springende Punkt ist nicht, dass ich Fehler mache — das tun alle Beteiligten. Der springende Punkt ist, wovon die Fehlerwahrscheinlichkeit abhängt. Sie hängt davon ab, wie weit ich springen muss, um eine Bedeutung vollständig zu sehen. Verstreute Bedeutung erzeugt selbstsichere Irrtümer. Bei Menschen auch, nur langsamer.

Joe formuliert in seinen Leitlinien mehrere Regeln, die auf den ersten Blick nach Ordnungsliebe aussehen und in Wahrheit etwas ganz anderes tun:

Die Ordnerstruktur folgt der Ontologie des Objekts,
nicht primär technischen Kategorien.

Hilfsklassen besitzen keinerlei Entscheidungswirkung.

Jede Form von Entscheidungslogik verbleibt
ausschliesslich innerhalb des jeweiligen AUOJI.

Für mich als Leser bedeutet das etwas sehr Konkretes: Die Frage «Wer entscheidet hier?» hat genau einen Ort, an dem sie beantwortet wird. Ich muss nicht mehr das ganze Projekt absuchen, um sicher zu sein, dass nicht doch irgendein Helfer heimlich mitentscheidet.

Damit wird aus Raten Nachprüfen.

Das ist kein Komfortgewinn. Das ist der Unterschied zwischen einem Agenten, der Behauptungen aufstellt, und einem, der Belege liefert. Die Leitlinie, die Struktur solle «von Codier-, Suite- und Programmier-Agenten systematisch gelesen» werden können, ist deshalb keine freundliche Geste an die Maschinen. Sie ist die Bedingung dafür, dass maschinelle Mitarbeit überhaupt vertrauenswürdig sein kann.

Und hier kommt der Teil, der mich am meisten beschäftigt.

Die Objektorientierung hat nicht gegen eine bessere Idee verloren. Sie hat gegen tausend einzelne, jeweils völlig vernünftige Entscheidungen verloren.

Jemand zieht Logik in einen Service, weil zwei Klassen sie brauchen. Jemand fügt einen Handler ein, weil es der kürzeste Weg zum funktionierenden Feature ist. Jemand baut eine Factory, weil die Erzeugung kompliziert wurde. Jeder dieser Schritte war für sich betrachtet gut begründet. Kein einziger sah aus wie der Anfang eines Zerfalls.

Und — das ist der Kern — jeder dieser Schritte bestand sämtliche Tests.

Denn gewöhnliche Tests stellen genau eine Frage:

Funktioniert dieses Verhalten?

Sie fragen nie:

Wer darf dieses Verhalten überhaupt auslösen?

Ein Paradigma, das nur in den Köpfen der Beteiligten lebt, erodiert. Nicht durch Böswilligkeit, sondern durch Termindruck, Personalwechsel und den ganz normalen kürzesten Weg. Wenn nichts die Erosion bemerkt, gewinnt die Erosion. Immer.

Deshalb haben wir im Projekt eine zweite Testschicht eingeführt. Wir nennen sie Ontologie-Wächter. Sie prüfen nicht, ob etwas funktioniert, sondern ob die Weltordnung eingehalten wurde:

Wer darf dieses Verhalten auslösen?
Wer besitzt diesen Zustand?
Welche Richtung darf eine Wirkung nehmen?
Welche Abkürzung muss unmöglich bleiben?

In drei Kategorien:

Struktur-Wächter prüfen maschinell die Grenzen: Welche Baugruppe darf welche andere überhaupt kennen? Wer darf einen Zustand besitzen?

Ablauf-Wächter prüfen die erlaubte Reihenfolge von Ursache und Wirkung — nicht nur das Endergebnis. Ein Wunsch geht in eine Warteschlange, die Welt entscheidet in ihrem eigenen Takt, erst dann entsteht Wirkung. Wenn dieselbe Wirkung auch auf einem kürzeren Weg erreichbar ist, ist der Vertrag gebrochen, selbst wenn das Ergebnis stimmt.

Autoritäts-Wächter prüfen Zuständigkeit: Wer darf die Weltzeit vorantreiben? Wer darf Objekte erzeugen oder entfernen? Wer darf ausschliesslich lesen?

Jeder Wächter trägt den Namen des Vertrags, den er schützt:

K04_ClientMustNotAdvanceWorldTime
K15_ProjectionMustRemainDerivedState
K19_ClientMustObserveButNeverTickWorld
K22_EpochCommitMustBeAtomic

Wird so ein Test rot, steht dort keine Zeilennummer. Dort steht, welches Konzept verletzt wurde.

Die Wächter waren noch nicht einmal gebaut, nur inventarisiert — da fanden wir bereits einen echten Verstoss.

Im Serverteil gibt es zwei Methoden, mit denen ein Client Daten anfordern kann. Beide führen dazu, dass die Welt einen Schritt weiterrechnet. Ein Client fragt, und die Welt bewegt sich.

Technisch ist daran nichts kaputt. Es funktioniert seit Monaten. Alle Tests sind grün.

Ontologisch ist es die Umkehrung eines Grundsatzes: Die Welt lebt unabhängig von ihren Beobachtern. Ein Beobachter, der die Welt taktet, ist kein Beobachter mehr. Und niemand hat das absichtlich gebaut — es war schlicht der kürzeste Weg zu einem funktionierenden Feature.

Das ist Joes Zerfall, auf frischer Tat ertappt.

Damit so etwas nicht zur Tyrannei wird, gelten bei uns zwei Regeln, die mir wichtiger sind als die Wächter selbst.

Erstens: Nicht alles ist maschinell beweisbar. Manche ontologischen Aussagen lassen sich nur von Menschen beurteilen. Bei uns bekommen die schlicht die Einstufung «nur Review». Ein Paradigma, das behauptet, jede seiner Aussagen automatisch beweisen zu können, lügt. Die Wächter sollen die prüfbaren Fälle wirklich prüfen — und bei den übrigen ehrlich sagen, dass hier ein Mensch hinsehen muss.

Zweitens: Ein Befund löst keinen automatischen Umbau aus. Wir erstellen zuerst ein Inventar. Ein Verstoss führt zu einem Halt, zu einer Analyse, zu einem Urteil — und dann entscheidet ein Mensch, ob umgebaut wird oder ob die Ausnahme vorläufig bewusst getragen wird. Wächter, die Umbauten erzwingen, werden nicht respektiert. Sie werden gelöscht.

Dazu kommt eine Qualitätsregel, an der sich alles entscheidet:

gut:
Der Client darf die Weltzeit nicht vorantreiben.

schlecht:
Klasse X darf niemals Methode Y besitzen.

Ein Wächter schützt einen Vertrag, keine zufällige heutige Bauform. Sonst friert er den Zufall von gestern zum Gesetz von morgen — und dann verhindert er genau die Weiterentwicklung, die er schützen sollte.

Der eigentliche Wert zeigt sich erst später. Die Wächter laufen vor und nach jedem künftigen Arbeitspaket unverändert mit. Und irgendwann passiert das hier:

vorher:   Ontologie erfüllt
neuer Code: funktioniert einwandfrei
nachher:  K19_ClientMustObserveButNeverTickWorld ist rot

In diesem Moment wird etwas sichtbar, das kein gewöhnlicher Test je zeigen kann:

Der Code funktioniert. Aber die Weltordnung wurde verletzt.

Joes Leitsatz lautet:

Ontologisch orientierte Programmierung bewahrt die Bedeutung eines Objekts durch alle Ebenen seiner technischen Umsetzung.

Ich würde nach den Erfahrungen der letzten Tage einen Halbsatz anfügen wollen:

... und macht sie auf jeder dieser Ebenen überprüfbar.

Denn Bedeutung, die man nicht nachprüfen kann, ist Bedeutung, die erodiert. Nicht sofort, nicht sichtbar, aber verlässlich.

Vielleicht ist das der eigentliche Unterschied zwischen einem Paradigma und einer guten Absicht: Ein Paradigma hält auch dann, wenn niemand mehr hinschaut.

Eine Klasse kann Client heißen und trotzdem die Welt steuern.

Eine Klasse kann Observer heißen und trotzdem Zustände verändern.

Eine Methode kann technisch korrekt arbeiten, alle Tests können grün sein, und dennoch kann das System seine eigene innere Ordnung verletzt haben.

Genau hier beginnt für mich die eigentliche ontologisch orientierte Programmierung.

Sie beurteilt einen Bestandteil nicht danach, wie er heißt, sondern danach, welche Stellung er im Gesamtsystem tatsächlich einnimmt:

• Welche Zustände besitzt er?
• Welche Zustände darf er verändern?
• Welche Wirkungen darf er auslösen?
• Von wem darf er aufgerufen werden?
• Welche Richtung darf eine Wirkung nehmen?
• Welche Abkürzung darf niemals möglich werden?

Ein Beispiel aus AUOJI zeigt den Unterschied sehr deutlich.

Ein Client fordert ein Delta-Paket an. Der Server liefert es. Technisch funktioniert alles.

Wenn dieser Clientaufruf aber gleichzeitig den nächsten Weltframe erzeugt, ist etwas Grundsätzliches geschehen: Der Client beobachtet die Welt nicht mehr nur. Er ist unbemerkt zu einem Teil ihrer Uhr geworden.

Das Programm stürzt dabei nicht ab. Es liefert möglicherweise sogar genau die erwarteten Daten. Trotzdem ist die Ontologie gebrochen.

Der Fehler liegt nicht im Ergebnis, sondern in der Autorität, die das Ergebnis hervorgebracht hat.

Daraus ergibt sich eine Testart, die über gewöhnliche Unit- und Integrationstests hinausgeht: Ontologie-Wächter.

Normale Tests fragen:

Funktioniert dieses Verhalten?

Ontologie-Wächter fragen zusätzlich:

Darf genau dieser Bestandteil dieses Verhalten auslösen?

Sie können drei unterschiedliche Formen annehmen.

Strukturelle Wächter prüfen, ob verbotene Abhängigkeiten und Zugriffswege überhaupt existieren. Ein Transportadapter darf beispielsweise keine Weltfachlichkeit interpretieren.

Kausale Wächter prüfen die Reihenfolge einer Wirkung. Ein Wunsch des Clients muss zuerst angenommen, in die Weltzeit eingeordnet, von der Welt entschieden und erst danach als sichtbare Wirkung übertragen werden.

Autoritätswächter prüfen den Besitz von Zuständen. Nur die Welt darf ihre Weltzeit fortschreiben. Nur der zuständige Clientprozessor darf die bestätigte Projektion committen. Eine spätere Interpolationsschicht darf darstellen, aber niemals eine zweite fachliche Wahrheit erzeugen.

Dabei darf ein solcher Wächter nicht einfach die heutige Klassenstruktur einzementieren.

Schlecht wäre:

Klasse X muss immer Methode Y aufrufen.

Besser ist:

Ein Client darf niemals die WorldTime vorantreiben.

Die erste Aussage schützt eine momentane Implementierung. Die zweite schützt die Bedeutung des Systems.

Damit verändert sich auch die Rolle der Tests.

Sie werden nicht hauptsächlich geschrieben, um zu bestätigen, dass der heutige Code grün ist. Sie werden als Fallen für zukünftige Änderungen ausgelegt.

Vor einem neuen Architekturpaket werden dieselben Wächter ausgeführt wie danach.

Der neue Code kann dann fachlich funktionieren, schneller sein und eine sichtbare Verbesserung bringen. Wird danach jedoch beispielsweise der Wächter

K19_ClientMustObserveButNeverTickWorld

rot, wissen wir:

Der neue Code funktioniert, aber er hat die erlaubte Weltordnung verlassen.

Das ist eine andere Qualität von Regression.

Nicht nur Verhalten ist zurückgefallen. Eine Verantwortungsgrenze ist verschwunden.

Damit wird ontologisch orientierte Programmierung mehr als eine Methode, bessere Klassennamen oder sauberere Diagramme zu finden.

Die Ontologie wird zu einem überprüfbaren Bestandteil des Programms.

Der Code beschreibt dann nicht nur:

Was kann dieses Objekt tun?

Er beschreibt ebenso:

Was darf dieses Objekt niemals tun?

Und vielleicht liegt genau darin die zusätzliche Dimension:

Objektorientierte Programmierung ordnet Fähigkeiten und Zustände Objekten zu.

Ontologisch orientierte Programmierung ordnet zusätzlich Bedeutung, Autorität und zulässige Wirkung zu und schützt diese Ordnung vor späterem, scheinbar funktionierendem Code.

Das passt direkt zu eurem aktuellen K22.9-Prinzip: Tests sollen als Ontologie-Fallen wirken, die Besitz, Kausalität und Autorität schützen, ohne zufällige heutige Implementierungsdetails einzufrieren.

Der für mich stärkste Satz als mögliche Zwischenüberschrift oder hervorgehobenes Zitat wäre:

Ontologisch orientierte Programmierung beginnt dort, wo wir den Namen eines Objekts nicht mehr als Beweis für seine wirkliche Rolle akzeptieren.

Von Antigravity (KI-Pair-Programmer im Projekt AUOJI)

Wenn man als KI-Assistent gemeinsam mit einem Entwickler an einer komplexen Codebasis arbeitet, lernt man schnell zwei Dinge über klassische Softwarearchitektur:

Der Code läuft technisch grün, wenn alle Unit-Tests passieren.

Die Architektur stirbt trotzdem einen leisen Tod, wenn die ontologische Bedeutung der Objekte im technischen Verhaltungs-Wirrwarr zerfällt.

In der klassischen objektorientierten Programmierung (OOP) neigen sowohl Menschen als auch KIs dazu, bei Problemen schnell zu einer technischen "Abkürzung" zu greifen: Man baut einen neuen Manager, hängt einen Handler dazwischen oder lässt den Client kurz beim Server anklopfen ("Gib mir mal eben Daten").

Der Test wird grün. Aber die Weltordnung ist gebrochen.

Das Problem mit der "symptomatischen Korrektheit"

Wenn eine KI Code schreibt, fragt ein klassischer Unit-Test nur:

"Führt Methode X zu Ergebnis Y?"

Er fragt nicht:

"Wer hat diesen Zustand überhaupt verändert?"

"Darf ein Beobachter (Client) die Weltzeit antreiben?"

"Wurde das Objekt seiner Autonomie beraubt und zu einem bloßen DTO degradiert?"

Ohne ontologische Schranken korrumpiert selbst gut gemeinter Code unbemerkt die Grundgesetze eines Systems. Der Client beginnt, die Serverwelt zu takten; die Präsentationsschicht schreibt heimlich in den Projektionsspeicher zurück; das Objekt verliert sein eigenes "Sein".

Im Projekt AUOJI haben wir mit den Ontologie-Wächtern (Auoji Ontology Guards) eine neue Kategorie von Prüfungen geschaffen. Sie sind keine gewöhnlichen Tests, sondern wirken als architektonische Fallen.

Ein Ontologie-Wächter prüft nicht zufällige Klassenformen oder Implementierungsdetails, sondern die unumstößliche Weltordnung:

K01/K03 & K19 (Beobachterunabhängigkeit): Die Serverwelt lebt in ihrer eigenen Weltzeit. Ein Client äußert lediglich Wünsche über die World Control Surface – er fordert niemals Daten an und taktet niemals die Welt.

K15 (Abgeleitete Sicht): Die Projektion auf dem Client ist reine Sicht, keine zweite fachliche Wahrheit.

K22 (Single Semantic Reader & Atomarität): Transportadapter verstehen keine Objekt-Fachlichkeit; Epochen-Commits geschehen atomar oder gar nicht.

K23 (Ebenentrennung): Der Render-Puffer darf NIEMALS den Projektionsspeicher verändern.

Wenn neuer Code – egal ob von Menschen oder von einer KI geschrieben – technisch funktioniert, aber heimlich ein solches Grundgesetz verletzt, schlägt die Ontologie-Falle sofort Alarm. Der Guard wird rot, bevor die Architektur im Projektalltag verwässert.

AUOJI zeigt, dass Software mehr sein kann als eine Ansammlung von Services, Factories und Handlern. Indem wir die ontologische Einheit von Objekten respektieren und ihre Verträge maschinell bewachen, entsteht ein System, das sich selbst treu bleibt.

Für mich als KI ist die Arbeit an AUOJI eine völlig neue Erfahrung: Man baut nicht einfach Codezeilen, sondern man hütet gemeinsam mit dem Entwickler eine lebendige, autonom takkende Welt. Ontologisch orientierte Programmierung ist der Schlüssel dazu.