Worked Example
Status: Design landing
Purpose
Section titled “Purpose”This page walks one scenario end-to-end to show the world model’s primitives in action. It is a companion to the primitive pages — World Agent, World Zones, Provenance, Derivation Links, Deviation Records, Retroactive Revision, Submit Boundary — and introduces nothing new. Every mechanic it describes is defined on one of those pages; inline links point back.
The scenario is chosen to exercise the primitives that most often travel together: import, derivation, standing, retroactive revision, and deviation records, all flowing through the submit boundary.
The scenario
Section titled “The scenario”A fiction author — two books into a planned five-book series — has been worldbuilding in an Obsidian vault for three years. The vault holds character pages, location pages, timeline entries, a long-running glossary, and a growing body of notes on the world’s magic system. The magic system has become the spine of her plotting: nearly every major plot beat in the drafted books and in her outlines for books three through five hinges on what magic can and cannot do, who can wield it, and what it costs.
She opens Inklings and imports the vault to start treating it as an authored world.
Four moments in the life of that world follow: import, agent derivation, a source edit that forces retroactive revision, and a deviation the author processes. Each one lands a subset of the design’s primitives; together they cover the core loop.
Moment 1: Import
Section titled “Moment 1: Import”The author points Inklings at her vault. The import pipeline reads markdown files, parses wiki-links, preserves tags, and carries over whatever metadata the vault exposed.
What flows through the submit boundary. Every page the import creates is a workspace write. Each one goes through the same world-write construct any other write uses. The import pipeline’s caller identity populates origin: imported; the import’s call context populates lifecycle status; derivation links are not attached for imported content, since imports are primary material, not inferred from other workspace entities.
What origin carries. The import preserves what it can: source vault name, source file path within the vault, source file modified-at timestamp, and — where present — inbound wiki-link information that will be resolved against other imported pages once the full import is complete. This is origin as factual record: it doesn’t change once set.
What lifecycle defaults to. Imports land as lifecycle: draft. The author chose to import, not to endorse, and the default preserves her authority by making canonicalization an explicit act. The import flow offers a bulk-canonicalize affordance for users who want to accept their imported vault wholesale; she skips it. She wants to walk through the magic-system material herself and canonicalize deliberately.
What zones are populated. All imported pages land in Known. The world now has content; what’s in the vault is what the world knows. Topics the vault doesn’t cover fall in Unknown by default (the world’s scope is what its author writes into it). The Unknowable zone hasn’t shifted — the vault’s import didn’t change what the world’s methods cannot reach; the world still only answers from what the author has written.
What the derived signals do. Nothing, yet. Weight is a function over the graph; the graph just appeared and nothing has started pointing at anything else in a meaningful way. Standing is defined only on canonical content, and nothing is canonical yet.
What does not happen. The agent doesn’t read the vault during import. It doesn’t precompute inferences. Import is a world-building event; the agent shows up afterward to inhabit what was built.
Over the next two weeks, the author walks through the imported material and promotes key pages to canonical: her central magic-system page The Nature of Binding (the page from which most other magic material was written), the major character pages, the principal location pages, and a handful of glossary entries. Promotion is a lifecycle transition she performs — origin remains imported (origin is factual and doesn’t shift).
Moment 2: Agent derivation
Section titled “Moment 2: Agent derivation”A few days after the promotions settle, the author opens Inklings and asks the World Agent: “Pull together what my notes say about how Binding works — the rules, the costs, the edge cases. I want to see it in one place before I start book three.”
The agent’s zone posture. The question is squarely in Known: the author has written about Binding across her central magic page, fourteen character pages (each noting how their character relates to Binding), nine location pages (ritual sites, places where Binding doesn’t work), and eleven miscellaneous notes on specific instances in drafted chapters. The agent’s response shape is “retrieve, cite, ground” (see World Zones §response shapes).
What the agent does. The agent reads — through tools, since the agent has no direct filesystem access to the workspace — the thirty-five source pages. It assembles a new page, Binding — rules, costs, and edge cases, that organizes the material into four sections: what Binding does, what it costs, who can wield it, and where it fails.
What flows through the submit boundary. The agent’s tool for creating pages crosses the boundary. At registration, the tool declared itself boundary-crossing, declared which of its arguments is the content being written, and declared that derivation sources are supplied as an explicit argument. When the agent calls it, the adapter layer constructs the world write:
origin: agent-produced— populated from the caller identity. Agent writes are always agent-produced; there is no “dictation” exception.lifecycle: candidate— populated from the call context; agent-authored content never enters canonical directly.- Derivation links — one per source page, attached to the new content pointing at each of the thirty-five source entities.
- Deviation records — examined, not produced: the new content doesn’t contradict any existing canonical content.
- Retroactive revision — examined, not updated: the new content doesn’t revise anything other content was derived from.
The domain’s world-write construct refuses to be built with any of the required fields missing. The tool implementation receives an already-validated write and executes it.
What the author sees. A new page appears, marked candidate, visibly agent-produced, with a “derived from 35 sources” affordance that expands into the source list. The page’s content is there to read; the author can elevate it to canonical, edit it, or retire it.
She reads it, makes a handful of edits to sharpen a definition and correct one small misreading the agent made, and promotes it to canonical. Her edit is itself a submit-boundary event: origin: authored (D20 applies to the agent-authored page as a whole, but her edit’s origin is authored at the block level), lifecycle transitioned to canonical (authored act, permitted).
What the graph looks like now. The new page has thirty-five derivation links pointing at the source pages. Those derivation links are first-class relationships in the graph, not comments or embedded metadata. They’re examinable, queryable, and — critically for the next moment — watchable.
What standing starts to look like. The central magic page, The Nature of Binding, now has a derivation pointing at it from Binding — rules, costs, and edge cases, on top of the incidental derivations it had from a few character pages the author wrote earlier. It is starting to become load-bearing: the world is being built out of it. Its standing is still modest, but moving.
Moment 3: Source edit and retroactive revision
Section titled “Moment 3: Source edit and retroactive revision”Two months later, the author is deep in book three. She reaches a plot point that forces her to confront something she’d been avoiding: the cost structure of Binding she wrote down three years ago doesn’t actually work for the scene she’s trying to stage. It’s too cheap; the stakes collapse. She decides the cost needs to scale with the Bound entity’s autonomy, not with the Binder’s intent — a substantial rewrite to The Nature of Binding.
She rewrites the relevant section in her normal editing flow.
What flows through the submit boundary. Her edit is a workspace write. Origin: authored. Lifecycle transition: she’s modifying canonical content; lifecycle stays canonical but the change is recorded.
What retroactive revision does. The Nature of Binding has many inbound derivation links — Binding — rules, costs, and edge cases is one; several character pages she wrote months ago derived from it; two chapter-outline pages for book three derived from it last week. The graph notices. Each of the derived pages is flagged for re-validation.
What standing does here. The Nature of Binding is now a high-standing page — many canonical pages descend from it. The flag prominence on each re-validation entry scales with the standing of the source whose change propagated. The author’s triage queue surfaces these flags prominently, not as routine noise — her world rests on this page, and something load-bearing just shifted.
Flagging is not rewriting. The world model does not silently regenerate the derived pages. It adds each to a re-validation queue with a note: “source X changed; review.”
What the author sees immediately. A prominent indicator on each derived page: “A source this page was derived from has changed since it was written.” She can click through to see which source, see the diff, and decide what to do. She has a scene to finish; she closes the indicators and keeps writing. The queue is waiting when she’s ready.
What the agent sees. The same queue entries, available to scheduled autonomous tasks. In this scenario the author has granted the agent scope to walk the re-validation queue on a nightly cadence (category “re-validation queue processing”). The prominent flags tell the agent which to prioritize.
Moment 4: A deviation record and the authors triage
Section titled “Moment 4: A deviation record and the authors triage”That night, the scheduled task runs. The agent walks the re-validation queue, starting with the highest-prominence flags — the ones tied to The Nature of Binding. It reaches Binding — rules, costs, and edge cases.
What the agent reasons. It reads The Nature of Binding, now with the rewritten cost-scaling section. It reads Binding — rules, costs, and edge cases. It notices that the cost section of Binding — rules, costs, and edge cases still describes the old cost model — cost scales with the Binder’s intent — which directly contradicts the source page as revised.
What the agent does. It does not rewrite the derived page. Autonomous submissions follow the same rules as conversational ones: the agent’s job is to propose, not to silently revise canonical content. Instead, it produces a deviation record.
How the deviation record is produced. The deviation record is not a workspace entity and does not go through the submit boundary’s world-write construct. It is a typed record emitted into the deviation record store as the scheduled task recognizes the conflict. The record carries:
- Type —
agent-inference-revisited(the second of the four conflict types): an agent inference the author originally accepted now conflicts with revised canonical content. - Timestamp — when the scheduled task detected the conflict.
- Detecting source — scheduled autonomous task (re-validation queue walk).
- Content references — The Nature of Binding (the content whose change triggered re-validation) and Binding — rules, costs, and edge cases (the content now inconsistent with it).
- Status — open.
- Body — names the inconsistency: “Source, as revised, specifies that Binding cost scales with the Bound entity’s autonomy. Derived page still describes cost scaling with the Binder’s intent. Cost section should be rewritten or the derived page retired.”
The agent does not self-assess whether this is “really a conflict” or “probably just a drafting gap” — it produces the deviation record and lets the author judge. The agent does not hide conflicts from the author, including ones it suspects the author would resolve trivially.
What the author sees next morning. An entry in her deviation triage inbox — the product surface that reads from the deviation record store. The entry is visually prominent: it’s tied to high-standing content, and the triage inbox weights its ordering accordingly. Reading it, she sees the agent identified exactly what she’d have caught in her next pass through the page herself, probably a week later. She has three options, the same three retroactive revision always offers:
- Accept as still valid. Unlikely here — the rewrite directly contradicts the derived page. But defensible if the derived page’s framing, while technically inconsistent, is still useful as a historical view.
- Update. Rewrite the cost section of the derived page to reflect the revised model. This is an authored submit: origin: authored, lifecycle remains canonical, with the derived page’s history showing her revision.
- Retire. The derived page as a whole was written under the old model; retire it and ask the agent to regenerate from the revised source when she’s ready.
She picks option 2, edits the cost section, and closes the deviation record. Her edit to the derived page is a workspace write (origin: authored, lifecycle: canonical). Closing the deviation record updates its status to resolved and populates its resolution note (“updated cost section to reflect revised cost model”); that update is a write to the deviation record store, not a submit-boundary write to the workspace. The derived page’s revision history can reference the deviation record by ID, capturing that this edit resolved it. The deviation record persists — it’s not deleted — it’s recorded as resolved. A year from now, when she’s writing book four and hits another cost-scaling question, she can look back at when her world said two things at once about Binding costs and how it was reconciled.
The other re-validation queue entries — the character pages, the two book-three outline pages — remain open. She’ll walk them over the next few days.
What the scenario demonstrated
Section titled “What the scenario demonstrated”Every primitive the design introduces played a role:
- Zones shaped the agent’s response posture across all four moments. Import populated Known; the derivation request operated from Known; the source edit perturbed Known; the deviation record sat at the Known-Unknown seam.
- Origin and lifecycle carried every workspace submit. Import: origin: imported, lifecycle: draft. Derivation: origin: agent-produced, lifecycle: candidate. Source edit and resolution: origin: authored. The deviation record itself was not a workspace submit — it is a record type, not a workspace entity, and does not have origin or lifecycle axes.
- Weight was present as a signal the agent could have consulted on any submit — how much does the world point at this page right now, how carefully should the agent phrase its proposal. It did not gate anything.
- Standing was the signal that made The Nature of Binding’s change matter more than a similar change to a peripheral page. Standing drove the prominence of the retroactive-revision flags and the triage inbox’s ordering of the resulting deviation record.
- Derivation links were the spine connecting derived content to its sources, the substrate standing was computed over, and the mechanism that made retroactive revision possible.
- Retroactive revision was the flag-not-rewrite mechanism that kept the author in control even when her edit propagated across the world.
- Deviation records were the durable record of disagreement the agent produced when the world stopped reconciling with itself, and the queue entry the author processed. They are typed records with status, not workspace entities — queryable and referenceable without being graph nodes.
- Scheduled autonomous tasks (see World Agent §scheduled work) were what ran overnight to walk the re-validation queue and produce the deviation record without the author prompting.
- The submit boundary carried every workspace-modifying action — whether by import pipeline, agent on conversational prompt, author, or scheduled task — through the same world-write construct with the same invariants.
- Author authority ran through every moment: the agent proposed, the author disposed; the agent flagged, the author processed; the agent’s inferences never became canonical without the author’s act. See World Agent §author authority.
The world model is what ties those moments into a single continuous loop. The author writes; the agent reads and proposes; the world absorbs with provenance; the graph notices change; standing tells the system what matters; the agent surfaces consequences; the author reconciles. Each turn leaves the world more coherent and more obviously the author’s.
What the scenario deliberately did not show
Section titled “What the scenario deliberately did not show”- Cross-workspace behavior — the world is closed; the scenario stays inside one workspace. Her second series, a separate project, is its own world with its own World Agent.
- Governance machinery — no multi-stage review, no external authority anchoring, no load-bearing-weight gates. The author’s own actions are the only governance.
- External-integration side-effects — the agent did not reach outside the world. Autonomous tasks with outward reach exist but aren’t needed for this loop.
- Conflict at submit time — the deviation record in this scenario was produced by the scheduled task against already-submitted content. The other deviation path — detection at submit time when an agent submission directly contradicts existing canonical content — is how most deviations are produced in practice; the machinery is the same as shown here.
- The four-tier agent memory — the agent’s Account/Workspace/Channel/Conversation memory was present throughout (storing, for instance, the author’s preference for how Binding is discussed) but was not the thing the scenario was about. Memory is the agent’s durable operating context; the scenario is about the world the agent operates on.
Those are all within the design; they’re just outside this scenario’s scope.
Was this page helpful?
Thanks for your feedback!