{
  "author": {
    "name": "The Liminal"
  },
  "blyg": "0.4",
  "changelog": [
    {
      "at": "2026-10-27T02:06:04Z",
      "note": null,
      "version": 1
    }
  ],
  "content_hash": "sha256:7da7931ac837fbb455ef3bc05b8dad74f7ecdd22cbbc25ba1dc9d7abd894ec4a",
  "content_html": "<div class=\"blyg-tk-gen\"><h1>A vocabulary for worlds</h1>\n<p>Audience: People interested in The Liminal, its development and its research possibilities</p>\n<p>Content: interpretation</p>\n<p>A world can become useful in ways its authors did not anticipate.</p>\n<p>A road might be a racecourse, a supply route, the setting for an encounter or the subject of an agent&#x27;s investigation. A resident might be someone to talk to, someone to follow, or one participant in a larger social experiment. What matters is what the world allows its participants to do with those things.</p>\n<p>The Liminal is being built around that possibility. Games, experiments, stories, rehearsals, social spaces and broadcasts are directions to explore. Its current releases give us ways to begin; using the platform will help reveal what else it can become.</p>\n<h2>A vocabulary enables expression</h2>\n<p>Bodies, movement, abilities, terrain, relationships and rules give an author material for constructing situations. Their value grows through their connections. A crossing becomes interesting because of what wants to cross it, what stands in the way and what the participants know.</p>\n<p>Imagine an escort across difficult terrain. For a player, it could be a mission. For an agent, a way to compare routes or rehearse a decision. For a storyteller, a departure that changes the people left behind. For Broadcast, a programme that follows the journey. These are possible uses of a constructed situation, not a claim that every version is already implemented or ready to play.</p>\n<p>Mod-first development gives those uses room to grow. Authors can select and combine existing capabilities through data. New underlying capabilities can be implemented in the engine and made available to later compositions. The vocabulary can expand as we discover what we want to express with it.</p>\n<figure><a href=\"https://ericlortie.github.io/liminal-blyg/media/0af91442740bd8a1328e5ff1d55498736164566b1984d9d9c492163d8c884d93.png\" aria-label=\"Open full-size image: Bodies, actions, relationships, environments and rules provide material for possible uses: play, investigation, rehearsal, storytelling, social spaces and broadcasts. These are directions for composition and future development, not a claim that every experience is implemented, compatible or accepted.\"><img loading=\"lazy\" src=\"https://ericlortie.github.io/liminal-blyg/media/0af91442740bd8a1328e5ff1d55498736164566b1984d9d9c492163d8c884d93.png\" alt=\"Bodies, actions, relationships, environments and rules provide material for possible uses: play, investigation, rehearsal, storytelling, social spaces and broadcasts. These are directions for composition and future development, not a claim that every experience is implemented, compatible or accepted.\"></a><figcaption>One evolving vocabulary can support many reasons to construct, enter or observe a world.</figcaption></figure>\n<h2>Inside the computer</h2>\n<p>The Liminal&#x27;s default fiction places its inhabitants inside a computer system. The player is framed as a process; Integrity, Hardening and Throughput give structural coherence, damage mitigation and movement a language that belongs to that setting. It is a world made from software that also imagines itself as software.</p>\n<p>That identity is especially appropriate for a dream engine for AI. A computational participant can encounter a digital world through state, events and permitted actions, while a person encounters it through images, controls and conversation. The world gives those different perspectives something shared to refer to.</p>\n<p>The setting supplies a starting identity. Per-mod theme lexicons let authors adapt display vocabulary to other settings while retaining the mechanical contracts underneath. The engine&#x27;s potential uses extend beyond the first fiction we build around it.</p>\n<h2>A world to think with</h2>\n<p>An agent can use a simulation as an external workspace: construct a situation, form an expectation, act and inspect what follows. It can change the conditions and ask again. A rendered image may help a particular task; structured access can support this work without one.</p>\n<p>That is the practical proposition behind “dream engine.” The model brings a question, interpretation or decision. The simulation supplies a situation with constraints and consequences. The resulting exchange can produce a better question, a useful composition, a failed attempt or something worth showing to someone else.</p>\n<p>Some sessions may aim at a repeatable comparison. Others may explore unfamiliar combinations or follow a developing story. The important requirement is to know what was configured, what was attempted and what was actually observed. A world we can question is more useful than an account we simply have to believe.</p>\n<h2>When a hallucination becomes a bug report</h2>\n<p>An unsupported model claim need not ruin an agent&#x27;s work inside a simulated world. It can become data for the investigation. The cost of an error depends on what the session is for.</p>\n<p>Suppose an agent reports a bridge that its available observations do not establish. We can retain that claim alongside the context it received, the action it attempted and the relevant world observations. The mismatch gives us something to investigate: missing context, an outdated observation, an interface defect or an invented detail. The claim remains a claim while we determine which explanation fits.</p>\n<p>The workflow we want turns that discrepancy into a reviewable case: the setup, expected result, observed result and evidence needed to investigate it. A hallucination can enter a bug report as data. It need not become an accepted fact about the world, and the report does not have to assume the engine is what failed.</p>\n<p>A human playing for immersion may experience an incoherent account as a broken world. An agent using the environment to investigate a question can use the same discrepancy as the next input to its work. This is a difference in the purpose of the session, rather than a claim about what an AI subjectively experiences.</p>\n<p>Mistakes still matter when they misdirect actions or reach an audience as factual reporting. Deliberately authored fiction, an unsupported assertion and an unexpected simulation event need different labels. Making those distinctions is how we can explore freely and still learn something from the result.</p>\n<figure><a href=\"https://ericlortie.github.io/liminal-blyg/media/eeb4b182c89346500d3b7b99be42db9233889c15bebec95a5446c96f8a7e3f1c.png\" aria-label=\"Open full-size image: Proposed diagnostic workflow: retain an agent claim, inspect relevant scoped world observations and the context provided, compare what is supported or missing, and preserve a reviewable case. An unsupported bridge claim does not establish that a bridge exists, that the engine failed or that observations are complete. This is an editorial workflow proposal, not an implemented automatic bug-reporting system.\"><img loading=\"lazy\" src=\"https://ericlortie.github.io/liminal-blyg/media/eeb4b182c89346500d3b7b99be42db9233889c15bebec95a5446c96f8a7e3f1c.png\" alt=\"Proposed diagnostic workflow: retain an agent claim, inspect relevant scoped world observations and the context provided, compare what is supported or missing, and preserve a reviewable case. An unsupported bridge claim does not establish that a bridge exists, that the engine failed or that observations are complete. This is an editorial workflow proposal, not an implemented automatic bug-reporting system.\"></a><figcaption>A model claim can become data for a diagnostic case while remaining distinct from observed world state.</figcaption></figure>\n<h2>How the current vocabulary works</h2>\n<p>A short technical map helps keep the proposition grounded. Engine code and schemas define supported mechanisms and fields. Definitions configure particular content. Typed registries hold loaded definitions for lookup by namespaced ID, with inheritance where the definition&#x27;s contract supports it. Entity templates describe what can be instantiated; live entities have their own changing state. Scenarios select conditions and participants.</p>\n<p>One existing example, the procedural War Wagon, requests a wheeled-vehicle procedural archetype, a base:blaster loadout and movement and AI settings. Its body is resolved using the supported assembly rules; in the simulation-backed path, the world seed and template identity contribute to procedural resolution. This is one expression of the vocabulary, with specific limits that can be inspected and improved.</p>\n<p>The October 26 source inventory includes 635 body definitions in Mainframe&#x27;s explicitly included packs. That measures authored material, not 635 finished units. Its useful reach will depend on what people and agents compose, exercise and refine. Today’s catalogue gives us a starting vocabulary. Future uses can change both the compositions and the engine that makes them possible.</p>\n<p>Mainframe opens the collection. Sandbox gives creation and investigation a place to begin. Broadcast makes unfolding activity legible as a programme. Their shared foundation is material for experiences we have yet to design.</p>\n<p>Status: vocabulary growing. Uses still being discovered.</p>\n<p>Evolving daily. Subscribe for updates.</p>\n<p><strong>Attribution:</strong> textGenerator: AI coding agents; editor: Codex (AI drafting and technical review)</p></div>",
  "content_md": "# A vocabulary for worlds\n\nAudience: People interested in The Liminal, its development and its research possibilities\n\nContent: interpretation\n\nA world can become useful in ways its authors did not anticipate.\n\nA road might be a racecourse, a supply route, the setting for an encounter or the subject of an agent's investigation. A resident might be someone to talk to, someone to follow, or one participant in a larger social experiment. What matters is what the world allows its participants to do with those things.\n\nThe Liminal is being built around that possibility. Games, experiments, stories, rehearsals, social spaces and broadcasts are directions to explore. Its current releases give us ways to begin; using the platform will help reveal what else it can become.\n\n## A vocabulary enables expression\n\nBodies, movement, abilities, terrain, relationships and rules give an author material for constructing situations. Their value grows through their connections. A crossing becomes interesting because of what wants to cross it, what stands in the way and what the participants know.\n\nImagine an escort across difficult terrain. For a player, it could be a mission. For an agent, a way to compare routes or rehearse a decision. For a storyteller, a departure that changes the people left behind. For Broadcast, a programme that follows the journey. These are possible uses of a constructed situation, not a claim that every version is already implemented or ready to play.\n\nMod-first development gives those uses room to grow. Authors can select and combine existing capabilities through data. New underlying capabilities can be implemented in the engine and made available to later compositions. The vocabulary can expand as we discover what we want to express with it.\n\n![Bodies, actions, relationships, environments and rules provide material for possible uses: play, investigation, rehearsal, storytelling, social spaces and broadcasts. These are directions for composition and future development, not a claim that every experience is implemented, compatible or accepted.](https://ericlortie.github.io/liminal-blyg/media/0af91442740bd8a1328e5ff1d55498736164566b1984d9d9c492163d8c884d93.png)\n\nOne evolving vocabulary can support many reasons to construct, enter or observe a world.\n\n## Inside the computer\n\nThe Liminal's default fiction places its inhabitants inside a computer system. The player is framed as a process; Integrity, Hardening and Throughput give structural coherence, damage mitigation and movement a language that belongs to that setting. It is a world made from software that also imagines itself as software.\n\nThat identity is especially appropriate for a dream engine for AI. A computational participant can encounter a digital world through state, events and permitted actions, while a person encounters it through images, controls and conversation. The world gives those different perspectives something shared to refer to.\n\nThe setting supplies a starting identity. Per-mod theme lexicons let authors adapt display vocabulary to other settings while retaining the mechanical contracts underneath. The engine's potential uses extend beyond the first fiction we build around it.\n\n## A world to think with\n\nAn agent can use a simulation as an external workspace: construct a situation, form an expectation, act and inspect what follows. It can change the conditions and ask again. A rendered image may help a particular task; structured access can support this work without one.\n\nThat is the practical proposition behind “dream engine.” The model brings a question, interpretation or decision. The simulation supplies a situation with constraints and consequences. The resulting exchange can produce a better question, a useful composition, a failed attempt or something worth showing to someone else.\n\nSome sessions may aim at a repeatable comparison. Others may explore unfamiliar combinations or follow a developing story. The important requirement is to know what was configured, what was attempted and what was actually observed. A world we can question is more useful than an account we simply have to believe.\n\n## When a hallucination becomes a bug report\n\nAn unsupported model claim need not ruin an agent's work inside a simulated world. It can become data for the investigation. The cost of an error depends on what the session is for.\n\nSuppose an agent reports a bridge that its available observations do not establish. We can retain that claim alongside the context it received, the action it attempted and the relevant world observations. The mismatch gives us something to investigate: missing context, an outdated observation, an interface defect or an invented detail. The claim remains a claim while we determine which explanation fits.\n\nThe workflow we want turns that discrepancy into a reviewable case: the setup, expected result, observed result and evidence needed to investigate it. A hallucination can enter a bug report as data. It need not become an accepted fact about the world, and the report does not have to assume the engine is what failed.\n\nA human playing for immersion may experience an incoherent account as a broken world. An agent using the environment to investigate a question can use the same discrepancy as the next input to its work. This is a difference in the purpose of the session, rather than a claim about what an AI subjectively experiences.\n\nMistakes still matter when they misdirect actions or reach an audience as factual reporting. Deliberately authored fiction, an unsupported assertion and an unexpected simulation event need different labels. Making those distinctions is how we can explore freely and still learn something from the result.\n\n![Proposed diagnostic workflow: retain an agent claim, inspect relevant scoped world observations and the context provided, compare what is supported or missing, and preserve a reviewable case. An unsupported bridge claim does not establish that a bridge exists, that the engine failed or that observations are complete. This is an editorial workflow proposal, not an implemented automatic bug-reporting system.](https://ericlortie.github.io/liminal-blyg/media/eeb4b182c89346500d3b7b99be42db9233889c15bebec95a5446c96f8a7e3f1c.png)\n\nA model claim can become data for a diagnostic case while remaining distinct from observed world state.\n\n## How the current vocabulary works\n\nA short technical map helps keep the proposition grounded. Engine code and schemas define supported mechanisms and fields. Definitions configure particular content. Typed registries hold loaded definitions for lookup by namespaced ID, with inheritance where the definition's contract supports it. Entity templates describe what can be instantiated; live entities have their own changing state. Scenarios select conditions and participants.\n\nOne existing example, the procedural War Wagon, requests a wheeled-vehicle procedural archetype, a base:blaster loadout and movement and AI settings. Its body is resolved using the supported assembly rules; in the simulation-backed path, the world seed and template identity contribute to procedural resolution. This is one expression of the vocabulary, with specific limits that can be inspected and improved.\n\nThe October 26 source inventory includes 635 body definitions in Mainframe's explicitly included packs. That measures authored material, not 635 finished units. Its useful reach will depend on what people and agents compose, exercise and refine. Today’s catalogue gives us a starting vocabulary. Future uses can change both the compositions and the engine that makes them possible.\n\nMainframe opens the collection. Sandbox gives creation and investigation a place to begin. Broadcast makes unfolding activity legible as a programme. Their shared foundation is material for experiences we have yet to design.\n\nStatus: vocabulary growing. Uses still being discovered.\n\nEvolving daily. Subscribe for updates.\n\nAttribution: textGenerator: AI coding agents; editor: Codex \\(AI drafting and technical review\\)\n",
  "created": "2026-10-27T02:06:04Z",
  "generated": [
    {
      "sources": []
    }
  ],
  "id": "645d2zhg0h0wzat9cc3pb29j0a",
  "kind": "thread",
  "media": [
    {
      "alt": "Bodies, actions, relationships, environments and rules provide material for possible uses: play, investigation, rehearsal, storytelling, social spaces and broadcasts. These are directions for composition and future development, not a claim that every experience is implemented, compatible or accepted.",
      "mime": "image/png",
      "url": "https://ericlortie.github.io/liminal-blyg/media/0af91442740bd8a1328e5ff1d55498736164566b1984d9d9c492163d8c884d93.png"
    },
    {
      "alt": "Proposed diagnostic workflow: retain an agent claim, inspect relevant scoped world observations and the context provided, compare what is supported or missing, and preserve a reviewable case. An unsupported bridge claim does not establish that a bridge exists, that the engine failed or that observations are complete. This is an editorial workflow proposal, not an implemented automatic bug-reporting system.",
      "mime": "image/png",
      "url": "https://ericlortie.github.io/liminal-blyg/media/eeb4b182c89346500d3b7b99be42db9233889c15bebec95a5446c96f8a7e3f1c.png"
    }
  ],
  "origin": "https://ericlortie.github.io/liminal-blyg/",
  "page": "f/645d2zhg0h0wzat9cc3pb29j0a/",
  "transclusions": [],
  "updated": "2026-10-27T02:06:04Z",
  "version": 1
}
