STORYDEPTH_WHOLE_ARC_INSTRUMENT_2026-07-27.md

pipelines/STORYDEPTH_WHOLE_ARC_INSTRUMENT_2026-07-27.md

THE WHOLE-ARC FLOW INSTRUMENT — design for a repeatable Pro→Epi connections sweep

Read-only research analysis. Axis: Josh's standing whole-arc-connections directive ("you're missing a

LOT"), designed as a REPEATABLE INSTRUMENT rather than a one-off pass. Every claim below is grounded in

a file or a scorecard read this session; absence-claims are positive-controlled where noted.

---

0. The headline (four findings, then the design)

F1 — The pass HAS run once, and it is stale by construction.

docs/proposals/WHOLE_ARC_CONNECTIONS_PASS.md (390 lines) exists and is substantial: 79 nodes audited,

65 named cross-arc through-line chains across 6 connection types, ~70 single-node opportunities in the 15

nodes WS1 never covered, ~40 care/violence recalibration verdicts, 9 true orphan/unpaid callbacks, a

7-tier prioritized re-cascade work-list, 2 cardinal forks (both since ruled/dropped in-file). It folds 13

working files under docs/proposals/whole_arc/ and extends aaa_ws1_opportunity_matrix.md.

Its last commit is e00051d, 2026-07-13. The v3 spine rewrite landed 2026-07-15 onward

(docs/SPINE_SCHEMA_v3.md 07-15; docs/spine/CH_40.md 07-15; docs/spine/CH_75.md 07-19). So the pass

audited a corpus that no longer exists in that form — it predates the v3 beat/fork/state graph (891

beats / 2062 deltas), the typed fork graph with ACTION-keyed options, the §18 derived-state axes, the

seam state-diffs, the state-delta grammar, the natural-voice rewrite, the presentation doctrine, the

COMBAT_PROGRAM_ADDENDUM §§7-12 rulings, and all three 2026-07-27 rulings including the amulet spine.

Josh's "never yet run at the current standard" is literally, verifiably true.

F2 — The RR layer is stale in exactly the same way, and by the same margin.

All nine reports: RR_12.md 2026-07-09 … RR_72.md 07-11, RR_FINAL.md 07-11. Every one predates v3.

Proof by content: RR_FINAL.md describes its window as "Ch 74 the Father's Court / Cassius Velheim … Ch

76-77 the Waterfall" — but the live spine reads CH_74 = Yggdrasil, CH_75 = The Realm at War, `CH_76 =

The Two Courts (Cassius), CH_77 = The Waterfall`. The endgame renumbered under the v3 rewrite and the

RR reports were never re-pointed. **This is decisive for the boundary question in §5: the RR layer cannot

be the first pass, because it is the more stale of the two.**

F3 — One true whole-arc tooth already exists, for exactly ONE arc class.

harness/check_spine_graph.py has a CORPUS MODE (fires only when all 79/80 nodes are passed in one

invocation) that upgrades four checks from WARN to ERROR:

• [mark] — mark_write {community: …, forward_track [CH_62 CH_75]} edges: every declared target chapter

must carry an in:-line containing the community token. **This is a real, machine-enforced

promise→payoff edge across the whole arc.** Regex MARK_FT_RE at line 543; check at 588.

• [seam] — cross-file ws-key agreement on both faces of a boundary.
• [s18] — path_bucket pre/post-Ch-65-lock consistency.
• [foundational] — FOUNDATIONAL forks anchor the Integrity §5.4 catalog.

That is the prototype of the instrument this analysis designs. It works. It covers community-mark forks

and worldstate seams — and nothing else. No amulet chain, no relationship arc, no thread payoff, no

era-rhyme, no boss lineage, no L3 chain, no companion arc, no object provenance.

F4 — The authoring input is structurally blind to the arc.

harness/enrich.py::continuity_anchor() (line 183) reads the predecessor entry's end-state only —

N-1, one hop. That is the root cause of "you're missing a LOT": the factory's own build pack cannot see

a promise made 40 chapters earlier. Every other continuity surface is partial or empty:

Positive-controlled absence claim: ls harness/ | grep -iE "densit|curve|pacing" returns nothing, and

no gate in the 29-gate roster names arcs, relationships, payoffs, or emotional pacing. The nearest

analogues are check_chapter_topography.py (mode variety, no-3-consecutive) and the corpus-mode

[mark] tooth. There is no arc-flow instrument today. There is one tooth that proves the pattern works.

The answer to Josh's second question ("how's everything been getting wired up?"). Honestly, in three

tiers with a hole in the third:

1. Doctrine lands reliably — a ruling → a doc + a DOC_MAP row + a ledger entry + a commit. This tier

is healthy (the anti-orphan doctrine is enforced socially and it holds).

2. Data homes land increasingly well — the §§7-12 schema mint (a1a47c2) put 13 data homes + 4

self-testing gates in one wave, 25→29 gates. The pattern is proven and repeatable.

3. Connective tissue between nodes has doctrine and prose and no data home and no gate — except

the single [mark] class. That is precisely why the whole-arc directive keeps re-surfacing: the work

*is* getting wired up per-node and per-system, and is *not* getting wired up per-arc. The instrument

below is the missing tier-2/tier-3 for the arc layer.

---

0.5 FRESH MEASUREMENTS (verification pass, 2026-07-27) — the hole INSIDE the working tooth

F3 is confirmed by reading cross_file_checks() (line 568) and the gate's own target list: the corpus

mode does fire (all 79 nodes + 3 exemplars are passed in ONE invocation by gates_config.json), and it

runs four ERROR-tier checks — [mark], [seam], [foundational], [s18]. **But the tooth has a silent

hole exactly where the connective debt lives, and three classes of arc-level state sit outside it.** All

four measurements below were computed against the live tree this session and are reproducible.

M1 — 64 marks are INVISIBLE to the [mark] tooth, by regex construction

MARK_FT_RE = re.compile(r"\{(\w+):[^{}]*?forward_track \[([^\]]+)\]", re.S). The target group is

[^\]]+ — one or more characters. An empty cell, forward_track [], therefore produces **no match at

all**: not checked, not reported, not counted. Verified directly:

forward_track []       -> []                          (no match - silently unchecked)
forward_track [CH_41]  -> [('south_africa','CH_41')]  (checked)

64 forward_track [] cells are empty, across 17 nodes — CH_04(4), 20(4), 23(4), 26(4), 30(5), 31(4),

33(4), 34(4), 35(5), 41(3), 42(4), 44(4), 45(3), 47(4), 49(2), 51(3), 53(3). Each is a fork option

authoring a permanent durable community mark with no declared consumer anywhere in the arc. The gate

is green and always will be, because an unfilled promise is spelled the one way the regex cannot see.

This is the sharpest finding of the verification pass, and it is noisy-gate-conceals /

a-search-that-cannot-match-reports-zero recurring in a new place: **the arc tooth's own blind spot is

precisely the population the whole-arc directive is about.** First fix, one line: match \[([^\]]*)\]

and treat an empty target list as UNCLAIMED — routed to the ledger as an open UNPAID row rather than a

hard FAIL, because it is work, not a defect.

M2 — 14 of 27 declared pairs are narratively unreciprocated (a DIFFERENT axis from the gate's)

Of the 27 distinct populated src -> forward_track[tgt] pairs, **14 have targets whose file never names

the source node anywhere: CH_03->63, CH_11->40, CH_12->40**, CH_15->69, CH_28->65, CH_29->65,

CH_39->75, CH_40->75, CH_48->65, CH_59->65, CH_62->65, CH_62->75, CH_72->75, CH_73->75.

Precision matters: the [mark] tooth checks that the target carries an in:-line containing the

community token. It does not check that the payoff node knows where its debt came from. Both axes are

real and they are different. The gate guarantees the machine reads the state; it cannot guarantee the

prose pays the promise. 11 of the 14 cross three or more RR windows — no Range Review could ever have

caught them, which is §5's boundary argument made in data.

The positive control that proves prose harvests do not land: CH_11->40 and CH_12->40 are the exact two

links WHOLE_ARC_CONNECTIVE_WEB.md (2026-07-14) named *"the single biggest missed web in the whole arc."*

Thirteen days and one full v3 rewrite later, still unpaid. A ledger row with a disposition would have

survived; a ranked table in a prose master did not.

M3 — the worldstate flow census: 30 keys, 14 write-only, 4 read-only

Across every beat in:/out: line in all 79 nodes: **30 distinct ws.* keys; 14 are WRITTEN and never

READ by any beat anywhere** — integrity_score, faction_standing_per_faction, relationship_history,

companion_loyalty_transition_events, reputation_biography_propagation, six_option_cumulative_record,

journal_entries_unlocked, trade_sovereignty_valence, dwelling_home_ledger,

atlantis_passage_decision, atmospheric_vril_density_modifier, vril_polarity_signature,

vimana_5th_mode_access, worn_rune_loadout — and 4 are READ and never WRITTEN: appearance_score,

convergence_node_state, integrity_level, ntala_inversion_state.

The [seam] tooth cannot see any of this: it compares only keys asserted on **both faces of an adjacent

boundary**, so it validates hop-by-hop agreement and never long-span flow.

The honest caveat the extractor must ENCODE rather than assume: **part of the write-only set is

legitimately consumed by runtime systems rather than by beats** (atmospheric_vril_density_modifier by

the vril-density dial; worn_rune_loadout by the loadout system). So Layer 0's correct output is not "14

orphans" but a typed split — beat_consumed / runtime_consumed / genuinely unconsumed — and only

the third bucket is a finding. relationship_history, companion_loyalty_transition_events, and

reputation_biography_propagation are the three that most need an answer, because they are exactly the

axis today's rulings made load-bearing.

M4 — intensity is already occupied; the pacing curve must not overload it

T0_Chapter_Index.intensity is populated on all 79 rows with four values — standard 47 · peak 24 ·

valley 5 · relief 3 — and is gated by check_chapter_topography.py R3 against HL_0048 ("no three

consecutive intensity-peaks; no three consecutive valleys"). Re-scoping that column would collide with a

hard line. Correction folded into §2.3.

---

1. (a) THE SWEEP ARCHITECTURE

1.1 The trap to avoid, named first

The obvious design — "79 per-node connection-miner agents, each reading its node against the full arc" —

is wrong three ways and must be rejected explicitly:

• It is an N² read. 80 spine files total 892,382 words / 23,513 lines. Each agent reading the arc is

~890k words of context, ×79. Unaffordable, and the model-tiering law forbids it.

• It produces per-node opinions, not arc facts. An arc fact ("this promise is unpaid") is only

visible from the arc, never from a node.

• It produces prose. The 2026-07-13 pass is the proof of what prose output costs: a 390-line master doc

that no gate reads and that went stale within 48 hours of the v3 rewrite.

1.2 The four-layer architecture

LAYER 0 — the deterministic connective extractor (zero-token, runs first, runs always).

A script, harness/extract_connections.py, mines the 80 spine files + the registries into ONE typed edge

table. It invents nothing: the grammar it harvests already exists in the v3 corpus:

• mark_write {community: …, forward_track [CH_NN …]} — explicit forward edges (already ERROR-checked).
• beat in: / out: lines — local.<k> and flag()/has() produce-before-consume tokens.
• ws.<name> worldstate keys + the seam state-diff blocks (exit→entry assertions).
• thread_refs THREAD_NN + progression_stage (Thread_Grid) — thread arcs.
• systems_touched prefixes (ability: boss: sub_boss: trade: antagonist: vril_site:).
• ## Side-questlines (§11) SQ beats + stage (SEED/ADVANCE/RESOLVE).
• ## End-state carry-forward / ## Continuity anchor field pairs.
• boss ids BE_*.Pn, scene rows, fork convergence_node, path_bucket, care_band.
• ## Key ally NPCs, companions_present, familiars_present, found_family, homes_established.

Then it computes the arithmetic that IS most of "you're missing a LOT":

• UNPAID — a forward edge whose target node contains no reader.
• ORPHAN — a node reads a token/entity/object no earlier node wrote.
• DANGLING — an arc with a setup and escalation but no terminal disposition.
• THIN — an arc with ≤2 touches across its declared span (the depth floor, §2.4).
• GAP — a thread/questline/relationship with a hole in its declared span (the Thread-4 class of hole

that survived undetected all the way to RR-FINAL Grid 3).

• UNCLASSED — an entity/object/relationship that recurs ≥3 times and belongs to no registered arc.

This is ~90% of the finding volume, deterministically, for free, and repeatably. It converts the sweep

from an opinion exercise into a diff.

LAYER 1 — arc-class auditors (the fan-out; the unit of work is the ARC, never the node).

Each auditor gets a fresh context, an arc-scoped slice produced by Layer 0 (the extracted beats of the

8-25 nodes its arc actually touches, not whole files), and one job: verify the arc's shape, grade its

depth, and name what is missing. Roster (examples-not-limits — the class list is seeds; a new ruling

mints new classes, see §4):

~55-70 auditors, run in 4-6 waves. Model set EXPLICITLY to the opus tier alias on every one (seat

law); the director never volume-audits.

Honest sizing. One RR window cost ~1,262,858 subagent tokens for 6 grids over 7 nodes (RR_72,

RR_FINAL headers). An arc auditor is materially cheaper per finding because Layer 0 did the retrieval: it

reads extracted beat slices, not full 11k-word entries. Realistic envelope: an arc auditor at ~40-90k

input; ~60 auditors ≈ 3-6M subagent-tokens for wave 1, i.e. roughly 3-5 Range Reviews' worth of spend

for a 79-node arc audit. That is the honest number — it is not cheap, and it is affordable exactly once

at this scale, which is why §3's diff-cadence matters more than the sweep itself.

LAYER 2 — refutation + reconciliation (the quality bar, non-negotiable).

• Refutation critics. Every auditor's findings go to a fresh-context critic whose job is to KILL what

the corpus already pays. Precedent with a measured kill rate: DESIGN_GAP_REGISTER v1.1 — "11 of 20 raw

lens findings killed with reasons." Without this, 60 auditors × ~15 findings = ~900 raw items, most of

them re-discovering paid arcs.

• Cross-arc reconciler. Arcs collide (ER-3 and ER-4 both terminate at the Ch-71 fused game-boss; ER-1/2/7

all pivot on Ch 28). Precedent: the §§7-12 mint's cross-critic "caught four cross-family collisions."

One reconciler per wave, adjudicating collisions and de-duplicating identical findings from different arcs.

• The care/reveal pass rides along, not after. Every proposed new connection is reveal-checked (no

House-of-Velheim pattern before ~Ch 38; Cassius Ch 76; thesis Ch 77) and care-checked against the §17

floor + the bolder calibration. The prior pass already proved this works in both directions (its

CARE+VIOLENCE critic returned PASS with only MINOR riders).

LAYER 3 — director adjudication + the ratification lanes. Contested findings only; everything else

routes by rule into an existing lane (§2.5).

1.3 Why this is an instrument and not a pass

Layer 0 is a script enrolled in run_gates.py — it runs on every commit forever, at zero token cost.

Layers 1-3 are the *expensive* part and they run on a diff: after wave 1, an arc is re-audited only

when git diff since its audit tag touches a node in its span (§3.2). The 2026-07-13 pass had no Layer 0,

so it had no way to be anything but a one-off.

---

2. (b) WHAT IT PRODUCES

Five artifacts. Every one has a named consumer before it is written (anti-orphan doctrine) and a

DOC_MAP row.

2.1 The Connection Ledger — the primary output, and it is DATA, not prose

registries/T0_Connection_Ledger/ (or docs/spine/CONNECTION_LEDGER.csv if it stays proposal-tier

first, then promotes). One row per typed edge:

edge_id, arc_class, arc_id, arc_name,
promise_node, promise_anchor,      # CH_NN + beat_id/fork_id/block
payoff_node,  payoff_anchor,
edge_kind,                          # setup | escalation | recognition | payoff | disposition | protect
edge_state,                         # PAID | PARTIAL | UNPAID | ORPHAN | PROTECTED | DECLARED_ABSENT
layer,                              # L1 | L1.5 | L2 | L3
reveal_ceiling,                     # earliest node this edge may surface
care_flag, evidence, disposition, source_pass, last_verified_tag

Why data and not a report: the 2026-07-13 prose master is the counter-example. A ledger is greppable,

gate-checkable, enrich-consumable, and diffable. A report is a snapshot that rots.

Seeding is cheap and honest: Layer 0 extracts the mechanical edges; the 65 named chains from the

2026-07-13 pass are re-verified against v3 and imported as rows (they are excellent research, wrongly

housed) — that alone recovers the prior investment instead of discarding it.

**The additive carry-forward property is the ledger's most important behaviour, and it is already solved

in this repo.** QUEST_SEED_HOUSING_LEDGER.md states the exact pattern to copy: *"GENERATED by … .

Regenerable and ADDITIVE: a row already routed to a non-UNROUTED disposition is carried forward across

re-runs, so typing work is never wiped. UNROUTED is the default, so a seed nobody has placed shows up as

an open row rather than as silence."* Apply verbatim. A re-run RE-MINES but **never wipes an adjudicated

row, and an unadjudicated row is visible, not silent** — which is precisely the property the 07-13

and 07-14 prose masters lacked, and precisely why M2's two flagship links are still unpaid thirteen days

later. disposition defaults to UNROUTED; declined_with_reason is a first-class value, so a

deliberately-declined connection is recorded as a decision rather than re-surfacing every sweep.

2.2 The gate — harness/check_arc_flow.py

Built on the house pattern: PASS-on-empty scaffold, LOUDLY DECLARED (the no_dead_end /

build_space precedent — every not-yet-armed assertion prints under "DECLARED NOT-ARMED" every run), with

--self-test must-fire/must-not-fire fixtures that exit 2 if a ruler rotted. Assertions, arming as the

ledger populates:

1. Every non-PROTECTED promise edge has a payoff node and the payoff node machine-visibly reads it

(generalizes the working [mark] corpus tooth to every arc class).

2. Every payoff resolves a declared promise (catches ORPHAN payoffs — a beat that pays a debt nobody owed).

3. No registered arc class has zero edges (the vacuity guard — an empty audit table is a FAIL state, never

a green; that discipline is already written into the runbook).

4. Per-arc depth floor: touches ≥ 3, plus a terminal disposition (§2.4).

5. Reveal-ceiling invariant: no edge surfaces its arc earlier than its ceiling.

6. Arc-class registration completeness: every arc_class in the ledger is registered in the spec, and every

registered class has ≥1 gate assertion (this is what stops class-drift, §4.5).

7. Freshness: the ledger regenerates from the corpus (the check_seed_housing freshness pattern — "regenerating

it from the queue produces the file on disk"), so a new node with no ledger rows fails loudly.

Non-gating for the harvest, gating for the invariants. The gate blocks on structural violations

(orphan payoff, unregistered class, stale ledger). It does not block on UNPAID — UNPAID is the work

queue, reported like the 264 UNROUTED seeds are: "open work, not a failure."

2.3 The emotional-pacing curve — measured, not felt

Josh asks that arcs "hold depth" and "flow end to end." Flow is a shape, and the corpus already carries

the typed fields to compute it:

• fork magnitude (the ordinal 5M scale, firewalled)
• beat count + mode/gameplay_function mix per node
• boss axis split (Patterns/Puzzles/Preparation), phase count
• care_band, layer mix (L1/L1.5/L2/L3), path_bucket
• Chapter_Index intensity labels (RR_FINAL: "Ch 76 is the required STANDARD-intensity exhale … the

Epilogue is the valley") — intensity is already canon-typed

• integrity deltas, companionship magnitude, community-state writes
• per-arc: payoff density over span position

CORRECTION (M4) — do not overload intensity. That column is populated on all 79 rows

(standard 47 / peak 24 / valley 5 / relief 3) and is bound by check_chapter_topography.py R3 to

HL_0048. It is the DRAMATIC/COMBAT topography axis and it is spoken for. The realm program's own §1.4

resolution is the model to copy — it proved the three instruments (DEMAND, POWER, AWE) *must not be tuned

as one*, and the same separation applies here. So the emotional curve mints its own axes, keyed on

chapter_id, proposal-tier first (a T0_Emotional_Curve table, or a Chapter_Index column pack behind the

registry-extension re-baseline):

• stake_register — what stands to be lost: none · personal · communal · civilizational · cosmic
• relational_load — how much of the node's weight sits on a relationship: absent · present · carrying · pivotal
• affect_valence — the emotional direction: elation · warmth · neutral · ache · desolation
• payoff_density — how many earlier promises this node CASHES: 0 · 1-2 · 3-5 · 6+ — **derived,

computed directly from the ledger**, so it is measurement and not opinion

The ordering discipline that keeps this honest: **MEASURE across all 79 first, present the real

distribution, then let Josh rule the rules** — the order the slope teeth and the build-space sweeps both

followed, and the reason neither became a noisy gate. A curve rule written against an imagined

distribution is how a gate learns to conceal.

The precedent that makes this legitimate rather than invented: check_chapter_topography.py already

enforces mode variety and no-3-consecutive over the chapter axis, with a declared baseline. The emotional

curve is *the same tooth on a different column set*. And the P5 density-curve ruling already establishes

the register: the scorecard checks "at or above curve position, a shape, never a tuned absolute"

(ROADMAP_POST_5090 §P1/§P5, the tuning firewall). So the curve gate asserts shape properties only:

• every peak is preceded by a valley within N nodes (no unrelieved escalation)
• no ≥3 consecutive peaks of the same class
• each arc's payoff density rises toward its terminus (arcs land, not fizzle)
• no node is a valley on all axes simultaneously (the "nothing happens here" detector)
• the relationship-arc axis is non-empty in every 10-node window (the loneliness detector — the axis

Josh's amulet/friend/mother ruling makes load-bearing)

It never tunes a number. Josh and the image/feel critics own the ceiling; the gate owns the floor.

2.4 The depth rubric — what "holds depth" means, arithmetically

Josh's own amulet spine is the rubric. Reverse-engineered from what he authored, an arc holds depth when:

1. A concrete carrier — an object, a person, or a place holds it (the amulet; the friend; the mother).

2. A cost — someone pays (the mother's life; the friend's hurt; the guilt).

3. Setup before payoff — the promise is planted before it is spent (the amulet passes at the birth).

4. Behavioral consequence — it changes what the protagonist *does* (pulling inward, deflecting, running).

5. ≥3 touches across the span — it recurs, not mentioned once (birth → run-back → grudge → the gift).

6. A disposition — it ends somewhere (the amulet given away to the healer's child).

All six are computable from ledger columns. Arcs scoring 6/6 are DEEP; ≤3 are STUBS. **The gate grades

the arithmetic; the critic judges only the ceiling** (is it *moving*), which is exactly the right division

of labour and matches the house rule that gates measure floors and never judge quality.

2.5 The flow reports + the harvest routing

• docs/spine/arc_flow/ARC_<id>.md — per arc: the beats in span order, state, unpaid debts, depth score

with evidence, curve position. Generated from the ledger, so it never drifts from the data.

• The harvest routes into EXISTING lanes — no new lane is created:
• new quest/side-content seeds → the housing ledger (400 rows / 264 UNROUTED), typed at §7.5
• new weave links → T0_Cross_Cultural_Link_Graph (184 rows) — **the era-rhyme backfill is the named

zero-population target: 9 chains, currently 0 edges**

• entity candidates → Character_Index / Creature_Roster (the deity-route precedent applies)
• L3 connections → the L3 lane; civ marks → the civ-marks queue
• per-node re-flesh items → the re-cascade work-list (the prior pass's Tier 0-6 structure, refreshed)
• relationship + object arcs → the arc registries that do not exist yet — this is where the

BG3-lens gaps (#41 companion personal-quest arcs have no bucket/class/FK/row; #42 no

companion↔companion state; #43 the BOND partner track) and the uncreated T0_Persona_Index

(window rank 11) get their home. The instrument is the forcing function that closes them.

2.6 The single highest-leverage output: enrich.py gains an ARC PACK

Change enrich.py from "predecessor end-state" to "predecessor end-state **+ every open promise pointed at

this node + every promise this node makes + this node's arc-curve position.**"

This is the piece that makes the whole thing self-sustaining. Without it, the sweep is a periodic cleanup

and the factory keeps re-creating the gap at every new chapter. With it, **the whole-arc audit becomes a

per-node authoring input** — an author building CH_47 sees "CH_18 promised you a dragon; CH_12's trickster

chain wants its fourth rung; the amulet has not been touched in 9 nodes." That is the mechanism by which

"everything we've worked on makes it into the factory."

---

3. (c) WHEN IT RUNS

3.1 The cadence

3.2 Why "after the amulet integration," specifically

The amulet brief describes an 18-file integration plan touching the Prologue, CH_01, the healer's-child

thread, CHAR_0005 characterization, and an open Ch-13+ gift beat. Running the sweep *before* that lands

would produce a ledger that goes stale the moment it lands — the exact failure mode of the 2026-07-13 pass.

Running it *after* means the amulet chain is in the corpus as the sweep's first and best test case: if

the instrument cannot extract the amulet's promise→payoff chain and grade it 6/6 on the depth rubric, the

instrument is wrong and we find out immediately against a chain Josh authored himself and knows cold.

But do not wait for P1's deep-read harvest. Run it on the current v3 corpus. The harvest is exactly the

class of work the ledger must be able to absorb incrementally — if it can't, better to learn that now.

3.3 The trigger mechanism already exists

CASCADE_RUNBOOK §regeneration-triggers already specifies detection by **git diff from a tag to HEAD over

the chapter's load manifest**. Reuse it verbatim for arcs: each arc audit closes with tag

arc/<arc_id>-vNN; an arc needs re-audit when git diff <tag>..HEAD touches any node in its span. No new

mechanism, no calendar, no "every N chapters" guesswork — **change-driven, which is the only cadence that

stays honest as the factory's throughput varies.**

---

4. (d) HOW TODAY'S NEW CANON MULTIPLIES IT

Each 2026-07-27 ruling is not merely new content — it is a new edge class, i.e. a new surface the old

spine had no way to express. This is the strongest argument that the sweep must be run *now* and must be

*extensible*, not run once against a fixed taxonomy.

4.1 The amulet chain → the OBJECT-PROVENANCE arc class (zero instrumentation today)

Mother → child at the birth → the mother dies unprotected → the run-back → the guilt → the King's

never-resentment → the townspeople's grudge → … → the onward gift to the healer's child (open beat, Ch 13+)

→ and every later node where the amulet is worn, absent, remembered, or its protection tested. Also mints

two derived arcs with no home: a MORAL-DEBT arc (the guilt) and a COMMUNITY-GRUDGE arc (the

townspeople) — both of which need readers downstream or they are stubs by the §2.4 rubric.

The concrete connection QUESTIONS the amulet creates — this is the form the auditors consume, and

the arc has never had an object worn continuously for 76 nodes that carries a death and is then given

away, so every one of these is new surface:

• Prologue. Is the amulet given an authored visual/audio signature at the amended CHPRO_B07 strong

enough that a player recognises it 76 nodes later? An object that pays off at Ch 13+ must be *readable*

at the origin, and no such signature exists today because the object is new.

• The Ch-1 → Ch-2 seam. It crosses because it is worn (the Child-Familiar precedent). Does

CH01_B09 (the landing) or the Ch-2 continuity anchor SHOW that it survived the fall? Today: no built

reference. If the player loses sight of it at the fall, the Ch-13 gift arrives cold.

• THE Ch 2 → Ch 13 GAP — the load-bearing question. Where is the amulet seen or felt across eleven

nodes? Today: zero built beats reference it (positive-controlled by grep across the node set). The

candidate surfaces the sweep must GRADE, never assume: Ch 2 — the familiar is lost, and the object

that protected *her* did not protect *it*; a devastating adjacency that is already built and costs

nothing. Ch 3 — the first vril gesture: does a concealment ward interact with a child first

reaching for vril? Ch 8 — the hardest-gated and highest-value rung: HL_0095 forbids fairy-realm

script identification before the in-chapter reveal, so the amulet must be unreadable or uninscribed

until Ch 8 — and at Ch 8 it can become legible. That is a canon-ORDERED payoff that nobody has

claimed. Ch 10/11 — recognition-via-land (IR-5): do those who see what she truly is also see the

ward? Ch 13 — the join, and the gift's first candidate window.

• The guilt engine across 76 nodes. Two distinct jobs. (i) **Retro-deepening at zero authoring

cost**: find every existing line the new canon retroactively sharpens — Ch 13's own closing line,

*"She cannot yet say why the old red stone comforts her,"* is already written in exactly the register

the guilt engine needs. (ii) Where the guilt surfaces as beat: the Ch-38 journal transfer; the

Ch-57 elder recognition; the Ch-69 Architect's Final Negotiation — IR-4 gains a second and far

sharper reading, an offer to undo a death made to someone who has believed since infancy that a death

was theirs; and Ch-76, where the brief already rules RESTRAINT (the mother unspoken between two

people who both know).

• The reveal hazard, owned by the sweep. Ch 1's fall now has a proximate emotional cause for the

first time. The entry's existing sentence — *it is not a punishment and it is nothing the child did* —

is now doing double duty and must be preserved verbatim. Every proposed amulet or guilt beat carries a

reveal check against that line, plus HL_0099 (the King by title only; the mother inherits that

discipline by relation) and HL_0116 (nothing of the Grand Sage or the thesis).

• The ward's own scope, as an arc invariant. The ward conceals what does not act; it answers nothing

to area effects, collapsing terrain, or a foe that strikes ground rather than targets. It must never

enter the selectable bonus pools or the Phase-5M build-space sweeps would correctly grade an

ally-invulnerability option as meta-collapse. Both are ledger invariants, not prose notes.

• The gift's staging — OPEN, and this is the right instrument to close it. Three candidates, each

with an arc-flow consequence the sweep can actually weigh: Ch 13 on joining (natural, clear of

HL_0095 — but the player gives the object away before learning to fear for the person); **after the

first real scare** (strongest emotionally, chosen out of fear rather than housekeeping — but it opens

a window of unprotected chapters that needs an answer, which the ward-seam audit above can supply);

Ch 38 at the journal transfer (the canonical midpoint already stages an object passing between

these two). PRESENT all three with a recommendation; never decide it unilaterally.

4.2 The rescue / HOLD ON → LET GO death choice → the RELATIONSHIP-STAKE arc class

The healer's child as THE RESCUER (never the reviver) is a role-arc: it must be seeded early, escalate,

and pay. The downed-window mechanic makes every companion relationship a mechanically-expressed promise —

"this relationship has stakes" — which by the depth rubric requires setup, cost, and disposition per

companion. This is the axis the BG3-lens gaps (#41/#42/#43) already flagged as structurally unhoused.

Its concrete questions:

• Presence audit, Ch 13 → Ch 77 (~60 nodes). Per combat node: is the healer's child present? If yes,

does the node's encounter design honour the rescue lane? **If no, the node needs an authored reason AND

an alternate rescuer** — otherwise a core mechanic silently vanishes for a stretch of chapters and

reappears with no explanation. No 10-node window can see this; it is definitionally arc-scale.

• Ordering. The rescuer must be established BEFORE the first post-Ch-13 boss that can down the player.

Which node is that? Deterministically answerable from Layer 0.

• The ward's honest seam, per boss. Which built bosses would have killed her (area effects,

collapsing terrain, untargeted strikes)? An arc-scale consistency question against

T0_Boss_Encounter_Registry + the beat graph. The answer is either encounter-design notes or authored

near-loss beats — and the near-losses are exactly what makes the "after the first real scare"

gift-staging option playable.

• J-5's seeded encounter canon (examples-not-limits): some bosses/dungeons/paths REQUIRE rescuing

companions, separate the party, or force solo/reduced-party play. Which built nodes are the natural

homes, and are they distributed rather than clustered? A distribution question only the arc sees.

• Story-death consistency. Does any built node stage a story-death the let-go lane would contradict,

or that J-2's exception clause must explicitly cover? And do the Prologue's scripted death and the

runtime death-surface share a register (J-7: no name — a voice and a choice), or read as two games?

4.3 The compressed/tiered crossings → the SEAM arc class

78 seams typed T0-T3. "Flow end to end" is, quite literally and partly, the seam chain: does the world

hand off between nodes in a way that reads as one journey. Seams are now typed data, so the seam chain is

extractable and gradeable today — and check_spine_graph's [seam] ws-agreement tooth is already its

first assertion. This class is nearly free to add and directly answers Josh's "flow end to end."

Its concrete questions: the Realm-Road door-ladder is ranked #3 in the 07-14 web ("the single

largest L3-made-literal" — ~18 ancient threshold tastes escalating into the nine otherworlds) and has

been unbuildable because it had no playable ground. Fork C just gave it ground. Which of the 78 seams

are the ladder's rungs? Which should carry era-rhyme rungs and which stay clean traversal (a seam that

carries everything carries nothing)? And, free at Layer 0: do the 78 typed seams AGREE with the

## Seam state-diffs blocks already authored in every node?

4.3b The five trade pins + Fork A (same-day, cheap, and already measurable)

• Five trade pins landed 2026-07-27 (TRADE_01+02 → Ch_59, TRADE_06 → Ch_60, TRADE_05+08 → Ch_61, with

reciprocal Chapter_Index cells; the §3.11 deferred-pins gate closed). Arc question: do the ancient

home bases of those trades carry a forward reference to their modern pins, and do Ch 59-61 name their

ancient sources? Note M2: CH_59→CH_65 is one of the 14 unreciprocated pairs. The pins closed a

two-hop data dead end for six trades; the sweep checks whether NARRATIVE reciprocity followed DATA

reciprocity — they are not the same thing and this is the cleanest available test case for that claim.

• Fork A — continuity-by-default, cut earned (schema-keyed cut classes, binding on CN5.2). Arc

question: does any built callback assume a hard cut to land? A flashback-shaped callback is now

schema-illegal unless its beat class is on the §3.2 list. One grep-plus-judgement pass, run once, then

encoded as a ledger invariant so it never has to be re-derived.

4.4 The other multipliers

• Natural-voice doctrine → voice consistency is an arc property: a recurring person's register must

hold across appearances, per-culture. A per-entity voice-continuity auditor (class J).

• The Rune Forge / build-space / ally stat builds → the player's proficiency line is an arc with

setup/escalation/payoff; the build-space sweeps already measure viability breadth — the arc instrument

measures whether the *narrative* of a build arrives.

• The presentation ladder → mastery-tier VFX variants are an escalation curve; they belong on the

pacing axis.

4.5 The extensibility rule this forces (the design's most important single line)

arc_class is an open enum with a registration rule: a ruling that mints an arc class is not "done"

until (i) the class is registered in the arc spec, (ii) its edges are extractable by Layer 0, and (iii) at

least one gate assertion arms for it. This is the anti-orphan doctrine applied to arcs — and it is what

makes the instrument survive Josh's next authoring session instead of being obsoleted by it.

---

5. (e) THE RR BOUNDARY — defined by AXIS, not by scope size

5.1 The two instruments, cleanly separated

Why the arc instrument must be non-gating: a gating whole-arc pass deadlocks the factory — every

chapter would block on a 79-node audit. Its teeth live in the *gate* (structural invariants, which are

cheap and continuous), not in the *sweep*.

5.2 The overlap to kill, and the evidence it is real

RR component 5 ("final range consistency") and RR Grid 3 (canon-fidelity, thread & continuity) currently

reach for cross-arc facts a 10-node window cannot see. The proof: RR_FINAL Grid 3 caught, at the very

last window, that "Thread 4 Flood Memory [was] dropped from the Ch 72-75 tracking" — a Major thread with a

tracking hole that seven earlier RRs could not see because it was never a within-window fact. That is

exactly the class of miss the arc instrument exists to catch, and exactly the class of work RRs should

stop attempting.

The rule:

• RR stops at the window boundary and delegates every cross-window claim to the ledger. Its Grid-3

continuity check becomes a lookup, not a re-derivation: "every ledger edge that crosses this window's

boundary is present on the window's face." Cheap, complete, and non-duplicative.

• The arc instrument stops at the arc and delegates every within-node correctness claim to the RR and

the normalize-doc critic. It never re-audits prose quality, care, or naming inside a node.

• Both get materially cheaper, and neither can produce a finding the other should have owned.

5.2b THE HANDOFF CONTRACT — what the RR HANDS the whole-arc pass, and back

A boundary is not defined until the interface is. Both directions are cheap and both are typed.

RR → arc instrument: a ## Carry block appended to every Range-Review report. Four lists:

1. OUTBOUND DEBT — every anchor the window PLANTED whose payoff lies outside it: the source

beat/fork, the state key or mark written, and the intended target node or explicitly UNCLAIMED.

This is the authored twin of the forward_track cell — and UNCLAIMED is precisely the value M1

proved the machine layer cannot currently express, so the human layer must.

2. INBOUND CREDIT — every payoff the window CASHED, and which window planted it.

3. NAMES FINALIZED — every name the window's Layer-3 naming pass SET. The arc instrument may never

propose a name for anything on this list. (Two instruments naming the same NPC is exactly how a

deprecated placeholder gets re-propagated, which is the failure the zero-deferral naming gate exists

to stop.)

4. CROSS-WINDOW FLAGS — findings the window saw the edge of and could not adjudicate.

The arc instrument consumes the union of all carry blocks as its first input, so it never re-derives

what the RRs already know. That is what makes the two compose rather than overlap.

Arc instrument → RR: a per-window SEEDING LIST. The promises that window must PLANT for a later

payoff to land, and the payoffs it must CASH — emitted straight from the ledger, so the RR authors into a

known arc and then audits the authored result. This closes the loop in both directions.

Retrofit, since all eight RRs are closed. Lists (1) and (2) are largely recoverable deterministically

— Layer 0 already extracts forward_track, Seam state-diffs, and End-state carry-forward. The reports

are short (42-343 lines; 894 total across nine files), so ONE agent can author all eight carry blocks from

the reports plus the extracted data in a single pass. **Do this in the first run: it is the cheapest

single input the instrument will ever get, and it makes the F2 staleness visible per-window instead of

per-corpus.**

5.2c Retire the three overlapping whole-arc documents (a precondition, not a nicety)

Three current-truth whole-arc claims live side by side today: WHOLE_ARC_CONNECTIONS_PASS.md (07-13,

390 ln), WHOLE_ARC_CONNECTIVE_WEB.md (07-14, 201 ln — which already carries inline *"the 07-13 doc is

stale on this item; do not re-surface"* reconciliation notes), and docs/spine/WHOLE_ARC_REVIEW.md (the

4-grid capstone). That is START_HERE rule 1 violated in the open — *a superseded truth kept next to its

replacement is the #1 hallucination vector for the next session* — and rule 3 (supersession is a

first-class edit) prescribes the fix exactly.

So the instrument's first ACT is not a fourth document. Their surviving findings are re-verified

against v3 and IMPORTED AS LEDGER ROWS (recovering the prior investment — see build-order item 3), and

the three files are then moved to docs/archive/ with SUPERSEDED BY markers and every cross-reference

updated in the same commit. Producing a fourth prose master beside them would repeat, for the fourth

time, the exact failure this instrument exists to end.

5.3 The sequencing recommendation (and why it inverts the historical order)

Given F2 — all nine RR reports predate v3 and RR_FINAL still describes the pre-renumber endgame — the

instinct to "re-run the eight RRs first" is wrong:

**Do NOT re-run 8 Range Reviews. Run the arc instrument on the v3 corpus first, and let its ledger tell

you which windows need a targeted RR refresh.**

Reasoning: RRs were the *only* cross-node instrument when they were built, so they were correctly the

first pass. Now they should be the second. The arc sweep is one audit over 79 nodes producing durable

data; re-running 8 RRs is eight audits over 79 nodes producing eight stale-in-a-week reports at roughly

1.26M tokens each (~10M total) with no data artifact. The arc sweep costs less, produces the durable thing,

and *scopes* the RR refresh instead of guessing at it. Strongest objection: RRs also carry L1-completeness,

L3-naming-finalization, and L2-transition components that the arc instrument does not replace — true, and

that is exactly why the targeted refresh still happens, just scoped by evidence rather than by calendar.

---

6. Risks, and the mitigations that are already house doctrine

---

7. The recommended build order (smallest first, each independently valuable)

0. The one-line [mark] regex fix (M1) — [^\]]+ → [^\]]*, with an empty target list routed as

UNCLAIMED (an open ledger row, not a hard FAIL) plus a must-fire fixture proving the gate goes red on

a mutated case. 64 invisible marks across 17 nodes become visible for the cost of one character.

Highest value-per-effort item in the entire design; do it before anything else.

1. harness/extract_connections.py + the ledger schema — zero-token, immediately produces the

UNPAID/ORPHAN/THIN arithmetic over the live corpus. Standalone value on day one. Ship it with the M2

reciprocity check and the M3 three-way beat_consumed / runtime_consumed / unconsumed ws split.

2. harness/check_arc_flow.py as a PASS-on-empty, loudly-declared, self-testing gate → suite 29→30.

3. Import the 2026-07-13 pass's 65 chains as ledger rows, re-verified against v3 — recovers the prior

investment instead of discarding it, and immediately populates classes C/D/H.

4. enrich.py arc pack — the factory stops re-creating the gap (§2.6). Highest leverage per line of code.

5. Register the new arc classes from the 2026-07-27 rulings (object-provenance, relationship-stake,

seam) and extract their edges.

6. Sweep #1 — Layers 1-3, after the amulet integration lands, against the v3 corpus.

7. The pacing-curve assertions on the topography-gate pattern, once the ledger has enough edges to

make the shape real.

8. RR refresh, scoped by the ledger — not eight blanket re-runs. Retrofit the eight ## Carry blocks

first (§5.2b): one agent, cheapest input the instrument gets.

9. Retire the three overlapping whole-arc documents to docs/archive/ with SUPERSEDED BY markers

once their findings are ledger rows (§5.2c) — the supersession is part of the landing, not cleanup.

Items 0-5 are deterministic or small and need no sweep budget at all. **Item 0 alone converts the

strongest measured finding in this analysis into a permanently-armed tooth for one character of code.**

Item 6 is the only large spend, and by then the instrument has already proven itself on free data.

---

8. The three items that go to Josh as briefs (never bare questions)

1. The pacing-curve rule-set. Ratify the four axes (§2.3) and their shape rules before

check_arc_flow's curve assertions arm. *Recommendation:* measure across all 79 first, present the

real distribution, then rule — the order the slope teeth and the build-space sweeps both followed.

*Strongest objection:* that is one milestone slower than ruling up front — accepted, because rules

written against an imagined distribution are how a gate becomes noisy, and a noisy gate CONCEALS.

2. The amulet gift's staging beat (Ch 13 join / after the first real scare / Ch 38 transfer) — left

explicitly OPEN by the 07-27 ruling. The arc instrument is the correct instrument to answer it because

the choice is an arc-flow judgement; it should PRESENT all three with the consequence of each and a

recommendation.

3. Auto-routing authority. May the harvest auto-route creative_within_vision rows into the apply

queue without per-row sign-off? *Recommendation:* yes — the ratified §10 autonomy contract plus the

elevated-autonomy ruling already cover it, and the guardrails (fresh-context critic + the full gate

suite + reveal/care re-verify) are the same ones every cascade node passes. Cardinal rows still

surface. *Strongest objection:* a connections harvest touches more nodes at once than any cascade node

did, so a bad row propagates wider — mitigated by the proposal-tier firewall and by application being

per-node and separately gated.

---

Provenance

Files read this session: docs/proposals/WHOLE_ARC_CONNECTIONS_PASS.md (full), WHOLE_ARC_CONNECTIVE_WEB_INVENTORY.md

(head), docs/proposals/SIGNIFICANCE_LENSES.md (§0-2F), docs/START_HERE.md (1-121),

docs/CASCADE_RUNBOOK.md (RR sections), docs/spine/range_reviews/RR_FINAL.md + RR_72.md,

docs/DESIGN_GAP_REGISTER.md (top-10 + v1.1 entries 41-45), docs/ROADMAP_POST_5090_TO_SHIP.md

(§P1/§P5), docs/proposals/AMULET_PROVENANCE_BRIEF.md (§1), harness/gates_config.json,

harness/check_spine_graph.py (docstring + cross_file_checks), harness/enrich.py

(continuity_anchor), harness/check_seed_housing.py, harness/check_weave_lifecycle.py,

scorecards (seed_housing, layer_register, weave_lifecycle), docs/spine/CH_40.md (structure),

docs/spine/CH_41.md (mark_write grammar), registry row counts, and git log dates.

**Verification pass (§0.5, §2.3 correction, §4.1/4.2/4.3b questions, §5.2b/5.2c), same day, added

after independent re-derivation:** harness/check_spine_graph.py cross_file_checks() read in full

(lines 540-655) + gates_config.json spine_graph target list (corpus mode CONFIRMED firing);

MARK_FT_RE behaviour on empty vs populated cells verified by direct execution; forward_track census,

reciprocity census, and the ws.* in/out census computed over all 79 nodes; T0_Chapter_Index column

list + intensity distribution read from the live CSV; docs/CASCADE_RUNBOOK.md §7 standing RR

components + docs/TRANSITION_TREATMENT.md Layers 1-3 (the RR interface); docs/spine/CH_13.md in full

and CH_75/CH_PROLOGUE heading maps (the v3.1 connection-surface shape);

docs/spine/DECISIONS_PENDING_JOSH.md the three 07-27 ruling blocks verbatim;

docs/proposals/AMULET_PROVENANCE_BRIEF.md §§1-7; docs/proposals/WHOLE_ARC_CONNECTIVE_WEB.md in full;

docs/proposals/QUEST_SEED_HOUSING_LEDGER.md head; docs/proposals/REALM_DESIGN_PROGRAM.md §1.4;

docs/spine/WHOLE_ARC_REVIEW.md; docs/spine/range_reviews/RR_22.md.

One claim CORRECTED during verification and recorded rather than quietly dropped: an initial reading

concluded the arc weave was *entirely* machine-unguarded (check_spine_graph.py shows no glob and

parses per-file). That was an absence claim reached without reading the corpus-mode branch — the same

a-search-that-cannot-match-reports-zero class this document warns about. The corpus mode is real and

active; the accurate finding is narrower, sharper, and stronger: **the tooth exists and 64 marks fall

through a hole in it.**

Docs-only analysis; no repo file was modified.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root