Local runtime
Operation on owned infrastructure with local API, dashboard/ops views and separated release states.
Updated: September 19, 2026Sovereign AI.
Sovereign AI.
Local. Auditable. Human-governed.
pumm.group documents Nova and NQIS as a private project for local AI systems. The focus is controlled knowledge intake, traceable decisions, technological sovereignty and a clear separation between vision, prototype and evidenced development state.
Overall concept
Nova is the idea. NQIS is the auditable foundation.
The project combines a long-term assistant vision with a technical platform that can be reviewed, limited and improved. Nova describes the desired interaction: understandable, personal, local and source-aware. NQIS describes the technical operating model: knowledge base, API, roles, safety boundaries, audit logs, evidence files and release checks.
The project makes no inflated AI claims: it does not present an all-knowing AI, technical consciousness or unlimited autonomy. The focus is a local and traceable AI environment where sources, decisions, changes and risks remain visible.
The three layers
- Nova
- Vision and interaction model for a local assistant that can explain, organize knowledge and support long-term work.
- NQIS
- Technical platform with grounded chat, memory/knowledge, Auth/RBAC, ops checks, evidence and safety gates.
- pumm.group
- Private project frame for documentation, book context, development state and clear positioning.
Current state
What is live today and what is prepared next
NQIS runs as a local auditable AI and operations platform on the v2.2-RC line. API and dashboard views are active. Grounded/stateful chat, knowledge access, persistence, central Auth/RBAC, audit/evidence and planning/governance components form the productive base. In addition, an A3.0 read-only candidate has been prepared with 28 fixed read-only capabilities, immutable target allowlists, role/client binding, redaction, audit and a feature-gate contract. It is not productively enabled yet.
Knowledge base
Memory, knowledge, sources, chunks and shape checks form the basis for traceable answers.
Grounded chat
Answers are derived from available context. Uncertain current questions are not invented without reliable sources.
Auth/RBAC
Roles such as admin, operator, reader and auditor separate visibility and mutating actions.
Safety layer
Direct tool or shell execution from model output remains blocked. Mutating actions require rules and approvals.
Audit & evidence
Check results, status files, logs and evidence artifacts make development and operation more traceable.
Restore & rollback
Archived states, checksums and restore probes reduce the risk of uncontrolled changes.
A3.0 read-only
A controlled read-only diagnostic layer is prepared for system, health and status inspection. It has been prepared and tested, but is not yet productively enabled.
Why local?
More control, less dependency, better traceability.
Local AI is not an end in itself. The key value is stronger control over data flows, models, sources, logs and system changes. This creates a different operating model than pure cloud chatbots: less black box, more responsibility and more technical accountability.
For Nova, personal assistance is therefore not only conversation, but a controlled environment with source grounding, safety logic and visible limits. For NQIS, every new capability has to fit architecture, tests, roles, evidence and rollback paths.
Technically evidenced: local operation, v2.2-RC runtime, health/readiness checks, dashboard views, grounded and stateful chat, knowledge base, central Auth/RBAC, audit/evidence and an isolated A3.0 read-only candidate with 28 capabilities.
Deliberately limited: no AGI claim, no technical proof of consciousness and no uncontrolled autonomy. Code execution, shell access, file mutations, service actions and productive changes remain blocked.
Development principle
New functions are not simply activated; they are checked against existing baselines, safety rules and traceability.
Roadmap
Controlled self-improvement instead of blind automation.
Phase 1 · productive
Local foundation
Runtime, API, dashboards, memory/knowledge, grounded chat, Auth/RBAC, audit/evidence and separated release states form the productive base.
Phase 2 · prepared
Capability and governance model
Granular capabilities, policy boundaries, change packages, task orchestration and security reviews were built and tested in isolation. Unsafe code execution remains fail-closed.
Phase 3 · current
A3.0 read-only
28 strictly read-only capabilities are prepared and not yet connected to production. An additional security review will precede activation, with the first rollout limited to a small set of low-risk diagnostic functions.
Later
Controlled extended autonomy
Mutating or executable capabilities require separate isolation, explicit approval, verification and a robust rollback path before they can be considered.