Paper Deployment

How it works

A backtest replays history the strategy may have implicitly memorized; a paper deployment runs the same frozen rules on data that did not exist when the strategy was built. That asymmetry is the entire value: overfitting cannot follow a strategy into the future.

A paper deployment is created from a backtested strategy version via the create_paper_deployment MCP tool. The deployed artifact is immutable and content-hashed, so what is running is never ambiguous — revising the strategy creates a new version with its own record rather than silently mutating the test in flight.

While running, the platform evaluates the version's entry and exit rules against live Polymarket data and simulates the fills. Each order, fill, and position change is appended to a write-once event ledger; the deployment page renders open positions, fills, and running P&L from that ledger alone, never from editable snapshots. The page also links back to the parent strategy version and its backtest result, binding the forward test to the exact claim it extends.

Lifecycle control is deliberately small: set_paper_deployment_state pauses, resumes, or stops a deployment; get_paper_deployments reads status. Both are MCP tools, so the agent that authored the strategy can supervise it across sessions.

Two honesty properties are built in. Fills are simulated at observed market prices — a paper deployment is not live trading, and live venue execution remains a v2-roadmap capability. And forward-test age is surfaced explicitly: a young deployment's record is labeled as too early to judge rather than allowed to read as confirmation, because a week of paper results is not statistically comparable to a multi-month backtest.