Deployment posture
Shadow Mode proves behavior before authority expands
Shadow Mode runs the capacity-acceptance path against live or replayed operating context without issuing authoritative setpoints. It records what GridNinja would have proposed, allowed, repaired, rejected, or marked no-proof, then compares those decisions with observed conditions and operator outcomes. The purpose is evidence accumulation and integration validation—not a disguised claim of autonomous operation.
Definition
What it is
Shadow Mode is a read-only deployment posture with explicit separation between observation, counterfactual decisions, and the systems that retain control authority.
Category boundary
What it is not
It is not a production control trial, a customer performance result, or permission to infer savings from counterfactual actions that were never executed.
Operational significance
Why operators care
Teams can test telemetry mappings, topology, constraints, refusal logic, and proof-pack quality while existing operating procedures remain authoritative. Evidence from this phase determines whether Advisory Mode is justified.
Mechanism
How the decision path works
- Step 01
Ingest read-only telemetry and declared topology through scoped adapters.
- Step 02
Generate timestamped counterfactual actions and runtime-assurance outcomes.
- Step 03
Compare predicted constraints with observed operating states and operator records.
- Step 04
Review false accepts, false rejects, no-proof cases, and data-quality failures before promotion.
Textual diagram equivalent
Decision flow
Read-only telemetry → counterfactual proposal → runtime-assurance outcome → comparison with observed operation → reviewed evidence → possible Advisory Mode gate.
Synthetic Shadow Mode review
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. A counterfactual workload shift is rejected after telemetry freshness crosses policy. No control command is sent; the stale-input refusal is retained for review.
Failure and no-proof cases
- Shadow outputs can influence operators even when the authority boundary is poorly labeled.
- Counterfactual benefits are reported as realized operational outcomes.
- Mappings or timestamps are wrong, making comparisons appear precise but invalid.
Limitations
- Shadow Mode cannot establish actuator behavior or closed-loop recovery that was never exercised.
- Observed correlation does not establish that a counterfactual action caused an outcome.
- Promotion requires named operational review and site-specific acceptance criteria.
Evidence and sources
Inspect the basis, not just the answer
Local evidence objects show the GridNinja proof contract. Primary sources provide external standards and risk-management context; they do not validate GridNinja performance.
Related operator resources
Continue the proof path
- Trust starts with boundariesSee how Shadow Mode, replay, allow / repair / reject decisions, audit logs, and proof packs establish evidence before bounded autonomy.
- Inspect how claimed headroom becomes proof-adjusted capacityWalk through a synthetic virtual capacity request as runtime assurance allows, repairs, or rejects actions and records the evidence.
- Tell us where capacity is constrained.Talk with GridNinja about a Capacity Audit, Shadow Mode evaluation, virtual capacity pilot, or bridge-power partnership.
Proof before autonomy
Test the evidence boundary against your capacity question
Start with a Capacity Audit or read-only Shadow Mode discussion. GridNinja does not require control authority to identify where a capacity claim remains unproven.