What Shadow Mode Is—and What It Is Not

Shadow Mode is a way to observe a decision path without turning that observation into an action. It lets users and operators inspect evidence, proposals, deterministic checks, and the conditions that would block or permit the next step.

It is not a promise of performance, a simulated fill, or a quiet route around execution controls.

The value of running without authority

Before automation is trusted with a broader role, it needs to be evaluated against replayed and current conditions. Shadow work creates a place to compare proposals, inspect disagreement, surface stale data, and understand cost or latency without allowing a result to become a transaction.

This is particularly important when an agent uses several specialists and a synthesis stage. A polished final answer can hide uncertainty upstream. Shadow evaluation keeps the supporting evidence visible and lets deterministic checks remain independently inspectable.

Status should match the mode

Mowazi distinguishes customer modes from development safeguards. Shadow, Approval, and Autopilot describe product-facing modes. Manual Guard and Lite Mode are development controls that keep local use bounded. Combining those labels would make the product sound more autonomous than it is.

The purpose of the distinction is simple: users should know whether they are looking at analysis, approval, a simulation, or an execution-capable path.

The current Mowazi routing modes

Mowazi's architecture documents three product-facing proposal routes. In Shadow, the system obtains a fresh quote and records a simulated fill. In Approval, it creates an expiring inbox item; a user approval starts a fresh execution workflow. In Autopilot, that same execution workflow can begin automatically only when the separately required capability and controls are present. Each route still reaches the deterministic execution boundary; the difference is how, or whether, authority enters the path.

01 / proposal

Candidate

Analysis proposes a route with bounded evidence.

02 / shadow

Observe

A fresh quote and checks are recorded as a simulated path.

03 / authority

Still absent

No signing adapter, credential, or live dispatch is granted.

Shadow is therefore not a more permissive form of execution. It is a narrower mode that lets the product observe a candidate decision against current conditions while preserving the absence of signing authority.

analysis result
  -> proposal
  -> fresh quote + deterministic checks
  -> shadow record / simulated outcome
  -> evidence and trace for inspection

no owner signature
no venue credential exposure to a model
no live dispatch

What the implementation can learn in Shadow

The current Mowazi architecture keeps detailed evidence, provider calls, synthesis, traces, evaluations, and simulated fills in Timescale. Convex holds current product state and UI-facing snapshots. This lets Shadow Mode compare a proposal with the state of the world it observed without transforming the current snapshot into a historical warehouse.

The useful questions are operational rather than promotional:

• Did the proposal have complete, bounded evidence?
• Did specialists and synthesis agree within the required model quorum?
• Was the route available and was the quote fresh at evaluation time?
• Which deterministic check would have blocked the next step?
• How much did the analysis cost and how long did it take?
• Did later replay or Shadow evidence contradict the proposal?

type ShadowObservation = {
  proposalId: string;
  quoteReference?: string;
  checks: Array<{ name: string; result: "pass" | "block" }>;
  simulatedOutcome?: "recorded" | "unavailable";
  executionAuthority: false;
};

The last field is not cosmetic. It is the promise that keeps the observation record from being misread as a transaction record.

A fresh check still matters in a non-executing mode

An analysis result can be old even when it will not trade. Mowazi's workflow model treats the fresh quote and deterministic policy pass as separate from earlier synthesis. Shadow Mode can therefore reveal that a route which looked plausible at analysis time had become stale, exceeded a policy condition, or lacked a healthy venue state when evaluated.

That is more valuable than a hypothetical “simulated fill” that assumes the earlier conclusion remained true. A credible Shadow record should say what it observed, when it observed it, and why an execution-capable path would have stopped or proceeded under its rules.

# Representative decision handling: record the outcome, do not submit.
checked = await gateway_call("/internal/preflight", safety_payload)
record_shadow(
    proposal_id=proposal_id,
    quote=checked["quote"],
    policy=checked["decision"],
    authority="absent",
)

Shadow is also an evaluation gate

Mowazi's research program requires replay/shadow-first evaluation for candidates that would affect the agentic system. Backtests and papers can support a hypothesis, but they do not establish production behavior. A feature must preserve strict outputs, idempotency, cost reservations, and the deterministic execution boundary before it can be considered for a bounded evaluation.

This is why the system's Closed Beta status matters. Shadow Mode is a way to learn under constrained access. It is not evidence that live execution is open, certified, or safe to imply. The honest product surface should retain that distinction even when a Shadow result looks compelling.

What Shadow Mode is not

It is not a performance guarantee, because a recorded route is not a realized execution. It is not a way to skip owner consent. It is not a substitute for venue certification or reconciliation. It is not a background loop that can quietly promote itself into authority. And it is not a reason to describe public quote data as a live private execution adapter.

The mode is valuable precisely because it refuses those shortcuts. It gives operators and users evidence about the boundary before asking anyone to cross it.