---
title: Worldview
description: "The bounded, decision-sized projection the agent actually reads to act: deterministic, auditable, and capped."
---

The belief state is the full posterior over a world. The worldview is the part of it that fits in front of a single decision. It answers one question: what is the minimal sufficient picture for the move I am about to make? The belief state grows for years. The worldview stays small on purpose, because the thing reading it has exactly one move to make right now.

A worldview is the read contract of the world model. Everything upstream (observations, extraction, fusion) exists to keep the posterior honest. The worldview is what the agent reads off that posterior the instant before it acts: `beliefs.before(query)` renders it into `context.prompt`, scoped to the move at hand. For the full picture rather than the turn slice, `beliefs.read()` returns the whole world model (see [World model](/dev/core/world)).

## Six slices, six questions

An oriented agent asks the same six questions every time it wakes. The worldview is organized as one slice per question, so the agent never has to assemble its bearings from scratch.

- **environment.** *Where am I?* The world identity and kind, the entities in play, the observation surfaces that fed the state, and the source ranking that holds here.
- **current.** *What is true right now?* The load-bearing claims, recent changes, open gaps, and active contradictions, each carrying derived flags: stale, stable, contradicted, uncertain.
- **intent.** *What am I after?* Goals with their success criteria, the constraints that bound them, and the single limiting factor: the one open belief most in the way of the goal.
- **policy.** *What must I respect here?* The invariants, source hierarchy, conventions, and anti-patterns declared for this world.
- **affordances.** *What can I do?* The world's action set, already filtered through policy and tagged with a safety class, surfaced as `allowed`, `flagged`, or `blocked`.
- **moves.** *What next?* The ranked next moves, each anchored to the specific belief its value would inform.

Those six slices line up with the six declared parts of the [world model](/dev/core/world): environment, intent, and policy carry straight over; observations fold into `current`; actions become policy-filtered `affordances`; and the belief state fans into `current` plus the ranked `moves`. The SDK hands them to the agent through `before(query)`: the serialized `prompt` the model reads, plus structured fields to route on. The top-ranked move rides back as `context.moves[0]`, so the agent opens every turn already pointed at its highest-value next step.

```ts
const context = await beliefs.before(query)

context.prompt   // the worldview, serialized for the model to read
context.beliefs  // the load-bearing claims in play
context.goals    // what we're after
context.gaps     // open questions
context.clarity  // 0-1 readiness: is there enough to act yet
context.moves    // ranked next moves; context.moves[0] is the top one
```

## Bounded on purpose

A worldview does not grow to a thousand items as the corpus grows. It is held to a small working set (think single digits, not pages), it drops items whose value falls below a relative cut against the leader, and it keeps only enough state to settle the move at hand. This is a design commitment, not a side effect of truncation.

The reason is empirical. Unbounded context measurably hurts agents: the more marginal material you pour into the window, the worse the agent gets at finding the thing that matters. A tight projection is the fix. The worldview sizes itself by relevance to the decision, not by how much happens to be in the store, so the picture stays the same shape whether the belief state holds fifty claims or fifty thousand.

The cut is relative, never a tuned threshold. The projection orders claims by their decision value, keeps the prefix that stays within a fraction of the top score, floors it so the agent always sees at least the top hinge, and caps it so the surface never sprawls. What survives is the set that actually changes the next move.

## Deterministic and auditable

Same inputs, same worldview. The projection reads a clock that is passed in rather than sampled, so a given belief state and world produce a byte-identical worldview every time. That is what makes the read-side replayable.

Every selected item carries a `trace`: the belief ids that produced it. A load-bearing claim traces to itself plus the dependencies whose movement propagates through it. A contradiction traces to both endpoints. A goal traces to the beliefs that ground it. A flagged affordance traces to the constraint that flagged it. Any leaf in the worldview can be walked back to the beliefs that put it there, which means an agent's decision is auditable from the surface it read, without reaching back into the store behind it.

The prose an LLM consumes is a render of this typed projection, never the source of it. The structured worldview is computed first and deterministically; the natural-language briefing is a downstream view. You can pin behavior on the typed object and trust that the prose follows it, rather than parsing prose to recover what the agent saw.

<Callout type="info" title="Trace, not just text">
A retrieved chunk tells you what matched a query. A worldview leaf tells you which beliefs produced it. That `trace` is the difference between a result you have to trust and one you can replay.
</Callout>

## It computes no new math

The worldview is a selection over the belief state, not a second opinion on it. Every signal it ranks and flags by is already defined elsewhere in the engine:

- **load-bearing influence** orders the claims and sizes the working set.
- **fragility** decides which beliefs read as stable versus exposed.
- **the decay schedule** decides which beliefs read as stale.
- **claim-truth uncertainty** decides which read as uncertain.

Nothing here re-scores a belief or invents a number. The projection picks, orders, and bounds; the values it reports are the same ones the belief state already holds. This keeps the read side cheap and keeps the math in one place: change how fragility or decay works once, and the worldview reflects it without a parallel implementation drifting out of sync.

## Where a worldview parts ways with retrieval

A memory system hands back retrieved chunks scored by a query: relevant to what you asked, in whatever quantity matched, with the burden of interpretation left to you. A worldview hands back a bounded, typed, ranked picture scoped to a decision, the same way every time, with provenance attached to each item.

The worldview is judgment shaped for a single move: not the documents that mention your topic, but the claims, gaps, conflicts, and next steps that actually bear on what you are about to do.

## The forward-looking move

As action history accumulates, the worldview can carry one more thing: a forward-looking recommendation, a projection of which action has the most value from here, ranked by expected goal-information gain. Until that history is real the worldview still ranks the single best next move, and the multi-step projection rides on top as an enrichment, never a claim the engine cannot yet back. [Moves](/dev/core/moves) covers the forecasting layer and how it earns trust.

<Callout type="info" title="Policy and actions are a modeling lens, not an enforcer">
The policy and affordance slices are how a developer encodes the rules and verbs of a world today: they shape what the worldview surfaces and how affordances are flagged. The engine does not yet enforce policy or execute actions on your behalf. A declarative config surface for that is on the roadmap.
</Callout>

## See also

<CardGroup cols={2}>
  <DocsCard title="World Model" description="The full frame: environment, observations, policy, and actions together." href="/dev/core/world" />
  <DocsCard title="Beliefs" description="The posteriors the worldview selects over." href="/dev/core/beliefs" />
  <DocsCard title="Intent" description="Goals, constraints, and the limiting factor." href="/dev/core/intent" />
  <DocsCard title="Clarity" description="How much of the picture is settled enough to act." href="/dev/core/clarity" />
  <DocsCard title="Moves" description="The ranked next actions the worldview surfaces." href="/dev/core/moves" />
  <DocsCard title="Core API" description="read(), before(), and the full SDK surface." href="/dev/sdk/core-api" />
</CardGroup>
