Frequently asked questions

Speculum AI is The AI Runtime Company. We build an independent runtime layer for production AI across models, platforms and deployment environments. Our two product families are Mirror OS for AI Runtime Stability and Mirror Token for AI Runtime Efficiency. Our focus is what happens once AI is running: how it behaves, how it is controlled, what evidence it produces and where avoidable execution can be reduced.

AI runtime is the operating phase when an AI workload is actively processing inputs, using tools, interacting with systems or taking actions. It is where intended behaviour meets real operating conditions—and where organisations need visibility, control and evidence.

Models, policies, evaluations and pre-deployment tests cannot fully determine what happens in a live environment. A runtime layer turns approved boundaries into operational control: observing behaviour, identifying relevant divergence, applying authorised responses and preserving evidence while the AI is running.

Speculum AI is designed for organisations operating AI in real workflows, including AI agents, orchestration, enterprise AI, AI factories, robotics, physical AI and autonomous systems. Suitability and deployment scope are assessed against the actual workload, environment and operating boundary rather than assumed from a category label.

Mirror OS is Speculum AI’s product family for AI Runtime Stability. It works from an agreed operating boundary and supports an approved progression through Observe → Detect → Govern → Enforce → Evidence. Deployment can begin with observation and evidence, with stronger controls introduced only when authorised.

Mirror Token is Speculum AI’s product family for AI Runtime Efficiency. It is designed to identify and reduce avoidable execution at runtime while preserving the required result and operating constraints. It is not simply a token-price tool, model router or feature inside Mirror OS.

Mirror OS governs how AI behaves. Mirror Token governs how AI consumes runtime resources. They are separate product families built on the same runtime foundation, addressing different operational questions. An organisation may use either product family or both, depending on its workload.

They are the three deployment lines within Mirror OS.

• Mirror Shield is the enterprise-grade deployment category for adding runtime control to an existing AI workload.
• Mirror Runtime provides deeper integration into a platform, orchestration layer or edge environment.
• Mirror Foundry configures the Mirror OS runtime foundation for domain-specific operating and evidence requirements.

The appropriate line depends on the workload, operating boundary and required depth of integration.

Mirror Shield Agent Edition is a dedicated deployment path within Mirror Shield for supported AI agent and AI agent orchestration environments. It provides a standalone local decision plane that makes deterministic runtime decisions without requiring an RSE or FDE. It remains part of Mirror Shield, not a separate product family. Current support and deployment scope are confirmed for each engagement.

AI Runtime Stability means production AI can be operated against an agreed boundary, with its behaviour observable, its control decisions authorised and its runtime events supported by evidence. It does not mean that AI can never fail. It means uncertainty and divergence can be identified and handled rather than silently treated as acceptable.

Red teaming examines how a system might fail. Guardrails constrain defined interactions. Governance establishes policies, responsibilities and accountability. Mirror OS complements all three by operating while AI is running: observing the live workload, identifying divergence from agreed boundaries, applying authorised controls and preserving evidence. It does not replace evaluation, cybersecurity, governance or human oversight.

Observability helps explain what a system is doing and diagnose what happened. Mirror OS can use approved observability data as runtime signals, then assess relevant behaviour against operating boundaries, support runtime decisions, preserve evidence and—where authorised—apply control. It complements observability rather than replacing it.

No. Mirror OS is designed to work with the AI environment an organisation already operates. It complements existing models, clouds, platforms, agent frameworks, orchestration and infrastructure. The depth of integration is selected according to the workload rather than requiring the organisation to rebuild its AI environment.

Deployment begins with the workload’s intended function, permitted actions, terminal conditions, policies and relevant operational constraints. For deeper integrations, an optional FDE assessment can map the environment and required evidence signals, then propose a runtime boundary and configuration for customer confirmation. Deployment can begin with observation and evidence, with control introduced only through approved stages. Mirror Shield Agent Edition provides a standalone local decision plane for supported AI agent and AI agent orchestration deployments, without requiring an RSE or FDE.

Mirror OS is designed for public cloud, private cloud, self-hosted, sovereign, on-premises and edge environments. Actual compatibility, coverage and integration are confirmed against the specific workload and deployment environment; they should not be presented as universal.

Yes. A focused workload is the clearest place to establish its operational boundary, identify the required signals and determine the appropriate deployment path. Different workloads within the same organisation may use different Mirror OS deployment forms.

Mirror OS is designed to preserve structured evidence of the runtime events and authorised control decisions that are in scope for a deployment. Depending on the agreed configuration, this can support operational review, investigation and governance. The exact evidence available depends on approved signals, retention rules and data boundaries. Runtime evidence does not, by itself, constitute a blanket guarantee of regulatory compliance.

Customer information, proprietary data, telemetry and export boundaries are defined for each deployment. Speculum AI does not assume unrestricted access to customer data. The required signals, where they are processed and how evidence is retained must be explicitly agreed before integration.

Mirror Token efficiency is evaluated against an agreed, workload-specific baseline while preserving required outcomes and operating constraints. Tokens, compute, energy, capacity and financial value must be measured separately; a reduction in one does not automatically produce an equal reduction in the others. The opportunity varies by workload, so Speculum AI does not publish a universal savings percentage.