Median cycle time
← Case studies
Operational simulation / Decision-support product
OpsTwin
Test an operating change before the queue feels it.
OpsTwin compares staffing and workflow changes under matched simulated conditions, then surfaces observed impact, uncertainty, risk, resource pressure, and economic tradeoffs—without presenting simulation evidence as operational certainty.
Deployed product prototype
Decision under testAdd one Level 1 agent vs. reduce triage time by 25%
Observed difference
Improved in 43 / 50 runsObserved difference
Improved in 35 / 50 runsIllustrative comparison surface — not a production prediction.
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, inspectable repository, versioned contracts, integrity validation, 247 backend tests, 172 frontend tests, and documented production verification.
- 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
Dashboards describe the queue after it forms.
Operations teams can usually see historical cycle time, service-level attainment, ticket volume, and resource utilization. The harder question is counterfactual: what changes if we add one Level 1 agent instead of reducing triage time by 25%?
Staffing, processing speed, escalation, rework, and downstream resource contention interact. A change that appears straightforward in a spreadsheet can produce less obvious effects once it moves through the full workflow.
Reason from historical averages.
Build a bespoke analytical model.
Test the change directly in production.
OpsTwin creates a narrower fourth option: bounded comparative evidence before intervening in the live operation.
02 / Objective
Make operational tradeoffs testable without overstating certainty.
The central principle was simple: comparative evidence, not prescriptive certainty.
01Represent an explicit operational baseline.
02Compare several bounded changes against that baseline.
03Hold simulated conditions constant across comparisons.
04Show observed impact and uncertainty in plain language.
05Expose the operational evidence behind the headline result.
06Keep assumptions inspectable and editable.
07Separate aggregate evidence from illustrative examples.
08Avoid turning statistical output into an automatic recommendation.
03 / Solution
Compare candidate changes under matched simulated conditions.
OpsTwin starts with a support-operation baseline with explicit assumptions about staffing, arrival rates, processing times, escalation, rework, and service-level targets. A user can define up to three intervention scenarios, such as adding one Level 1 agent, reducing triage time by 25%, or changing an escalation threshold.
The system runs the baseline and each scenario repeatedly using the same random-seed schedule. Each scenario therefore experiences matched simulated conditions, making the comparison less vulnerable to random variation between unrelated runs.
Observed impact
Cycle-time change, framed as a measured simulation difference.
Consistency
How frequently a scenario improved on the baseline.
Uncertainty
A confidence interval around the estimated difference.
Operational pressure
Comparative risk, resource, queue, and workflow evidence.
Economics
Cost implications only when the user configures assumptions.
Decision boundary
The stronger tested result is identified; the product does not decide implementation.
04 / What I built
A complete operational comparison loop.
Guided comparison
One fixed baseline, two candidate changes, one simulation action, and an immediate plain-language result.
Advanced scenario lab
A full editing environment for baseline assumptions, up to three scenarios, execution settings, guardrails, and detailed evidence.
Paired simulation engine
Repeated baseline and scenario runs use matching random seeds so comparisons are made under equivalent simulated conditions.
Operational evidence layer
Flow, risk, and resource views connect the headline result to queue behavior, utilization, and workflow structure.
Integrity validation
Contract, deterministic, and mathematical checks validate simulation responses before evidence reaches the interface.
Export system
Comparison results and supporting evidence export as structured JSON or CSV artifacts.
05 / Product experience
Two levels of complexity, one analytical system.
Guided mode / default
Understand the decision before interacting with the model.
Guided mode presents the current operation, two candidate interventions, one comparison action, and an immediate factual result. Supporting evidence then appears one panel at a time.
- The current operation.
- Two candidate interventions.
- One comparison action.
- An immediate factual result.
- Supporting evidence one panel at a time.
Advanced mode
Expose the full analytical workspace when it is needed.
Advanced mode makes baseline assumptions, scenario overrides, execution settings, guardrails, and detailed evidence inspectable and editable.
The guided interface does not create a simplified analytical path. Both modes use the same simulation engine, contracts, and comparison logic.
06 / Usability iteration
Analytical correctness did not guarantee clarity.
An early version exposed the entire simulation workspace immediately. It was analytically complete but difficult for a first-time visitor to understand: mechanics appeared before the decision, statistical terminology appeared before interpretation, and the central result was buried behind evidence sections.
01Guided mode became the default entry point.
02The decision moved ahead of the mechanics.
03Results appeared immediately after execution.
04Statistical language received plain-language interpretation.
05Evidence moved into one accessible tab system.
06Advanced controls remained available in a separate mode.
07A first-run orientation and terminology glossary were added.
Frontend coverage increased from 142 to 172 tests during this work, with no existing test removed. The iteration is supported by automated regression, expert review, owner walkthrough, and browser quality assurance; a five-participant human usability study has not yet been completed.
07 / Methodological decision
Paired evidence is stronger than unrelated simulation runs.
Running a baseline once and a scenario once would create a weak comparison: a difference could come from the intervention, or simply because each run received different random conditions.
OpsTwin instead applies common random numbers. Run 1 of the baseline and run 1 of every scenario use the same random-seed conditions; the same applies to every repeated run. Differences are calculated within these matched pairs.
Fifty paired runs are used by default, exposing how consistently an intervention improves on the baseline and how much the estimated effect varies.
Improvement frequency is not a production success probability.
A confidence interval is not a guaranteed outcome range.
Comparative ranking is not an operational recommendation.
Simulation evidence is not causal proof.
08 / Evidence surfaces
The headline result is only the beginning of the analysis.
Flow
Maps stages, routes, and resource pools while overlaying scenario changes and returned pressure evidence.
Risk
Surfaces the risk classification attached to a comparison instead of hiding uncertainty in a technical table.
Resources
Shows where a scenario changes queue pressure or resource utilization across the workflow.
Sensitivity
Sweeps one explicit factor across defined tested values, without interpolation, extrapolation, or an implied optimum.
Economics
Calculates recurring and one-time cost evidence using only assumptions entered by the user.
Playback
Reconstructs one sampled run as an illustration, explicitly separate from aggregate evidence across all runs.
09 / Engineering and reliability
Evidence should fail safely rather than render convincingly.
OpsTwin uses deterministic and contract-driven boundaries throughout the system. SimPy provides discrete-event execution; FastAPI validates versioned Pydantic contracts; deterministic child-seed generation preserves matched baseline and scenario schedules; and structured integrity checks run before evidence reaches the interface.
The project was developed through an AI-assisted software workflow, while product scope, system architecture, acceptance criteria, verification, and final decisions remained human-directed.
Next.js interfaceVersioned request contractFastAPI simulation serviceSimPy execution engineIntegrity validationStructured evidence and export
The system is intentionally stateless: no database, authentication, user accounts, persisted simulation history, or external operational data source. This keeps the prototype focused on analytical architecture and product interaction rather than infrastructure the use case does not yet require.
10 / Deployment recovery
Deployment boundaries are architectural boundaries.
The first production deployment failed during the Next.js build. A frontend module imported a baseline fixture from the repository’s examples directory. The directory was excluded from the deployed bundle, so the file was available locally but unreachable inside the production build boundary.
The symptom was a missing module; the underlying problem was architectural: the web service depended on a runtime asset it did not own.
Own the runtime asset
Package a runtime-owned copy inside the web service.
Protect the source of truth
Add regression verification that fails if the runtime copy diverges from the canonical example.
The incident became part of the case study rather than being removed from the narrative: packaging rules, deployment configuration, and ignored directories form part of the system architecture.
11 / Outcome
A deployed decision-support product with inspectable boundaries.
247
backend tests passing
172
frontend tests across 22 files
50
paired runs used by default
ESLint, Ruff, TypeScript, strict mypy, the Next.js production build, FastAPI build, source-package verification, and Guided and Advanced production routes all passed documented verification.
These measurements describe engineering scope and verification depth. They are not business-impact claims: no real-company operational outcome has been measured.
Which intervention produced the stronger observed improvement?
How consistent was that improvement, and how uncertain is the estimate?
Where did pressure move inside the operation?
What happens economically under explicitly configured costs?
12 / Honest limitations
A bounded operational model, not a production optimization platform.
- The canonical model represents support operations rather than arbitrary workflows.
- No real-user or real-company data has been processed.
- There is no database, authentication, persistence, or multi-user state.
- Results are simulation evidence, not causal proof or a production-outcome guarantee.
- The product does not autonomously recommend an action or guarantee an optimal configuration.
- Sensitivity analysis tests one factor at a time, and representative playback shows one sampled run rather than an aggregate outcome.
- Human participant usability testing remains pending.
Production use would require model calibration, data integration, security, observability, and validation against organization-specific operating definitions.
13 / What I learned
The strongest analytical product is not the one that claims the most.
A mathematically correct model can still fail as a product when users cannot understand what decision it supports. OpsTwin reinforced that analytical correctness and usability are separate requirements; uncertainty needs interpretation, not decoration; and aggregate and representative evidence answer different questions.
The central design decision was not adding another simulation feature. It was controlling where the system’s evidence ends.
OpsTwin
Test an operating change before implementing it.
Explore the guided comparison, inspect the advanced workspace, or review the architecture and verification evidence.
