← Case studies
Operational simulation / Decision support
OpsTwin
Test a staffing or workflow change before applying it to a live service operation.
OpsTwin is an operational simulation and decision-support prototype for service operations. Its canonical example compares adding one general support agent with making initial ticket review and assignment 25% faster.
Public product prototype
Case Snapshot
The strategic brief
The problem, the system response, the available proof, the strategic value, and the intentional boundary.
- 01Problem
- Operational dashboards explain what happened, but not how queues, staffing pressure, and service levels may respond to a proposed change.
- 02System
- A decision-support workspace that compares a baseline with bounded interventions through paired, repeated discrete-event simulations.
- 03Proof
- Live deployment, public repository, versioned contracts, integrity validation, and historical verification records. At the last recorded checkpoint, 247 backend tests and 172 frontend tests passed.
- 04Value
- Creates comparative evidence before a team commits to a staffing change, process redesign, or live operational pilot.
- 05Limitation
- A bounded support-operation model: it does not prove causality, predict production outcomes, or autonomously recommend an action.
01 / Problem
Operational dashboards show what happened. They do not test a proposed change.
Service teams can see ticket volume, resolution time, and workload after the fact. The harder question is counterfactual: what may change if capacity is added or the first review step is faster?
Those changes move pressure through the whole workflow. A local improvement can shift queueing or workload elsewhere, so OpsTwin compares each change against the same simulated operating conditions.
Build a bespoke analysis for every question.
Test the change in the live operation.
02 / Product
A guided comparison first. The full workspace when it is needed.
Start with the operation
Review the fictional support workflow, its assumptions, and the measure being compared.
Compare two bounded changes
Add one general support agent or make review and assignment 25% faster.
Read the evidence
Inspect observed average change, matched-test consistency, uncertainty, process effects, and team workload.
03 / Demonstrated comparison
The result explains the evidence. It does not choose an action.
The public guided flow compares the current operation with two proposed changes. The screenshot below is a current result from the fictional support scenario, not evidence from a real company.
Observed average change
The difference in the selected measure across matched simulation runs.
Matched-test consistency
How often a proposed change performed better than the current operation.
Plausible range
A range around the estimated average change that can include improvement, no improvement, or a worse result.
Decision boundary
A ranking can be inconclusive. Comparative evidence is not a recommendation.
04 / Interface proof
The product keeps the result connected to the operation behind it.
The Process view shows where a proposed change enters the workflow. Team workload keeps capacity and waiting evidence visible alongside the headline comparison.
05 / Method
Matched simulation makes the comparison fairer.
OpsTwin uses common random numbers. Run 1 of the current operation and run 1 of each proposed change share the same simulated conditions. The same pairing applies across repeated runs.
This reduces the chance that a difference is caused only by unrelated simulated demand. It does not turn the model into a production forecast or causal proof.
Improvement frequency is not a production success probability.
A plausible range is not a guaranteed outcome range.
Comparative ranking is not an operational recommendation.
Simulation evidence is not causal proof.
06 / Engineering and reliability
The interface exposes evidence only after the model has checked it.
The public interface sends a versioned request to a FastAPI simulation service. SimPy runs the discrete-event model, while deterministic child seeds preserve the matched baseline and scenario schedule.
A deployment failure also clarified an ownership boundary. The web app had depended on a fixture outside its deployed bundle, so the runtime asset was moved into the service that needed it and protected against drift.
Next.js interfaceVersioned request contractFastAPI simulation serviceSimPy execution engineIntegrity checksEvidence and export
07 / Outcome
A deployed prototype with inspectable evidence and clear limits.
The live product, public repository, and current screenshots make the implementation inspectable. No real-company operational outcome is claimed.
At the last recorded verification checkpoint, 247 backend tests and 172 frontend tests passed. Those counts are historical records, not a claim about the current full suite.
08 / Limitations
A bounded support model, not a production optimization platform.
- The canonical scenario represents a fictional support workflow, not an arbitrary operation.
- No real-company or real-user data has been processed.
- The prototype has no database, authentication, persistence, or multi-user state.
- Simulation output is not causal proof or a production-outcome guarantee.
- The product does not autonomously recommend an action or guarantee an optimal configuration.
- No measured business outcome or completed participant study is claimed.
Production use would require model calibration, data integration, security, observability, and validation against organisation-specific operating definitions.
09 / Learning
The useful boundary is where the model stops speaking for the operator.
A mathematically valid model can still fail as a product if people cannot see the decision it supports or the uncertainty it carries.
OpsTwin treats the result as comparative evidence. The operator still owns the decision, the assumptions, and the next step.
OpsTwin
Explore the comparison, then inspect the model behind it.
Open the guided product or review the repository and implementation details.
