Interpretability and World-Model Debugging › What Debugging a World Model Means

Debugging seeks an explanation for a measured failure. A poor loss or return can reveal a problem without locating it. Validation loss remains useful for model selection when it matches the intended use; in model-based control, downstream search and feedback can make prediction loss an incomplete guide to decision quality. We therefore examine both component predictions and the composed system.

Consider the pipeline as a chain of interfaces. The encoder reads observation history (and, in an oracle variant, privileged simulator state) and writes a latent state $z_t$. The transition model reads $(z_t, a_t)$ and writes a predicted $z_{t+1}$. The planner uses $z_t$, the transition model, the cost objective, and its search configuration to choose $a_t$. The environment advances under that action and produces the next observation. These are specified contracts for our comparisons, not guarantees enforced by Python array types. We must also disclose auxiliary parameters, random streams, and privileged inputs. Substitution is controlled only when the surrounding contracts and information sources remain compatible.

A useful debugging frame is to ask three questions in order:

1. Is the representation informative? Does $z_t$ carry the information the downstream task needs? This is a question about the encoder and the observation channel, answered with probes and concept analysis.
2. Is the dynamics correct? Given a correct state, does the transition model predict the next state accurately, and does error stay bounded as the horizon grows? This is a question about the transition model, answered with teacher-forced and recursive rollouts.
3. Is the planner configured correctly? Given a correct model, does the search find good actions? This is a question about the planner, answered with controlled substitution.

These three questions hold the task objective fixed. Check that objective too: does the supplied cost or reward express the intended task? Correct transitions and accurate search can still produce unwanted behavior when the planner solves the wrong objective. The laboratory uses a specified task cost throughout; it does not inject or diagnose a learned reward-model fault.

This order is a useful starting point, not a prerequisite for every test. Privileged simulator states let us test a transition model before trusting the learned estimator. A reference model similarly lets us test a planner while the deployed model remains faulty. The important requirement is to specify the input information and reference assumptions for each comparison.

The questions interact. An estimator error can change a transition model's input distribution; in other cases, a learned transition is calibrated to the estimator's coordinates and remains accurate there. A transition error can change candidate rankings and selected actions. Closed-loop return combines these effects. A controlled experiment changes one specified factor while keeping the rest fixed as far as the protocol permits, and reports what other quantities changed as a consequence.

This distinction is the spine of the chapter. We will build tools that localize, and we will be precise about what localization does and does not license you to claim. In particular, "localize" is a relational verb: you localize a fault relative to an interface, a distribution, and a substitution protocol. Change any of those, and the localization can change too.