Business World Model

TL;DR

World models let an agent rehearse actions in its head before taking them. Every serious world model so far has been built for pixels and physics: driving, robotics, games, video. Business does not work that way — the “state” of a company is not a scene, it is a set of entities (customers, products, subscriptions) with attributes and relationships, and there are no laws of business the way there are laws of motion.

This paper defines a Business World Model (BWM): a three-part internal simulator made of (1) a semantic state built from business entities and their attributes, (2) dynamics approximated by trained ML models plus hard-coded business rules, and (3) an explicit, enumerated action space of things the company is actually allowed to do. An agent planner sits on top and uses those three parts to generate candidate initiatives, estimate their effects, check them against constraints, and rank them.

The payoff the authors are after is a shift in how you talk to a business system: from “target tier-4 churn-risk subscribers over $10/month and give them 10% off” to “cut paid churn 2%, touch at most 20,000 subscribers, and don’t lose more than 0.1% of revenue — propose two campaigns.”

Be clear about what this paper is. It is a position and architecture paper. There are no experiments, no benchmarks, no numbers. The reference implementation on GitHub is three LLM agents that read two markdown tables and write a recommendation — no models are called, no state is stored, nothing is simulated. The framing is genuinely useful and the components are all real; the evidence that it works is entirely absent.

Problem & Motivation

The pain in one sentence: today’s autonomous business systems execute the plan you hand them, but they cannot tell you whether it was the right plan.

The authors’ own prior work (Pang and Sayama, IEEE SysCon 2026) built a neuro-symbolic system that reliably executes a business initiative end-to-end. That system will happily run “find subscribers paying over $10/month in churn-risk tier 4 in above-median-income cities, send them 10% off.” What it will not do is ask whether tier 3 at $15 would have been better, what the discount does to revenue, or whether a different lever entirely — a bundle, a content change, a retention email — would beat the discount. Every consequential decision was made by the human before the system was invoked. The AI was the hands, not the head.

Why can’t you just point an existing world model at this? Three structural mismatches:

• The state is semantic, not visual. A driving world model’s state is roughly “what the camera sees.” A company’s state is “these 4.2M consumers, with these tenures and these engagement patterns, holding these subscriptions at these rates against these products.” There is no frame to predict.
• There are no laws of business. Physics generalizes; a churn elasticity does not. Business dynamics are context-dependent relationships that shift with competition, regulation, macro conditions, and the company’s own past actions. You can only ever approximate them locally, from your own data.
• The action space is small, discrete, and legally constrained. A robot arm has a continuous action space. A subscription business has maybe forty things it can actually do, most of which need approval. Enumerating that space explicitly is more useful than learning it.

There is a fourth pain, which is organizational and which the paper is right about: the pieces already exist and don’t compose. Strategy lives in decks. Measurement lives in dashboards. Prediction lives in a churn model somebody’s data science team shipped two years ago and which nobody’s planner can call. Optimization lives in a pricing tool. None of them share a vocabulary, so no agent can query them as one system. A BWM is essentially a proposal to make them share one.

What’s New (Core Contribution)

Four claims, ranked from most to least real.

1. The business-semantics-centric state formulation — genuinely useful framing. Before: world model states are latent vectors or pixel frames learned from observation. Now: state is explicitly the key business entities, their attributes, and their relationships. Crucially, attributes get partitioned into controllable (price, discount, rate — an action can set them directly) and non-controllable (churn probability, revenue, retention — you can only move them through the dynamics). That partition is the whole ballgame: it names precisely why business planning is hard. Your levers never touch your goals directly.

2. The explicit action space tied to entity attributes — a good design constraint. Before: an LLM planner is free to propose anything, including things your company cannot legally or operationally do. Now: an action is formally defined as a modification to one attribute of one entity, and the feasible set A(S_t) is enumerated and state-dependent. This is a hard grounding constraint that kills a large class of LLM hallucination — the planner cannot invent “offer lifetime free tier” if that’s not in the table.

3. The neuro-symbolic dynamics layer — real but not new. Before: world models are learned end-to-end and differentiable. Now: dynamics are a registry of heterogeneous predictors — trained ML models where you have data, deterministic coded rules where you have regulation or policy. The registry is queryable by an agent (each model advertises its input features and what it predicts). Sensible and correct, but this is a model registry with metadata, which MLOps has had for years. The novelty is pointing an agent at it, not the registry itself.

4. “The first Business World Model” — an act of naming. The authors say so explicitly, and to their credit they also admit in the conclusion that “many individual components… are not themselves new.” What is new is the assembly and the label. Take that seriously without overrating it: naming a category is how a category gets built, and the name is a good one. But do not mistake it for a technical result.

What is not here: any learning of the dynamics from the model’s own rollouts, any uncertainty propagation across a multi-step trajectory, any optimizer, any evaluation. The paper defines the box; it does not fill it.

How It Works (Technically)

The one equation, translated

The formal core is two lines that will look familiar to anyone who has seen a Markov Decision Process:

S_{t+1} ~ P(S_{t+1} | S_t, a_t)
a_t ∈ A(S_t)

Line 1, in English: “Given the business as it stands right now (S_t) and one action you’re considering (a_t), here is a probability distribution over what the business looks like next (S_{t+1}).” The squiggle ~ means “is drawn from” — the output is not one number, it is a spread of possible outcomes with likelihoods. That matters commercially: the honest answer to “what does a 10% discount do to churn” is never a single number, it is a distribution with a mean and a width, and the width is what tells you whether to run the campaign.

Line 2, in English: “The action you pick has to come from the set of actions that are actually available given the current state.” A(S_t) depends on S_t — you cannot discount a product that is already at floor price, you cannot email a subscriber who opted out.

What this is operationally: P is not one model. In a BWM, P is assembled at query time out of whatever predictors and rules are relevant to the attributes the action touches. If the action is “set subscription rate,” the planner pulls the churn model (rate is one of its inputs) and a revenue rule (deterministic arithmetic), and composes them. That composition is the interesting engineering problem, and the paper does not solve it — it just says the registry makes it possible.

The state, concretely

For the paper’s running example (a media subscription company), state is three entity types:

The reference implementation’s entire action space is two rows: change subscription rate and change product standard rate. That is honest about how small a real starting action space is — and it is a fair place to start, because those two levers cover most retention and pricing work at a subscription business.

Architecture & data flow

The static picture — what the parts are:

flowchart LR
  OBS[Business observations<br/>CRM, billing, web analytics, market data] --> ST

  subgraph BWM["Business World Model (internal simulator)"]
    ST[(Semantic state<br/>entities, attributes, relations)]
    DYN[Dynamics registry<br/>ML models + coded rules]
    ACT[Action space A of S<br/>attribute-level levers]
  end

  ST -->|current attribute values| PLAN
  DYN -->|"P of S-next given S, a"| PLAN
  ACT -->|feasible levers| PLAN

  GOAL[Outcome spec + constraints<br/>'cut churn 2%, lose <0.1% revenue'] --> PLAN
  PLAN[AUTOBUS-BWM planner<br/>LLM reasoning + search] --> CAND[Ranked candidate initiatives<br/>with predicted effects + side effects]
  CAND --> HUMAN{Human approves}
  HUMAN -->|selected plan| EXEC[Execution layer]
  EXEC --> ENV((Real business))
  ENV -->|new observations + realized outcomes| OBS

The dynamic picture — what happens to one request:

flowchart TD
  A["Goal: reduce paid churn 2%<br/>≤20k subscribers, revenue drop ≤0.1%"] --> B[Parse goal into<br/>target attribute + constraints]
  B --> C[Query dynamics registry:<br/>which models predict churn?]
  C --> D[Read model metadata:<br/>churn model needs rate, visit frequency, visit breadth]
  D --> E[Query action space:<br/>which levers touch those inputs?]
  E --> F["Candidate generation:<br/>segment × lever × magnitude"]
  F --> G[Simulate each candidate:<br/>run churn model on modified state]
  G --> H[Propagate side effects:<br/>revenue rule, capacity rule]
  H --> I{Constraints satisfied?}
  I -->|no| F
  I -->|yes| J[Score + rank surviving candidates]
  J --> K[Present top-2 with predicted<br/>churn Δ and revenue Δ]
  K --> L[Human selects → execute]
  L --> M[Observe realized outcome]
  M -->|update state, retrain/recalibrate models| C

Schematic candidate search. Each branch is one candidate campaign (a segment × a lever × a magnitude) rolled forward through the dynamics into predicted churn change and revenue change. The shaded band is the constraint region from the goal spec; branches outside it are pruned, and only survivors get ranked and shown to the human. The numbers are illustrative, not the paper's — the paper reports none.

Tracing one request end to end

Start: "Reduce overall paid-subscriber churn by 2%. Propose two campaigns. Touch no more than 20,000 subscribers. Total revenue must not decline more than 0.1%."

1. Goal parsing. Target attribute = churn rate on the Subscription entity. Direction = down. Magnitude = 2%. Constraints = {reach ≤ 20,000; revenue Δ ≥ −0.1%}.
2. Dynamics lookup. The planner reads the model registry and finds Churn Prediction — described as predicting probability of churn within 60 days, from monthly rate, site-visit frequency, and site-visit breadth. That metadata is what makes the registry agent-usable: the planner now knows churn is reachable through monthly rate.
3. Action lookup. The action space says the company can change subscription rate (entity: Subscription, attribute: Rate). Rate is a churn-model input. A causal path from lever to goal now exists: change rate → subscription.rate → churn model → churn probability → churn rate.
4. Candidate generation. Cross segments (rate band × churn-risk tier × income percentile) with lever magnitudes (5%, 10%, 15% discount). This is the step the paper hand-waves; in practice it is either LLM-proposed or a bounded grid search.
5. Simulation. For each candidate: copy the state, apply the attribute change to the targeted subscribers, re-run the churn model on the modified rows, aggregate into a predicted churn rate.
6. Side-effect propagation. Revenue is not in the churn model. It comes from a deterministic rule: revenue = Σ(rate × retained subscribers). The discount cuts rate on the targeted rows; retention rises. The net can go either way — which is exactly why the paper’s two illustrative candidates differ in revenue impact while matching on churn.
7. Constraint filtering. Drop anything reaching more than 20,000 subscribers or losing more than 0.1% of revenue.
8. Ranking and presentation. Two survivors: tier 4 above $10 at 10% off (churn −2.1%, revenue flat), tier 3 above $15 at 10% off (churn −2.1%, revenue −0.05%). The human picks.
9. Feedback. Execute, observe the realized churn, feed the result back into state and into model recalibration. This closes the loop — and it is the single hardest step, because your realized outcome is one sample from the distribution you predicted, and attributing the difference between predicted and realized is a causal inference problem, not a bookkeeping problem.

The state as an entity-attribute graph, in 3D — drag to orbit. Blue spheres are controllable attributes an action can set directly; grey spheres are non-controllable outcome attributes. Orange links are dynamics (ML models and coded rules) that carry an effect from a lever to an outcome. The point of the picture: there is never a direct edge from a lever to a goal. Every path runs through a model you had to train or a rule you had to write.

The reference implementation, honestly

The GitHub repo (cecilpang/autobus-bwm-paper) is three agents on the OpenAI Agents SDK pointed at Gemini:

sequenceDiagram
  participant U as User
  participant P as planner_agent
  participant M as ml_model_discovery_agent
  participant A as action_recommendation_agent
  U->>P: "Reduce churn 2%, ≤2000 subs, revenue drop ≤$20k"
  P->>M: which models help here?
  M->>M: read bwm/ml_model_registry.md
  M-->>P: churn model (inputs: rate, visit freq, visit breadth)
  P->>A: which levers touch those inputs?
  A->>A: read bwm/action_space.md
  A-->>P: change subscription rate; change product standard rate
  P-->>U: recommended campaign (prose)

That is the whole thing. The “state” does not exist — there is no consumer data. The “dynamics” are two rows of a markdown table describing models that are never called. Nothing is simulated; the final campaign is written by Gemini from the two tables. It is a demo of the interface between a planner and a BWM, not of a BWM. Useful as a skeleton, misleading as evidence.

The algorithm, simplified

Here is the loop the paper describes but does not write. This is the part worth typing yourself:

# The core BWM planning loop: propose -> simulate -> constrain -> rank.
# Stubs: state is a dataframe-like of entity rows; registry.predict(name, rows) calls a
# real trained model; rules are deterministic python functions over the state.

def plan(goal, state, registry, action_space, rules, n_candidates=200):
    # 1. Which dynamics can even reach the goal attribute? Metadata-driven, not guessed.
    models = registry.models_predicting(goal.target_attribute)      # e.g. churn model
    reachable_inputs = {f for m in models for f in m.input_features} # e.g. {rate, visit_freq}

    # 2. Only levers that write an attribute some model reads can move the goal.
    levers = [a for a in action_space if a.attribute in reachable_inputs]
    if not models or not levers:
        return []                                                   # honest dead end, no LLM guessing

    scored = []
    for cand in propose(goal, state, levers, n=n_candidates):       # segment x lever x magnitude
        # 3. Simulate: copy state, apply the intervention, re-predict.
        sim = state.copy()
        rows = sim.select(cand.segment)                             # the targeted entity rows
        rows[cand.lever.attribute] = cand.apply(rows)               # e.g. rate *= 0.90
        for m in models:
            rows[m.output] = registry.predict(m.name, rows)         # P(S_next | S_t, a_t), per row

        # 4. Side effects the goal model never sees, from deterministic rules.
        effects = {name: fn(sim) for name, fn in rules.items()}     # revenue, cost, capacity
        effects[goal.target_attribute] = aggregate(sim, goal.target_attribute)
        effects["reach"] = len(rows)

        # 5. Constraints are hard filters, not soft penalties -- a plan that breaks
        #    a revenue floor is not a worse plan, it is not a plan.
        if not all(c.satisfied(effects) for c in goal.constraints):
            continue

        # 6. Score only on goal attainment; constraints already did their job.
        scored.append((goal.utility(effects), cand, effects))

    scored.sort(reverse=True, key=lambda x: x[0])
    return scored[:2]                                               # candidates for a human to pick

Two things to notice. First, steps 1–2 are the paper’s real contribution in code form: the planner is routed by metadata, so it cannot propose a lever with no modeled path to the goal. Second, step 3 is where a real BWM diverges from the paper — registry.predict on the modified state gives you a correlational prediction, and you have quietly assumed the model stays valid under intervention. It usually does not. More on that below.

Built on Prior Work

The LeCun-vs-Xing framing is the intellectually sharpest part of the paper, and it earns its place. The authors’ position is a real one: a BWM should not learn latent business embeddings, because a business plan that cannot be read, argued with, and audited by a human executive is not a business plan. The grounding is entities and attributes precisely so the output survives a boardroom.

Results & Evidence

There are none. No experiments, no dataset, no baseline, no metric, no ablation. The paper says so itself: the implementation “remains limited in scope and should not be viewed as a full realization of the proposed architecture,” and calls for future case studies.

What the paper offers instead:

• Two illustrative candidate campaigns with specific numbers (−2.1% churn, 0% and −0.05% revenue). These are invented for the example. Nothing produced them.
• A GitHub demo that, as shown above, runs three LLM agents over two markdown tables. It demonstrates that an LLM can read a registry and name a lever. It does not demonstrate simulation, prediction, constraint satisfaction, or any BWM claim.
• Four figures, all conceptual diagrams.

What the evidence does establish: the architecture is coherent, the vocabulary is clean, and the metadata-routing pattern (models advertise inputs and outputs; the planner picks levers that reach the goal) works well enough to run.

What it does not establish — and these are the load-bearing questions:

• Whether composed predictions stay calibrated. Chaining a churn model into a revenue rule into a capacity rule compounds error, and nobody measured it.
• Whether a supervised model survives intervention. Your churn model learned that people on low rates churn less, in a world where you chose who got low rates. Set rates by fiat and that correlation can evaporate. This is the single biggest technical hole and the paper does not name it.
• Whether the LLM planner picks good candidates or merely plausible ones. Search quality is untested.
• Whether any of it beats a competent analyst with a SQL prompt and a spreadsheet — the baseline nobody ran.

Read this as a well-argued position paper that stakes out a category. That is a legitimate contribution. Just do not cite it as proof that BWMs work, because it does not claim to be, and anyone checking your sources will notice.

How You’d Use It

This paper is more useful as a build sequence for your own operation than as a single technique to bolt on. It gives you a defensible reason to do the unglamorous data work first, and each stage stands on its own even if you stop there. It touches three lenses: your business (the economics of running with AI in the loop), your automations (the back-office pipelines that feed it), and your harness (the tool surface your agents end up calling).

The build order, rung by rung:

1. Semantic entity layer (weeks, not months). Define your own four to eight key entities, their attributes, and their relationships, then wire it to your real systems. This is a data-modeling project wearing an AI hat. It is unglamorous, it is the actual bottleneck, and the paper is right that it must come first. Output: a queryable state store with a documented schema.
2. Action space inventory. Sit with whoever runs operations and enumerate every lever: what attribute does it write, who approves it, what are its bounds, what preconditions gate it. This is a workshop, not a build, and it usually surfaces that nobody in the company has ever written the list down. Output: a versioned action-space registry with approval metadata.
3. Dynamics registry. Wrap whatever predictive models you already own behind a uniform interface with honest metadata — inputs, output, training window, known drift, confidence. Add deterministic rules for the arithmetic (revenue, margin, capacity). Most companies already have three or four models sitting unused; making them agent-callable is high-value and low-risk. Output: a model registry your agent can query.
4. Simulator. Now, and only now, the “what if” engine: apply an intervention to a state copy, re-predict, propagate side effects, report a distribution. Output: a scenario endpoint.
5. Goal-driven planner. The LLM layer on top that turns “cut churn 2% without losing revenue” into ranked candidates with predicted effects. Output: the part that actually looks impressive in a demo.

Where the effort pays off: rungs 1–3. They are unsexy, they are where most operations are actually broken, and they are what makes rungs 4–5 possible instead of theater. The paper’s incremental-build argument is a good reason not to skip straight to the planner.

Where it slots into your harness: a BWM is not a competitor to your orchestration layer — it is a tool surface for it. Concretely, three tools your existing planner agent gains: query_state(entity, filter), list_feasible_actions(state), and simulate(action, segment) -> distribution over outcome attributes. Everything else in your multi-agent system stays as it is. If you already run one, this is one new capability behind three tool definitions.

The honest read: right now your AI executes the campaign you designed. This is how it starts proposing the campaign — and showing its work on why it thinks that campaign wins. That is the real payoff, and it also tells you exactly where the data work needs to go first.

Where it breaks in production: in regulated contexts the action space is genuinely hard (every lever has an approval workflow); in fast-moving markets your dynamics models drift faster than you can recalibrate; and inside any company, whoever signs off on a recommendation will not accept it without seeing which model produced which number — so the explanation path is a requirement, not a feature. Build the audit trail from day one.

Build Your Own (Minimal Recipe)

A weekend version that captures the real value — a working simulator, not an LLM narrating tables.

Pick a domain with a real outcome variable. Subscription churn is ideal because the data is small, the levers are few, and the outcome is measurable. Use a public dataset (the Telco churn set is fine) so you are not blocked on sourcing your own data.

Build order:

1. State (2 hours). Three tables: consumer, subscription, product. One dataframe each, joined by keys. Add a controllable: bool flag per column in a schema file. That flag is the paper’s central insight; make it explicit in code.
2. Dynamics registry (3 hours). Train one real model — sklearn gradient boosting on churn, or xgboost — and register it with metadata: {name, description, input_features, output_attribute, entity, trained_on, calibration}. Add two deterministic rules as plain Python functions: revenue(state) and reach(segment). The registry is a dict of dataclasses; you do not need MLflow.
3. Action space (30 minutes). A YAML or markdown table: action name, entity, attribute, allowed range, precondition. Start with two actions, exactly like the paper’s demo. Resist the urge to add more before the loop works.
4. Simulator (4 hours — the heart). simulate(state, action, segment) -> dict of outcome deltas. Copy the state, apply the attribute change to the selected rows, re-run every registered model whose inputs changed, then evaluate the rules. Return a dict, not prose.
5. Candidate search (2 hours). Do not start with an LLM. Start with a bounded grid: three segments × two levers × four magnitudes = 24 candidates. Simulate all of them, filter by constraints, sort by goal attainment. You now have a working BWM planner with zero LLM calls, and a baseline to measure the LLM against.
6. LLM layer (2 hours, last). Now add an agent that parses the natural-language goal into the structured Goal(target_attribute, direction, magnitude, constraints) object, and another that explains the winning candidates in prose. Use the LLM for translation and explanation, not for arithmetic.

The two genuinely hard parts:

• Uncertainty, not point estimates. A churn model gives you a probability per row; aggregating those into a portfolio churn rate with an honest confidence interval means bootstrapping or a calibrated ensemble. Skipping this makes your simulator confidently wrong, which is worse than useless in front of an executive. Budget real time here.
• Intervention validity. Your model learned correlations under the company’s historical policy. When your action changes the policy, the correlation may not hold — this is the classic confounding problem, and it is why every serious retention team runs holdouts. Practical answer: attach a validity note to every model saying which interventions it was validated under, and force the simulator to flag when an action moves an input outside its training distribution. A cheap version of this is a distance-to-training-distribution check per row.

Reach for: pandas + scikit-learn for state and dynamics (no deep learning needed, and shallow trees are more auditable), pydantic for the registry and action schemas (metadata validation is doing real work here), any agent framework you already run for the goal-parsing layer, and dowhy or econml when you get serious about the intervention problem.

What to skip: graph databases (a dataframe join is fine until you have millions of relationships), vector stores (the state is structured, not semantic search), and fine-tuning anything.

How to Improve It

Five concrete places the paper leaves value on the table. Each is testable, and the first two are the ones that would turn this from a position paper into a result.

1. Make the dynamics causal, not correlational. The paper’s dynamics are supervised predictors, which answer “what do subscribers like this usually do,” not “what happens if I intervene.” Swap in uplift models or double machine learning (econml) trained on your own historical A/B tests and holdouts, so simulate estimates a treatment effect rather than a conditional average. Test: hold out a real past campaign, predict it both ways, compare against the realized lift. This is the highest-value single change and it is the paper’s most conspicuous omission.

2. Propagate uncertainty and rank on risk, not means. Right now a candidate is scored on a point estimate. Return a distribution per candidate (bootstrap the model, sample the rules), then rank on something risk-aware — probability of hitting the goal, or expected value subject to a 95% floor on revenue. Test: measure how often the top-ranked candidate under mean-ranking violates its constraint when the true outcome is sampled. It will be more often than anyone expects.

3. Close the learning loop the paper only draws an arrow for. The feedback edge in every BWM diagram is unspecified. Make it concrete: after execution, compare predicted vs. realized per candidate, store the residual, and use accumulated residuals to (a) recalibrate models and (b) reweight the planner’s trust in each model. A model whose predictions have been wrong three campaigns running should stop being routed to. This is a small piece of engineering with a large effect on whether anyone keeps using the system.

4. Reserve part of the budget for exploration. A planner that always picks the highest-estimated candidate never learns whether the second-best was better — the standard exploit-only trap. Allocate a small fraction of reach (2–5%) to deliberately uncertain candidates, which doubles as a permanent holdout for improvement #1. Think of it as an insurance premium on model quality, because that is what it is. Test: over six campaigns, compare model calibration with and without the exploration budget.

5. Add real multi-step planning with cross-effects. The paper’s example is one action, one horizon. Real initiatives are sequences, and they interfere: discount now and you cannot discount again next quarter without training customers to wait. Model the action space as state-dependent the way the paper’s own notation A(S_t) promises but the demo ignores — applying an action should shrink the feasible set for subsequent steps. Then do a shallow beam search over three-step sequences. Test: check whether the best three-step sequence beats three greedy one-step choices.

A sixth, more commercial: build the explanation path as a first-class output. Every recommended number should carry a trace — which model, on which rows, with what confidence, plus which rule computed the side effect. The paper treats human-legible state as a design principle but never extends it to human-legible derivations. In practice that trace is what gets a recommendation approved, and it is a genuine differentiator against a black-box competitor.

Glossary

• World model — an agent’s internal model of its environment, used to predict what happens next and rehearse actions before taking them.
• BWM (Business World Model) — this paper’s proposal: a world model whose state is business entities and attributes rather than pixels or physics.
• AUTOBUS-BWM — the authors’ name for the full autonomous business system that plans and executes using a BWM.
• Semantic state — the business described as named entities, their attributes, and their relationships, rather than as a learned vector.
• Controllable attribute — a field an action can set directly (price, discount, rate).
• Non-controllable attribute — a field you can only move indirectly, through the dynamics (churn probability, revenue, retention).
• Action space, A(S_t) — the enumerated set of levers actually available given the current state; state-dependent because preconditions change.
• Dynamics — how the business evolves; here, a mix of trained ML models and hard-coded deterministic rules rather than physical laws.
• Model registry — a catalog of predictive models with metadata (inputs, outputs, description) so an agent can discover which model is relevant.
• Neuro-symbolic — combining learned models (neural) with explicit rules and logic (symbolic); the paper’s dynamics layer is exactly this.
• Rollout / simulation — applying a hypothetical action to a copy of the state and predicting forward, without touching the real business.
• Counterfactual reasoning — estimating what would have happened under a different action than the one taken.
• P(S_{t+1} | S_t, a_t) — “the probability distribution over next states, given the current state and an action”; the standard transition function from Markov decision processes.
• MPC (Model Predictive Control) — a control method that predicts forward with a process model, applies the first step, then re-plans; the closest engineering ancestor of a BWM.
• STRIPS — a 1971 planning formalism defining actions by preconditions and effects; the ancestor of the paper’s attribute-level action space.
• Dyna — Sutton’s 1991 architecture that interleaves acting in the real environment with planning against a learned model of it.
• JEPA (Joint Embedding Predictive Architecture) — LeCun’s approach: predict abstract representations of the future instead of reconstructing raw observations.
• Uplift model / treatment effect — a model that estimates the change an intervention causes, rather than the outcome level; what a BWM’s dynamics arguably should be.
• Calibration — whether a model’s stated probabilities match observed frequencies; a 30% churn prediction should be right about 30% of the time.
• Confounding — when a correlation in your training data was caused by a third factor (often your own past policy), so it breaks when you intervene.
• Holdout — a randomly excluded group that receives no treatment, used to measure what an action actually caused.