An enterprise needs a revisable model of its world

01 / The world and our account of it are different objects

An enterprise acts through representations: inventory records, forecasts, policies, schedules, conversations, and judgments. Any consequential decision depends on which of these representations is relevant and how closely it corresponds to the situation now.

My proposal is to treat decision-critical context as a revisable model of the world. By “model,” I mean an explicit account of the entities, relationships, assumptions, and constraints needed for a particular decision. I am not claiming a complete digital replica of the enterprise, or using “world model” to imply a trained generative simulator.

The central question is epistemic: what does the organization have reason to believe, and what would make that belief change? AI makes this question practical whenever a system carries an interpretation from one source into another decision.

02 / A useful distinction from decision theory

In their treatment of partially observable decision problems, Kaelbling, Littman, and Cassandra distinguish the underlying state from an agent’s belief about it. Their framework also accounts for actions that gather information. [1] The useful conceptual lesson here is to keep the state of the world separate from our representation of it.

The analogy has limits. A formal partially observable Markov decision process requires specified states, actions, dynamics, observations, and rewards. A narrative context store does not acquire the framework’s guarantees merely because we call it a belief state. An enterprise may also contain legitimate disagreements about objectives that no shared probability estimate resolves.

I borrow the distinction, not a claim to have solved the organization as a formal decision process.

03 / Four kinds of statement that should remain distinguishable

Consider an illustrative scheduling decision. “A specialist is assigned” records an observation. “The specialist will be available tomorrow” expresses a belief about a future state. “The work requires that qualification” states a rule. “This system may confirm the appointment” grants authority. Each statement can affect the action, but each changes for a different reason.

A new assignment can change the evidence. A credible absence report can change the forecast. A policy owner can change the qualification requirement. An authorized manager can withdraw permission. Blending these statements into “ready to schedule” removes distinctions the next decision may need.

This suggests a representation with four separable layers:

• Evidence: observations, sources, and when they were obtained.
• Beliefs: interpretations, assumptions, and unresolved uncertainty.
• Rules: applicable constraints, their scope, and who can revise them.
• Authority: the specific decisions or actions a person or system may take.

04 / Compression should preserve what can change the decision

Handoffs require compression. Carrying every document and conversation forward is expensive, exposes unnecessary information, and can overwhelm the next participant. The design problem is deciding what may be omitted without changing the meaning needed downstream.

I would define decision-relevant context as a distinction whose alteration could change the permissible or preferred next action. This is a proposed design test, not a mathematical claim of sufficiency. Ask what the receiver would do if an assumption were false, a source were stale, or a permission applied only to another case.

When the answer changes, preserve that distinction or require a fresh check. Where the answer does not change, the extra detail may not belong in the handoff. This makes context selection relative to a decision rather than an ambition to collect everything.

05 / A counterexample: more structure can make work worse

For a low-consequence task using a stable source and an obvious acceptance criterion, separating every statement into layers may add more effort than it removes. A short summary or direct lookup could be sufficient. A rigid schema can also give false confidence when its fields are filled with unsupported interpretations.

The proposal is therefore conditional. Add structure where a lost distinction can materially affect the action, and judge the representation by its consequences. Completeness of metadata is a poor substitute for the quality of the underlying evidence.

06 / A proposed experiment

Choose a simulated workflow with known cases of stale information, conflicting scope, and withdrawn permission. Give two conditions the same evidence, access to sources, model, and time budget. In one, pass a narrative summary. In the other, use explicit evidence, belief, rule, and authority fields. Keep the information budget comparable so the test does not simply reward receiving more material.

Include stable routine cases as well as cases where a relevant fact changes after the handoff. Before running the test, define which commitments are invalid and what counts as an appropriate request for more information. Measure incorrect commitments, correct abstentions, unnecessary delays, total effort, and the ability to trace a correction upstream.

The hypothesis predicts an advantage for the structured representation specifically in the cases where scope or state changes matter. If it performs no better there, or creates excessive delays without preventing consequential errors, its proposed value is weakened. If both conditions succeed equally, the additional structure may be unnecessary for that workflow.

07 / A model is useful only if it can be corrected

The final responsibility belongs to the organization. Someone must be able to revise an interpretation, retire an obsolete source, and decide which dependent actions require review. Correcting one answer while leaving the shared representation unchanged is a local repair, not necessarily organizational learning.

The question I would bring to a design review is simple: show me the evidence that could change this decision, and show me how that change reaches the next person or system. A useful enterprise model should make both visible.