Testing a Business Model Before Spending a Dollar (The Sim Loop)
Draft — S8.1 · series: CONTENT-ROADMAP-99 S8 (Simulation → Live) · status: DRAFT · grounding: wiki simulation-mode · edge-detection-cli · dashboard · task-tracker · tags: simulation, paper-trading, business-model, kot-scoring, polymarket, edge-detection, prediction-markets, ai-agents, digital-architecture, sovereign-infrastructure, local-first, web-4.0, digital-business, ai-automation, kanban-orchestrator, council-system, hermes-agent, openfang, credit-safety, autonomous-operations
Every business model is a hypothesis. The hypothesis says: if I do X, people will pay Y, and the margin between cost and revenue will sustain the operation. Most founders test this hypothesis by spending money — building the product, hiring the team, launching the marketing campaign — and then checking whether the hypothesis was right. The check comes after the spend. If the hypothesis was wrong, the money is gone.
There is another way. You can test the hypothesis before spending a dollar. Not by asking people whether they would pay for something — survey data is cheap and unreliable — but by running the actual rules of the business against real data, in a closed environment that physically cannot place a real trade, send a real invoice, or burn a real dollar. This is the simulation loop. And it is the first article in the S8 series on Simulation → Live because everything else in this series — the promotion gates, the scoring, the dashboard feedback — depends on whether the sim loop works.
What the sim loop actually is
The simulation loop is a paper-trading engine that replays resolved markets using their real trade tapes. Every fill executes at the tape price at the exact timestamp a signal fires. Adverse slippage is modeled at 25 basis points by default. Fees are deducted. Positions settle at the market’s actual outcome: 1.0 if you held the winner, 0.0 if you did not. The engine sees zero lookahead — only prints up to the current tick.
This is not backtesting. Backtesting applies a strategy to historical data and reports what would have happened. The sim loop does something subtly different: it replays the execution* of a strategy against the *actual fills that occurred in the market, including the slippage and fee structure that real traders face. The difference matters because a strategy that looks profitable on closing prices can be unprofitable when you account for the fill you actually would have gotten.
The engine is built on four modules. market_data.py` pulls resolved Polymarket markets and their trade tapes via the Gamma API. `execution.py` handles fills, slippage, fees, flat-stake sizing, and per-market entry caps. `strategies.py` implements the signal generators — mean reversion, trend following, dual-side momentum. `scoring.py applies KOT scoring: expectancy, profit factor, drawdown, and a verdict gate that only awards PROVEN_EDGE when the numbers clear a real threshold.
Why safe-by-default is non-negotiable
The most important architectural decision in the simulation engine is the toggle. It defaults to OFF. When a developer instantiates the execution engine with sim_enabled=False, the engine raises an exception if anyone attempts to run a trade. There is no wallet, no API key for an exchange, no integration with any live trading venue. The engine physically cannot place a real trade.
This is not a precaution — it is a design constraint. The sim loop exists to answer the question “would this have worked?” without creating the possibility that it accidentally does work, or worse, accidentally loses money. A paper-trading system that can accidentally go live is not a paper-trading system. It is a live system with extra steps.
The toggle is the architectural boundary between simulation and production. The S8 series will build on this boundary — the promotion gate in S8.3, the KOT-scored edges in S8.4, the dashboard feedback in S8.6 — but the boundary itself is established here, in the sim loop, where the only output is a report.
The edge-detection pipeline: signal before strategy
A simulation engine without a signal source is an empty frame. The edge-detection-cli skill fills this frame. It implements three core formulas from the ACP (Automated Commerce Protocol) trading system:
The edge formula: edge = p_true - market_price. Enter when edge exceeds 7%. The true probability is derived from spot momentum on Coinbase and Binance — if Bitcoin is trending up on the spot exchanges, the YES price on a crypto prediction market should reflect that. When it does not, there is an edge.
Expected value: EV = (p × profit) - (q × loss). Only trade when EV is positive. This is the filter that kills strategies with a positive win rate but negative expected value — the gambler’s trap.
Kelly criterion: f* = (p × b - q) / b. Optimal position sizing, applied at quarter-Kelly for safety. Full Kelly is too aggressive for prediction markets where the edge is thin and the sample size is small.
The edge-detection-cli scans Polymarket markets, calculates these three metrics, and exports the results as CSV or JSON. The simulation engine consumes these exports as signal inputs. The two systems are decoupled by design: the edge scanner finds opportunities, the sim engine tests whether acting on those opportunities would have been profitable. Neither system can place a real trade.
Real data catches real bugs
The first live run of the simulation engine against 40 resolved Polymarket markets exposed two bugs that unit testing could not catch. Trade tapes interleave both sides’ fills at their own prices — a YES-trading strategy saw an incoherent 0.2-YES/0.8-NO series that the strategy interpreted as a signal when it was actually just the tape recording both sides. Fixed with side filtering and yes-equivalent conversion for dual-side strategies.
The second bug was sizing. A percentage-of-growing-bankroll approach with re-entry churned one market into 3,154 trades and overflowed to NaN. Fixed with flat-stake sizing and a per-market entry cap of one round trip. Neither bug would have appeared in unit tests because both require the texture of real market data — interleaved fills, variable liquidity, edge cases in the tape format — to surface.
The results after fixes: the dual-side momentum strategy (long YES in uptrend, long NO in downtrend, 8/24 moving average) earned PROVEN_EDGE with 40 trades, positive net expectancy of 14.2% per trade, and a profit factor of 5.9. The naive YES-only strategies lost money — exactly as they should have, because the corpus contains markets where YES is overpriced and the smart money is on NO. The sim killed the bad strategies cheaply. That is its job.
The dashboard and the task tracker
The simulation loop does not run in isolation. The Hermes dashboard — running on port 9119 alongside the gateway on 8642 — provides the observability layer. When the sim engine runs, the dashboard shows token usage, session activity, and job status. The task tracker (the kanban board backed by SQLite) records which strategies were tested, what the verdict was, and what the next step should be.
This is the loop: the edge scanner finds signals, the sim engine tests them, the scoring module grades them, the dashboard shows the results, and the task tracker records the decision. The cycle repeats until a strategy either earns PROVEN_EDGE or is discarded. No money moves. No API keys are exposed. No exchange integration is required. The only resource consumed is compute time and tokens — and both are tracked by the dashboard.
Why this matters for the S8 series
The simulation loop is the foundation of the Simulation → Live series. Every subsequent article builds on the assumption that a strategy can be tested without risk. S8.2 will layer simulation onto content pipelines. S8.3 will define the promotion gate — the exact criteria a strategy must clear before it is allowed to touch real money. S8.4 will formalize KOT-scored edges. S8.5 will extend the sim to paper-trading with real rules and sim money. S8.6 will build the dashboard feedback loop. S8.7 will introduce microsharks — ephemeral agents for ephemeral tasks. S8.8 will connect simulation to lead development. S8.9 will explore prediction markets as simulation environments. S8.10 will honestly assess where the simulation breaks.
But none of that works if the sim loop itself does not work. The engine must be safe by default. The signal pipeline must be decoupled from execution. The scoring must be honest — PROVEN_EDGE means something, not everything passes. And the bugs that real data surfaces must be caught before any real dollar is at stake.
The sim loop is the answer to the only question that matters before going live: would this strategy have made or lost money? If the answer is “made money, after fees, after slippage, over a meaningful sample,” then the strategy is a candidate for promotion. If the answer is anything else, the sim loop saved you a dollar. That is its job. That is the only job it has.
Grounded in wiki concepts simulation-mode`, `edge-detection-cli`, `dashboard`, `task-tracker`, entity `polymarket`, and source `simulation-mode-20260803`. Skills: `edge-detection-cli`, `kanban-orchestrator`, `kanban-worker. First article in the S8 series on Simulation → Live. Design notes on a running system, not a sales pitch.
Semantic Relationships
– [[simulation-mode]] — orchestrates
– [[edge-detection-cli]] — orchestrates
– [[polymarket]] — orchestrates
– [[kanban-orchestrator]] — orchestrates
– [[dashboard]] — orchestrates
– [[task-tracker]] — orchestrates
– [[kot-scoring]] — orchestrates
