# I make simulation impossible to mistake for production. Why fixtures, simulated controls, and mock providers need visible identity, hard boundaries, and contamination checks. - **Canonical URL:** https://vidhata.me/notes/i-make-simulation-impossible-to-mistake-for-production - **Author:** Vidhatanand V. (Vid) - **Role:** Fractional CTO and AI Systems Architect **Published:** 04 Sep 2026 | **Reading time:** 8 minute read ## Why I hold this position Simulation is one of the fastest ways to build and test a difficult system. A camera can be replaced by fixture video, a machine signal by a control panel, a model provider by deterministic responses, and a database by seeded local state. The danger begins when those substitutes can be mistaken for operational evidence. I do not rely on memory or convention to preserve the distinction. A simulation path should identify itself in the interface, the event record, the configuration, and the stored artefact. Production should reject it where the consequence matters, not merely hide the button that exposes it. ## A simulated control must carry its identity everywhere. A bright label in the user interface is useful, but it is not enough. Events created through a simulated control need an environment or provenance field. Artefacts should retain the fixture source. Runs should show which providers, inputs, and policies were active. Exports should not strip that identity away. This makes test evidence easier to interpret. A reviewer can separate a successful pipeline demonstration from a successful field observation. The system can also prevent simulated results from entering production reports, model training data, compliance evidence, or dashboards that assume a real source. ## Production must reject simulation, not merely conceal it. A hidden route, query parameter, or environment flag can still be triggered accidentally. For consequential controls, I want server-side and deployment-level enforcement. Production configuration should disable the capability, and the API should reject simulated events even if a client tries to send them. The same rule applies to mock providers. Deterministic responses are valuable for tests, but the deployed service should expose which provider mode is active and fail its readiness check when a prohibited mode appears. A visual difference is helpful. A hard boundary is safer. ## I use fixtures without letting fixtures contaminate evidence. Seeded databases, fixture videos, synthetic events, and local object stores should have clear namespaces and reset paths. Tests need to clean up or rebuild the whole environment coherently. Resetting relational rows while leaving old objects, cached responses, or queue messages behind creates evidence that looks real because it survived the test. I add contamination checks where the cost justifies them. A run can assert that every artefact belongs to the current fixture set. A browser gate can fail when placeholder content appears in a production-shaped route. A report can exclude simulated sources by policy rather than relying on the analyst to remember. ## A demo should reveal the boundary instead of disguising it. There is no weakness in saying that a path is simulated. The weakness is using presentation to blur what has and has not been proven. A useful demo shows the real contracts, state transitions, error behaviour, and operating surface while naming the parts that still depend on fixtures or placeholder models. That honesty improves the next build decision. The team knows whether it needs better inference, a real device integration, production data, or simply scale testing. Simulation remains a powerful engineering tool because nobody has to pretend it is already the world. ## What I take into the next build - Persist simulation identity with runs, events, and artefacts. - Reject prohibited simulation paths on the server and in deployment checks. - Reset data, objects, queues, and caches as one test environment. - Use demos to show the evidence boundary, not hide it. ## Continue reading [All Fractional CTO field notes](https://vidhata.me/notes) ## Work with Vid Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).