AI Architecture (Advisory-Only)

AI in Consystence is advisory and diagnostic only. It can answer questions about the plant, explain alarms and trends, and propose an action for an operator to execute — but it never commands equipment. Automated anomaly detection and failure prediction are roadmap (see Edge ML). 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.

What AI is used for

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

Engineering questions — explaining device types, controller tags and the engineering model (see /device-types/). The assistant makes no configuration change itself.
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.

The human gate is the same everywhere: the assistant proposes and a person acts. Commands are propose-only: the assistant can propose a command, but it never actuates — the proposal is marked as requiring confirmation, and the operator executes it through the control panel. The assistant does not deploy controller code: nothing in the assistant can deploy a program or confirm a deployment. The assistant does not reconfigure the plant: tools that would register a controller, activate data points, rebind pipeline tags, bind scene elements or manage virtual controllers are not offered to assistant sessions. 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.

IO, the advisory assistant

IO is Consystence’s advisory assistant, in the web console and through a site server (early access). 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.

A separate, standalone IO chat at consystence.io is also planned: one web interface at one address, with no per-tenant addresses. The tenant comes from the sign-in, with a default that a signed-in person can switch. It is not yet publicly available.

The tiered advisory plane

A completion request resolves to a tier chosen per call on the two-rung cloud ladder; a site-local tier at the plant is roadmap. The tiers are genuinely different capabilities, not just price points:

Site-local advisory (roadmap). A model on site hardware. Not available today.
Non-apex — the cloud workhorse. A 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 of its plan, and usage is metered in AI credits. The cloud cell enforces that entitlement before any cloud model runs: it refuses a tier the tenant is not entitled to. Because the model behind each tier is a per-tenant configuration choice, changing or restricting it is configuration, not a rebuild.

Inference location and residency

Hosted operational data is stored in Azure Australia East. Since 26 October 2026, advisory AI requests have been processed outside Australia, a temporary exception to our in-Australia inference rule; the processors and locations are listed at consystence.com/trust. This applies to requests a site server relays through the cloud too. Advisory AI can be left off for a site. A site server can also send a prompt directly to a model provider, including as a fallback, if whoever administers the server enables that in the server’s settings (it is not set from the console); a prompt sent that way is processed where that provider runs. On a site server, advisory AI can be switched off. Site-local inference is roadmap. The platform’s control and data paths are unaffected by AI availability (it degrades, it does not gate).

Every call served through the regional advisory gateway writes a tenant-scoped advisory-audit record — caller, tenant, the model and inference region, and content hashes of the prompt and completion, never the text — to a separate store; the gateway refuses to serve a call if that record cannot be written. Separately, the in-product assistant’s conversations are recorded under the operator’s identity in the platform’s operational journal and kept as a permanent record: each message the operator types, each answer and notice the assistant gives, and a short extract of each tool’s request and result. Text that looks like a credential is redacted. The assistant shows a notice that the conversation is recorded.

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 server with direct internet access can call a model provider itself where its administrator has enabled a direct route in the server’s settings. 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 a provider is unavailable, the router can send the request to another available provider, and it retries a failed call at most once on another provider; when no suitable provider is available, the request fails cleanly. Once a call reaches the cloud cell, neither the cell nor the regional gateway re-routes it to a different provider: a provider failure there fails the request. A request the router sends to a direct provider follows the residency note above. 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/>roadmap · not available today]
  router --> cloud[Cloud cell<br/>auth · entitlement · metering]
  cloud --> gw[Regional advisory gateway<br/>hash-only audit]
  gw --> tools[Read-only data seam]
  tools --> gw
  floor -.-> out[Advisory output:<br/>text / 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. Advisory-only is therefore a structural property of the granted scopes, not a prompt instruction: any command the advisory plane proposes is for a person to review and execute.

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 inference as the baseline, including on the PLCnext VL3 target platform; GPU inference on an Nvidia Jetson Orin where a workload needs it), kept strictly advisory. No on-edge TensorRT/ONNX runtime ships today. See /edge/edge-ml/ for the planned shape.

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 advisory assistant and any future edge ML — is advisory and diagnostic only.
It recommends and explains; it never commands equipment and can only propose a command for an operator to execute.
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 are enforced at the plant, in deterministic controller logic and hardwired safety relays, outside any AI 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/.