Produktive Basis
API, Health/Readiness, zwei Dashboard-Varianten, Grounded/Stateful Chat, Auth/RBAC, Memory/Knowledge, Ops und Audit/Evidence bilden den laufenden Kern.
NQIS
Lokale KI-Plattform mit Audit, Memory und Governance.
NQIS ist der technische Kern hinter dem Nova-Konzept. Der Stand vom 19. September 2026 beschreibt eine lokale v2.2-RC-Runtime mit FastAPI-API, zwei Dashboard-Varianten, Health-/Ready-Endpunkten, zentraler Auth/RBAC-Steuerung, Grounded und Stateful Chat, Memory/Knowledge, Ops, Audit/Evidence sowie Planning- und Governance-Bausteinen. Zusätzlich ist A3.0 Read-only als isoliert getesteter Kandidat vorbereitet; produktiv aktiviert ist diese Stufe noch nicht.
Stand 19.09.2026v2.2-RC · API & Dashboards aktivA3.0 Read-only · vorbereitet, noch nicht produktiv
Capability- und Governance-Arbeit
In einem isolierten Entwicklungszweig wurden granulare Systemfunktionen mit Policy-Grenzen, strukturierten Änderungspaketen, Task-Orchestrierung sowie End-to-End- und Sicherheitstests erprobt. Dieser Zweig ist nicht produktiv angebunden.
A3.0 Read-only
28 ausschließlich lesende Capabilities sind mit festen Allowlists, Rollen-/Clientbindung, Schemas, Redaction, Audit und kontrollierter Freischaltung vorbereitet. Die isolierten Sicherheits- und Registry-Tests sind bestanden; produktiv aktiviert sind die Funktionen noch nicht.
Funktionaler Stand
Vom Experiment zur prüfbaren KI-Betriebsplattform.
Der aktuelle Stand beschreibt eine lokal laufende, geprüfte KI-/Ops-Plattform. Entscheidend ist nicht nur, dass eine Antwort erzeugt wird, sondern wie sie zustande kommt, welche Quellen beteiligt waren, welche Route genutzt wurde, welche Rolle zugreifen darf und welcher Nachweis später verfügbar bleibt.
NQIS ist damit kein einzelner Chatbot, sondern eine Orchestrierungs- und Governance-Schicht für lokale KI-Arbeit. Memory, Knowledge, API, Dashboard, Safety, Evidence, Projektkontext und Release-Prozesse wirken zusammen. Historische Nachweise werden klar vom aktuellen Betriebszustand getrennt.
Bereits abgedeckte Bereiche
- lokaler Betrieb auf eigener Infrastruktur
- v2.2-RC-Runtime
- FastAPI-API und OpenAPI-Beschreibung
- Health- und Ready-Prüfungen
- zwei Dashboard-/Ops-Ansichten
- Memory/Knowledge und Grounded/Stateful Chat
- Projektkontext und Evidence-Historie
- zentrale Auth/RBAC-Steuerung
- Rollen- und Governance-Grenzen
- Planning-, Task- und Entscheidungsbausteine
- Audit- und Evidence-Strukturen
- Release-, Restore- und Rollback-Gedanke
- Capability-Registry und fail-closed Policy-Modell in der Entwicklungsumgebung
- strukturierte Änderungspakete und gebundener Task-State als getestete Entwicklungsbausteine
- A3.0 mit 28 vorbereiteten Read-only-Capabilities
- Runner und freie Code-/Shell-Ausführung technisch deaktiviert
- klare Trennung zwischen produktiver Basis, vorbereiteten Funktionen und historischen Nachweisen
Architekturprinzip
Jeder Schritt soll begründbar bleiben.
| Schicht | Aufgabe | Nutzen |
|---|---|---|
| Memory & Knowledge | Quellen, Chunks, Claims, Konzepte und lokale Wissensdaten strukturiert bereitstellen. | Antworten können auf nachvollziehbarem Kontext beruhen. |
| Grounded Chat | Relevante Quellen suchen und Antworten daraus ableiten. | Reduziert Halluzinationen und macht Unsicherheit sichtbarer. |
| Natural Chat Routing | Anfragen zwischen normalem Chat, General Knowledge, lokalen Systemfragen, Rechnerlogik, Ops-Readonly und blockierten Aktionen unterscheiden. | Antworten sollen menschlich nutzbar bleiben, ohne technische Grenzen zu verstecken. |
| Ops & Dashboard | Health, Readiness, Status, Logs, Evidence und Betriebsdaten sichtbar machen. | Betrieb, Diagnose und Wartung bleiben überprüfbar. |
| Projektkontext & Evidence | Projektartefakte, Entscheidungen, Nachweise und offene Arbeitsbereiche strukturiert zugänglich machen. | Langfristige Projektkontinuität wird möglich, ohne alte Snapshots als Live-Status zu verwechseln. |
| Auth/RBAC | Rollen, Berechtigungen und geschützte Bereiche erzwingen. | Nicht jede Rolle darf alles sehen oder verändern. |
| Safety & Governance | Risikogrenzen, Not-Aus-Mechanismen, blockierte Shell-Ausführung und Freigaben definieren. | Automatisierung bleibt kontrolliert und auditierbar. |
| Capabilities & Policy | Funktionen granular registrieren, Eingaben validieren und erlaubte Ziele, Rollen und Clients technisch begrenzen. | Neue Fähigkeiten werden nicht als freie Befehle, sondern als prüfbare Verträge eingeführt. |
| Release & Evidence | Checks, Prüfsummen, Restore-Proben, Berichte und historische Nachweise dokumentieren. | Änderungen werden messbar, vergleichbar und rückrollbar. |
Grounded Chat und General Knowledge
Grounded Chat bedeutet, dass eine Antwort nicht als freier Text aus dem Nichts entstehen soll. Vor der Antwort werden passende Wissens- und Memory-Bausteine gesucht. Nur wenn ausreichender Kontext vorhanden ist, wird daraus eine Antwort erzeugt. Fehlt eine belastbare Grundlage, ist eine vorsichtige Ablehnung besser als eine erfundene Behauptung.
Für allgemeine Wissensfragen wird zusätzlich an einer saubereren General-Knowledge-Route gearbeitet: stabile Grundlagenfragen sollen direkter beantwortet werden, während aktuelle oder unsichere Fakten weiterhin Quellen, Frischeprüfung oder klare Begrenzung benötigen.
Auth/RBAC und geschützte Aktionen
Die Rollenlogik trennt lesende, prüfende und verändernde Zugriffe. Ein Dashboard kann Informationen anzeigen, ohne automatisch produktive Aktionen auszulösen. Mutierende Aktionen benötigen stärkere Grenzen, weil sie Systemzustände ändern können.
Das Ziel ist eine Assistenz, die helfen kann, ohne unkontrolliert zu handeln. Direkte Shell- oder Codeausführung aus Modellantworten bleibt blockiert. Für die nächste produktionsnahe Stufe ist ausschließlich A3.0 Read-only ausgewählt; schreibende oder ausführende Fähigkeiten bleiben produktiv gesperrt.
Aktuelle Entwicklungsstufe
A3.0 Read-only: kontrollierte Systemwahrnehmung vor Aktionsrechten.
Die aktuelle Entwicklungsstufe konzentriert sich bewusst auf einen klar begrenzten ersten Schritt: Nova soll zunächst fest registrierte System- und Diagnoseinformationen lesen können, ohne Dateien, Dienste, Datenbanken oder Netzwerke zu verändern. Der Kandidat ist vorbereitet und isoliert getestet, aber noch nicht produktiv angebunden.
28 Read-only-Capabilities
Feste Capabilities, Schemas und Allowlists begrenzen Dateisystem-, System-, Health-, Git-, Journal- und weitere Diagnosezugriffe. Die Freischaltung soll schrittweise erfolgen und zunächst auf besonders risikoarme Diagnosefunktionen begrenzt bleiben.
Fail-closed statt Fallback
Runner, freie Shell, Codeausführung, Dateiänderungen, Git-Mutationen, HTTP-/DB-Schreibzugriffe sowie Prozess- und Serviceaktionen bleiben technisch gesperrt.
Nächster Schritt
Vor einer produktiven Aktivierung folgt eine zusätzliche Sicherheitsprüfung. Anschließend sollen zunächst nur besonders risikoarme System-, Runtime- und Health-Abfragen freigeschaltet werden.
Grenzen
Realistische Einordnung
Entwicklungsstand: NQIS ist ein wachsendes lokales Projekt mit laufender und geprüfter Runtime, aber kein öffentlich betriebener Cloud-Dienst.
Live vs. Historie: Live-Health, Dashboard und Ledger-API können aktuell erreichbar sein, während einzelne Ledger-Snapshots ältere Projektstände beschreiben.
Autonomie: Der aktuell vorbereitete A3.0-Pfad ist ausschließlich lesend. Codeausführung und produktive Änderungen sind weiterhin nicht freigegeben; spätere Aktionsrechte benötigen einen getrennten Sicherheitsnachweis.