The sandbox is not optional

Traditional software earns trust through tests because traditional software is a function of its inputs, and you can write the inputs down. An operator is different. Its most important input is an operation in motion: a stream of orders, tickets, sensor readings, and human behavior that no fixture file resembles. Synthetic test data is polite. Production is not. The order with three refunds and a partial shipment, the thermostat that reports twice and then goes silent, the customer who replies to a closed conversation from last quarter. These are the cases that decide whether an operator is safe, and none of them appear in a test you invented at your desk.

The usual answer is staging, and staging is where good intentions go to drift. The data is stale, the integrations are stubbed, and everyone quietly knows the real test happens in production, watched nervously. For a system that reads dashboards, that is tolerable. For a system that acts, on orders, on messages, on equipment, it is not. So Fibric does not treat the sandbox as an environment you may set up. It is a phase of every operator’s life, enforced by the platform.

Replay: recorded reality, not invented fixtures

Where a governed path has retained envelopes, replay can expose the operator to real historical inputs and known edge cases. It is not full fidelity: external state, timing, unavailable signals, model versions, and downstream behavior can differ from live execution. In rehearsal mode, proposed actions are recorded instead of performed.

The output of a replay should be a set of proposed-action records linked to their inputs and policy decisions. It shows what the tested configuration proposed against the available recording, not a guarantee of what every live condition would produce.

Policy rehearsal: change the rules before the rules change you

Replay answers a second question that teams rarely get to ask safely: what happens if I change the policy? Loosen a refund threshold, widen an operating window, grant an operator a new capability, and you have changed the behavior of a live system in ways that are hard to predict from the diff alone. In the sandbox, you rehearse it. Run the same recorded week under the current policy and the proposed one, and diff the receipts. The difference between the two runs is the consequence of your change, expressed as concrete actions: forty-one refunds that would now auto-approve, three setpoint changes that would now be blocked. You approve the diff, not the hope.

Receipts you can diff

A shared record schema makes rehearsal and observed live activity easier to compare. The comparison still needs to account for configuration, model, timing, and external-state differences. BearScope is the live product proof point; this broader promotion path is a reference control objective.

The public Smart City Labs twin is an illustrative model, not a standing live-building sandbox. A real BACnet pilot would need validated telemetry, controller emulation or bounded commissioning, human review, and independent safety controls before authority expands.

Not a courtesy, a load-bearing wall

We built the sandbox into the platform rather than the docs because optional safety steps have a short half-life. Under deadline pressure, anything skippable gets skipped. The rehearsal phase is not skippable on Fibric, for our operators or anyone else’s: an operator’s authority to dispose real effects is something it graduates into, with the receipts to show for it. That sounds strict until you have watched a replay catch, in an afternoon, the exact edge case that would have taken a week and an apology to untangle in production. Then it just sounds like engineering.

Keep reading: Receipts, not logs · The deterministic executor