AI Skills & Fences New in 1.0.0
An assistant does not have "access to the plant". It has a resolved set of tools, and four independent things narrow that set. Every one of them subtracts; none of them can widen another.
what its SKILLS select
∩ what its REALM permits
∩ what the ADMINISTRATOR has switched on
∩ what the PERSON ASKING already holds
The result is never larger than any single term. On top of that, each instance — a chat widget on a screen, an AI node in a pipeline — carries fences saying which tags, databases, external systems and specialists it may reach.
The intersection above decides what the model is offered. Every individual call is re-authorized on the server when it is made, against the same permissions and fences. A tool that should not have been offered still cannot be used.
Skills
A skill is one coherent job an assistant can do, and it selects a group of tools. You plug skills into an instance; you do not pick tools.
Everyday reads
| Skill | What it gives |
|---|---|
| Tags & Namespace | Read live tag values and browse the namespace |
| Plant Vocabulary | Turn what operators call something into what the system calls it |
| History & Trends | Historian trends and aggregates over a time range |
| Alarms & Root Cause | What is alarming now, what alarmed before, and the stored cause→consequence links |
| Knowledge Base | Search uploaded manuals, SOPs and reference documents |
| Saved Queries | Run reports an engineer already wrote and saved |
| Files & Library | List and read files in the uploads store and asset library |
| Playbook Checks | Calculate the figures a playbook's checks define, exactly, on the server |
| Specialists | Run focused assistants your engineers saved |
| External Systems | Look things up in an ERP, a CMMS or another connected system |
Engineering
| Skill | What it gives |
|---|---|
| Database Explorer | Explore the schema and write free-form read-only queries |
| View Authoring · Pipeline Authoring · Alarm Authoring · Query Authoring | Help build each of those, as proposals |
| P&ID Drafting | Draw diagrams to ISA-5.1 using this plant's symbol library |
| Tag Write · Data Write · File Write | Suggest a change — a person still approves it |
Database reach is deliberately split in two. Database Explorer authors free-form SQL and is available only on the platform; Saved Queries runs what an engineer already wrote, and is available everywhere. That split is the entire reason a pipeline node or an HMI widget can touch a database at all.
The four authoring skills stay separate rather than collapsing into one "Engineering" skill, so an assistant can be given alarm rationalization without also being handed view and pipeline authoring.
Tool selection stays reliable at roughly ten to twenty tools and degrades well before fifty. The AI node warns past five plugged skills and refuses past eight — a node that needs more is a signal to split it in two, or to hand part of the question to a Specialist.
Realms
Where an assistant runs is the one term in the intersection that is hardcoded, not configured. Some capabilities are engineering activities rather than operating activities, and must be structurally unreachable where nobody is supervising — so that no misconfiguration anywhere can expose them.
| Realm | Who is there | Notes |
|---|---|---|
| Platform | An authenticated engineer, at a keyboard, who typed the message themselves | The only realm where free-form SQL is reachable |
| Runtime | An operator at an HMI chat widget — a panel physically reachable by everyone on shift | |
| Pipeline | An unattended AI node | The most exposed of the three |
The pipeline realm being the most exposed is the opposite of the intuition. On the platform a human writes the prompt; a pipeline's input is a vendor webhook, an MQTT payload or an email body that nobody read first. So free-form SQL and every write stay out of it — the node emits a decision, and a deterministic node downstream performs any action. The pipeline graph an engineer drew is the authorization artifact.
Options a realm forbids never appear in the editor, and the same ceiling is enforced again at the tool level, independently, so a mistake in the skill mapping still cannot get past it.
Capabilities — the administrator's switchboard
Settings → AI Assistant carries one switch per capability, applying to every assistant on the
installation. This is also the kill switch: turning one off withdraws it everywhere, immediately.
| Capability | Default |
|---|---|
| Read tag values · Browse namespace · Read historian · Read alarms | On |
| Read files · Search knowledge base | Off |
| Calculate playbook checks · Ask specialists | Off |
| Let the assistant call external systems | Off |
| Propose tag writes · saved queries · views · pipelines · alarms · tag relationships · file writes | Off |
Everything that did not exist in an earlier release arrives off, so an upgrade never silently widens what an installation's assistants can do.
Database read and write are not on this 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 — and because a connection can carry a separate read-only credential for the assistant. → AI assistant
Fences — the instance's own limits
A capability says what may be done anywhere. A fence says what this assistant may reach. Every
fence is fail-closed: empty means nothing, and "everything" is stated explicitly with *.
| Fence | Limits |
|---|---|
| Tag scope | Which namespace folders and tags it may read |
| Connections | Which database connections it may query |
| External systems | Which named endpoints it may call |
| Specialists | Which saved specialists it may run |
It now means nothing, and that is not backward compatible. A screen or pipeline node saved before the change meant everything and now means nothing.
That direction is the safe one to get wrong: an assistant that suddenly cannot read a tag says so, in front of the person who can fix it, whereas one reading more than intended is silent. But it does mean existing authors must pick Everything explicitly.
How a tag fence behaves
Reads are refused outside the fence — a tag value, a trend, the relationship graph, a proposed write.
Discovery is filtered, not refused. Namespace browse and tag search still work; out-of-fence tags are simply invisible. Refusing them outright would break the loop the assistant is told to follow — search first, then read exactly what came back — and push it toward guessing a path instead.
The tag scope, the connection fence and the endpoint fence are separate questions on purpose. An assistant fenced to Line 1's tags may still need the maintenance database, and one that reads the ERP may have no business reading tags.
Fences matter most on a pipeline node
A node's prompt is a vendor webhook or an email body nobody read, so text inside it can steer the
model toward a different connection or a different external system on the same installation. Give a
node the one database and the one endpoint it needs, and never *.
Role ceilings
On an HMI chat widget you can hand the decision to the operator's own runtime roles instead of
the screen's settings. Tick the roles decide on the widget and its skills and fences are replaced
by the union of the ceilings configured for the roles that operator holds, in
Settings → Identity & Access.
Two things follow from that:
- An operator holding two roles gets the union — the widest of what they hold. This matches how the runtime write level already works; a second, opposite rule for one identity is the kind of inconsistency that produces a support ticket nobody can reproduce.
- A role with no AI profile configured contributes nothing, and a union of nothing is nothing — so an operator holding only that role gets an assistant that can do nothing. That is the correct fail-closed reading, but it looks broken rather than unconfigured, so the Designer warns about roles with no profile before the screen ships.
The trade this makes is that a screen cannot be narrower than a role: with the box ticked, a maintenance engineer gets their full role reach on every screen that ticks it.
What is deliberately not offered
An unattended assistant must not simultaneously hold private data, untrusted content and a way to talk to the outside. A QUBIQ assistant already holds the first two by construction — it reads live tags and historian data, and tag descriptions, alarm text and uploaded PDFs are all attacker-influenceable. So the third leg is the one under our control, and it is classified per skill and checked structurally: an external-egress skill cannot be plugged alongside an internal one in an unsupervised realm.
That is why Named Endpoints is built the way it is — the model selects an operation by name and can neither compose a URL nor invent a destination — and why it does not count as external egress.
See also
- AI assistant — configuration and governance
- AI playbooks — writing the procedure down once
- AI specialists — saved sub-assistants
- External systems — reaching an ERP or a CMMS
- AI node — the unattended realm