Das Problem der Engineering-Invarianten
Wenn ein autonomer Agent eine Engineering-Aufgabe bearbeitet, bleibt als Ergebnis eine Codeänderung, ein Dokument, ein Testresultat. Die Engineering-Kette, die das Ergebnis tragen soll — welche Anforderung adressiert wird, welche Architekturentscheidung greift, welcher Trace, welche Evidenz —, ist meist nicht vorhanden oder wird unter Druck fabriziert. Eine Woche später, wenn die Änderung geprüft, debuggt oder regulatorisch verteidigt werden muss, fehlt diese Kette.
LLMs durch Instruction-Tuning und RLHF auf Engineering-Disziplin zu trainieren, verbessert das durchschnittliche Verhalten, erzwingt aber keine Invarianten. Engineering-Invarianten — getracete Anforderungen, begründete Architektur, evidenzgestützte Lieferungen — lassen sich nicht zuverlässig als gelerntes Verhalten erhalten. Sie müssen durch einen Mechanismus erzwungen werden, der ausserhalb des Vorschlagenden liegt. Man trainiert keinen Compiler darauf, Typfehler abzulehnen; man baut einen Type-Checker.
Nidus: eine Governance-Runtime für KI-gestütztes Engineering
Nidus mechanisiert das V-Modell für KI-gestützte Software-Lieferung. Die Engineering-Methodik — Anforderungen, Architektur, Design, Traceability, Proof Obligations, Evidenz — wird in ein einziges entscheidbares Artefakt externalisiert: die lebende Spezifikation. Jede von einem Agenten vorgeschlagene Mutation wird gegen die aktive Proof-Obligation-Menge verifiziert, bevor sie persistiert wird. Das Repository enthält ausschliesslich Zustände, welche die Verifikation bestanden haben.
Organisatorische Standards kompilieren in wiederverwendbare Guidebooks: Constraint-Bibliotheken, die jedes geführte Projekt importiert. Ein neues Projekt übernimmt die geerbten Constraints automatisch; die Methodik lebt in der Umgebung, nicht im Agenten.
Eigenschaften auf öffentlicher Ebene:
- Lebende Spezifikation, die Anforderungen → Architektur → Design → Traces → Proofs → Evidenz als ein strukturiertes Artefakt abbildet.
- Entscheidbares Verifikations-Gate bei jeder Mutation; Commits werden erst nach Erfüllung aller aktiven Obligations akzeptiert.
- Wiederverwendbare Guidebooks lassen organisatorische Standards per Vererbung über Projekte hinweg wirken.
- Rekursive Selbst-Governance: Die Regeln, die das Artefakt steuern, leben im Artefakt selbst und unterliegen demselben Gate.
- Die Git-Historie eines Nidus-Artefakts ist eine Folge verifizierter Zustände. Der Audit-Pfad ist eine strukturelle Eigenschaft des Artefakts, kein separater Prozess.
Für KI-gestützte Engineering-Teams — und für regulierte Einsätze, die jede maschinell getroffene Entscheidung verteidigen müssen — verschiebt das die Engineering-Disziplin von einer Verhaltenseigenschaft des Modells zu einer strukturellen Eigenschaft des Systems.
Selbst-hostendes Referenzdeployment
Nidus hat seine eigene Konstruktion mitgesteuert. Drei LLM-Familien (Claude, Gemini, Codex) lieferten eine Referenz-Implementierung von 100 000 Zeilen unter derselben Proof-Obligation-Menge, mit der das Artefakt selbst geführt wird. Detaillierte Deployment-Metriken, Latenztabellen, die empirische Lesion-Studie und das Friction-Modell stehen im öffentlichen Preprint.
Preprint
Nidus: Externalised Reasoning for AI-Assisted Engineering — arXiv:2604.05080.
Verwandte Forschung
- Technische Notizen zu Wissenssystemen (in englischer Sprache) — thermodynamische Einordnung von Wissensverstärkung; Kontext für externalisierte Methodik als Wissenssubstrat.
- Forschungs-Index — Gentian-Architektur, Nidus-Governance, technische Notizen.