AI Architecture (Advisory-Only)

AI in Consystence is advisory and diagnostic only. It can configure, query, and explain — it can recommend an action, surface an anomaly, or predict a failure — but it never commands equipment. Every control action reaches the field through the deterministic controller path, and an operator acknowledges and executes it. This boundary is architectural and is the first thing to understand about the whole subsystem.

Advisory-only boundary

No AI output is wired to a control write. Models produce text, classifications, and structured recommendations; they do not actuate anything. Hard interlocks live in IO modules and safety relays on the deterministic control path — not in software, and never in a model.

What AI is used for

The platform uses LLMs for a small, bounded set of operator- and engineer-facing tasks:

• Configuring — drafting device-type definitions, tag mappings, and engineering-model structure (see /device-types/). The plant-reconfiguration tools are held at the admin role and apply their changes when an admin invokes them.
• Querying — natural-language questions over historical and live telemetry, returning read-only answers.
• Classifying — roadmap: high-volume, cheap labelling of events and readings (for example, anomaly triage). No automated classification pipeline ships yet.
• Explaining — narrating what an alarm or trend means, so an operator can decide what to do.
• Server-driven UI assembly — helping compose the semantic UI tree that the server renders to every client (see /architecture/multi-renderer/).

The human gate differs by category. Control actions are propose-only: the agent can propose a command, but it never actuates — the proposal is marked as requiring confirmation, and the operator executes it through the control panel. Controller code deployments get the same treatment: an AI-proposed deployment is held server-side as a validated proposal, and a separate, role-gated operator confirmation — outside the model’s reach — executes it. Other configuration is role-gated, not confirmation-gated: the remaining reconfiguration tools are held at the admin role and apply their changes when an admin invokes them, so the human gate there is the role and the chat request, not a separate review/apply step. The control write itself always remains human and deterministic. External AI clients can also connect through the platform’s MCP server, which is read-and-propose only — it can read plant state and propose a command for an operator to review and execute, never execute one itself. See the MCP server.

The IO advisory chatbot

IO is the standalone, tenant-scoped advisory chat on the consystence.io plane, separate from the in-product agent. The consystence.io apex is the sign-in front door — it resolves the signed-in user’s org memberships and requires an explicit tenant selection when membership is ambiguous — and each tenant then chats at its own {slug}.consystence.io address, provisioned automatically with the tenant. Like every advisory surface, it grounds its answers exclusively through the read-only cell data seam, so it is structurally incapable of a control write.

Not yet generally available

IO ships with the platform’s launch gates still on — treat general availability as pending.

The tiered advisory plane

A completion request resolves to a tier chosen per call: a site-local grounded advisory at the plant, and a two-rung cloud ladder above it. The tiers are genuinely different capabilities, not just price points:

• Site-local — grounded. A small model runs on-site and answers from plant state the platform pre-fetches for it (process overview, active alarms) rather than by calling tools. It is cheap, private, and offline-capable — its inference stays at the plant, so a site keeps advisory even with no internet link. It reasons over real data; it does not drive tools. This tier is proven on-site, and converges on the cloud ladder’s non-apex model as roadmap.
• Non-apex — the cloud workhorse. An onshore cloud model for everyday advisory questions. Today it answers grounded advisory only; letting it call the platform’s read-only tools for its own multi-step retrieval is gated behind the platform’s tool-use fidelity evaluation and remains roadmap.
• Apex — frontier reasoning. The strongest reasoning model, for the hardest diagnostic and explanatory questions. Tool-grounded, multi-step retrieval over telemetry, historian, and configuration runs on this tier today.

Which tiers a tenant may use is an entitlement: a plan includes some tiers and meters usage, and access to a higher tier can be gated or purchased. The cloud cell enforces that entitlement before any cloud model runs — it refuses a tier a tenant is not entitled to, and refuses once a tenant’s usage allowance is exhausted. Because the model behind each tier is a per-tenant configuration choice, changing or restricting it is configuration, not a rebuild.

Onshore inference and residency

The platform’s primary region is Azure australiaeast, and the advisory plane keeps model inference onshore: the site-local tier runs at the plant, and the cloud tiers are served by stateless advisory gateways that invoke their models in Australian cloud regions — so a tenant’s prompts are reasoned over in the same jurisdiction as the rest of the platform, never shipped offshore. A residency-bound tenant can be pinned to the on-site or an onshore tier; and where a boundary matters you can disable the AI providers entirely — the platform’s control and data paths are unaffected by AI availability (it degrades, it does not gate).

Every cloud advisory call writes an onshore, tenant-scoped advisory-audit record — caller, tenant, the model and inference region, and content hashes of the prompt and completion — to a separate, access-restricted store. This is the evidence base for the advisory-only claim.

How a site reaches the plane

All LLM traffic on a server flows through an in-process router that resolves the right tier for each request and falls back cleanly when a provider is unhealthy. A site with direct internet access can call its configured providers itself. A site behind a locked-down corporate firewall relays its cloud-tier calls through the cloud cell, which authenticates the site, meters per-tenant usage, and forwards the call to the advisory gateway. If the site’s local tier is unreachable, the router falls back to a cloud tier; if a cloud provider is unhealthy, it fails over to the next available one. The site never talks to the regional gateway directly — the cloud cell always sits in front of it.

flowchart TD
  req[Completion request] --> router[In-process router]
  router --> floor[Site-local tier<br/>grounded · offline-capable]
  router --> cloud[Cloud cell<br/>auth · entitlement · metering]
  cloud --> gw[Regional advisory gateway<br/>onshore inference]
  gw --> tools[Read-only data seam]
  tools --> gw
  floor --> out[Advisory output:<br/>text / classification / recommendation]
  gw --> out
  out -. never a control write .-> field[Field equipment]

The read-only data seam is the load-bearing safety property: whichever tier answers, it grounds its response through a credential that can read telemetry, historian, and configuration but cannot reach the control-write surface. So no tool wiring, prompt injection, or gateway compromise can turn an advisory call into a setpoint change — advisory-only is a structural property of the granted scopes, not a prompt instruction.

Advisory billing is pre-GA

The advisory tiers — and the offline-capable site-local tier — are proven, and the entitlement and usage metering that gate the paid tiers are live and enforced. Self-serve purchasing sits behind the platform’s launch gates. A site running its own local tier, or configured direct to a provider, is unaffected.

Edge ML

On-edge inference is on the roadmap, not shipped. The planned model is cloud-trained ONNX timeseries models executed on the edge runtime (CPU on the PLCnext VL3; GPU-capable on the Nvidia Orin variant), kept strictly advisory. No on-edge TensorRT/ONNX runtime ships today. See /edge/edge-ml/ for the planned shape.

Note

Edge ML inherits the same boundary as cloud LLMs: it classifies and predicts, it does not actuate. Whether a model runs in the cloud or on an edge device makes no difference to the control path.

The advisory-only boundary

Industrial safety standards (IEC 61511, ISO 13849) and mining regulation require that safety-critical actions have a deterministic, auditable control path. Models are probabilistic and opaque, so the platform makes the rule explicit and architectural:

• AI — both the site LLM and any future edge ML — is advisory and diagnostic only.
• It recommends, explains, and predicts; it cannot directly command equipment.
• All control actions go through the controller via the established deterministic path; the operator acknowledges and executes.
• The AI chat surface is read-only from a control perspective. Alarm acknowledgement is an operator action, never an AI action.
• Hard interlocks live in IO modules and safety relays, outside any software model.

This is the same boundary stated at the top of this page, and it is the load-bearing constraint of the AI architecture. For how AI fits the wider platform, see /architecture/overview/.