Answered from what the system does today. Where a lane is built but has not closed on a recorded session, the answer says so.
No. ArcUI runs online and offline. The twin, the contract, the session record and the reasoning layer all run on your own hardware — a model on the machine or on the plant LAN via Ollama — and dictation is transcribed on the device. You can also point it at an external provider with your own API key. Which one you use is a setting, not a rebuild.
No. An agent proposes; a person authorizes. Every action an agent may propose is declared in advance in the operational contract, with its write target, its preconditions and the effect it expects. The operator sees a card naming the evidence behind the proposal and decides. The write is then attributed to the person who authorized it, not to the agent that asked. A playbook you declared in advance can be configured to run by itself; one the system learned never grants itself that permission.
Every session closes as a folder on disk: an append-only journal of every value, action and intervention in the order it happened, a snapshot of the contract in force, and a SHA-256 manifest that can be signed. It replays inside the twin with the original sequence and timing — not a video of it — so an auditor re-reads the session without a database, without our servers and without a licence.
No. The same system runs on three launch profiles: Desktop on an ordinary monitor with mouse and keyboard, VR — PC with a headset driven by the PC, and XR — Passthrough as a standalone headset app. The operator picks one when the session opens, and the sealed session records which surface it was conducted on. Changing surface means closing the session and opening the other profile; a session never switches underneath you.
OPC UA, Modbus TCP, MQTT, Kafka, REST/HTTP and WebSocket, under one provider contract, plus replay from recorded CSV and a tag simulator for offline work. It does not replace your control system or your historian: it reads them. An OPC UA node reporting a Bad status is named rather than written, so an unreadable sensor never reaches the twin as a plausible zero.
ArcUI does not train models. It makes the ones already in use auditable and replayable. The reasoning layer runs on a local model via Ollama, or on Anthropic, Gemini or any OpenAI-compatible endpoint you add with your own key. The model is replaceable; the rules, the authority and the record stay yours.
Less than a connection. ArcUI builds the model from what you already have — the equipment datasheet, the supplier’s AAS submodel, or a few hours reading the plant — so a team can operate and train in the twin before anything is wired. Building with the SDK requires Unity 6000.5 or newer.
No. ArcUI is an interface layer and an intelligence agent. It is not a safety instrumented system and not the interlock of last resort; your existing protection layers keep that job. What it adds is that every authorized change carries the name of whoever authorized it, and the whole shift is on file.
A mitigation that worked during an alarm can become a proposal, carrying the moment in the record that produced it and checked against previous firings of that same alarm. An authorized person accepts, edits or rejects it, and the decision is recorded beside the evidence. Once approved it becomes a deterministic playbook for the next equivalent alarm. This lane is built and unit-tested; no recorded session has closed it yet, so unlike the rest of this page it is described from code rather than from a run.
Yes, over MCP. External clients reach the twin through a published tool surface under the same authentication, contract validation and journalling as any other writer. Read tools answer directly; anything that writes is queued as a proposal for an operator to authorize. Agent participation extends the audit trail rather than bypassing it.