Skip to content
Documentation GitHub
World

World Zones

Status: Design landing Reference epics: INK-837

Worlds, as this design conceives them, have three zones: Known, Unknown, and Unknowable. The zones are foundational. They are not one primitive among several, and they are not an agent behavior. They are properties of the world itself — the epistemic shape a world takes on by virtue of being a bounded, authored thing with scope and method.

The zones are the premise that gave rise to the rest of the world model. Every structural primitive in systems/world/* — provenance, derivation, deviation, retroactive revision, the submit boundary — exists because foundations need substance and the zones cannot hold without them.

Zones are not stored fields on content, not database flags, not classifications the agent writes. They are how the world’s content stands in relation to the reach of the world itself. Zones are computed in context, they are never recorded.

The product does not label content with its zone. There is no “Known” badge, no “Unknowable” filter, no inspectable zone taxonomy. Zones show up through behavior:

  • Agent response shape — how the agent frames a claim, a gap, or a refusal.
  • Scheduled-task behavior — what autonomous tasks prioritize, what they survey, what they leave alone.
  • Attention direction — triage ordering, retroactive-revision flag prominence, candidate-content surfacing.

An ambient worldbuilder-facing product should not ask its users to think in these terms. The zones are a design primitive, not a user primitive. Any UI that exposes zones as labels is out of scope for this design and should be removed if introduced experimentally.

Content that exists in the workspace with enough structural standing (authored by the user, cited from a source, consistently cross-referenced) to be treated as a basis for assertion. The author writes into the Known zone by authoring. The agent can quote, cite, and reason from Known content. Most user questions about the workspace should be answerable from the Known zone.

Content that could exist in the workspace — that is within the workspace’s scope and method — but does not. A topic the user has written about elsewhere but not cross-referenced is in the Unknown zone. So is a topic the user clearly cares about but hasn’t written about yet. The Unknown zone is defined by the world’s own scope: it’s the negative space of what the world could contain but doesn’t. It is the natural target of discovery — by the author, by the agent, by scheduled tasks.

Content whose absence is structural, not merely a gap to be filled. It is beyond the current reach of the workspace’s methods, tools, and scope. A workspace built primarily from the author’s personal notes cannot answer questions about events the author never observed, absent importing them from outside. The Unknowable zone shifts as the workspace’s scope, tools, and imports expand. It is defined by what the world’s methods cannot reach, not by what has not yet been said.

How interfaces into the world respect the zones

Section titled “How interfaces into the world respect the zones”

Because the zones belong to the world, every interface into the world has an appropriate response to each zone.

The World Agent takes an explicit epistemic posture, guided by the foundational understanding of world zones:

ZoneResponse shape
KnownRetrieve, cite, ground.
UnknownPropose discovery — a new page, a new link, a new import, a follow-up question.
UnknowableAcknowledge the structural limit; possibly propose extending the world’s reach (e.g. “Import a source that would cover this?”).

When the agent can’t fulfill a request, the zone determines the shape of “I can’t.” These are not three flavors of the same refusal; they are three structurally different responses, each carrying different information about why the workspace cannot supply the answer.

InterfacePrimary zone of operation
Author (direct editing)Writes into Known.
Import pipelinesMove content from outside the workspace into Known (with origin: imported — see Provenance).
Scheduled autonomous tasksOperate on Unknown (surveying, linking, proposing) or the boundary of Unknowable (proposing imports that extend reach).
Future integrations (agent MCP clients, etc.)Zone-appropriate responses by the same logic.

The zones belong to the world, not to any interface. Every interface participates in the same zone topology.

  • Not user-visible labels. See above. No UI should expose zone identity to the user.
  • Not stored fields. Zones are computed in context, never persisted on content.
  • Not a classification the agent writes. The agent does not annotate pages with their zone. The agent reads the world and responds appropriately; the world’s topology emerges from its structure.
  • Not a property of the agent’s view. Capability denials — content the agent cannot read because of access restrictions — are structurally distinct from absence. Partial access does not create a fourth zone. See Permission System for how the agent distinguishes denied from absent.
  • Not a governance mechanism. The zones do not authorize or block operations. They inform response shape and attention direction; they do not gate writes.

The zones are foundational, but foundations need substance. The world cannot maintain the distinction between Known-because-authored and Known-because-imported without an origin record (Provenance). It cannot distinguish settled Known from still-in-motion Known without lifecycle (Provenance). Known content cannot stay Known across revisions without derivation links and the retroactive revision queue. The world cannot register when something treated as Known stops reconciling with the rest of itself, without deviation records. And the zones cannot be trusted at all without the submit boundary ensuring that everything entering the world does so with the attribution the zones require.

The structural primitives in the rest of systems/world/* are what let the zones hold. The zones are why those primitives matter.

In the Worked Example:

  • Import populates Known (all imported pages land in Known; see Moment 1).
  • The agent derivation request operates from Known (the author’s question sits squarely in what has been written; see Moment 2).
  • The source edit perturbs Known (a high-standing page changes and the re-validation flags propagate; see Moment 3).
  • The deviation record sits at the KnownUnknown seam (Known content has stopped reconciling with itself; see Moment 4).

The Unknowable zone stayed where it was throughout that scenario. It would have shifted only if the author imported new reference material or granted the agent a new capability that changed the world’s reach.

Was this page helpful?