Productive foundation
API, health/readiness, two dashboard variants, grounded/stateful chat, Auth/RBAC, memory/knowledge, operations and audit/evidence form the running core.
NQIS
Local AI platform with audit, memory and governance.
NQIS is the technical core behind the Nova concept. The status as of September 19, 2026 covers a local v2.2-RC runtime with FastAPI API, two dashboard variants, health/readiness endpoints, central Auth/RBAC, grounded and stateful chat, memory/knowledge, operations, audit/evidence and planning/governance components. A3.0 read-only has additionally been prepared and tested as an isolated candidate; it is not productively enabled yet.
Updated Sep 19, 2026v2.2-RC · API & dashboards activeA3.0 read-only · prepared, not yet productive
Capability & governance work
An isolated development branch has been used to test granular system functions with policy boundaries, structured change packages, task orchestration, end-to-end tests and security controls. This branch is not connected to production.
A3.0 read-only
28 strictly read-only capabilities are prepared with fixed allowlists, role/client binding, schemas, redaction, audit and controlled activation. Isolated security and registry tests have passed; the functions are not yet productively enabled.
Functional state
From experiment to reviewable AI operations platform.
The current state contains several building blocks that together form a traceable local AI environment. The important part is not only that an answer is generated, but how it is derived, which sources were used, which role is allowed to access it and which change remains traceable later.
NQIS is not a single chatbot. It is an orchestration and governance layer for local AI work. Memory, knowledge, API, dashboard, safety, evidence and release processes work together.
Covered areas
- local operation on owned infrastructure
- v2.2-RC runtime
- FastAPI API and OpenAPI description
- health and readiness checks
- two dashboard/ops views
- memory/knowledge and grounded/stateful chat
- project context and evidence history
- central Auth/RBAC control
- role and governance boundaries
- planning, task and decision components
- audit and evidence structures
- release, restore and rollback model
- capability registry and fail-closed policy model in the development environment
- structured change packages and bound task state as tested development components
- A3.0 with 28 prepared read-only capabilities
- runner and free code/shell execution technically disabled
- clear separation between the productive base, prepared functions and historical evidence
Architecture principle
Every step should remain explainable.
| Layer | Task | Value |
|---|---|---|
| Memory & Knowledge | Provide sources, chunks, claims and concepts in structured form. | Answers can rely on traceable context. |
| Grounded Chat | Retrieve relevant sources and derive answers from them. | Reduces hallucinations and makes uncertainty visible. |
| Ops & Dashboard | Show health, readiness, workers, status, logs and evidence. | Operation, diagnosis and maintenance remain reviewable. |
| Auth/RBAC | Enforce roles, permissions and protected areas. | Not every role may view or modify everything. |
| Safety & Governance | Apply risk boundaries, emergency-stop mechanisms, blocked shell execution and approvals. | Automation remains controlled and auditable. |
| Capabilities & Policy | Register functions granularly, validate inputs and technically bind allowed targets, roles and clients. | New abilities are introduced as reviewable contracts rather than free-form commands. |
| Release & Evidence | Document checks, freeze packages, checksums and restore probes. | Changes become measurable, comparable and reversible. |
Grounded Chat
Grounded chat means that an answer should not be free text generated without context. Relevant knowledge and memory chunks are retrieved first. If sufficient context exists, the answer is derived from it. If evidence is missing, cautious refusal is safer than an invented claim.
This approach is especially important for current, technical or security-relevant questions. It does not eliminate all errors, but it provides a better basis for review, diagnosis and trust.
Auth/RBAC and protected actions
Role logic separates reading, reviewing and mutating access. A dashboard may display information without automatically triggering productive actions. Mutating actions require stronger boundaries because they can change system state.
The goal is an assistant that can help without acting uncontrolled. Direct shell or code execution from model output remains blocked. The selected production-near path is A3.0 read-only only; mutating and executable capabilities remain productively disabled.
Current development stage
A3.0 read-only: controlled system perception before action rights.
The current development stage deliberately focuses on a clearly bounded first step: Nova should first be able to read fixed system and diagnostic information without modifying files, services, databases or networks. The candidate is prepared and tested in isolation, but not yet connected to production.
28 read-only capabilities
Fixed capabilities, schemas and allowlists constrain filesystem, system, health, Git, journal and other diagnostic access. Activation is intended to be gradual and initially limited to especially low-risk diagnostic functions.
Fail-closed, no fallback
Runner, free shell, code execution, file mutations, Git mutations, HTTP/database writes, and process and service actions remain technically blocked.
Next step
An additional security review will precede productive activation. The initial rollout is intended to include only especially low-risk system, runtime and health queries.
Limits
Realistic positioning
Development state: NQIS is a growing local project, not a public cloud service.
Quality: Grounding, tests and evidence improve traceability but do not replace expert review in critical cases.
Autonomy: The currently prepared A3.0 path is strictly read-only. Code execution and productive changes remain disabled; later action rights require a separate security case.