Local‑first
Eigene Infrastruktur, lokale Dienste und reduzierte Datenabflüsse. Cloud-Dienste sind für das auf dieser Seite beschriebene Konzept nicht zwingend erforderlich.
Technologie
Eine lokale KI‑Architektur für nachvollziehbare Arbeit.
Die technische Idee hinter Nova/NQIS kombiniert lokale Dienste, strukturierte Wissensspeicher, API-Grenzen, Rollenlogik, Sicherheitsgates und Evidence-Dateien. Dadurch entsteht eine KI-Umgebung, die nicht nur antwortet, sondern prüfbar betrieben werden kann.
Local-firstEvidence-firstSafety-first
Evidence‑first
Relevante Fortschritte bleiben durch Statusdateien, Checks, Logs, Prüfsummen, Testausgaben und Release-Artefakte nachvollziehbar.
Safety‑first
Keine direkte Shell- oder Codeausführung aus Modellantworten. Neue Fähigkeiten werden als feste Capabilities mit Policy-, Rollen-, Audit- und Fail-closed-Grenzen eingeführt.
Systemmodell
Von Wissen zu Antwort zu Freigabe.
NQIS/Nova ist auf kontrollierte Abläufe ausgelegt. Kontext, Quellen und Systemzustand werden von Ausführungsrechten getrennt. Antworten und Pläne können entstehen, aber technische Fähigkeiten werden nur über registrierte Capabilities mit festen Schemas, Allowlists, Rollen und Auditpfaden verfügbar. Die aktuell ausgewählte produktionsnahe Stufe A3.0 bleibt ausschließlich lesend.
1Quelle oder lokale Daten aufnehmen
2In Memory, Chunks, Claims und Konzepte strukturieren
3Antwort oder Plan mit Quellenbezug erzeugen
4Risk-Gates und Governance-Regeln anwenden
5Audit-Event und Evidence schreiben
6Bei Bedarf Freigabe oder Rollback-Pfad verlangen
Architekturebenen
Die Plattform besteht aus mehreren klar getrennten Schichten.
Interface
Dashboard, Chat-Oberfläche, Statusseiten und API-Dokumentation. Diese Ebene macht das System bedienbar und beobachtbar.
API & Orchestrierung
Routen, Jobs, Ops-Endpunkte und Übergänge zwischen Anfrage, Verarbeitung und Ergebnis.
Memory & Knowledge
Wissensbasis, Chunks, Quellen, Claims, Suchfunktionen und Prüfungen der Datenform.
Modelle & Router
Lokale LLM-Nutzung, Routing-Entscheidungen, Parameter, Fallback-Ideen und Auswertung der Antwortqualität.
Reflection & Decision
Bewertung von Vollständigkeit, Quellenbezug, Unsicherheit, Risiko und nächstem sinnvollen Schritt.
Safety Layer
Not-Aus-Mechanismen, blockierte Tool-Ausführung, Risikogrenzen, Freigaben und Schutz gegen unkontrollierte Änderungen.
Ops & Evidence
Health, Readiness, Logs, Metriken, Testausgaben, versionierte Release-Artefakte, Prüfsummen und Restore-Proben.
Governance
Rollen, Berechtigungen, Auditierbarkeit, Dokumentation und klare Trennung zwischen stabiler Basis und Entwicklung.
Capabilities & Policy
Granulare Registry, feste Eingabeschemas, Ziel-Allowlists, Rollen-/Clientbindung und fail-closed Policy trennen Modellplanung von technischen Rechten.
Warum diese Trennung wichtig ist
Viele KI-Demos wirken überzeugend, solange nur ein Chatfenster sichtbar ist. Für ein lokales System reicht das nicht. Eine belastbare Assistenz braucht Wissen, Rechte, Grenzen, Prüfpfade und einen nachvollziehbaren Betriebszustand. Deshalb trennt NQIS zwischen Oberfläche, Wissen, Entscheidung, Ausführung und Audit.
Diese Trennung verhindert nicht jeden Fehler, macht Fehler aber sichtbarer. Sie erleichtert Tests, Rollbacks, Sicherheitsbewertungen und spätere Erweiterungen.
Release- und Prüfgedanke
Neue Funktionen sollen nicht unkontrolliert in den stabilen Stand wandern. Ein Release-Stand wird eingefroren, geprüft, mit Evidence versehen und archiviert. Entwicklungsstände bleiben getrennt, bis sie belastbar genug sind.
Ein breiter Entwicklungsprototyp wurde deshalb nicht direkt produktiv angebunden. Nach Capability-, End-to-End- und Sicherheitsprüfungen wurde A3.0 Read-only als kleinste produktionsnahe Stufe gewählt; Codeausführung bleibt mangels nachgewiesener sicherer Sandbox deaktiviert.
Roadmap
Aktuelle Entwicklungsrichtung
Heute · produktiv
Grounded, lokal, prüfbar
v2.2-RC-Runtime, API, Dashboards, Memory/Knowledge, Grounded Chat, Auth/RBAC, Ops und Audit/Evidence bilden die laufende Basis.
Vorbereitet
Capability- und Governance-Schicht
Granulare Capabilities, Policy-Grenzen, strukturierte Änderungspakete, Task-State und Sicherheitsprüfungen wurden isoliert erprobt. Unsichere Ausführung bleibt standardmäßig gesperrt.
Aktuell
A3.0 Read-only
28 ausschließlich lesende Capabilities sind vorbereitet. Vor der Produktivaktivierung folgen eine zusätzliche Sicherheitsprüfung und eine schrittweise Einführung, beginnend mit besonders risikoarmen Diagnosefunktionen.
Später
Kontrollierte Aktionsrechte
Schreibende oder ausführende Fähigkeiten benötigen eine getrennte sichere Ausführungsumgebung, ausdrückliche Freigabe, Verifikation und einen belastbaren Rücksetzpfad.