Stabiler Nachweisstand
v2.0.0‑rc1 steht für den getrennt gehaltenen, stabileren Runtime- und Evidence-Stand. Diese Linie bleibt von experimenteller Entwicklung separiert.
NQIS
Lokale KI‑Plattform mit Audit, Memory und Governance.
NQIS ist der technische Kern hinter dem Nova-Konzept. Die Plattform soll lokale KI-Arbeit prüfbar machen: mit Wissensbasis, Grounded Chat, Rollenmodell, Sicherheitsgrenzen, Betriebsstatus, Evidence und kontrollierten Release-Ständen.
v2.0.0-rc1 Nachweisstandv2.1.1-dev aktivAuth/RBAC-Hardening
Aktive Entwicklung
v2.1.1‑dev konzentriert sich auf Auth/RBAC-Hardening, geschützte Bereiche, Rollenlogik und Governance für mutierende Aktionen.
Kommunikationslinie
NQIS wird als lokale, auditierbare Assistenzplattform dargestellt – ohne AGI-, Bewusstseins- oder grenzenlose Autonomie-Behauptung.
Funktionaler Stand
Vom Experiment zur prüfbaren KI‑Betriebsplattform.
Der aktuelle Stand umfasst mehrere Bausteine, die zusammen eine nachvollziehbare lokale KI-Umgebung ergeben. Entscheidend ist nicht nur, dass eine Antwort erzeugt wird, sondern wie sie zustande kommt, welche Quellen beteiligt waren, welche Rolle zugreifen darf und welche Änderung später rückverfolgbar bleibt.
NQIS ist damit kein einzelner Chatbot, sondern eine Orchestrierungs- und Governance-Schicht für lokale KI-Arbeit. Memory, Knowledge, API, Dashboard, Safety, Evidence und Release-Prozesse wirken zusammen.
Bereits abgedeckte Bereiche
- lokaler Betrieb auf eigener Infrastruktur
- Wissensabruf aus Memory/Knowledge-Basis
- Grounded Chat mit Quellenbezug
- Ablehnung unsicherer aktueller Fragen ohne Quelle
- API-Routen und OpenAPI-Beschreibung
- Dashboard-, Ops- und Statusdaten
- Health-, Readiness- und Ops-Checks
- Auth/RBAC-Grundschutz
- Rollen admin, operator, reader, auditor
- geschützte Bereiche für Dashboard, Docs und Ops
- abgesicherte mutierende Aktionen
- standardmäßig blockierte Executor-/Tool-Ausführung
- Audit- und Evidence-Dateien
- Release-Freeze und Archivierung
- Restore- und Rollback-Proben
- Trennung stabiler Runtime und Entwicklungsline
Architekturprinzip
Jeder Schritt soll begründbar bleiben.
| Schicht | Aufgabe | Nutzen |
|---|---|---|
| Memory & Knowledge | Quellen, Chunks, Claims und Konzepte strukturiert bereitstellen. | Antworten können auf nachvollziehbarem Kontext beruhen. |
| Grounded Chat | Relevante Quellen suchen und Antworten daraus ableiten. | Reduziert Halluzinationen und macht Unsicherheit sichtbar. |
| Ops & Dashboard | Health, Readiness, Worker, Status, Logs und Evidence sichtbar machen. | Betrieb, Diagnose und Wartung bleiben überprüfbar. |
| 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. | Automatisierung bleibt kontrolliert und auditierbar. |
| Release & Evidence | Checks, Freeze-Pakete, Prüfsummen und Restore-Proben dokumentieren. | Änderungen werden messbar, vergleichbar und rückrollbar. |
Grounded Chat
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.
Dieser Ansatz ist besonders wichtig für aktuelle, technische oder sicherheitsrelevante Fragen. Er schützt nicht vollständig vor Fehlern, schafft aber eine bessere Grundlage für Prüfung, Diagnose und Vertrauen.
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.
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.
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, kein öffentlich betriebener Cloud-Dienst.
Qualität: Grounding, Tests und Evidence verbessern Nachvollziehbarkeit, ersetzen aber keine fachliche Prüfung in kritischen Fällen.
Autonomie: Selbstverbesserung wird als kontrollierter, freigabebasierter Prozess verstanden – nicht als unbeschränkte Selbständerung.