The Two-Part World Model: Scaffold, Dynamics, and Why Your Protocols Are Training Data

Everyone talks about world models but nobody defines what they are. In the AI discourse, “world model” is treated as a single blob of capability that emerges from scale. You train on enough data, the model develops an understanding of how the world works, and somehow it can predict what happens next.

This is wrong. Or at least, it’s incomplete in a way that matters.

A world model has two distinct components. Conflating them is causing real problems in how we build and evaluate AI systems.

The Two Parts

The first component is what I call the scaffold. This is a state table — a structured representation of what exists, what properties things have, and what relations hold between them. The scaffold answers the question: what is true right now?

The second component is the dynamics. These are the patterns of transformation — the rules, regularities, and processes by which states evolve into other states. The dynamics answer the question: what happens next?

These are not the same thing. They do different jobs. They might require different architectures, different training signals, different inductive biases.

Consider the Towers of Hanoi puzzle. The scaffold is simple: a state table tracking which peg each disk is on. Five disks, three pegs, five entries in the table. That’s the entire representation of “what is true right now.”

The dynamics are also simple: only the top disk on a peg can move, and you can only place a disk on an empty peg or on a larger disk. Three rules.

Solving the puzzle means loading an initial state into the scaffold, then repeatedly applying the dynamics to transform it toward a goal state. The scaffold holds state. The dynamics evolve state. Both are necessary. Neither is sufficient alone.

Why This Matters

When we train models end-to-end on prediction tasks, we’re asking them to learn both scaffold and dynamics simultaneously, implicitly, in one undifferentiated mass of weights. We never explicitly separate “what representation should we use” from “what transformation patterns should we learn.”

This creates problems.

First, it makes failures hard to diagnose. When a model gets something wrong, was it because it built the wrong scaffold — wrong entities, wrong relationships, missing state variables? Or was it because it applied the wrong dynamics — incorrect transformation patterns to a correct state? These are different bugs requiring different fixes. But in an end-to-end system, they’re indistinguishable.

Second, it makes reasoning brittle. Chain of thought prompting helps models reason better. But chain of thought without explicit state tracking is dynamics without scaffold. The model reasons about its reasoning about its reasoning, with no ground truth to check against. It’s like playing blindfold chess without knowing the position. Eventually you lose track.

I tested this directly. I solved Towers of Hanoi in my context window, maintaining an explicit state table after each move. It worked. The reasoning was traceable. When I made suboptimal choices, I could see exactly which state led to which decision. The scaffold made the dynamics auditable.

Third, it makes knowledge hard to accumulate. If everything is implicit in weights, you can only improve through more training. But if scaffold construction is explicit — if there’s a structured representation you can inspect and modify — then you can improve by fixing the representation directly.

Pattern Matching Is Not Reasoning

There’s a deeper issue here. Without explicit scaffolds, models don’t actually reason. They pattern match.

Default mode for a language model is recognition and retrieval. Input comes in, activates patterns from training, output comes out. This is fast. It’s often good enough. When the problem resembles familiar training examples, pattern matching produces correct answers. But it’s not reasoning. It’s sophisticated lookup.

The difference matters when problems are novel compositions. Familiar pieces in unfamiliar arrangements. The pattern matcher sees pieces it recognizes and produces outputs that look right — plausible text that resembles good answers. But plausible isn’t the same as correct.

Scaffolds force actual reasoning. When you maintain explicit state, you can’t just pattern match your way through. Each step has to be consistent with the scaffold. If I’m solving Towers of Hanoi and I say “move disk 3 to peg B” — the scaffold lets me check. Is disk 3 actually the top disk on its current peg? Does peg B have a larger disk or is it empty? The state table catches the pattern-matched move that sounds right but violates the rules.

Without the scaffold, there’s nothing to check against. The model produces step after step of plausible-sounding reasoning, but consistency between steps is accidental. It might hold together. It might not. There’s no enforcement mechanism.

This is why chain of thought helps but isn’t reliable. It slows the model down and makes some reasoning explicit. But without a scaffold to maintain state, the chain is just words about words. At some point the model loses track of what’s actually true in the problem, and the pattern matcher takes over, producing text that looks like reasoning but isn’t grounded in state.

Protocols force scaffold construction. Without a protocol, the model might jump straight to pattern matching — see the problem, activate similar examples, produce an answer. With a protocol that says “first build the state table, then identify legal moves, then evaluate options” — the model has to construct the scaffold before proceeding. The protocol is a forcing function that prevents premature pattern matching.

This is the real distinction between plausible and correct. Pattern matching produces plausible outputs — things that look like good answers based on surface features. Scaffolded reasoning produces correct outputs — things that are actually consistent with the problem state. They overlap most of the time, which is why pattern matching seems to work. But when they diverge, you want correct. And you can only get correct by maintaining state.

Consider a more realistic example: scheduling. You’re allocating meeting rooms for a conference. Room A holds 50 people, Room B holds 30. Session 1 needs 40 seats, Session 2 needs 25, Session 3 needs 35. Sessions 1 and 2 overlap in time, Sessions 2 and 3 overlap, Sessions 1 and 3 don’t overlap.

A pattern matcher sees a constraint satisfaction problem, activates templates from training, and produces a plausible-looking assignment. Maybe it says: Session 1 in Room A, Session 2 in Room B, Session 3 in Room A. That sounds reasonable.

But is it correct? To verify, you need a scaffold — a state table tracking room assignments by time slot. When you build it, you can check: does Session 1’s time in Room A conflict with anything? Does Session 3 fit in Room A given the capacity constraint? Are all the overlap constraints satisfied?

Without the scaffold, you’re trusting the pattern matcher’s output. With the scaffold, you can verify each assignment against explicit state. When the model says “Session 3 in Room A,” you can check: Room A holds 50, Session 3 needs 35, Sessions 1 and 3 don’t overlap so no time conflict — valid. That’s reasoning. The other way is hoping.

The Spatiotemporal Scaffold Is Special

Not all scaffold dimensions are equal. The three dimensions of space and the one dimension of time have a privileged status.

You might think spatial and temporal relations are just more entries in the state table. “The cup is on the table” and “Alice owns the cup” are both relations, after all. Why treat one as special?

Because space and time are the substrate in which physical causality operates. They’re what makes locality meaningful. Things can only directly interact with nearby things. Causes precede effects. Information has speed limits.

When modeling physical reality, the 3+1 dimensional scaffold isn’t optional. It provides the addressing scheme that makes physical dynamics coherent. You can’t have a world model of physical reality without it.

Abstract domains might have looser scaffold constraints. An insult from ten years ago can affect behavior today. A belief in one country can influence actions in another. Social and logical dynamics don’t respect spatial locality the way physical dynamics do. This is part of what makes them harder to model — the scaffold constraints are weaker, so the dynamics can go anywhere.

Learning World Models Has Two Parts

If world models have two components, then learning world models is two different problems.

Learning the scaffold means learning ontology — what entities exist, what dimensions matter, how to address and organize state. This is learning the structure of the world.

Learning the dynamics means learning physics, broadly construed — the patterns by which states transform. This is learning the processes of the world.

A baby doesn’t just learn that “things fall.” First they learn that there are things. That things persist. That things have locations. That’s scaffold construction. Object permanence is a scaffold insight. Only then can dynamics like “unsupported things fall” be meaningfully learned.

I suspect current models struggle partly because they’re trying to do both with machinery that might be suited for only one. They’re learning dynamics on an impoverished implicit scaffold that doesn’t carve reality at its joints.

Protocols Describe Scaffolds

Here’s where it gets practical.

A protocol is an explicit specification of how to approach a problem. “First identify the entities. Then identify their properties. Then identify the relationships. Then determine what changes over time.” That’s scaffold construction, written down.

When you write a protocol, you’re not learning anything new. You’re freezing what you already know into explicit structure. The protocol says: here’s how to build the scaffold for this kind of problem.

The protocol handles the known cases. When it fails — when you hit an edge case the protocol doesn’t cover — you fall back to explicit reasoning. You build the scaffold from scratch, work through the dynamics carefully, solve the problem.

Then you update the protocol.

This is how chess theory works. Opening theory is a tree of pre-computed scaffolds with attached evaluations. When you’re “in theory” you’re following the protocol. When you’re “out of theory” you have to calculate from scratch. When someone discovers a new move that works, it gets added to theory. The protocol expands.

I experienced this directly when I was younger, reading a book on the Sicilian Pelikan over months of train commutes. After absorbing that theory, I could play blindfold chess in those lines. Not because I’d gotten better at tracking raw board positions, but because the opening theory gave me compressed scaffolds. Named lines instead of coordinates. The scaffold was pre-built. I just navigated within it.

Protocols describe scaffolds until they don’t work. When they stop working, you’re at the frontier. That’s where learning happens.

The Connectionist Reframe

If you’re committed to end-to-end learning, everything I’ve said might sound like a retreat to symbolic AI. It’s not.

Here’s the bridge: every protocol you write and refine is synthetic training data.

The explicit reasoning traces — building scaffolds, applying dynamics, finding edge cases, fixing the protocol — that’s exactly what you’d want a model to learn from. It’s high-quality structured reasoning with inspectable steps and clear error attribution.

The connectionists can distill it into weights. The neuro-symbolic folks can keep it explicit. Same process, different interpretation of where the knowledge lives at runtime.

But here’s the crucial point: we don’t train better models so we can get rid of protocols. We train better models so they can extend protocols.

Protocols handle the known cases. When you hit an edge case — when the protocol doesn’t work — you’re at the frontier. Now you need to reason your way to a solution, and then update the protocol to cover the new case.

A better-trained model is better at that frontier reasoning. It has stronger intuitions about scaffold construction. It can work through novel situations more reliably. It can figure out why the protocol failed and how to fix it.

The goal isn’t to replace protocols with weights. The goal is to have weights that are good enough to extend the protocols when they break. Better intuition means you can push further into unknown territory and bring back better protocols.

This is the flywheel: protocols train better models, better models reason through harder edge cases, that reasoning produces better protocols, which train even better models. Each turn of the cycle pushes the frontier outward.

OpenAI’s reasoning models are already doing something like this. The chain-of-thought traces in o1 and o3 include explicit scaffold construction. They’re building representations before applying dynamics. But as far as I can tell, they’re not saving the protocols. They’re not reusing successful reasoning structures. Each problem gets solved from scratch.

This is a missed opportunity. If you saved the successful scaffolding patterns, you could refine them. You could find where they fail. You could build hierarchies of protocols for different problem classes. And yes, you could use them as training data for the next generation of models.

The learning loop would be: use protocols, find edge cases, reason through them, update protocols, train on successful protocols, get better intuitions, write better protocols, find subtler edge cases. Each turn of the cycle operates at a higher level.

Why Imperfect Protocols Still Work

A reasonable objection: this sounds fragile. What if the protocol is wrong? What if it doesn’t cover the case? What if the hierarchy loads the wrong sub-protocol?

Here’s the thing: large language models are smart. A capable model with a shitty protocol still gets the right answer most of the time.

This isn’t a bug, it’s the whole point. The protocol provides structure. The model provides capability. They work together. The protocol doesn’t have to be perfect because the model compensates for its gaps.

Consider what happens with a flawed protocol. The protocol says “identify entities” but doesn’t specify how. The model’s pattern matching handles the how. The protocol says “check constraints” but misses one. The model notices something feels off and checks anyway. The protocol doesn’t cover an edge case. The model doesn’t halt — it falls back on its training and reasons through it.

This is the opposite of old symbolic AI. Those systems needed perfect rules because they couldn’t compensate. If the rule was wrong, the system was wrong. No recovery. That brittleness is why symbolic AI lost to statistical approaches.

Protocols for language models aren’t like that. They’re more like scaffolding in the construction sense — temporary support structure while you build. The scaffolding doesn’t have to be load-bearing forever. It just has to help the model stay on track.

A bad protocol is better than no protocol. No protocol means pure pattern matching from the start. A bad protocol at least forces some scaffold construction, some state tracking, some structure. The model might deviate from the protocol when it’s not working, but it started from a better place than if it had just freestyled.

And when the protocol fails visibly — when the model struggles despite following it — that’s diagnostic information. You can see where the protocol broke. You can fix that specific part. You can’t do that with pure pattern matching because there’s nothing explicit to examine.

The goal isn’t perfect protocols. The goal is protocols good enough to help, with models smart enough to handle the imperfections. As models get smarter, they can work with rougher protocols. As protocols get refined, they help even modest models. Both improve together.

This is also what makes it a self-supervised learning problem. Even bad state is state. Even a flawed scaffold is something the model can reason about.

There’s an observation floating around the prompt engineering community that giving an LLM a wrong solution as a starting point often produces better results than giving it nothing. This seems counterintuitive until you understand the scaffold principle. A wrong solution is still structure. It’s something to analyze, critique, and fix. “Here’s an attempt, find what’s wrong with it” is a much better starting point than “solve this from scratch.”

The model can trace through the wrong solution and find where it breaks. It can identify what the attempt got right — often most of it. It can focus its reasoning on the broken part rather than reconstructing everything from nothing. The wrong solution provides a scaffold, and even a bad scaffold beats no scaffold.

This connects to research showing that increasing the number of reasoning steps improves performance even when some of those steps contain errors. The structure helps regardless of correctness. Having steps to examine, evaluate, and potentially fix is more valuable than having nothing explicit to work with.

With pure pattern matching, there’s nothing to analyze when things go wrong. The model produced output, the output was wrong, end of story. You can’t ask “where did the reasoning fail” because there was no explicit reasoning to examine.

But with a scaffold — even a bad one — there’s structure. The model can look at it and say “this state doesn’t make sense” or “this transition violated a constraint” or “we’re tracking the wrong entities.” The scaffold makes the failure legible. And legible failures are learnable failures.

The model uses the protocol, hits a case it doesn’t handle, reasons through it anyway, and the successful reasoning trace becomes training data. No human labeling required. The supervision signal comes from the structure itself. Did the scaffold remain consistent? Did the dynamics produce a valid end state? Did the solution actually work? These are checkable without human annotation.

The protocol defines “known territory” — cases where we have explicit structure. Anything outside the protocol is unknown territory. When the model successfully navigates unknown territory, that reasoning trace becomes new training data. The known territory expands. The protocol can be updated. The cycle continues.

This lowers the bar dramatically. You don’t need perfect protocols to start. You don’t need to anticipate every edge case. You don’t need a team of knowledge engineers carefully crafting flawless specifications.

You can start with really bad protocols. Rough, incomplete, maybe even wrong in places. As long as the model is capable enough to compensate and the pipeline captures successful reasoning, the protocols will improve over time. Bad protocols morph into good protocols. Good protocols morph into better ones. The system bootstraps itself.

This is what makes it a true self-supervised learning task. The protocol rewriting is automatic. You just need one meta-protocol — an error protocol that says: on error, analyze what went wrong, propose a fix, test it, and if it works, rewrite the protocol. That’s it. That’s the entire self-improvement loop.

Think of the error protocol as a compiler and debugger rolled into one. Standard protocols are the code the model runs. When execution hits a contradiction — “I moved disk 3 to peg B, but peg B already has a smaller disk” — the error protocol triggers. It doesn’t hallucinate through the contradiction the way pure pattern matching would. It stops, audits the scaffold, identifies whether the bug is in state tracking or rule application, proposes a patch, and retries.

A reasonable question: when does the model follow a protocol versus override it? The answer is simple. Protocols are authoritative until they produce contradictions. Follow the protocol. If following it leads to inconsistent state or violated constraints, that’s when the error protocol activates. The model doesn’t get to override protocols because it “feels” like a different approach would be better. It overrides when the scaffold breaks.

This keeps the system disciplined. Pattern matching would love to take shortcuts, to skip the state tracking, to jump to plausible-looking answers. The protocol prevents that. Only failure — explicit, checkable failure against the scaffold — earns the right to modify the protocol.

And protocol rewriting itself follows a protocol. There’s a meta-protocol for how to analyze failures, propose fixes, test them, and integrate successful changes. It’s protocols all the way down. But that’s fine — it has to bottom out somewhere, and a small set of meta-protocols for error handling and protocol evolution is a manageable foundation.

The model does the analysis. The model proposes the fix. The model tests it. The model rewrites the protocol. No human in the loop required for the iteration. Humans can curate, can review, can inject expertise — but the basic cycle runs on its own.

There’s a speed concern here. Explicit error correction is slow. Running the error protocol, auditing state, proposing fixes — this takes time. But this is where distillation matters.

The slow explicit phase generates traces. Every successful fix-and-retry sequence is a high-quality reasoning example. You save these traces and train on them. The model’s weights begin to internalize the error protocol. What was slow and explicit becomes faster and more intuitive. The model starts to develop a feel for when a scaffold is becoming inconsistent, because its dynamics have been shaped by thousands of corrections.

But here’s what’s important: distillation doesn’t replace the scaffolds. It makes the model better at working with them, not better at working without them. The protocols remain guardrails at runtime. Intuition improves, but explicit structure stays. You don’t throw away the protocols after training any more than a chess master throws away opening theory after internalizing it. The theory is still there to check against when intuition wavers.

The explicit work isn’t wasted overhead. It’s generating the training signal for the next level of capability.

This makes the whole approach a tractable engineering problem rather than an impossible knowledge engineering problem. The old symbolic AI required perfect rules because the systems couldn’t compensate. This requires good-enough rules because the models can compensate — and then the compensation gets folded back into better rules.

This is genuine self-improvement. Not in the sci-fi sense, but in the practical sense: the system generates its own training signal by solving problems its current protocols can’t handle, then uses those solutions to build better protocols.

The Hierarchy Problem

Protocols need to be hierarchical.

A single monolithic protocol that covers everything won’t fit in a context window. Even if it did, most of it would be irrelevant noise for any given problem.

But there’s a deeper reason for hierarchy: models degrade when asked to do too many things at once. Research on multi-instruction following shows that performance consistently drops as the number of simultaneous instructions increases. One benchmark found that even the best frontier models achieve only 68% accuracy when given hundreds of instructions. The degradation patterns vary — some models show threshold decay, maintaining performance until a critical point, others show linear or exponential decay — but all models degrade.

The practical implication: you can’t reliably ask a model to do more than two or three things in a single prompt. Try to do four, and something gets dropped or mangled. This isn’t a bug to be fixed with more training. It’s a fundamental constraint on how attention and instruction-following work.

This means protocols must be broken into steps. Not as a stylistic choice, but as an engineering necessity.

Programmatic Protocols

This leads to a crucial implementation pattern: programmatic protocols. Instead of giving the model one complex prompt with many instructions, you break the protocol into discrete steps executed sequentially. Each step does one or two things. The output of one step becomes input to the next.

Think of these steps as tools. A tool is really just a programmatic protocol — a discrete operation with defined inputs and outputs that’s been implemented in code rather than natural language. “Summarize this document” is a tool. “Extract entities from this text” is a tool. “Check this state table for constraint violations” is a tool.

To make this concrete, consider setting up a GitHub repository. As a written protocol, it might say:

1. Create a new directory for the project
2. Initialize git with git init
3. Create a README.md with project description
4. Create a .gitignore appropriate for the language
5. Create the initial project structure
6. Stage all files with git add .
7. Make initial commit with git commit -m "Initial commit"
8. Create repository on GitHub
9. Add remote origin
10. Push to main branch

A model following this written protocol executes each step, maintaining a scaffold of what’s been done and what the current state is. If step 8 fails because the repository name is taken, the error protocol triggers — analyze the failure, propose a fix (different name), retry.

The same protocol as a tool looks different. You call create_github_repo(name, description, language) and the tool handles all ten steps internally. The model doesn't see the intermediate states. It just gets back success or failure, plus the repository URL.

Both are protocols. The written version is explicit and auditable — you can see exactly what happened at each step, debug failures precisely, and refine individual steps. The tool version is faster and more reliable for well-understood operations — the steps have been debugged and hardened into code.

The choice depends on the situation. Novel or complex tasks benefit from written protocols because you need the auditability. Routine operations benefit from tools because they’re faster and less error-prone. As written protocols mature and stabilize, they become candidates for conversion to tools.

This is the natural evolution: written protocol → refined through use → hardened into tool → called as a single step in higher-level protocols.

Protocol Permissions and Hierarchy

Not all protocols should be rewritable. Some protocols are read-only — foundational rules that shouldn’t change based on individual task experience. Others are rewritable — operational procedures that should evolve as the system learns.

Read-only protocols include things like:

• Safety constraints
• Ethical guidelines
• Core definitions and ontologies
• Meta-protocols for error handling and protocol evolution

Rewritable protocols include:

• Task-specific procedures
• Domain heuristics
• Optimization strategies
• Case-specific handling

The distinction matters because the error protocol and post-processing review could otherwise destabilize foundational rules. If a model encounters a situation where violating a safety constraint would “solve” an immediate problem, you don’t want the protocol evolution mechanism to weaken that constraint. Read-only protocols are protected from the rewrite loop.

Protocols also exist at different levels, and higher-level protocols override lower-level ones when there’s a conflict. The hierarchy might look like:

• Level 0: Invariant constraints (read-only, never violated)
• Level 1: Domain principles (read-only, rarely overridden)
• Level 2: Task-class protocols (rewritable, general procedures)
• Level 3: Case-specific protocols (rewritable, specific handling)

When a Level 3 protocol conflicts with a Level 1 principle, Level 1 wins. The model doesn’t get to rewrite “always validate user input” just because a specific case would be easier without validation.

This creates a stable foundation with flexible operations on top. The core stays fixed while the edges evolve. It’s how human institutions work — constitutions and laws create fixed constraints, while policies and procedures adapt to circumstances within those constraints.

Protocol Evolution Through Post-Processing

One more implementation detail: protocol updates shouldn’t happen in real-time during task execution. They should happen in post-processing.

After the model completes a task, you run a review step. The model looks at its own work and asks: did I deviate from the protocol anywhere? If I did, was the deviation an improvement? Does the protocol need to be updated to reflect what I learned?

This separates execution from reflection. During execution, the model follows the protocol and uses the error protocol only when it hits explicit contradictions. After execution, it can take a broader view — noticing patterns, identifying inefficiencies, proposing refinements that aren’t triggered by failures.

Post-processing also creates natural batching. You don’t update the protocol after every single task. You accumulate experience, then periodically review and refine. This prevents protocol churn and allows patterns to emerge across multiple instances before committing changes.

The review protocol is itself a protocol: examine the trace, compare to the specified protocol, identify deviations, evaluate whether deviations were beneficial, propose protocol updates if warranted. Simple, explicit, auditable.

Context Window as Managed Memory

This brings us to implementation. If protocols are external knowledge that gets loaded into context, then context window management becomes crucial.

Right now, context management is crude. Stuff everything in until it’s full. Maybe truncate from the beginning. Maybe do some retrieval. Hope for the best.

But if you’re serious about scaffolds and protocols, you need intelligent curation. What’s in the window is your working state. It determines what you can reason about.

The context window should be a view rendered from a richer structure. A manifest that points to chunks. Some chunks are the current exchange. Some are relevant protocols. Some are the active scaffold. Some are compressed summaries of earlier work.

The manifest is like a page table. The chunks are pages. The context window is RAM. Storage is disk. Forty years of operating system design, waiting to be applied to LLM context management.

The Claim

Here’s what I’m claiming:

A world model is not one thing. It’s a scaffold that holds state and dynamics that evolve state. These are different. They need different treatment.

Chain of thought is dynamics without scaffold. That’s why it’s unreliable. It works until you lose track of state, which you inevitably do when state is implicit.

Protocols describe scaffolds. They’re explicit specifications of how to build representations for problem classes. They’re frozen knowledge that handles known cases.

When protocols fail, you’re at the frontier. That’s where explicit reasoning happens. That’s where you build scaffolds from scratch. That’s where you update the protocols.

The whole process — protocols, refinement, hierarchy, accumulation — generates synthetic training data. Whether you keep the protocols explicit or distill them into weights, the process is the same.

The field has been arguing about connectionism versus symbols. But the process is the same process. The argument dissolves into an engineering decision about where knowledge lives at runtime.

Build the scaffold. Run the dynamics. Refine when it breaks. Accumulate what works.

That’s what world models are for.