# Project export: OpsProof: Stress-Test Changes Before They Reach Customers This document was generated by HackStack to give an AI agent context about a hackathon project. Sections are labeled with their provenance; content marked as truncated was cut to keep this document small. ## Project metadata - Hackathon: OpenAI Build Week - Tagline: 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. - Devpost: https://devpost.com/software/opsproof-operational-digital-twin - GitHub: not linked - Demo: https://opsproof.yooint.chatgpt.site/ - Video: https://www.youtube.com/embed/LPtDtNgJIrg?enablejsapi=1&hl=en_US&rel=0&start=&version=3&wmode=transparent - Team: contributor stats unavailable ## Devpost submission (written by the team) ### 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 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 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. ## README (from the GitHub repository) No README available. ## Detected evidence (automated analysis) No repository was indexed for this project. Claimed technologies below could not be checked against code. - CSS (language) — claimed on Devpost, not found in the code - Next.js (technology) — claimed on Devpost, not found in the code - OpenAI (technology) — claimed on Devpost, not found in the code - React (technology) — claimed on Devpost, not found in the code - Tailwind CSS (technology) — claimed on Devpost, not found in the code - TypeScript (language) — claimed on Devpost, not found in the code ## Codebase structure No repository index available. ## Key source files No repository index available; no source files included.