SimForge
Model-generated simulators, executed in isolated sandboxes
Describe a physical operation in plain language; SimForge generates a simulator, runs it in an isolated sandbox, forks that sandbox into competing interventions, and ranks them.
- Tests
- 200
- test functions across the simulation, sandbox, API and finance layers
- Application code
- 4,806 lines
- Build time
- 1 day
Figures with a dotted underline carry their source. Hover one to see whether it was verified in code or reported in project documentation.
Context
The situation
A CAPEX question — “should we buy another tank?” — is usually answered with a spreadsheet built on averages, which cannot express what happens when a collection is missed three days running.
The problem
Two problems at once. Modelling the operation properly requires code somebody has to write, and if a language model writes that code it must not execute inside the application that trusts it.
What I built
Separate reasoning from numerical truth, and isolate execution. The model produces a structured specification and generates a simulator against a fixed contract; the simulator runs inside an isolated sandbox; and the sandbox’s native copy-on-write forking branches one baseline operational state into competing interventions that are compared under the same assumptions.
Industrial infrastructure decisions — storage capacity, logistics schedules, operational buffers — are evaluated with averages and spreadsheets, and a decision that looks good on an average fails under operational uncertainty. SimForge turns a natural-language description of an operation into an executable model, runs it inside an isolated sandbox, then forks that sandbox into alternative futures to compare interventions on operational and financial outcomes. The language model builds the specification and generates the simulation logic; Python owns time evolution, resource constraints, stochastic events, Monte Carlo aggregation and every financial calculation.
Architecture
How it fits together
- Operation describedinput
natural language
- Model specificationlanguage model
typed, with provenance per parameter
- Generated simulatorlanguage model
fixed simulate(config, seed) contract
- Isolated sandboxguard
static validation, then execution
- Forked futuresdeterministic
copy-on-write, one per intervention
- Monte Carlodeterministic
seeded rollouts per fork
- Ranked decisionoutput
operational and financial, computed in Python
Key decisions
The choices that shaped it
- 01
Forking is the product primitive, not a checkbox
Each intervention branches from the same baseline sandbox state via native copy-on-write forking, so scenarios differ only by the intervention being tested. The runner deliberately detects whether fork support is available and reports why it is not, rather than silently degrading to something that looks the same but is not.
- 02
One contract for every generated simulator
Every generated simulator exposes the same entry point and returns the same shape — timeseries, metrics, events — which is schema-validated on return. The configuration defines the world; the simulator defines behaviour. A CAPEX scenario is a different config, never a rewrite.
- 03
Every parameter carries provenance
Each value is labelled as supplied by the user, researched, estimated, or introduced as an assumption to make the model executable. The interface must show the difference. An estimate is never silently promoted into a site-specific fact.
- 04
Finance is Python, not prose
Recovered output, annual benefit, and payback are computed in code from simulation results. If the backend did not calculate a number, the assistant cannot present it as a simulation result.
Evidence
What it actually looked like
Baseline against three interventions, compared under the same assumptions.
Interface
The decision layer: operational resilience and payback, computed in Python.
InterfaceMy contribution
Primary author. Owned the simulation engine, sandbox execution, scenario forking, Monte Carlo, finance and tests.
What I owned
- A deterministic reference simulator for a production, storage and collection operation
- The sandbox execution layer, including deliberate detection of fork support
- Scenario forking and the Monte Carlo aggregation layer
- The financial and decision engine — recovered output, benefit, payback
- The API contract between the simulation half and the modelling half
- The full test suite
What I did not
- The requirements agent and natural-language specification building
- The simulator-generation prompt and provenance labelling
- The frontend
Stack and limits
Built with
- Python
- FastAPI
- Pydantic
- Daytona SDK
- OpenAI API
- Chart.js
- pytest
Techniques
- Sandboxed execution of model-generated code
- Copy-on-write sandbox forking
- Seeded Monte Carlo scenario evaluation
- Parameter provenance labelling
What it is not
- The end-to-end flow was built in a single day and demonstrated on one worked industrial example.
- The reliability loop allows one repair attempt on generated code. It is safe execution, not an autonomous debugger.
- A teammate owned the natural-language modelling half; my ownership is the execution and decision side.
Next
Chapter 02
Forkcast
A language model can explain a decision. It cannot be allowed to invent the numbers behind it. Forkcast enforces that in code, and exposes the verifier so anyone can attack it.
Explore case study→Chapter 01
DepotOps
At 18:40 a charger fails. The agent simulates tonight two hundred times, finds that most of them end badly, and evaluates five interventions before anyone notices.
Explore case study→