World models, what we work on, and where to begin

Physical Reasoning is an open source research collective. Our code, data pipelines and results are in public repositories, including the results that did not work, so you can start contributing without asking anyone. This page covers what a world model is, the four threads we work on, what to read, and where to start. Budget about an hour for it.

What a world model is

A world model is a learned simulator of an environment. Given the current state and an action, it predicts what happens next.

  observation o_t
        |
    [encoder]
        |
    latent z_t ----> [decoder] --> o_t+1
        |
    action a_t
        |
   [dynamics]
        |
    latent z_t+1 --> reward, value, outcome

Three parts, and the middle one is the idea. The encoder compresses a large observation, such as a video frame of two million numbers, into a compact latent state. The dynamics model predicts the next latent state from the current one and the action; this is where the physics lives. The decoder turns a latent state back into an observation when you need to look at it.

The payoff is that you can roll forward in latent space without decoding anything. Dreamer learns behaviour from trajectories it imagines this way. That is the difference between a world model and a video generator: a video generator produces plausible pixels, a world model produces a state you can plan in.

A latent in this sense is not just a hidden layer. Every network has hidden activations; a latent here is a designed bottleneck, with an encoder into it and dynamics defined on it. That distinction decides what you can measure about a model, and most of our work is about measuring.

The lineage, briefly

If you read one thing first, read Ha and Schmidhuber (2018). It is short, and much of what followed is a variation on it.

What we work on

Four threads, all asking one question: has a model learned how the world works, or only the surface statistics of its training data? Prediction error on held-out data cannot tell those apart, so each thread tests a model against something harder.

1. Forecasting against the market

A prediction market prices every outcome, and its price is the hardest baseline available: everyone willing to stake money on the answer. isotherm is a calibrated decision model for Kalshi's daily temperature markets, scored out of sample against the market's own price at the same moment. On New York, adding free National Weather Service forecasts to the price gained +0.224 nats per ladder in the second half of 2023, and nothing distinguishable from zero, or worse, since 2025: the crowd learned to read the forecast. The strategy found on 2023 to 2026 data passed its sealed test as registered, narrowly (+$1,851 over 95 days, Newey-West t 1.77), with monthly profit halving each month. The model is live as an API and an MCP server.

The lesson so far, across weather, gas, indices, currencies and commodities: skill pays where public information takes work to use, and not where the information is a free real-time price. Every result, including the failures, is in FINDINGS.md and on the dashboard.

2. Probing learned representations

We trained joint-embedding predictive architectures (JEPAs) on Kalshi strike ladders and probed what the frozen encoder had learned, against raw inputs and an untrained encoder of the same width. The representations never beat the raw inputs (ridge R² +0.4529 for the best JEPA readout, +0.5091 for raw features), and an untrained encoder got almost all of the way (+0.4423). The collapse diagnostic we built correlated with usefulness the wrong way (+0.390), and the metric everything was ranked by turned out to be mostly measuring input reconstruction. One narrow lift survives every control: +0.0278 residual R² on future realised volatility.

What carries over: run the untrained-encoder control, and check whether a probe target can rank representations at all before training anything. Write-up: We tried to break our own diagnostic.

3. Sealed forward tests

Benchmarks leak into training data. Outcomes that have not happened yet cannot. forward freezes and hashes every entry before a round opens and scores it only on outcomes that resolve afterwards, against copying the last value and against the market on the same outcome. In dry runs, ECMWF's learned weather model (AIFS) loses to its physics model (IFS) out of the box (−0.061) and beats it once both are calibrated (+0.133); the best blend still loses to the Kalshi market priced at its bids (−0.113); and no released time-series foundation model beats copying the last price. Results.

4. Evaluating world models under intervention

A model that holds up under intervention is one you can plan with. We argue that a world model should be judged on whether its imagined outcome of an action matches what actually happens when the action is taken, not on prediction error alone (Prediction is not understanding). The hard part is ground truth: you have to perform the intervention, which is expensive in most domains. Markets are an exception. A matching engine is deterministic, so replaying order books we record ourselves shows what a limit order we never placed would have done; forward's task 3 scores models on exactly that. Its first pipeline check uses one day of recordings, so there is no result yet, and a test on physical environments is still an open problem.

How the threads connect

They are four attacks on the same question, and the lessons move between them. forward's six columns are built from the other threads: skill against copying, because causal-jepa showed that a model which copies its input looks healthy on every other diagnostic; skill against the market priced at its bids, because isotherm found that mid prices flatter every model on thin books; and the share of a gain one month explains, because isotherm found the month explains 97 to 99% of the variance in its results. Intervention is the test none of the others can run: the first three check predictions of outcomes the model cannot influence.

Two topics from our earlier notes, learning action spaces from unlabeled video and persistent spatial memory for interactive world models, have no code or results yet. We list them so they are not mistaken for work in progress; proposals are welcome.

How we work

1. Pre-register. The question, the data and the pass rule are written and pushed before any test data is fetched. Anything found by looking is labelled exploration and goes to a sealed test before it counts.
2. Seal the test. A test set or forward window is scored once, under the rule written before it.
3. Publish negative results. Every pre-registered test is written up whatever it returns. Corrections go beside the original, never in place of it.
4. Beat the strongest baseline. The market priced at its bids, copying the last value, an untrained encoder of the same size.
5. Honest intervals. 95% intervals that resample whole dates, because rows on one date are not independent.

Each repository's CONTRIBUTING.md has the details, the setup (Python and uv) and the commit style.

What to read

Tier 0 is about a day and is enough for a real conversation with us. The rest is for going deep on a thread.

Two habits matter more than coverage. Find what each paper did not show: every result has a scope, and the useful question is where it stops. And run at least one model yourself: reading about world models and debugging one are different skills.

Where to start

The quickest way in is one of the open problems: twelve starter projects, a few days to a few weeks each, every one an issue on GitHub with the code, the data, a first step and the pre-registered test it would be judged by. Comment on the issue before you start, so two people do not do the same work.

If you would rather start from scratch, a two-week path that needs nothing from us:

1. Days 1 to 2. Read Tier 0. You should be able to explain why a latent is not just a hidden layer.
2. Days 3 to 5. Train DIAMOND or an IRIS-style model on one Atari game. The point is not the score; it is that you have debugged a world model and seen where it breaks.
3. Days 6 to 10. Pick a thread and try to break it: find what one of our results did not show, and test it.
4. Days 11 to 14. Write one page: what you tried, what happened, and what you now believe that you did not before. Lead with what surprised you, and post it as an issue on the repository it concerns.

Contributing does not require applying for anything. If you do want to work with us, the open roles are on the Join page, and a page like the one above, about something that did not work, tells us more than a CV.

Open problems: physicalreasoning.ai/open-problems. Code: github.com/physicalreasoning. Questions about a project: an issue on its repository. Anything else: contact@physicalreasoning.ai.