OpsProof: Stress-Test Changes Before They Reach Customers

OpsProof turns compatible event logs into a transparent operational model, stress-tests demand spikes and outages, exposes bottlenecks, and finds the lowest-cost tested plan that restores an SLA.

Comment

Inspiration

Operations teams often have timestamped event data but no simulation specialist. When demand rises, a station fails, or staffing changes, they often rely on intuition and discover bottlenecks only after customers feel the impact.

I built OpsProof around one practical question: what is the lowest-cost tested change that can protect an operational SLA before a modeled disruption reaches customers?

What it does

OpsProof turns compatible local Fulfillment or Support event logs into transparent operational models. It validates the data, calibrates a reviewed Operation Pack, requires confirmation of assumptions and business inputs, stress-tests demand spikes or outages, identifies the repeated bottleneck, and finds the lowest-cost tested recovery plan that qualifies for the chosen SLA.

Its main output is a Decision Proof: normal, stress, and recovery evidence across the same 100 fixed random seeds. If the data is incompatible or no tested option qualifies, OpsProof refuses to invent a recommendation.

How we built it

I built OpsProof as a TypeScript application with Next.js, React, Zod, Web Workers, Vitest, and Playwright.

The numerical core, FlowTwin, is a deterministic discrete-event simulation engine. It models arrivals, FIFO queues, shared resource capacity, routing, outages, service slowdowns, utilization, SLA performance, Monte Carlo experiments, and bounded optimization.

All operational data processing, simulation, and reporting run locally in the browser. The final product has no runtime AI API, provider call, database, or external data dependency.

Challenges we ran into

The hardest challenge was avoiding a convincing-looking but untrustworthy “AI says…” product.

An earlier direction explored converting operating procedures into models with an LLM. I deliberately removed that runtime dependency. A plausible model is not enough for a staffing or service decision, so the final product uses validated event logs, reviewed Operation Packs, explicit confirmation, and observed-versus-simulated fit before it can recommend anything.

Another challenge was UX: simulation tools can easily become walls of charts. I redesigned the product around one question — What will keep the operation safe? — and made the main result a clear action, cost, SLA reliability, and bottleneck explanation.

Accomplishments that we're proud of

  • A complete local event-log-to-decision workflow with no API key.
  • Transparent input validation and clear refusal states for unsupported evidence.
  • A deterministic FlowTwin engine with reproducible 100-seed comparisons.
  • A bounded optimizer that explains why the selected recovery beats other tested options.
  • A Decision Proof export containing the model, scenario, candidate set, and evidence.
  • A polished fulfillment demo plus a separate support-center example.
  • Strong verification: unit tests, browser E2E tests, Worker-runtime tests, accessibility checks, mobile layouts, reduced-motion behavior, and production builds.

What we learned

I learned that reproducibility is a product feature, not just an engineering detail. Using common random seeds makes normal, stress, and recovery comparisons fair and inspectable.

I also learned that a narrow, honest product is stronger than a generic AI wrapper. OpsProof supports only two reviewed operation types and clearly exposes assumptions, provenance, and limitations. It does not pretend to understand every process or guarantee a real-world outcome.

Codex was especially valuable as a development collaborator for architecture, implementation, tests, reviews, and documentation. The human product decisions remained central: what to support, what to reject, and what evidence a recommendation must show.

What's next for OpsProof: Stress-Test Changes Before They Reach Customers

OpsProof is intentionally a bounded MVP, not a universal process-mining platform or workforce scheduler.

Next steps would include more reviewed Operation Packs, richer but still auditable recovery options, stronger import templates, and controlled integrations with real operational systems. The central principle will remain the same: test an operational change before customers experience its consequences, and show the evidence behind the decision.

Built With

Share this project:

Updates