Lokale Runtime
Betrieb auf eigener Infrastruktur mit lokaler API, Health-/Ready-Prüfungen, Dashboard-/Ops-Ansichten und getrennten Release-Ständen.
Stand: 19. September 2026
Souveräne KI.
Souveräne KI.
Lokal. Prüfbar. Menschlich geführt.
pumm.group dokumentiert Nova und NQIS als privates Projekt für lokale KI-Systeme. Im Mittelpunkt stehen kontrollierte Wissensaufnahme, nachvollziehbare Entscheidungen, technische Souveränität und eine klare Trennung zwischen Vision, Prototyp und belegbarem Entwicklungsstand.
Gesamtkonzept
Nova ist die Idee. NQIS ist das prüfbare Fundament.
Das Projekt verbindet eine langfristige Assistenzidee mit einer technischen Plattform, die sich prüfen, begrenzen und weiterentwickeln lässt. Nova beschreibt die gewünschte Interaktion: verständlich, persönlich, lokal und quellenbezogen. NQIS beschreibt die technische Arbeitsweise dahinter: Wissensbasis, API, Rollen, Sicherheitsgrenzen, Audit-Logs, Evidence-Dateien und Release-Prüfungen.
Das Projekt erhebt keine überzogenen KI-Ansprüche: Es wird weder eine allwissende KI noch technisches Bewusstsein oder unbegrenzte Autonomie behauptet. Im Mittelpunkt steht eine lokale, nachvollziehbare KI-Umgebung, bei der Quellen, Entscheidungen, Änderungen und Risiken sichtbar bleiben.
Die drei Ebenen
- Nova
- Vision und Bedienidee einer lokalen Assistenz, die Wissen erschließt, Zusammenhänge erklärt und langfristig unterstützend wirken soll.
- NQIS
- Technische Plattform mit Grounded Chat, Memory/Knowledge, Auth/RBAC, Ops-Checks, Evidence und Safety-Gates.
- pumm.group
- Private Projektklammer für Dokumentation, Buchbezug, Entwicklungsstand und klare Einordnung.
Aktueller Stand
Was heute bereits live geprüft und technisch vorbereitet ist
NQIS läuft als lokale, auditierbare KI- und Betriebsplattform auf einer v2.2-RC-Linie. API und zwei Dashboard-Varianten sind aktiv. Grounded und Stateful Chat, Wissenszugriff, Persistenz, zentrale Auth/RBAC-Steuerung, Audit/Evidence sowie Planning- und Governance-Bausteine bilden die produktive Basis. Zusätzlich ist ein A3.0-Read-only-Kandidat vorbereitet: 28 fest registrierte, ausschließlich lesende Capabilities mit Allowlists, Rollen-/Clientbindung, Redaction, Audit und Feature-Gate-Vertrag. Dieser Kandidat ist noch nicht produktiv aktiviert.
Wissensbasis
Memory, Knowledge, Quellen, Chunks, Projektkontext und Statusprüfungen bilden die Grundlage für nachvollziehbare Antworten.
Grounded & Stateful Chat
Antworten werden aus verfügbarem Kontext abgeleitet. Sitzungen und Gesprächsverläufe bleiben getrennt; unsichere Aussagen werden nicht ungeprüft als Wissen übernommen.
Auth/RBAC
Zentrale Rollen für Reader, Operator und Admin begrenzen Sichtbarkeit, Bedienung und verändernde Aktionen.
Safety Layer
Direkte Tool- oder Shell-Ausführung aus Modellantworten bleibt blockiert. Verändernde Aktionen benötigen Regeln und Freigaben.
Audit & Evidence
Prüfergebnisse, Statusdateien, Logs und Evidence-Artefakte machen Entwicklung und Betrieb nachvollziehbarer.
Backup & Rollback
Archivierte Stände, Prüfsummen, Sicherungen und definierte Rückwege begrenzen die Risiken technischer Änderungen.
A3.0 Read-only
Vorbereitet ist eine kontrollierte Lesestufe für System-, Health-, Status- und weitere Diagnosefunktionen. Sie ist technisch vorbereitet und getestet, aber noch nicht produktiv aktiviert.
Warum lokal?
Mehr Kontrolle, weniger Abhängigkeit, bessere Nachvollziehbarkeit.
Lokale KI ist kein Selbstzweck. Der entscheidende Vorteil liegt darin, Datenflüsse, Modelle, Wissensquellen, Logs und Systemänderungen stärker kontrollieren zu können. Dadurch entsteht ein anderes Betriebsmodell als bei reinen Cloud-Chatbots: weniger Blackbox, mehr Zuständigkeit, mehr technische Verantwortung.
Für Nova bedeutet das: persönliche Assistenz wird nicht nur als Gespräch verstanden, sondern als kontrollierte Umgebung mit Quellenbezug, Schutzlogik und nachvollziehbaren Grenzen. Für NQIS bedeutet das: jede neue Fähigkeit muss in Architektur, Tests, Rollen, Evidence und Rollback-Pfade passen.
Technisch belegt: lokaler Betrieb, v2.2-RC-Runtime, Health-/Ready-Prüfungen, zwei Dashboard-Varianten, Grounded und Stateful Chat, Wissensbasis, zentrale Auth/RBAC-Steuerung, Audit/Evidence sowie ein isoliert getesteter A3.0-Read-only-Kandidat mit 28 Capabilities.
Bewusst begrenzt: keine AGI-Behauptung, kein technischer Bewusstseinsnachweis und keine unkontrollierte Autonomie. Codeausführung, Shell, Dateiänderungen, Serviceaktionen und produktive Änderungen bleiben gesperrt.
Entwicklungsprinzip
Neue Funktionen werden nicht einfach aktiviert, sondern gegen bestehende Baselines, Sicherheitsregeln und Nachvollziehbarkeit geprüft.
Roadmap
Die Richtung: kontrollierte Selbstverbesserung statt blinder Automatisierung.
Phase 1 · produktiv
Lokales Fundament
Runtime, API, Dashboards, Memory/Knowledge, Grounded Chat, Auth/RBAC, Audit/Evidence und getrennte Release-Stände bilden die produktive Basis.
Phase 2 · vorbereitet
Capability- und Governance-Modell
Granulare Capabilities, Policy-Grenzen, Change-Packages, Task-Orchestrierung und Sicherheitsreviews wurden isoliert aufgebaut und getestet. Unsichere Codeausführung bleibt fail-closed blockiert.
Phase 3 · aktuell
A3.0 Read-only
28 ausschließlich lesende Capabilities sind vorbereitet und noch nicht produktiv angebunden. Vor einer Aktivierung folgt eine zusätzliche Sicherheitsprüfung; die Einführung soll zunächst auf wenige risikoarme Diagnosefunktionen begrenzt bleiben.
Später
Kontrollierte erweiterte Autonomie
Schreibende oder ausführende Fähigkeiten kommen erst nach eigenständigem Sicherheitsnachweis, isolierter Ausführung, ausdrücklicher Freigabe, Verifikation und belastbarem Rollback in Betracht.