Local‑first
Owned infrastructure, local services and reduced data flows. Cloud services are not required for the concept described on this site.
Technology
A local AI architecture for traceable work.
The technical idea behind Nova/NQIS combines local services, structured knowledge stores, API boundaries, role logic, safety gates and evidence files. The result is an AI environment that can be operated and reviewed, not just queried.
Local-firstEvidence-firstSafety-first
Evidence‑first
Progress remains traceable through status files, checks, logs, checksums, test output and release artifacts.
Safety‑first
No direct shell or code execution from model output. New abilities are introduced as fixed capabilities with policy, role, audit and fail-closed boundaries.
System model
From knowledge to answer to approval.
NQIS/Nova is designed for controlled workflows. Context, sources and system state are separated from execution rights. Answers and plans can be produced, but technical abilities are only exposed through registered capabilities with fixed schemas, allowlists, roles and audit paths. The currently selected production-near stage, A3.0, remains strictly read-only.
1Ingest source or local data
2Structure as memory, chunks, claims and concepts
3Create answer or plan with source grounding
4Apply risk gates and governance rules
5Write audit event and evidence
6Require approval or rollback path where needed
Architecture layers
The platform consists of clearly separated layers.
Interface
Dashboard, chat interface, status pages and API documentation.
API & orchestration
Routes, jobs, ops endpoints and transitions between request, processing and result.
Memory & Knowledge
Knowledge base, chunks, sources, claims, search functions and data-shape checks.
Models & Router
Local LLM usage, routing decisions, parameters, fallback ideas and output quality checks.
Reflection & Decision
Evaluation of completeness, source grounding, uncertainty, risk and next steps.
Safety Layer
Emergency-stop mechanisms, blocked tool execution, risk boundaries, approvals and protection against uncontrolled changes.
Ops & Evidence
Health, readiness, logs, metrics, test output, versioned release artifacts, checksums and restore probes.
Governance
Roles, permissions, auditability, documentation and separation between stable baseline and development.
Capabilities & Policy
Granular registry, fixed input schemas, target allowlists, role/client binding and fail-closed policy separate model planning from technical rights.
Why separation matters
Many AI demos look convincing as long as only a chat window is visible. A local system needs more than that: knowledge, rights, boundaries, review paths and a traceable operating state. NQIS therefore separates interface, knowledge, decision, execution and audit.
This does not prevent every error, but it makes errors more visible and supports tests, rollbacks, security review and later extensions.
Release and review model
New functions should not move into the stable state uncontrolled. A release state is frozen, checked, supplied with evidence and archived. Development states remain separate until they are reliable enough.
A broader development prototype was therefore not connected directly to production. After capability, end-to-end and security testing, A3.0 read-only was selected as the smallest production-near stage; code execution remains disabled because a sufficiently safe sandbox has not been demonstrated on the host.
Roadmap
Current development direction
Today · productive
Grounded, local, reviewable
v2.2-RC runtime, API, dashboards, memory/knowledge, grounded chat, Auth/RBAC, operations and audit/evidence form the running base.
Prepared
Capability and governance layer
Granular capabilities, policy boundaries, structured change packages, task state and security checks were tested in isolation. Unsafe execution remains disabled by default.
Current
A3.0 read-only
28 strictly read-only capabilities are prepared. An additional security review and a gradual rollout, beginning with especially low-risk diagnostic functions, will precede productive activation.
Later
Controlled action rights
Mutating or executable capabilities require a separate safe execution environment, explicit approval, verification and a robust rollback path.