Your team operates the system. The recorded shift stays available, and knowledge tools can preserve proposed lessons with their evidence — so the next person does not start from zero.
01 — Operate
People and the assistant run the system. While recording is armed, values and actions are captured with the identity of whoever produced them.
02 — Evidence
The session closes with a SHA-256 manifest over its evidence files. Signing is optional; replay reconstructs the recorded state and timing.
03 — Learn
Use MCP knowledge tools to preserve proposed lessons from recorded sessions, together with their source evidence. Proposals do not change operating rules automatically.
01 — Operate
One twin, three modes.
Live
Connected to the real source — instruments, equipment, control system. What you see is the current state.
Training
The same twin, with faults and events injected to rehearse. Isolation is a property of how the scene is wired, not of the mode: a provider configured for outbound sync still publishes. Rehearse against a scene whose providers only read.
Replay
A recorded session plays back with its original sequence and timing, read-only.
In all three
The same opt-in recording engine is available. When armed, writes within the twin and governed decisions share one evidence path.
02 — Evidence
The session closes as a file you keep.
Attributed
Recorded values name who or what wrote them, and when: an operator in XR, an instrument, an external system, ARIA.
Authorized
Every point declares who may write it. In strict Operations a write from anyone else is refused with an explicit reason and never reaches the DataStore.
Sealed
The bundle carries a SHA-256 manifest and can be signed for tamper-evident custody.
Portable
It replays inside the twin, and it reads without our servers.
Run the MCP knowledge tools on a recorded session to derive proposed updates from operator decisions or telemetry findings. A session does not automatically generate proposals when it closes.
Preserved
Proposals are stored with their source-session references and supporting evidence. They remain identifiable proposals, separate from the operating rules.
In development
Integrated review in Unity, historical checks for learned playbooks and their promotion into executable responses still require implementation and integration. The existing proposal tools do not make that a complete operational workflow.
The rulebook
What governs the loop.
Three things have to be true of the operating rulebook for any of the above to hold. Between them they are the difference between seeing an asset and being able to account for it.
Dependencies
What is part of what, what feeds what, what fails together. Declared as a model of the equipment type, not of one unit.
Ownership
Who — or what — may write each point. Declared up front and enforced where the write arrives, so authority is a property of the data, not a convention.
Evidence
What actually happened, in order, attributed and sealed. Without it the other two are opinions.
ARIA
Ask it about the machine in front of you.
ARIA uses your operational contract and approved documentation, with cited passages available for review. It proposes governed actions for a person to authorize. Separately, deterministic playbooks explicitly configured in advance can run automatically under the declared policy.
Local
A model on your own hardware, via Ollama. No API key, no vendor account, nothing leaves the installation. The model is replaceable; the rules, authority and record remain yours.
External
Anthropic, Gemini or any provider you add to the registry, with your own API key. Your account, your terms with that vendor.
Switching is a setting, not a rebuild.
Which equipment or process would you like to improve?