MeridiansMeridians

Branching — the fork instrument and the shape of the novel

From the Meridians Wiki · Public · Maintained · human-contract

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, decision architecture, production, scaffold, and budgeted fate exploration.

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.

TierScopeWhat it saysWhere
Mandatea branch, many arcsWhere 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: BranchPlanCoordinationPlan (autoExecute tells auto mode to run it)
Directionone readingWhat 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
Readingone forkWhat could happen, and how likely. The priced cohort of futures (§1–§2).ReadingFuture[]

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:

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_stopthere is no spend bound; { type: "spend"; budgetUsd } is proposed by fate exploration 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.

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:

// 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:

≥ 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:

                 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 §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:

thinkingResource?: "fate" | "world" | "system" | "chaos" | "freeform";
thinkingStyle?:    "freeform" | "divergent" | "deduction" | "abduction" | "induction";
networkBias?:      "inside" | "outside" | "neutral";

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:

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 §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); 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 §7 already puts the turn in the final scene. So:

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:

StructureWhat it isFit for Meridians
Linear / kineticno branching; replay is re-interpretation (Higurashi, Umineko)trivially supported — and not worthless: our frameDeltas are literally "the same events, reframed"
Simple branching / Time Caveevery choice spawns a permanent branch; no merges; no state tracking neededwhat naive sister-branch fan-out produces. Combinatorially explosive, and under a dollar budget the explosion is a literal bill
Gauntletone anointed path, pruned by branches ending in failurethread closure against the protagonist gives bad ends for free
Split and merge / branch-and-bottleneckbranches rejoin at common events; relies heavily on state tracking to keep past choices meaningfulthe natural fit, and the argument of this document
Ladderreaders step off a common route at different points, not one shared forkmatches multi-thread domains, where threads open and close at different scenes
Early / late branchingshort vs. long shared openingour accepted trunk is a common route, so we default to late branching
Parallel storiesconcurrent tracks the reader switches betweenexpressible per-seat; the information boundary makes it honest
Detoura choice that includes or excludes optional materialthe 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 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:

  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:

  • entityResolutionDeltaswho this actually was. The canonical revelation delta.
  • frameDeltaswhat 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:

SignalDerived from
branch factor and depthbranch tree
reconvergence ratio (bottlenecks ÷ forks)shared downstream entries
common-route fractiontrunk 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 depthentityResolutionDeltas / 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.

// 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 §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

RequirementStateWhere
Arc-anchored Readings, many per arc, one activeshippedReading, arc.readingId
Softmax-priced cohort with falsification handlesshippedFuture.priorLogit / considered / breaks / opens
Recorded vantageshippedasOfEntryId, contextScope
Direction + paradigm + thinking-style steershippeddirection, settings
Fan batch producing whole continuationsshippedFuturesRunState, FutureRun.result
Per-arc rarity of the taken pathshippedpresentLogit, presentProbability, priorLogitRarityLabel
Route-level accumulated rarity (the divergence meter)builda pure derivation over a branch's arcs
Ending valence from thread closure, paired with raritybuildthread closure
Orthogonality-aware fan selection (§4)build — currently top-of-cohort by probabilityfan policy
Fork-vs-bottleneck decision at an arc terminalbuildcadence policy
asof-only enforcement for fork readingsbuild (the field exists; nothing enforces it at a fork)contextScope
Direction-vs-instruction discipline (§3)build — convention today, unenforceddirection convention
Branch trunk + divergence at entries (a common route, structurally)shippedbranch model
Typed state deltas that make reconvergence cheapshippedSceneDelta (7 delta kinds)
Thread closure / abandonment detection (bad-end material)shippedisThreadClosed, isThreadAbandoned
Revelation deltas (entityResolutionDeltas, frameDeltas)shippedscene.ts
Sister-branch generation with divergence pressureshippedfutures/scenario generation
Arc grain as the pacing and fork unitshippedSCENES_PER_ARC
Structure classifier (the seven signals of §9)buildpure derivation in core
StructureTarget as an exploration input, shaping promotionbuildexploration policy
Reconvergence detection + bottleneck selectionbuildbranch-tree derivation
Derived route-order dependency graph (§8)buildpure derivation over revelation deltas
Knowledge-gated route availability (reader-knowledge, not completion count)buildreader + seen-state
Playthrough evidence as a scouting prior, firewalled from canonbuildtelemetry 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?