AI Assistant
QUBIQ includes an AI assistant that can answer questions about your plant and draft configuration. Its defining property is that it proposes changes rather than making them: a human approves before anything is applied.
It appears in three places, and they are not equivalent — see realms:
| Where | Who is asking |
|---|---|
| The platform assistant | An engineer, at a keyboard |
| An AI Chat widget on a screen | An operator, on a panel anyone on shift can reach — in chat mode, or with a live dashboard beside the chat 1.0.8 |
| An AI node in a pipeline | Nobody — the input is a webhook, an MQTT payload or an email body |
This page is about governing it. Five companion pages cover the rest:
| Page | Answers |
|---|---|
| Skills & fences | What an assistant is allowed to do, and what narrows it |
| Live dashboards | A dashboard an operator asks for in words, beside the chat |
| Playbooks | How to write an answer procedure down once |
| Specialists | Saved sub-assistants it can hand a sub-question to |
| External systems | Letting it look something up in an ERP or a CMMS |
Configuration
The assistant is configured in Settings → AI Assistant. Reading and changing its configuration — the model,
its credentials, and which connections it may reach — requires Manage AI Settings. Using it
requires Use AI Assistant.
Manage AI Settings is super-admin only by default, because it exposes billable API credentials and the assistant's kill switch.
Max output tokens New in 1.0.8
Each model profile can carry Max output tokens — the most one answer may hold, thinking included. Leave it blank (Auto) and Claude models use their own limit while every other model gets a safe 8,192. That is too little for a thinking model such as DeepSeek V4, which can spend all of it thinking before it writes a word of the answer; set its documented limit instead. The 32k and 64k chips fill in the usual values.
The setting applies to everything that uses the profile: the chat, AI nodes, the Symbol Editor's Ask AI, and the assistant drawing a symbol. Saving any other AI settings card keeps it; until 1.0.8, saving the embedding (RAG) settings reset every profile to automatic.
An answer that reaches the limit says so. Changed in 1.0.8 The partial answer is kept and ends with a note naming the limit and suggesting to ask it to continue or to narrow the question. Before, it stopped mid-sentence, which looked like a crash — and on Gemini could not be detected at all. A specialist cut off the same way is reported to its caller as cut short.
Governing what it can reach
Per-connection access
Each connection is individually allowed or denied to the assistant. A connection the assistant cannot see does not appear in its context at all.
Deny by default and allow deliberately. The assistant does not need your ERP.
Read-only credentials
SQL, MongoDB and QuestDB connections can carry a second, read-only credential the assistant uses instead of the primary one.
Connection "MES"
primary: qubiq_rw (used by pipelines)
AI: qubiq_ro (used by the assistant — SELECT only)
Test it separately with Test AI credential on the connection (needs Edit Connection) — the normal test only validates the primary login.
If the assistant may explore a production database, give it an account that cannot write. Enforce it at the database, not by instruction.
The propose-and-approve model
For anything that changes the system, the assistant produces a proposal. A human reviews it and approves or rejects.
Listing, approving, rejecting and abandoning proposals all require Use AI Assistant.
Proposals cover views, pipelines, alarms, named queries, tag relationships, file writes, tag writes and database writes — and 1.0.8 new tags, tag types, MQTT publishers and library symbols. Nothing in that list is applied without approval.
Tags, tag types and broker publishing New in 1.0.8
In the Designer the assistant can draft namespace configuration. Each kind is its own capability, off by default, and every approval goes through the same services the Designer's own screens use, so a proposed tag is polled, historised and alarmed exactly like one a person created.
| Proposal | What the approval card tells you |
|---|---|
| A tag — internal, expression or device | Its path, type and source. An expression is compiled against the live namespace when it is proposed and again when it is approved. A device tag's connection is checked; its address is not, because that means talking to the equipment, and the card says so. Folders the path implies are created with it, and the card says how many. |
| A tag type (UDT) — define one, or apply one to a machine | Applying one creates real tags, and the card says how many. Editing an existing type is not offered: it changes every instance, and belongs in the Designer where they are on screen. |
| An MQTT publisher — which tags go to which broker | It is always created switched off; nothing leaves until a person turns it on. The broker connection must already exist, and an empty or * tag scope is refused. |
Approving a tag or a type needs Manage Namespace; approving a publisher needs Create Connection. A proposed device tag or publisher is held to the assistant's own connection fence, so it cannot bind a tag to equipment, or publish to a broker, that the assistant itself could not read.
Symbols New in 1.0.8
"Draw a ball valve for the library": the assistant draws it, the server checks the drawing with the same rules as the Symbol Editor's Ask AI, and a drawing that fails goes back to the model to fix. Approving the proposal opens the Symbol Editor on an unsaved new symbol; nothing is saved until someone clicks Add to library. It needs the Create symbols capability, the Symbol Authoring skill, and Manage Symbol Library to approve.
Review proposals properly. A plausible-looking alarm setpoint or SQL statement is exactly the kind of thing that reads fine and behaves badly. The approval step is only worth something if it is a real review.
The capability switchboard
Settings → AI Assistant carries one switch per capability, applying to every assistant on the
installation. Anything that did not exist in an earlier release arrives off, so an upgrade never
silently widens what your assistants can do.
Reads
| Capability | Default |
|---|---|
| Read tag values · Browse namespace · Read historian · Read alarms | On |
| Read files | On 1.0.6 |
| Search knowledge base | Off |
| Ask specialists | Off |
| Build dashboards — live dashboards on an AI Chat widget | Off 1.0.8 |
| Let the assistant call external systems | Off |
Calculate playbook checks is gone. Removed in 1.0.8 An exact figure is now a compute specialist's job, and every saved check was converted into one. → Playbooks
Changed in 1.0.6 It is a read, and it was the only read that was not on — so an engineer building a specialist found Files & Library greyed out and had to go and ask an administrator to switch on a read.
Three things bound the change. It is only the default, so an installation where anybody has ever saved AI settings keeps the answer they gave, off included. Both file tools still require Manage File Library, an administrative permission an operator cannot hold, so this changes which administrator ticks a box rather than what an ordinary user can reach. And it is reads only — writing a file is still a proposal a human approves.
Search knowledge base is deliberately not included. Its tool needs only View Namespace, which nearly every identity holds, so defaulting it on would be a real widening of what the ingested document set is exposed to. That one stays an explicit decision.
Proposals — every one of these produces a proposal a human approves, never a change:
| Capability | Default |
|---|---|
| Propose tag writes · saved queries · views · pipelines · alarms · tag relationships · file writes | Off |
| Create symbols · Propose tags · Propose tag types (UDT) · Propose broker publishing | Off 1.0.8 |
Database read and write are not on that list. They are decided per connection, in a matrix, because "may read the MES, may not read the ERP" is the question people actually have.
Turning a capability off is the kill switch for it: it is withdrawn from every assistant, every widget and every pipeline node at once.
→ Skills & fences for how a capability combines with an assistant's skills, its realm and the asker's own permissions.
What it works from
The assistant is given the generated component catalog and the scripting API reference, kept in lockstep with the product, so it works from the real surface rather than plausible invention. Tag search uses your tag descriptions — another reason to write them.
Where a value comes from. New in 1.0.7 Reading a tag tells the assistant its source — device, internal or expression — and for an expression tag, the formula and the tags it reads. Before, every tag looked alike to it: it could not say why a value never changes, why a write would be refused, or that a number is derived rather than measured, and it would describe a computed value as though a sensor had produced it. This matters most for tags created by a UDT, which is how most internal and expression tags come to exist. An expression tag with no formula is reported as broken — it will never produce a value — rather than as merely empty.
Saved query refusals reach it. Changed in 1.0.7 When the assistant calls a saved query without a required parameter, it is now told which one, with its type, its meaning and the known values, and can ask or fill it in. Database errors are still withheld from it. → Declared parameters
Saved query times on QuestDB are bound in UTC. Changed in 1.0.8 A saved query the assistant ran on a QuestDB connection with a time window — today, last 7 days — or a point-in-time parameter could return no rows, with no error, when the server was not on UTC, and the assistant reported the empty answer as true. Times are now bound in UTC on QuestDB. They are the same instants; other databases are unchanged.
Gateway variables. New in 1.0.8 With the Gateway Variables skill the assistant reads the values pipelines and scripts keep in variables — a counter, the current batch, a KPI — in one call instead of a database query. It sees its own project's variables and the global ones, up to 50 by name or 500 in a listing, and a value over 4 KB is previewed. A name that is not set is reported as not set; the assistant is told never to supply a value for it. It is covered by Browse namespace, so it needs no capability of its own.
Conversations
Chatting, and listing, reading or deleting past conversations, all require Use AI Assistant. Conversations are per user.
Throughput
Settings → AI Assistant → AI Throughput & Limits bounds how much AI work runs at once, and shows
whether the current limits are holding — in use, peak, and whether a limit is the thing you are
hitting.
| Limit | Default | Set it |
|---|---|---|
| Concurrent chat turns | 8 | People are usually reading, not asking — concurrency is far lower than user count. |
| Concurrent AI node runs | 4 | Below chat turns, on purpose: someone waiting at a keyboard should win. |
| Concurrent tool calls | 24 | Above the other two combined — one turn can make a dozen lookups. |
| Concurrent specialist runs | 8 | A specialist is a whole second conversation. 1.0.8 |
| Specialist runs per person | 3 | One caller's share of the pool above, so one operator asking several at once cannot use it up. 1.0.8 |
Each is 1–512, and changes reach the AI services within about 30 seconds without a restart. Changed in 1.0.8 The specialist pool used to be sized at boot and shown read-only, and Concurrent tool calls was saved but never applied; all five take effect now. A per-person share larger than the pool it divides is refused, because it would never bind.
AI service instances (1–16), below the limits, is how many AI service processes run. It is read when QUBIQ starts, so a change needs a restart. Raise the limits first — that is free and instant — and add an instance only when a limit is already high and turns are still refused.
Time limits New in 1.0.8
The AI time limits card, below throughput, sets how long each kind of AI work may take. These were environment variables that took a shell and a restart to change; a change now applies from the next turn.
| Limit | Default | Range | Bounds |
|---|---|---|---|
| Chat answer limit | 180 s | 10–1800 s | One whole question, end to end. Raise this first when the assistant stops before it finishes. |
| AI node limit | 120 s | 10–1800 s | One unattended pipeline run, and the ceiling every AI node's own timeout is capped to. |
| Tool call limit | 30 s | 5–600 s | One lookup, such as a query against a slow database. |
| Compute specialist limit | 60 s | 5–900 s | One compute specialist's calculation. |
The defaults are the values the environment variables had, so an installation that never opens the card behaves as before.
The clocks nest, and the card refuses a set that does not: a tool call must be shorter than both the chat answer limit and the AI node limit, and a compute specialist cannot outlast the chat answer that called it. An outer clock set below an inner one would not fail loudly — the turn would stop with the wrong message.
Raising the AI node limit is what lets a node ask for longer: the node editor's maximum timeout follows it. The browser waits the chat answer limit plus 30 seconds before reporting a lost connection, so a long answer is no longer blamed on the network.
The limits on both cards live with the rest of the AI settings, which a backup does not carry because the same record holds provider API keys. A restore keeps the target's own values.
Audit attribution
Every AI-originated action is recorded with both identities: the assistant as the origin, and the human whose proposal it acted on as the actor.
An AI-initiated change is never anonymous, and the audit journal answers "who approved this" as well as "what made this change".
Data leaving the plant
Using a hosted model means plant context leaves your network — tag names, descriptions, schema detail, query results.
Before enabling it, decide:
- Is that acceptable to your security policy and your customer's?
- Which connections may be included? (Deny by default.)
- Do tag descriptions contain anything confidential?
- Is a self-hosted or on-premise model required?
On an air-gapped network the assistant simply will not reach a hosted provider, which is the correct outcome rather than a fault.
Governance checklist
- Manage AI Settings held by administrators only
- Use AI Assistant granted deliberately, not to everyone
- Connections denied by default, allowed one at a time
- Read-only AI credentials on every permitted database
- Every instance's fences set
explicitly — a fence is fail-closed, so an unset one reaches nothing, and
*reaches everything - No pipeline node fenced to
*on connections or external systems - External systems reviewed: a real pattern on every parameter, and the master switch off unless something needs it
- Runtime roles that carry an AI widget given an AI profile, or their operators get an assistant that can do nothing
- Proposals reviewed by someone competent to judge them
- Data-egress implications signed off
- Audit journal configured, so AI actions are attributable
Disabling it
Revoke Use AI Assistant from every role, or deny every connection. The kill switch lives behind Manage AI Settings, so the assistant cannot be re-enabled by a user who merely uses it.
Next
→ Skills & fences — what an assistant is allowed to do
→ Live dashboards · Playbooks · Specialists · External systems