Core concepts

A few concepts recur throughout nivq. Learn these and the rest of the docs read easily.

Workspace

A workspace is the top-level tenant boundary. Members, agents, data sources, billing, and the audit log all live inside a workspace, and nivq enforces isolation between workspaces at five layers (auth, routing, query, storage, and audit). A user can belong to several workspaces with a different role in each: OWNER > ADMIN > MEMBER.

Agent

An agent is a configured assistant inside a workspace. Each agent is bound to:

• one data source (an external database it may read), and
• one LLM provider (the model it reasons with).

This is why two agents in the same workspace can talk to different databases with different models. See Configuration for how providers are wired.

Data source

A data source is a connection to an external database nivq reads from (PostgreSQL, MySQL, and more). Connections are encrypted at rest with AES-256. nivq generates and validates SQL against the data source through a guard before executing — and only read statements pass.

Governance & the approval queue

nivq is read-only by design. Any operation that would mutate data, or any new pattern the agent wants to "learn", is parked in a human approval queue. Nothing is applied until a person approves it. This is the core promise: the agent reasons and proposes, a human decides.

Audit log

Every SQL validation, execution, and permission denial is written to a per-workspace, partitioned audit log. It is designed for compliance review (KVKK / BDDK / GDPR / EU AI Act) and never silently dropped.

Licence

Each nivq deployment runs under a signed licence that defines the validity window and quotas (workspaces, agents, users, features). Enforcement is unconditional — a deployment cannot run unlicensed. With no licence installed, nivq boots into activation-pending and unlocks once a valid licence is uploaded. See Licensing & activation.