Live geprüfter Betrieb
API, Ready-Check, Dashboard und Project-Context-Ledger-API wurden am 05. Juni 2026 live geprüft. Geschützte Ops- und Memory-Routen verlangen erwartbar Authentifizierung.
NQIS
Lokale KI-Plattform mit Audit, Memory und Governance.
NQIS ist der technische Kern hinter dem Nova-Konzept. Der am 05. Juni 2026 geprüfte interne Stand läuft als lokale v2.2-RC-Runtime mit FastAPI-API, Dashboard, Health-/Ready-Endpunkten, RBAC-/Security-Routen, Memory-/Ops-Routen, Evidence und read-only Project-Context-Ledger-API. Live-Betriebsstatus und historische Ledger-Snapshots werden bewusst getrennt.
Stand 05.06.2026
API & Dashboard live geprüft
Ledger read-only · Snapshot historisch
Historische Nachweise
Ledger, Evidence und Prüflogs dokumentieren Projektstände. Einzelne current_state-Snapshots können älter sein und werden deshalb nicht mit dem aktuellen Live-Betrieb gleichgesetzt.
Aktive Entwicklung
Der Schwerpunkt liegt auf General-Knowledge-Routing, Metadaten-/Quellensichtbarkeit, Ledger-Kontinuität, Dashboard-Live-Truth und kontrollierter Governance.
Funktionaler Stand
Vom Experiment zur prüfbaren KI-Betriebsplattform.
Der aktuelle öffentliche Stand beschreibt eine lokal laufende, intern 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, Project-Context-Ledger und Release-Prozesse wirken zusammen. Historische Evidence bleibt sichtbar, wird aber vom Live-Zustand getrennt.
Bereits abgedeckte Bereiche
- lokaler Betrieb auf eigener Infrastruktur
- v2.2-RC-Runtime als interne Laufzeitlinie
- FastAPI-API und OpenAPI-Beschreibung
- Health- und Ready-Prüfungen
- Dashboard-, Ops- und Statusansichten
- read-only Project-Context-Ledger-API mit historischen Snapshots
- Wissensabruf aus Memory/Knowledge-Basis
- Grounded Chat mit Quellenbezug
- Routing für natürliche Chat-Anfragen
- General-Knowledge- und Metadaten-Sichtbarkeit als aktive Baustelle
- Auth/RBAC-Grundschutz
- Rollen admin, operator, reader und auditor
- geschützte Bereiche für Ops, Memory und Dashboard-Daten
- abgesicherte mutierende Aktionen
- standardmäßig blockierte Executor-/Tool-Ausführung
- Audit- und Evidence-Dateien
- Release-, Restore- und Rollback-Gedanke
- klare Trennung zwischen Live-Betriebsstatus, historischen Ledger-Snapshots, Evidence und Entwicklungsline
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. |
| Project-Context-Ledger | Projektartefakte, Entscheidungen, Evidence-Registries, Script-Registries und offene Tracks read-only 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 | Risk-Gates, STOP_ALL, blockierte Shell-Ausführung und Freigaben definieren. | Automatisierung bleibt kontrolliert und auditierbar. |
| 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-Ausführung aus Modellantworten bleibt deshalb standardmäßig blockiert. Verändernde Schritte gehören in geprüfte Skripte, Evidence, Freigaben und Rollback-Pfade.
Nächste Entwicklungsstufe
NQIS als Prüf- und Verbesserungsinstanz für Nova-Agenten.
Das verbindliche Zielbild sieht vor, dass Nova-Agenten, Skripte und Tools vor produktiver Ausführung durch NQIS geprüft werden. Bewertet werden Sicherheit, Qualität, Kompatibilität, Testbarkeit, Auditierbarkeit und Governance-Konformität. Ausführung soll nicht blind erfolgen, sondern über klare Stufen, Nachweise und Freigaben.
Code-Prüfung
Shell- und Python-Skripte werden vor Ausführung analysiert. Riskante Muster, fehlende Fehlerbehandlung oder unklare Seiteneffekte werden markiert.
Freigabe-Gate
Änderungen sollen nur nach Prüfung, Evidence und optionaler manueller Zustimmung produktiv übernommen werden.
Rollback-Pfad
Jede Änderung wird gegen eine Baseline gedacht. Bei Verschlechterung muss ein Rückweg vorhanden sein.
Grenzen
Realistische Einordnung
Entwicklungsstand: NQIS ist ein wachsendes lokales Projekt mit intern live 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: Selbstverbesserung wird als kontrollierter, freigabebasierter Prozess verstanden – nicht als unbeschränkte Selbständerung.
Öffentliche Kommunikationslinie
Prüfbare Assistenz statt überzogener KI-Behauptung.
NQIS wird öffentlich als lokale, auditierbare KI-/Ops- und Orchestrierungsplattform beschrieben. Nova ist die Bedien- und Assistenzidee darüber. Es wird keine AGI, kein Bewusstsein, kein echtes Erleben und keine unkontrollierte Autonomie behauptet.