Concepts
The Scene (the Scene source)
A Scene is a node in a Scenario. Every Scene is baked into one shared low-level, markup-centric Scene source — Markup, with Bindings and Logic embossed from it. Custom is that Scene source; Modes are projections of it.
On this page
A Scenario is the whole work: a graph of nodes. Each node is a Scene — the unit an author builds at each point in the scenario. (When we need a generic noun for the surface, we call it an Interactive Document.)
Every Scene, no matter how it was authored, is baked into one shared low-level surface: the Scene source. The Scene source is markup-centric: one material — Markup — with Bindings and Logic embossed from it. We walk it as three layers below, but they are not three co-equal materials you tab between; Bindings and Logic are abstractions that rise out of the one markup Scene source:
- Markup — content, structure, media.
- Bindings — the templating layer woven into the markup. Bindings only read state.
- Logic Blocks — reusable WHEN/IF/DO rule packs you place and fill in.
This page walks the three layers in depth and makes one point load-bearing: Custom is the Scene source. The friendly Modes (Decision “what do you do?”, Slides, …) are higher-level abstractions stacked on top of these same three layers — projections, not a different thing. Because there is nothing underneath a Mode but the Scene source, ejecting a Mode to Custom is lossless.
The Scene is the unit you build; the Scenario is the whole work. A Scenario is a graph of Scenes; a Scene is a stack of three layers.
The custom view is a view, not “the code”
The Custom surface of a Scene is shown through the Source view (“Edit as code”). It is a VIEW of the same Scene you author through any Mode — never “the code”, never “a script”, never “an eject”. You author the same Interactive Document; the Source view just shows it as declarative Markup-with-logic. Switching to it loses nothing and adds nothing — it is the same Scene, viewed closer to the floor.
Layer 1 — Markup (content, structure, media)
Markup is the floor: what the player reads, the way it is laid out, and the media it carries.
- What it is. Markdoc plus a safe, sandboxed HTML subset. Markdoc gives you content as data with declarative tags; the HTML subset covers the structural and media cases Markdoc alone does not.
- What it does. Holds the authored body of the Scene — prose, headings, lists, images, embedded media, the visible shape of the screen.
- What it is not. It is not a program. There is no place in the Markup to attach a state change. The Markup describes what the Scene is, not what it does over time.
Markup is deliberately a safe surface. Only the sandboxed Markdoc + HTML subset is allowed, so a Scene authored or imported from anywhere can be rendered without trusting it. (See the security note in Reuse and the Workspace Library and the project security posture.)
Layer 2 — Bindings (the templating layer — read only)
Bindings are the templating layer woven into the Markup. They make the Markup dynamic without making it a program.
There are two kinds of Binding, and both only read state:
- Insert a value. Drop a value into the prose:
{score},{playerName},{found} of 5. The value is read from state and substituted into the text. - Show or hide a block by a condition. Reveal or conceal a chunk of Markup depending on a condition: show this paragraph if trust is at least 3, otherwise show that one.
The load-bearing fact: Bindings read; Logic writes. A Binding can pull a value out of state and put it on the screen, or decide whether a block of Markup appears — but it can never change state. That asymmetry is the structural wall between Layer 2 and Layer 3.
You will not see a “read-only” label on a Binding, because none is needed. The Markup simply offers no affordance to write from inside a Binding — there is nowhere to attach a change. Structure teaches the wall: a Binding is something you drop into the Markup that fills itself from state, the way a spreadsheet formula cell fills itself. There is no slot there to put a state change, so there is nothing to label.
Bindings read, Logic writes. That one sentence is the whole relationship between Layer 2 and Layer 3.
Layer 3 — Logic Blocks (reusable rule packs with inputs)
Logic Blocks are the rule layer of a Scene: where things happen.
-
What it is. A reusable WHEN/IF/DO rule pack you place or reference inside a Scene. Each Block exposes inputs — the blanks you fill in when you place it.
-
What it does. Carries the rules of the Scene. Every rule has one shape:
WHEN
<trigger>[IF/WHILE<condition>] DO<effects>.This is fill-in-the-blank English: WHEN you click this, IF trust is at least 3, DO go to the Briefing. The full grammar of triggers, conditions, and effects is covered in Logic: triggers, conditions, effects.
-
Inputs, not parameters. The fill-in slots of a Logic Block are inputs or blanks to fill in — never “parameters”, “props”, or “arguments”. An instance of a Block is “the same Block, with these blanks filled in”.
Logic Blocks are the only place a Scene writes. That is the other side of the wall: Bindings read state into the Markup; Logic Blocks are where state actually changes. Every effect a Logic Block performs changes exactly one of three things — Memory (facts the run remembers), Content (what’s shown), or Context (where you are in the scenario). Those three families are the entire alphabet of effects; see Logic: triggers, conditions, effects.
Because Logic Blocks are reusable, the same Block authored once can be placed across many Scenes as linked instances. Where they live, how you make and place them, and the difference between a reusable Block and a cosmetic group are all covered in Reuse and the Workspace Library.
The three layers, at a glance
| Layer | Name | What it carries | Reads or writes state? |
|---|---|---|---|
| 1 | Markup | Content, structure, media (Markdoc + safe HTML subset) | Neither — it describes the Scene |
| 2 | Bindings | Templating woven into the Markup: insert a value, show/hide a block | Reads only |
| 3 | Logic Blocks | Reusable WHEN/IF/DO rule packs with inputs | Writes (the only writer) |
One Scene. Three layers. Markup is the body, Bindings make it dynamic by reading, Logic Blocks make it act by writing.
Custom is the Scene source; Modes are projections of it
This is the frame to hold onto:
- Custom is the floor. The three-layer Scene source — Markup, Bindings, Logic Blocks — is the lowest-level surface every Scene is baked into. Nothing sits beneath it.
- Modes sit on top. A Mode (Decision “what do you do?”, Slides, …) is an opinionated, higher-level abstraction over the Scene source. A Mode pre-fills the same three layers from a recipe and hides the parts you don’t need for that style of Scene.
- Ejecting is lossless. Because a Mode is only a projection of the Scene source, switching a Scene from a Mode to the Custom Source view loses nothing. There is nothing underneath a Mode but the three layers — so the eject is just a change of view onto the same Scene.
A Decision Scene and a hand-authored Custom Scene are the same kind of thing underneath: both are a Scene built on Markup + Bindings + Logic Blocks. The Mode is a friendlier way in; the Scene source is what is actually there.
Where this fits
This is one of five concept pages that paint a single mental model. The Scene source established here is the floor everything else stands on:
- The mental model (start here) — the whole picture on one page.
- Logic: triggers, conditions, effects — the WHEN/IF/DO rule shape, the five triggers, and the three effect families (Memory · Content · Context).
- The truth model — why the Playthrough log is the single source of truth, and how Memory, Content, and Context are rebuilt from it.
- Reuse and the Workspace Library — Logic Blocks, Components, and Blueprints as definitions you place as linked instances.