Architecture
How Mirror OS works
An independent runtime layer, beside your AI.
Mirror OS observes, adjudicates and evidences live AI behaviour from outside the model, the agent and the platform — without replacing your models, platforms or infrastructure.
Three questions
What runs. Where it runs. How Mirror OS is deployed.
Three different questions, often confused. Mirror OS answers each one separately.
The workload
AI agents, orchestration, AI factories, robotics and physical AI, autonomous systems.
The environment
Public cloud, private cloud, self-hosted, sovereign, on-premises and edge.
The path
The agent path (Agent Edition) or the enterprise path (Shield, Runtime, Foundry).
The independent layer
One runtime layer across your AI environments.
In every supported environment, Mirror OS remains the same independent control layer.
What AI runs
MIRROR OS — INDEPENDENT RUNTIME LAYER
Independent · Cross-platform · Cross-model · Cross-environment
Where AI runs
Mirror OS does not replace what you run.
It does not replace Linux or Windows, your AI stack, your models or your agent framework. It is installed and connected beside them, and holds runtime authority independently of each.
Runtime signals
Approved runtime signals, evaluated in context.
Mirror OS uses approved signals from the customer environment and, where required, Stability Data Nodes. Unknown remains a risk state, not evidence of safety.
- Customer telemetry
- AI governance signals
- Platform and orchestration signals
- Stability Data Nodes
- Deployment context
Mirror OS
EVALUATE · CORRELATE · IN CONTEXT
Potential instability surfaced
Surfaced as early as the approved signals allow.
Take action
Contain · mitigate · block or intercept · escalate.
The Runtime Control Loop
Observe → Detect → Govern → Enforce → Evidence → Improve
Platform capabilities are not separate products. Each is delivered by a stage of the loop.
| Stage | What happens | Capability it delivers |
|---|---|---|
| 01Observe | Live behaviour is read from your existing telemetry or from Stability Data Nodes. | Runtime visibility · runtime analytics |
| 02Detect | Approved runtime signals are evaluated together to surface potential instability as early as the available evidence allows. | Runtime signal assessment |
| 03Govern | One policy framework is applied across heterogeneous models, agents and platforms.Determinism · the authoritative path is deterministic | Unified policy across environments |
| 04Enforce | Mirror OS decides what is allowed to happen. The platform carries out the decision.Determinism · statistical signals inform, never decide | Contain · mitigate · block · escalate |
| 05Evidence | In-scope runtime events and authorised control decisions are preserved in a structured evidence trail.Evidence custody · the record stays with you | Evidence and audit trails · operational review · investigation support |
| 06Improve | Runtime evidence informs approved operational improvements without changing authority automatically. | Operational review and improvement |
Deterministic authority
Intelligence does not define its own authority.
Mirror OS adjudicates. The platform executes.
Runtime control is policy-bounded. Model-assisted detection may contribute signals where a deployment permits it, but it cannot create or expand authority. In RSE-based deployments, the RSE adjudicates within the customer-approved boundary; the authorised customer environment executes the resulting action. Agent Edition performs its approved deterministic decisions locally within the deployment.
Deployment components
What arrives in your environment.
- RSERuntime Stability EngineThe central decision engine for RSE-based Mirror OS deployments. It evaluates live runtime signals against customer-approved policies, determines whether an action should be allowed, constrained, stopped or escalated, and records the evidence behind that decision. It does not rely on a general-purpose LLM. Selected deployment profiles may incorporate purpose-built model-assisted detection as an additional runtime signal source.
- FDEForward Deployment Engineer AI agentSpeculum’s deployment AI agent. Before go-live, the FDE can assess the environment, map available controls and signal sources, and propose the runtime boundary for the customer to confirm. After deployment, it can optionally interpret RSE decisions and support advanced services. The FDE is not required for every deployment and operates only within the permissions and scope agreed for that deployment.
- Data nodesStability Data NodesDeployable signal collectors used when your environment does not provide suitable or sufficient telemetry. They collect the approved runtime signals required by Mirror OS and make them available to the RSE for decision-making and evidence.
- TelemetryYour existing sourcesMirror OS can use signals from your existing AI governance, observability and platform tools. These sources tell the system what is happening; the RSE evaluates those signals against policy and determines what is allowed to happen.
- Agent EditionStandalone local decision planeA dedicated Mirror Shield version built for AI agent deployments, from an individual agent to an AI agent orchestration environment. It provides standalone, local deterministic runtime decisions without requiring an RSE or FDE.
Deployment environments
Where is the AI running?
Mirror OS is designed to run across these environments under one runtime layer. Coverage for a specific environment is confirmed for each deployment.
- Public Cloud
- Private Cloud
- Self-Hosted
- Sovereign
- On-Premises
- Edge
Deployment control
Control remains in the customer environment.
Mirror OS operates within the customer’s approved environment and authority boundary. Speculum AI does not operate a central control plane that receives reporting from customer deployments.
Agent Edition operates as a standalone local decision plane. Where a customer uses its own on-premises control plane, integration can be defined for that deployment.