Dynamic World Models: The Missing Requirements Layer for AI-Native Software Engineering

AI can generate code. That does not mean it understands the world the code is supposed to represent.

This distinction is becoming one of the central problems in AI-native software engineering. A model may produce a plausible database schema, API, or workflow while missing an implicit business rule, confusing a role with a person, or treating a derived state as a source of truth. The output can be syntactically correct and still describe the wrong system.

The missing layer is not another code generator. It is a better representation of requirements.

We call this representation a Dynamic World Model: a reasoning framework for explaining how a domain works and why it is in its current state. In this framework, concepts participate in events, under constraints, to create and evolve relationships. Software is then generated or implemented as an executable projection of that explanation.

Software Problems Begin as Representation Problems

The conventional delivery pipeline looks like this:

Requirement -> Design -> Code -> Runtime

Most engineering tools optimize the later stages. They help us write, build, deploy, and observe software faster. Yet many failures in complex systems begin earlier:

• requirements are ambiguous;
• business rules remain implicit;
• domain boundaries are unclear;
• state changes are described without their causes;
• the same concept acquires different meanings across teams and systems.

If the representation is incomplete, faster code generation only produces the wrong system sooner.

The more useful pipeline for AI-native engineering is:

Human Intent -> World Model -> Software Projection -> Runtime

Here, the world model is more than a machine-readable specification or a durable semantic contract. It is an explanatory framework between human intent and executable software. It should support reasoning about what exists, how it came to exist, which rules make it valid, what may happen next, and how a proposed action would change the world.

That requires several forms of reasoning:

• structural reasoning about concepts, roles, and relationships;
• causal reasoning about the events that produced the current situation;
• temporal reasoning about how the situation changes over time;
• normative reasoning about what is permitted, required, or prohibited;
• counterfactual reasoning about what would happen if a proposed event occurred.

A representation that can only be parsed is not yet a world model. A useful world model must help explain reality and evaluate possible changes to it.

Beyond Entity-Centric Modeling

Traditional software models often begin with an entity, its attributes, and links to other entities:

Employee
  name
  salary
  department

This is convenient for tables and objects, but it can hide the meaning of the domain. An employee is not a fundamental kind of person. It is a role that exists because of an employment relationship between a person and a company.

Person -> Employment -> Company

The same pattern appears elsewhere:

• a customer is a party in a purchase relationship;
• an owner is a party in an ownership relationship;
• a manager has a role in a management relationship;
• a member participates in a membership relationship.

This relationship-centric view preserves identity while allowing roles, responsibilities, and capabilities to change over time.

Relationship-Boundary Collapse: Choosing the Right Resolution

Relationship-centric modeling does not mean that every relationship must always be expanded in full. A model should be able to change resolution according to the question being asked.

Consider a company system that only needs to know who its current employees are. During that part of the lifecycle, employment may have only a simple beginning and end. The system does not need to reason about the natural person independently, the negotiation that created the employment, or every internal transition of the relationship.

At that resolution, the boundary can collapse:

Expanded explanation:
Person -> Employment -> Company

Collapsed company view:
Employee -> Company

Employee := Person + active Employment, viewed from the Company boundary

Employee is useful here as a collapsed relationship boundary. It presents a stable, concept-like interface to a deeper structure whose internal dynamics are temporarily irrelevant.

If the problem changes, the boundary can be expanded again. A hiring workflow needs to distinguish the candidate, the company, the proposed employment, the events that create it, and the constraints that govern the process. Contract changes, concurrent employments, legal identity, and termination disputes may also require the expanded model.

Collapse is therefore not deletion and not a claim that Employee is intrinsically a kind of Person. It is a controlled abstraction with a declared viewpoint, observable behavior, and a trace back to the expanded relationship. Constraints hidden inside the boundary must either remain preserved or be exposed as part of its contract.

This operation makes the world model recursive. A relationship can be expanded into its participants, events, and constraints; it can also become a participant in another relationship. For example, an Employment relationship may participate in an Assignment to a project, while that assignment can itself be collapsed into a project-membership boundary for a simpler application.

Person + Company
  -> Employment
      -> Assignment
          -> Project

Reasoning can move up or down this structure until it reaches the resolution required by the current decision. State is recursive as well: the visible state of Employee is a projection of the deeper state of Person + Employment, and that boundary state may become an input to another relationship at the next level. The world model is therefore not a flat ontology. It is a recursively navigable explanation of reality.

Four Primitives of a Dynamic World Model

At a given time t, the world model can be summarized as:

$$W(t) = \left\langle C,\;R(t),\;E_{\le t},\;K(t) \right\rangle$$

where C is the set of concepts, R(t) is the set of relationships effective at time t, E(<=t) is the event history observed up to that time, and K(t) is the set of applicable constraints. Time is the index over which the model evolves, rather than a fifth independent primitive.

Concept

A concept is a semantic participant in the world: a person, company, account, product, machine, place, or unit of money. It is not necessarily a final class or table. It is something that can participate in relationships and events.

Relationship

A relationship is a meaningful structure among concepts. It has more than endpoints. It may have a lifecycle, roles, effective dates, capabilities, invariants, and evidence of how it came into existence.

Employment, ownership, authorization, custody, and subscription are relationships in this sense.

Event

An event is something that creates, changes, or ends a relationship. Hiring creates employment. Transferring an asset changes ownership. Revoking a mandate ends an authorization.

Events give the model a direction of time:

Concepts -> Event -> Relationship change

Constraint

A constraint determines whether an event is allowed, whether a relationship is valid, and how a transition may occur.

A payment may require sufficient funds and valid authorization. A hire may require an approved position and an eligible candidate. A transfer may require the current owner to have the right to transfer the asset.

These are not implementation details. They are part of the requirement.

Behavior Comes From Relationships

Object-oriented interfaces often place behavior directly on an object:

Person.submitLeave()

But a person does not have a universal ability to submit leave. That capability exists within an active employment relationship and under a company's leave policy.

Person
  -> active Employment
  -> Company policy
  -> submit LeaveRequest

The relationship grants a role. The role provides capabilities. Constraints decide whether a specific action is currently permitted.

This matters to an AI agent. To suggest or execute the next action safely, the agent must know not only what object it is looking at, but also which relationships are active, which capabilities they provide, and which constraints apply.

State Is Often a Projection, Not a Primitive

Many fields that appear fundamental are actually summaries of history.

An account balance can be modeled as the projection of deposits, payments, transfers, holds, and reversals. A married = true flag can be understood as the existence of an active marriage relationship. An inventory quantity may be the projection of receipts, reservations, shipments, returns, and adjustments.

Event history -> Projection -> Current state

More generally, an attribute is a context-dependent projection of the world observed up to a particular time:

$$\operatorname{Attribute}_A(t) = \pi_A\!\left(W_{\le t},\operatorname{Context}\right)$$

For example:

$$\operatorname{Age}(p,t) = \pi_{\mathrm{age}}\!\left(p,\operatorname{BirthEvent},t\right)$$

The same rule applies recursively to a collapsed relationship boundary:

$$\operatorname{State}(b,t) = \pi\!\left( \operatorname{State}(G_{source},t), \operatorname{viewpoint}, \operatorname{observableScope} \right)$$

This does not mean every system must use event sourcing. It means the model should distinguish facts, transitions, and derived views. A database column may cache a projection for performance without becoming the semantic origin of the fact.

Dynamic World Models and RAG Solve Different Problems

Retrieval-augmented generation helps an AI system locate relevant information:

Documents -> Retrieval -> Answer

It is well suited to the question: Where is the knowledge?

A Dynamic World Model helps answer different questions:

• Why is this relationship valid?
• Which events can happen next?
• Which constraints apply?
• What will change if an action succeeds?
• Which software view is a projection rather than a source of truth?

RAG helps AI find knowledge. A world model organizes that knowledge into an explanation of reality: what exists, why it exists, which constraints sustain it, and how it may change. That explanatory structure makes reasoning and responsible action possible. The two approaches are complementary.

Software Is a Projection of the Model

One world model can have several technical projections:

World-model element	Possible software projections
Concept	type, identifier, schema, vocabulary
Relationship	entity, aggregate, table, foreign key, graph edge
Event	command, API endpoint, message, workflow transition
Constraint	policy, validation rule, authorization guard, invariant
Projection	query model, view, report, cached field

No single projection is the world model itself. A relational schema emphasizes storage, an API emphasizes interaction, and an agent runtime emphasizes available actions and policies. Keeping the semantic model above these projections makes the intent portable across implementations.

Building and Repairing the Model

Large language models can help extract candidate concepts, relationships, events, and constraints from existing documents, APIs, databases, code, and operating procedures. That makes reverse engineering a world model possible at a scale that was previously impractical.

Extraction is only the beginning. A useful system also needs world-model repair:

• detect conflicting meanings and duplicated concepts;
• validate relationship completeness and cardinality;
• find events without preconditions or outcomes;
• identify constraints that exist in code but not in requirements;
• compare runtime evidence with the declared model;
• route consequential semantic changes through human review.

The long-term feedback loop is:

Reality
  -> World Model
  -> Software Projections
  -> Runtime Events and Evidence
  -> World-Model Repair

From World Understanding to Reliable Agent Action

An LLM alone does not make an agent reliable. Reliable action also depends on the fidelity of the world model, the coverage of semantic constraints, and the assurance provided by the execution boundary:

$$\begin{aligned} \operatorname{ReliableAgent} ={}&\operatorname{LLMCapability}\\ &\times\operatorname{WorldModelFidelity}\\ &\times\operatorname{ConstraintCoverage}\\ &\times\operatorname{ExecutionAssurance} \end{aligned}$$

This is a conceptual reliability formula, not a statistical estimator. The multiplication expresses a systems property: if any factor approaches zero, the reliability of the whole agent approaches zero. A capable model cannot compensate for a false explanation of the world, missing business constraints, or an execution layer that cannot enforce them.

What We Intend to Define Next

Dynamic World Models are a design direction, not a claim that every capability described here already exists in TeaQL. The next step is to turn the idea into a testable requirements contract.

That contract should define:

1. a canonical metamodel for concepts, roles, relationships, events, constraints, capabilities, and projections;
2. stable identity and versioning rules so the model can evolve without losing meaning;
3. explicit preconditions, effects, and evidence for events;
4. validators for semantic conflicts, broken relationships, and incomplete constraints;
5. projection contracts for databases, APIs, generated business APIs, policies, and agent tools;
6. traceability from human requirements to model elements, generated artifacts, and runtime evidence;
7. repair workflows with confidence, provenance, review, and rollback boundaries;
8. conformance tests that verify an implementation preserves the declared semantics.

TeaQL's model-driven generation and deterministic business APIs provide useful foundations for exploring this direction. A Dynamic World Model would sit above any individual language, database, or runtime and make the business meaning explicit before projection.

The Direction

The future of software engineering is not simply more code generation. It is the construction of models that can explain reality, reason about change, and produce software without losing the meaning of either.

The compact definition is:

Concepts participate in events, under constraints, to create and evolve relationships. Software systems are executable projections of those dynamic relationships.

When AI can work from that representation, it can do more than imitate existing code. It can reason about why the system exists, what may happen next, and whether a proposed change still describes the world humans intended.

In AI-native software engineering, AI should not replace deterministic software generation. It should serve as the semantic bridge between human intent, a reasoned world model, and executable systems.