Branching — the fork instrument and the shape of the novel

Source path: knowledge-base/specs/visual-novel/branching.md

# Branching — the fork instrument and the shape of the novel

Status: **rough spec (direction).** Not an implementation contract; nothing here ships until scheduled.

This document owns both the **fork instrument** and the **shape of the novel**: how a directed Reading
produces a divergence, how its rarity is exposed, and what branch topology that instrument should produce. It
works alongside the [visual-novel delivery](README.md), [decision architecture](decisions.md),
[production](production.md), [scaffold](scaffold.md), and
[budgeted fate exploration](../fate-exploration/README.md).

The claim it argues:

> We do not need a branching mechanism. We have one, and it is a **probabilistic instrument** rather than a
> menu: a directed Reading taken at an arc's end produces a priced cohort of futures, and the price is the
> branch's rarity. Branching is therefore not authored — it is **read**, then chosen from, and the choosing
> is recorded permanently.

> Branch topology is not an implementation detail of a visual novel. It **is** the novel's form — the
> medium's equivalent of "novella / epic / anthology". And because Meridians generates scenes *from typed
> world state* rather than hand-authoring state-conditioned variants, it can afford the structure the craft
> considers best and human studios can least afford.

---

## 0. Three tiers of control

Guidance enters the story at three different scopes, and conflating them is how a "directed" story becomes a
dictated one. All three are shipped vocabulary; only the budget bound on them is not.

| Tier | Scope | What it says | Where |
|---|---|---|---|
| **Mandate** | a branch, many arcs | *Where this is going.* A Director-declared trajectory of **peaks** (forces converge, threads culminate, the branch commits) and **valleys** (tension is seeded, an arc pivots), built by **backward induction**: the destination is chosen first, then the structural anchors that earn it are derived backwards. One anchor per arc. | `Branch.coordinationPlan: BranchPlan` → `CoordinationPlan` (`autoExecute` tells auto mode to run it) |
| **Direction** | one reading | *What to consider next.* A steer on a single cohort — which threads to press, which actors to load, which region of the world to reach into. | `Reading.direction`, `SavedReasoningGraph.direction`, `FuturesConfig.direction`, `AutoConfig.direction` |
| **Reading** | one fork | *What could happen, and how likely.* The priced cohort of futures (§1–§2). | `Reading` → `Future[]` |

The layering rule: **a Mandate says what an arc must earn; a Reading says how the world might earn it.** A
Mandate names peaks and valleys, never the futures that reach them — the moment a mandate enumerates the
continuation, the instrument is decoration. This is the same discipline §3 applies to `direction`, one scope
up: legitimate guidance can still be disappointed by the reading.

Two derived properties worth stating, because they are what make mandates useful for a VN rather than merely
for automation:

- **A mandate is a structural target with a shape.** Peaks and valleys are exactly the fork-and-bottleneck
cadence of §5 seen from the authoring side: a valley is where a reading should fan, a peak is where it
should converge and commit. A mandate is therefore the natural place to declare *what kind of novel this
branch is* (§7) without hand-placing a single fork.
- **A mandate is branch-scoped, so sister branches may disagree.** Two routes over one situation can run
under different mandates and remain the same work — which is the multi-POV and parallel-route structure
arriving for free.

### Auto mode and exploration mode

The two automated lanes differ in exactly one respect — how many futures they carry forward:

```text
auto mode one line : read → take the modal future → generate → repeat, under a Mandate
exploration mode a fan : read → select 2–3 divergent futures (§4) → generate each → score → promote
```

Auto mode is shipped (`AutoConfig`, `checkEndConditions`, `autoExecute` against the branch's coordination
plan). Its end conditions today are `scene_count`, `arc_count`, `all_threads_resolved`, `planning_complete`,
and `manual_stop` — **there is no spend bound**; `{ type: "spend"; budgetUsd }` is proposed by
[fate exploration](../fate-exploration/README.md) and is not implemented. Exploration mode as a *mode* is
unbuilt entirely: its parts (batch runner, priced cohorts, `virtualDomain` results) are shipped, the policy
that spends a dollar budget across a fan and promotes the survivors is not.

Both lanes should take the same bound, for the same reason: a scene count bounds *effort*, and effort is not
what runs out.

---

## 1. What is already wired

This is the load-bearing section: the fork machinery is shipped, and a VN branching layer should consume it
rather than reinvent it.

```text
SavedReasoningGraph grounding — the "why", steered by `direction`, with thinkingStyle/resource
↓ linkedGraphIds
Reading a cohort of `Future`s, softmax-priced over `priorLogit`, taken as-of an entry
↓ arc.readingId (one ACTIVE per arc, mirrored onto arc.futures)
arc.futures: Future[] what generation and Branch Futures consume, unchanged
↓ FuturesRunState a batch: one FutureRun per selected future
FutureRun.result { arc, scenes, virtualDomain } — a fully realised continuation, not a stub
↓ commit
Branch sister branches; the highest `probabilityAtStart` becomes the active branch
```

The pieces that matter for a VN, all present today:

- **An arc may host many Readings, one ACTIVE.** `Reading.arcId` + `arc.readingId`. So "take a fresh reading
at the end of every arc" is the shipped cadence, not a new one — and multiple competing readings of the
same arc can coexist, which is exactly how a fork gets more than one honest option set.
- **The cohort is priced, not enumerated.** `Future.priorLogit` in `[-4, +4]`, softmaxed across the cohort.
Divergence arrives **graded**.
- **Each future carries its own falsification handles.** `variables` (with intensities), `reasoning`,
`considered`, `breaks`, `opens` — the universal inference shape. A choice screen has real material to
render without generating anything extra.
- **The vantage is recorded.** `asOfEntryId` + `contextScope: "asof" | "full"` + `includedStreams`. A reading
can be honest about what it could see.
- **The steer is a first-class field.** `Reading.direction` (and `SavedReasoningGraph.direction`,
`FuturesConfig.direction`) — a user-supplied string captured at generation *for transparency*.
- **A batch produces whole continuations.** `FutureRun.result` carries an `arc`, its `scenes`, a
`treeProposal`, and a `virtualDomain` — so a scouted branch is a real playable world, and
`FuturesConfig.sceneCount` (bounded 2–8) sets its length.
- **Autonomy is already typed.** `source: "manual" | "regenerate" | "loop"` on both Reading and
SavedReasoningGraph. The overnight scout has a home in the vocabulary.

## 2. Rarity is already recorded — and it is the fate axis

The single most useful shipped field for a VN nobody has used as one:

```ts
// Arc
presentLogit?: number; // [-4,+4] — the chosen future's priorLogit, transferred on commit
presentProbability?: number; // 0–1 — its softmax share within the originating cohort at commit time
```

The type contract states the intent exactly: *"preserving how strongly was this pulled-toward when it was
chosen as a permanent record of the path's rarity."* And `priorLogitRarityLabel` already bands it:

```text
≥ 3 expected ≥ 1 likely ≥ -1 even ≥ -3 rare < -3 tail-event
```

Two consequences for the novel.

**A route has a measurable improbability.** Sum (or mean) `presentLogit` along the arcs of a branch and you
have a route's accumulated rarity — every step's log-prior, exactly as recorded at the moment it was taken.
That is a divergence meter that we are already persisting per arc, not a new mechanic. It is honest in a way
a hand-authored meter cannot be, because the number was assigned *before* the outcome was known.

**Rarity is not valence, and the pairing is the design space.** Ending valence comes from thread resolution
(closure for or against the protagonist — see §9); rarity comes from
accumulated logit. They are independent axes, which yields the four endings the medium actually trades in:

```text
expected rare / tail-event
good the earned ending the "true route" — the one
(modal, satisfying) that had to be found
bad the tragedy you the freak catastrophe
walked into knowingly (a fluke, and it must read as one)
```

Both axes are already derivable, so "good / bad / in-between" endings need no separate scoring pass — and
the reader can be shown *after* commitment that they took an 8.6% path, which is the payoff for hiding the
prior beforehand ([decisions.md](decisions.md) §6).

## 3. Directed reading — shaping fate without lying to the instrument

The Director's dial is `direction`, and its scope must be stated precisely, because this is where a
probabilistic instrument is easiest to corrupt.

**Direction shapes the option space. It must never move the prices.**

- Legitimate: *what the cohort should consider* — which threads to press, which actors to put under load,
which unexplored region of the world to reach into, what kind of pressure the next arc should apply. A
direction is a question posed to the reading.
- Illegitimate: *what the cohort should conclude* — instructing that a preferred future be priced likely, or
re-rolling a cohort until the desired branch is modal. That is not fate-shaping, it is fixing the readout,
and it destroys the meaning of `presentLogit` retrospectively.

The distinction has a clean test: a direction is legitimate if the reading it produces could still
disappoint the Director. If a direction cannot come back with "the thing you asked about is a tail event",
it is an instruction, not a steer.

The graph settings are the other half of the dial and already exist on `SavedReasoningGraph.settings`:

For fork-making specifically: `thinkingStyle: "divergent"` is the outward-branching mode and materialises in
`opens`; `thinkingResource: "chaos"` is the documented creative agent that *introduces new World entities or
Threads* — the escape hatch when a domain has become too settled to fork honestly; `networkBias: "outside"`
pulls toward base rates rather than the domain's own momentum. A structural target
(§12) should reach for these rather than for prompt improvisation.

## 4. Which futures become branches — fan selection

A cohort is larger than a fork. Selecting the fan is the one genuinely new policy this document asks for, and
the naive policy is wrong.

**Do not take top-k by probability.** The modal cohort members are the ones most likely to be *near
duplicates of each other* — they read the same momentum the same way. A fork built from the top three
futures is the expensive version of no fork at all.

Select instead for **spread across the two axes we already have** — prior and orthogonality:

```text
one anchor the modal continuation (the world as it means to go)
one+ contender mid-prior, maximally orthogonal (a genuinely different world)
0–1 tail low-prior, high consequence (rare, and it must announce its rarity)
```

Then apply the shipped gates before it becomes a choice screen: typed divergence in `WorldExpansion` deltas
and at least one irreversible delta ([decisions.md](decisions.md) §4). Orthogonality is measured on the
delta sets, not the prose — two futures whose `variables` differ but whose deltas coincide are one future
described twice.

Costs, so the policy is bounded by something real:

- Fan size is the budget lever, and it is linear: `FuturesConfig.selectedFutureIds` already runs a subset,
and a batch costs `fan × sceneCount` generations. Fan 2–3 at a fork is a *choice*; fan 6 is a survey.
- Only the taken branch earns production assets ([fate-exploration](../fate-exploration/README.md)); the
untaken sisters stay text until a reader reaches for them.
- A cohort is cheap to *read* and expensive to *run*. Prefer reading widely (many futures priced) and running
narrowly (few futures generated) — the priced-but-unrun members are still useful: they are the
`considered` material the choice screen and the flowchart's unexplored edges are made of.

## 5. Cadence — where readings are taken

The arc terminal is the natural fork point and needs no new anchor: readings are arc-anchored, `sceneCount`
is 2–8, and [decisions.md](decisions.md) §7 already puts the turn in the final scene. So:

```text
arc: scenes 1..n-1 establish, escalate
arc: scene n turn / reveal, payoff withheld
→ directed Reading taken as-of scene n (asof, never full — hindsight would leak the answer)
→ cohort priced
→ fan selected (§4), gated (decisions §4)
→ fork offered, or the modal future accepted silently
```

Not every arc terminal is a fork. An arc whose reading returns a dominant modal future with no orthogonal
contender is a **bottleneck** — accept the modal continuation and keep reading. That is the branch-and-
bottleneck structure emerging from the instrument rather than being imposed on it, and it is why the
structural target can be *targeted* but never *forced*: the reading is allowed to say the world does not
fork here.

`contextScope: "asof"` is mandatory for fork readings. A `full`-scope cohort was drafted knowing what came
after the fork; it is a fine analytical artifact and a dishonest choice screen.

---

## 6. The craft's taxonomy, and where we land in it

The medium has a settled vocabulary for branch shape (VNDev Wiki, *Branching*; Kreminski/Short's *Standard
Patterns in Choice-Based Games*). Each entry below is a real structure with real tradeoffs, and each maps
onto something our record can or cannot express:

| Structure | What it is | Fit for Meridians |
|---|---|---|
| **Linear / kinetic** | no branching; replay is re-interpretation (Higurashi, Umineko) | trivially supported — and *not* worthless: our `frameDeltas` are literally "the same events, reframed" |
| **Simple branching / Time Cave** | every choice spawns a permanent branch; no merges; **no state tracking needed** | what naive sister-branch fan-out produces. Combinatorially explosive, and under a dollar budget the explosion is a literal bill |
| **Gauntlet** | one anointed path, pruned by branches ending in failure | thread closure *against* the protagonist gives bad ends for free |
| **Split and merge / branch-and-bottleneck** | branches rejoin at common events; **relies heavily on state tracking** to keep past choices meaningful | **the natural fit, and the argument of this document** |
| **Ladder** | readers step off a common route at *different* points, not one shared fork | matches multi-thread domains, where threads open and close at different scenes |
| **Early / late branching** | short vs. long shared opening | our accepted trunk *is* a common route, so we default to late branching |
| **Parallel stories** | concurrent tracks the reader switches between | expressible per-seat; the information boundary makes it honest |
| **Detour** | a choice that includes or excludes optional material | the cheapest meaningful choice we can offer, and the least interesting |

Two of these deserve to be argued rather than tabulated.

### Time Cave is the default we must refuse

An unconstrained fan is what exploration naturally produces, and it is the structure the craft warns about
most consistently: fan `f` at depth `d` yields `f^d` distinct leaves, and every leaf is prose someone paid
for. Fan 3 at depth 5 is 243 terminal branches. With the exploration spec's ~$0.014 scout and ~$0.56
production numbers, a fan-3 depth-5 tree is ~$3.40 to scout and **~$68 to produce in full** — and almost all
of that spend buys near-duplicates, because most divergences do not survive five scenes as distinct worlds.

The craft's objection is aesthetic (each path gets thin), ours is economic, and both point the same way.

### Branch-and-bottleneck is normally expensive — and for us it is cheap

This is the deepest structural asymmetry in the whole project, so it is worth stating plainly.

In a hand-authored VN, branch-and-bottleneck is the *good* structure and the *rare* one, because after the
branches rejoin, every subsequent scene must be written to account for every combination of prior state.
That is the authorial-burden problem: state-conditioned content grows multiplicatively in the number of
tracked flags, so studios cap the flag count, and past choices decay into cosmetic acknowledgements
("Clementine will remember this").

Meridians inverts that cost. A scene is **generated from the domain state**, and the state is already typed
and complete: `SceneDelta` carries `threadDeltas`, `worldDeltas`, `systemDeltas`, `frameDeltas`,
`ownershipDeltas`, `entityResolutionDeltas`, `controlDeltas`. A post-bottleneck scene does not need
hand-written variants — it needs the same generation call against a different world. **The variation is an
input, not a manuscript.** The marginal cost of honouring a prior choice fifty scenes later is one scene's
generation, not fifty conditioned rewrites.

That inverts the recommendation. For a human studio, reconvergence is a compromise that saves writing. For
us it is the *cheaper and better* structure: bounded node count, unbounded state memory, and choices that
keep mattering long after the branches visually rejoin.

And the flag discipline that constrains studios does not apply either. Flags and affection points are a
poor domain model — a compressed stand-in for a world state the engine could not afford to hold. We hold the
world state. The corresponding discipline for us is the opposite risk: unbounded state that no reader can
track. Which is what §8 is for.

What the flag *did* for the medium still matters, though, and is worth keeping: small commitments that
accumulate quietly and open a path much later. That mechanism survives here without the flag — a nudge to a
named relationship edge, evidence on an open thread, a fact learned — and a gate stated in world terms
rather than as a hidden threshold. [Systems](systems.md) owns it, along with the rule that an accumulating
axis must eventually be harvested by something downstream.

---

## 7. The structure a Meridians novel should target

Composed from the above, the recommended default form — the shape the exploration policy should aim at
unless a Director says otherwise:

```text
common route (accepted trunk, late branching)
─────────────────────────────────●────────────── fork at an arc terminal (decisions.md §2)
╱│╲
route A ╱ │ ╲ route C each route = a sister branch carrying
│ B │ typed deltas that persist
bad end ◄───┤ │ ├───► bad end (thread closes against the protagonist)
╲ │ ╱
───────────────────────────────────●──────────── bottleneck: a world event that happens
│ in every route, read differently in each
continues, state-carrying
```

Properties worth naming:

- **Late branching with a real common route.** The accepted trunk is shared, so the world is established
once and paid for once. Skip-over-seen (reader spec §3) is what makes a re-read of the common route
bearable, which is why the two specs constrain each other.
- **Bottlenecks are world events, not narrative resets.** A bottleneck is a scene whose *occurrence* is
route-invariant while its *reading* is not — the same event, entered with different state, different
knowledge, different allies. That is not a compromise; it is the medium's best trick.
- **Bad ends by thread closure, not by authorial punishment.** `isThreadClosed` / `isThreadAbandoned` already
detect an ended question; a route where the fork's thread closes against the protagonist's interest is a
bad end derived from the world, not scripted as a slap. The craft's convention here (FSN's Tiger Dojo)
is that a bad end **teaches** — ours does that with the ending card's `breaks` field: this is what would
have made it go otherwise.
- **Ladder over single-fork where the domain supports it.** A domain with several live threads should let
readers step off at different points rather than at one grand crossroads. It reads as a world with several
things going on, which is what a multi-thread domain actually is.

---

## 8. Enforced route order, derived rather than decreed

The strongest structural idea in the canon is FSN's: three routes, **hard-locked in order** (Fate → UBW →
Heaven's Feel), because each assumes what the previous one revealed. Reading them out of order is not
forbidden for tidiness — it is a lesser experience, because the later route's revelations land on ground the
reader has not stood on.

In a hand-authored VN this is a persistent-variable check the author sets by fiat. **For us it is
derivable.** A route's comprehension depends on facts a reader can only have acquired elsewhere, and we have
those facts typed:

- `entityResolutionDeltas` — *who this actually was*. The canonical revelation delta.
- `frameDeltas` — *what that earlier event actually meant*. A reframe of already-read material is a
revelation whose whole force depends on having read the original.
- thread `payoff` / `closure` events — a question answered in route A that route B assumes settled.

So: **route B is order-dependent on route A when B's material consumes revelations A produces.** That is a
dependency edge computable from stored deltas, and it yields a partial order over routes — a *derived*
reading order, with a true route falling out naturally as the sink of the dependency graph: the route that
consumes the most and produces the least, readable only once the others have paid for it.

Two consequences:

1. **The lock can be honest.** Rather than "locked", the reader can be told *there is material here you have
no ground for yet* — which is true, and which is a better invitation than a padlock.
2. **The reader's own knowledge is the real key.** Virtue's Last Reward's design lesson is exactly this:
the locks are informational, and "the keys are always information" — you jump to another thread, learn
why something happened, and return able to proceed. Our version has the advantage of being *checkable*:
we know which revelations a reader has seen (seen-state), so a gate can test the reader's knowledge
rather than their completion count.

This also justifies the flowchart as a first-class surface rather than a convenience. In VLR the agency
lives not in the in-fiction choices but in **which thread you explore and when** — and a scouted fan of
branches with an explorable flowchart is precisely that instrument.

---

## 9. Structure as a description of the novel

The Director's question is not "how many branches" but "what kind of thing does my domain make?" — and the
shape answers it. Given a prepared branch tree, its structure is classifiable from graph shape plus deltas,
with no model in the loop:

| Signal | Derived from |
|---|---|
| branch factor and depth | branch tree |
| reconvergence ratio (bottlenecks ÷ forks) | shared downstream entries |
| common-route fraction | trunk length ÷ mean route length |
| step-off dispersion (single fork vs. ladder) | variance of fork positions |
| terminal character (endings vs. bad ends) | thread closure sign at terminals |
| revelation dependency depth | `entityResolutionDeltas` / `frameDeltas` graph → §8 |
| state carry (do old choices still bite?) | deltas from pre-bottleneck forks still live at terminals |

Those seven numbers describe a novel's form, and they name it in the craft's own vocabulary: *a late-branching
three-route structure with two bottlenecks, a gauntlet fringe, and a dependent true route* is a genuinely
informative thing to tell a Director about their domain.

They also make the structure **steerable**, which is the answer to "guide the VN branching process": the
exploration policy takes a **structural target** alongside its dollar budget, and the target changes what
the budget buys.

```ts
// direction, not a shipped type
type StructureTarget = {
form: "linear" | "time-cave" | "gauntlet" | "split-merge" | "ladder" | "parallel";
routes?: number; // how wide the fan may get
reconvergeEveryArcs?: number; // how often branches must be pulled back to a bottleneck
badEnds?: "none" | "sparse" | "gauntlet";
commonRouteArcs?: number; // how much is shared before the first step-off
};
```

Concretely, the target rewrites the promotion rules the exploration spec already defines: `split-merge`
promotes candidates that **reconverge** on a shared downstream event and demotes ones that run away;
`ladder` spreads fork positions instead of stacking them at one entry; `gauntlet` promotes a narrow spine and
keeps failure branches short and cheap. Same budget, same scoring, different shape — and the budget goes much
further under a reconverging target, because bottlenecks cap node count while state keeps the divergence
meaningful.

**The anti-metric rule applies here too**, and harder than elsewhere: the structural target governs *which
candidates are kept*, never *what the world is*. A domain whose causal structure genuinely admits one path
must be allowed to produce a linear novel. Manufacturing a three-route structure over a world that has one
is how the instrument starts lying, and a reader feels it as weightlessness long before they can name it.

---

## 10. The training loop, stated honestly

The ambition — more playthroughs producing better branching decisions — is right, and the exact shape of the
loop matters, because there is a version of it that quietly destroys the instrument.

**What playthrough evidence may train: where to look.**

- which forks readers actually stop at, versus skip through;
- which routes go unread, and which bottlenecks readers return to;
- where readers rewind (a confusion signal) or quit (a pacing signal);
- which revelations were consumed before the route that needed them (an ordering signal);
- which candidate structures produced novels people finished.

That is a scouting policy — a prior over *where in the possibility space to spend the next dollar*. It gets
better with every playthrough, it is genuinely a training loop, and it is safe because its output is an
allocation, not a claim.

**What playthrough evidence may never train: what is true.**

Reader behaviour must not adjust thread stance, prior logits, position calibration, or the truth of the
world. The moment popularity feeds back into what the domain believes, the domain believes what is
entertaining — Goodhart's law arriving on schedule, and the exact failure the repo already legislates
against: *verification is a readout, never an input*. The [delivery spec](README.md) §4 states the same
boundary at the record level (reading writes nothing to canon), and this is its epistemic half.

The honest formulation, then:

> **The novel is the artifact. The playthrough trains the scout, not the world.**

Two smaller cautions on the same theme. Optimising for completion produces short, safe, low-consequence
novels — the medium's own history is instructive, since its most durable works are demanding rather than
frictionless. And reader evidence is *sparse and biased* long before it is useful: a single Director's
reading habits are not a signal about narrative quality, and treating them as one will overfit a domain to
one person's Tuesday evening.

---

## 11. What this is not

- **Not a second generator.** The batch, the commit, the branch lineage, and the pricer are shipped; this
document adds selection policy and cadence, nothing executable.
- **Not a scoring pass.** Rarity is read off `presentLogit`. Valence is read off thread closure. Neither
needs an LLM judge, and both stay deterministic.
- **Not a place for reader telemetry.** Playthrough evidence may inform *where the next reading is taken and
how wide the fan is*. It may never touch `priorLogit`, `presentLogit`, stance, or calibration
(§10). Verification is a readout, never an input.

---

## 12. The honest ledger

| Requirement | State | Where |
|---|---|---|
| Arc-anchored Readings, many per arc, one active | shipped | `Reading`, `arc.readingId` |
| Softmax-priced cohort with falsification handles | shipped | `Future.priorLogit` / `considered` / `breaks` / `opens` |
| Recorded vantage | shipped | `asOfEntryId`, `contextScope` |
| Direction + paradigm + thinking-style steer | shipped | `direction`, `settings` |
| Fan batch producing whole continuations | shipped | `FuturesRunState`, `FutureRun.result` |
| Per-arc rarity of the taken path | shipped | `presentLogit`, `presentProbability`, `priorLogitRarityLabel` |
| Route-level accumulated rarity (the divergence meter) | build | a pure derivation over a branch's arcs |
| Ending valence from thread closure, paired with rarity | build | thread closure |
| Orthogonality-aware fan selection (§4) | build — currently top-of-cohort by probability | fan policy |
| Fork-vs-bottleneck decision at an arc terminal | build | cadence policy |
| `asof`-only enforcement for fork readings | build (the field exists; nothing enforces it at a fork) | `contextScope` |
| Direction-vs-instruction discipline (§3) | build — convention today, unenforced | direction convention |
| Branch trunk + divergence at entries (a common route, structurally) | **shipped** | branch model |
| Typed state deltas that make reconvergence cheap | **shipped** | `SceneDelta` (7 delta kinds) |
| Thread closure / abandonment detection (bad-end material) | **shipped** | `isThreadClosed`, `isThreadAbandoned` |
| Revelation deltas (`entityResolutionDeltas`, `frameDeltas`) | **shipped** | `scene.ts` |
| Sister-branch generation with divergence pressure | **shipped** | futures/scenario generation |
| Arc grain as the pacing and fork unit | **shipped** | `SCENES_PER_ARC` |
| **Structure classifier (the seven signals of §9)** | **build** | pure derivation in `core` |
| **`StructureTarget` as an exploration input, shaping promotion** | **build** | exploration policy |
| **Reconvergence detection + bottleneck selection** | **build** | branch-tree derivation |
| **Derived route-order dependency graph (§8)** | **build** | pure derivation over revelation deltas |
| **Knowledge-gated route availability (reader-knowledge, not completion count)** | **build** | reader + seen-state |
| **Playthrough evidence as a scouting prior, firewalled from canon** | **build** | telemetry lane, exploration only |

---

## 13. Open questions

1. Is the divergence meter a **reader-facing** artifact (shown after an ending, as the medium does) or an
internal promotion signal only?
2. Should a Director be able to see the cohort's prices *before* choosing which futures to run — and does
that make the subsequent `presentLogit` less honest?
3. When a reading returns no orthogonal contender, is it right to accept the modal future **silently**, or
should the reader be told that this arc had no fork in it?
4. Does a tail-event branch need a higher production bar (a fluke ending that looks cheap reads as a bug),
or a lower one (it will be seen least)?
5. May a Director re-roll a cohort at all? A single re-roll is authorship; unlimited re-rolls are price
fixing, and the field that records rarity cannot tell the difference.
6. **Is the structural target per domain or per production?** One world could plausibly yield a tight
gauntlet novel and a sprawling ladder novel from the same record.
7. **Who chooses a bottleneck** — the Director marking a world event as route-invariant, or a derivation
proposing candidates from events every sister branch already shares?
8. **Should a derived route order ever be enforced**, or only advised? Enforcement is the FSN lesson;
advisory respects that we derived it rather than authored it. I lean advisory-by-default, enforceable
per production.
9. **Do bad ends cost production budget?** They are the cheapest content to generate and the easiest to
overproduce; a gauntlet fringe could eat a budget in failure states nobody re-reads.
10. **How many routes before a domain stops being one novel** and becomes an anthology — and is that a
problem worth preventing, or the natural end state of a world that keeps growing?

Open on GitHub

Raw Markdown source