Foundation Models bringen Fachwissen. Ich baue das, was Erfahrung daraus macht.

01 — NEXUS

Ein Gedächtnis, das den Modellwechsel überlebt

Kein Sprachmodell, keine Oberfläche — die Schicht dazwischen, die sich merkt, ordnet, zurückstellt und vergisst.

Neue Sitzung. Möglicherweise ein anderes Modell. Dieselbe Vorgeschichte.

Sprachmodelle werden zunehmend austauschbar. Die gemeinsame Vorgeschichte nicht. Deshalb liegen bei NEXUS Identität und Gedächtnis nicht im Modell, sondern daneben — das Sprachmodell muss nicht selbst der dauerhafte Assistent sein, es ist das Modell, das momentan für diesen Assistenten arbeitet. Ein Modellwechsel ist dann kein Beziehungsverlust mehr, sondern ein Werkzeugwechsel.

Erfahrung statt Faktenspeicher

Ein einfaches Chat-Memory hält fest: „Der Nutzer bevorzugt X.“ Ein Erfahrungsgedächtnis bewahrt zusätzlich: „Wir haben X ausprobiert. Y wurde ebenfalls geprüft, aber wegen Z verworfen. Das Ergebnis war Q.“ Das ist der Unterschied zwischen Fakten speichern und Erfahrungen für künftige Entscheidungen nutzbar halten.

Genau dafür ist NEXUS gebaut: Bewahrt wird der Arbeitsstand — welche Entscheidung getroffen wurde und warum, welche Alternative verworfen wurde, was schon einmal ausprobiert wurde und wie es ausging. Eine Instanz gewinnt eine Erkenntnis und legt sie ab; eine spätere baut darauf, trifft eine neue Entscheidung, und auch deren Begründung bleibt erhalten. So werden aus einzelnen Sitzungen eine fortlaufende Zusammenarbeit.

Wie es arbeitet — für alle, die tiefer einsteigen wollen

Als Dienst, für eigene Bots und Projekte

NEXUS wird als Dienst angeboten: Wer einen eigenen Assistenten, Bot oder Agenten betreibt, bindet das Gedächtnis an, statt eines zu bauen. Die eigene Anwendung behält ihr Modell, ihre Oberfläche und ihre Logik — NEXUS hält darunter die Vorgeschichte.

Wofür

Überall dort, wo dieselbe Person über Monate wiederkommt und der Verlauf sonst im Kopf eines Einzelnen liegt.

Grundsatz

NEXUS trifft keine automatisierten Entscheidungen über Personen. Bewertung und Entscheidung bleiben beim Menschen.

Personenbezogene Daten sind ausdrücklich eingeschlossen. Der erste Anwendungsfall war ein persönliches Gedächtnis — der sensibelste denkbare. Deshalb liegt die Mandantengrenze in der Datenbank und nicht im Anwendungscode: in 80 geprüften Mandantenpaaren null Fremdtreffer, bei durchweg gelingendem Zugriff auf die eigenen Daten. Betrieb in der EU, beim Kunden oder ohne Netzanbindung; Bedeutungsberechnung und Nachbewertung laufen auf der eigenen Anlage. Inhaltsverschlüsselung je Mandant zuschaltbar, Aufbewahrung je Anwendung einstellbar — von „endgültig vergessen“ bis „dauerhaft erhalten“. Klarnamen verlassen das Haus nur als Platzhalter, mit Rückübersetzung der Antwort.

Im Messtest findet NEXUS die passende Stelle in 96 Prozent der Fälle. Gemessen wird NEXUS nach MBRC, einer offenen Prüfcheckliste für Gedächtnissysteme in KI-Anwendungen. Methode und Messberichte sind veröffentlicht.

02 — Plattformen

Drei Domänen, ein Substrat

Ich baue keine Einzellösungen mehr, sondern Plattformen — jede auf demselben Gedächtnis, jede mit eigenem Fachmodell und eigenem Rechtsrahmen.

Der gemeinsame Nenner ist immer derselbe: Es gibt eine Vorgeschichte, sie verändert sich langsam, sie liegt größtenteils in Mails, Protokollen und Köpfen — und wer sie kennt, entscheidet besser. Was sich unterscheidet, ist das Fachmodell darüber und die Normenlage darunter.

03 — Systeme

Was sonst noch läuft

Anwendungen, aus denen die Architektur hervorgegangen ist.

04 — Zusammenarbeit

Drei Wege, die hier zusammenlaufen

05 — Über

Siebzehn Jahre Steuerungs- und Sicherheitstechnik als Grundlage der KI-Architektur

Ich verbinde 17 Jahre Erfahrung in Steuerungs- und Sicherheitstechnik, unter anderem in der Modernisierung sicherheitskritischer Anlagensteuerungen, und in der Geschäftsführung eines Unternehmens der Gebäudetechnik mit der Architektur und Umsetzung von KI-Systemen.

In der Personenbeförderung bestimmt die Sicherheitsbetrachtung die Konstruktion, nicht umgekehrt. Der Fehlerfall ist dort kein Ausfall und kein Ticket, sondern eine schwere Verletzung. Deshalb ist die Sicherheitskette kein Bestandteil, den man später ergänzt: Sie wird getrennt ausgeführt, getrennt geprüft und getrennt abgenommen, und alles andere darf nur laufen, solange sie es erlaubt. Wer so gearbeitet hat, zieht rechtliche und normative Anforderungen nicht nachträglich ein — er fängt damit an. Bei FOREMAN lag die KI-Verordnungs-Einstufung vor dem ersten Commit; bei LEDGER und DOSSIER stand die Festlegung „kein System of Record“ vor der ersten Modulskizze.

Dieselbe Denkweise steht hinter dem veröffentlichten Messstandard: Der Maßstab steht öffentlich da, bevor eine Zahl daneben steht.

Retrofit ist Integration in Gewachsenes, mit Abnahmeprotokoll. Eine Anlage läuft seit zwanzig Jahren, die Dokumentation ist unvollständig oder falsch, das Bauteil gibt es nicht mehr — und sie bekommt trotzdem eine neue Steuerung. Man muss ein System verstehen, das man nicht gebaut hat, darf es nicht dauerhaft anhalten, und am Ende steht eine Prüfung, die man besteht oder nicht. Das ist derselbe Job wie die Anbindung an eine gewachsene Systemlandschaft, nur mit einem härteren Termin: Die Anlage muss morgen früh wieder fahren.

Im Sondermaschinenbau ist keine Anlage wie die andere und trotzdem muss jede an bestehende Systeme andocken. Man lernt dort, die Schnittstelle vor dem Innenleben zu entwerfen, weil das Innenleben ohnehin dreimal geändert wird. Dass NEXUS unter den drei Plattformen sitzt wie eine Datenbank unter einer Anwendung und dabei austauschbar bleibt, ist dieselbe Denkbewegung — nicht Softwarearchitektur-Lehrbuch, sondern Maschinenbau.

Wie ich arbeite

Ich orchestriere. Architektur und Entscheidungen entstehen im Gespräch mit einem Modell, das mir widerspricht; Implementierung und Fehlersuche laufen über spezialisierte Werkzeuge gegen eine festgeschriebene Spezifikation. Diese Methode braucht ihre eigenen Qualitätstore, sonst entsteht Geschwindigkeit auf Kosten der Substanz. Deshalb sind die Tore hart: keine Typfehler, keine Testabdeckung unter der Schwelle, keine Dokumentation, die dem Code hinterherhinkt.

Die Methode hat eine Form. PLANWERK ist die Projektierung davor: Absicht, Schadensklasse, Anforderungen, Entwurf, Rechts- und Sicherheitsbetrachtung — mit Toren, die ich selbst passiere, und Prüfungen in einer Sitzung, die den Entstehungsweg nicht kennt. AEOS ist der Rahmen, in dem ein Agent danach baut, und er begrenzt das Modell hart. Die Verfahren liegen als Ontologie vor — welcher Aufgabentyp welche Schritte hat, welche Regel und welche Prüfung je Schritt gilt — und der Agent bekommt sie vor dem Schreiben, nicht danach. Anforderungen, Spezifikation und Tests sind für ihn schreibgeschützt; widerspricht ein Test der Spezifikation, hält er an und meldet. Pfade, Befehle und Geheimnisse, die er nicht anfassen darf, werden gesperrt, nicht empfohlen. Ein Befund zählt erst, wenn er reproduziert ist — Test rot vor dem Fix — und ein Test zählt erst, wenn er einen absichtlich eingebauten Fehler findet. Jede Sitzung hat Kontrollpunkte und ein Kontextbudget; was sich nicht prüfen lässt, wird nicht durchgelassen. Und drei Dinge entscheidet der Agent nie: was gebaut wird, welche Schadensklasse gilt und wann ein Tor bestanden ist.

Meine Stärke liegt vor dem Code. Aus einer unscharfen Anforderung ein System schneiden, das trägt: Grenzen setzen, Fehlerfälle zuerst denken, rechtliche und normative Anforderungen zu Architektur machen statt zu einem Anhang, Schnittstellen vor Innenleben entwerfen — und die Sache dann bis zum laufenden Betrieb durchziehen. Dazu gehört auch die Bereitschaft, Systeme zu bauen, die selten so gebaut werden.

Wo ich am stärksten bin, ist deshalb der Anfang: ein Vorhaben, das noch unscharf ist, in ein System übersetzen, das trägt — und es von dort bis zum laufenden Betrieb führen. Alles, was auf dieser Seite steht, ist auf diesem Weg entstanden.