supernatural/LENS_hades-death-run-realm-identity_DRAFT.md
Lens id: hades-death-run-realm-identity
Title set: Hades (Supergiant, 2020) + Returnal (Housemarque, 2021)
Matrix cells claimed: #13 "Defeat axis + retry latency (the Hades economy)"; #14a share (otherworld-as-distinct-ruleset, realm-biome identity half)
Scope (pre-registered handoffs — NOT audited here):
LENS_sm64-movement-camera-onboarding_DRAFT.md, finding SM64-9, which explicitly scopes itself to "not the run economy, but the per-attempt latency of an authored execution surface" and recommends RecordRetryLatency). This audit does not re-land RecordRetryLatency. My half is the RUN ECONOMY: what a defeat *costs and pays*, what the next attempt *starts from*, and how the loop *structures repeat play*.presentation-craft-anim-audio (R-A16). I audit realm gameplay-grammar identity only.Method note. Every finding cites file + line/section. Zeros are positive-controlled (a term known to exist,
run through the same tool over the same corpus). DESIGNED-UNBUILT is never reported as MISSING.
---
1. Defeat is a transaction, not a punishment. Hades pays out on every death in a *typed*, machine-known
currency (Darkness/Keys/Gems/Nectar), and the payout is legible *at the moment of death* on the
death screen. Returnal's equivalent is knowledge + permanent unlock ledger entries.
2. The run is the unit of content. Length, escalation curve, bail-out and re-entry are *designed*
properties of a run, not emergent from level layout.
3. Biome identity is a RULESET, not a skin. Tartarus/Asphodel/Elysium/Styx each change enemy grammar,
hazard class, room vocabulary and reward mix — the same weapon plays differently per biome.
4. The gift loop makes relationship a BUILD component. Nectar → Keepsake → an *equippable* stat/behavior
modifier. Affection is not a number in a menu; it is a slot you fight with.
5. The between-run hub carries the narrative. Hades' story is delivered almost entirely in the hub,
paced by run count, with a guaranteed-new-line budget so returning is never dead air.
6. Time-to-next-attempt is the generosity dial. Hades is ~15 s from death to next run start, and the
run is *re-entered*, not resumed.
---
_(every block carries: lesson · cited current state · positive control · self-refutation ·
verdict class · owner/wave/priority · reuse-first recommendation)_
---
---
Class: DESIGNED-UNBUILT · Priority: HIGH (slice) · Owner: P1 (engine) + schema-data ·
Workable tag: WIRE-SMALL (one write call at an existing funnel)
What the title set proves. Hades' death payout is a *transaction in a typed currency* the game
can read back: Darkness, Keys, Gems, Nectar are quantities banked at the moment of death, and every
subsequent run reads them. The payout being machine-known is what lets the game *escalate* it, gate
on it, and prove it happened.
Current state (cited). Our equivalent is designed and rowed. WS_041 composure_node_mastery is
"a per-boss/per-mode object of Composure sub-nodes the player has mastered across attempts (a banked
knowledge/skill credit)" and WS_042 banked_tell_reads is "the death-as-knowledge economy, never an
XP handout", both listing death_learning_resolver as a consumer
[registries/T0_Worldstate_Variables [ACTIVE v0.1]/Sheet1.csv rows 42-43]. Both tags are GENERATED
into the engine: UE_DECLARE_GAMEPLAY_TAG_EXTERN(WS_composure_node_mastery) /
(WS_banked_tell_reads) [Source/Humanity/Public/Quest/GeneratedWorldstateSchema.h L58-59], defined
[.cpp L50-51], registered as EWsKind::Object [.cpp L117-118] and name-mapped [.cpp L168-169].
And nothing writes them. The shipped death path captures the boss row's death_reward string,
logs it to telemetry as player_death_consolation, and arms a HUD banner
[Source/Humanity/Private/Core/HumanityCharacter.cpp L281-320, HandlePlayerDeath] — no worldstate
write of any kind.
Positive control. banked_tell_reads|composure_node_mastery over
C:\dev\Humanity\Humanity\Source returns 8 occurrences across exactly 2 files —
GeneratedWorldstateSchema.h (2) and GeneratedWorldstateSchema.cpp (6) — i.e. declaration,
definition, kind-registration and name-map, and nothing else in the entire codebase. Reachability
control on the same corpus and tool: WS_integrity_score|integrity_score returns 44 hits across 9
files, five of them in QuestSubsystem.cpp — worldstate keys ARE written in this codebase, so the
zero is real, not a search artifact. death_learning_resolver over the canon repo returns 6 hits in 4 files
(T0_Worldstate_Variables, BUILD_PLAN_END_TO_END, T99_Translation_Combat,
DECISIONS_PENDING_JOSH) — a named resolver that exists only in prose.
Self-refutation attempted. *"The greybox is early; a string is a legitimate placeholder."* —
Partly, and that is why this is DESIGNED-UNBUILT, not MISSING. But the placeholder chose the WRONG
half: the display is built and the ledger is not, which is the inverse of the cheap order. The write
is one call at a funnel that already fires, on tags that already exist, keyed on a column
(composure_nodes) that is already populated on the slice boss
(BE_0002 composure_nodes = direct=lunge_feint_dodge__cornered_frenzy_punish;stealth=stalk_tell_break;environmental=torch_vent_expose).
Reuse-first recommendation. At HandlePlayerDeath, write banked_tell_reads through the
existing UWorldStateSubsystem, keyed boss_id → the composure-node ids already on the BE row.
Zero new schema, zero new registry, one call site. This is the load-bearing half of the Hades
economy and it is currently the cheapest unbuilt thing in the defeat axis.
---
Class: WEAKER · Priority: HIGH (slice) · Owner: P1 (engine) + spec-doc ·
Workable tag: DATA + SMALL-WIRE
What the title set proves. Hades never says the same thing twice at the same moment. The payout
*quantity* scales and the payout *voice* is a rotating, run-count-aware line budget — the reason
death #40 still lands. Returnal does the same with its ledger entries. Repetition is the failure
mode the genre solved on purpose.
Current state (cited). ResolveActiveFightConsolation() finds the live boss and returns
Boss->GetPlayerDeathConsolationLine() — the boss row's single death_reward string — with no
attempt index, no rotation, no dedupe
[Source/Humanity/Private/Core/HumanityCharacter.cpp L237-267]. The data confirms one line per boss:
T0_Boss_Encounter_Registry is 281 rows, death_reward populated 281/281, 264 distinct strings
— i.e. one authored line per encounter, e.g. BE_0002 *"logs his stalk cadence for the retry; unlocks
a polo-corruption lore fragment"*. The ruled brief already knows the missing piece and lists it as
mint item 15: "consolation-paid-once ledger | durable ws.* per encounter instance | new row"
[docs/pipeline_review/FORKB_RESURRECTION_BRIEF_2026-07-27.md L525], and calls the death surface
"a hard floor item on the most-repeated surface in the game" [ibid. L384].
Positive control. consolation|repeat|once per over the FORKB brief returns 9 hits across §2,
§4, §5.4 and §6 — the brief's own vocabulary is reachable; the *implementation* of the paid-once rule
is what is absent, and its absence is visible directly in the code above.
Self-refutation attempted. (a) *"264 unique strings is already a lot of variety."* — Variety
ACROSS bosses, none WITHIN a boss, and the retry loop is intra-boss by definition. (b) *"This is a
natural-voice-pass problem, not a systems problem."* — The natural-voice pass is already scheduled to
rewrite this column (mint item 16, "the death_reward column rewrite"), which is exactly why the
*shape* must be decided before the rewrite: rewriting 281 single strings bakes the defect in for a
second time at full authoring cost.
Reuse-first recommendation. Ride the already-ruled WS_044 defeat ledger (whose row shape
already carries {event_id, encounter_ref, outcome, …} [FORKB L518]) for an attempt_index, and let
death_reward become a small ordered set — first death teaches the tell, third names the counter,
later ones stay short. The column, the ledger and the authoring pass all already exist; only the
cardinality of one field changes. Do this BEFORE the natural-voice pass touches the column.
---
Class: MISSING (design invariant) · Priority: HIGH · Owner: spec-doc + P2 ·
Workable tag: ONE INVARIANT ON AN EXISTING GATE
What the title set proves. Both teachers guarantee the next attempt is never strictly harder than
the one you just lost. Hades resets the run; Returnal's difficulty escalation is *player-elected*
(Heat / opt-in modifiers), never a consequence of failing. That guarantee is what makes a punishing
game generous, and it is a stated invariant, not an emergent property.
Current state (cited). Our doctrine deliberately goes the other way: "On death: write a
graduated persistence delta to ws.* (front strength, boss array) + respawn at checkpoint **with
the world ADVANCED, never reset**; no progression flag hard-gated on a kill. Guarded by
check_no_dead_end.py" [docs/PRE_5090_BUILD_PLAN.md L1780, item P2.14]. The doctrine is echoed in
the shipped code as a comment — "the player returns, but BOSS state PERSISTS across the respawn — the
boss is not reset (its Composure damage / defeat state / withdrawal all stand)"
[HumanityCharacter.cpp L349-352] — where it currently runs in the player's FAVOUR. The world-side
delta is specified and unbuilt: "the world-advance delta on death (VOL2 SL-1 — specified and unbuilt;
nothing is written to world state on death today)" [FORKB L476, item A5]. **Nowhere in the corpus
is there a clamp on the delta.**
Positive control. never harder|monotonic|ratchet|death spiral|compound|unwinnable|softlock over
docs/ returns 30+ hits — monotonic in ENGINE_OPTIMIZATION_DOCTRINE B7, ROADMAP_POST_5090 L516
("otherwise the monotonicity tooth fires a false regression"), FUN_REBUILD_PLAN R2.3 ("monotonic
de-escalation") and CASCADE_RUNBOOK L247 — so the vocabulary is live and reachable in this corpus.
Zero of those hits is a bound on the death delta.
Self-refutation attempted. (a) *"check_no_dead_end.py already guards it."* — It guards
PROGRESSION reachability (no dead end), which is a different property from DEMAND monotonicity. A
world that advances until the fight is unwinnable is still fully reachable and still fails the
player. (b) *"Graduated persistence is Josh's ruled doctrine; bounding it is re-litigation."* — Not
proposed. The doctrine says the world advances; it says nothing about the failed encounter's demand,
and a bound on demand leaves the world-advance narrative fully intact. (c) *devil's advocate against
timidity*: is this a timid ask on an R-17 bar? No — the ask is not "make death cheaper", it is "make
the cost AUTHORED instead of accumulating". Sundered and The Forgotten One stay as hard as ruled.
Reuse-first recommendation. State the invariant on the existing Gate 9 check_no_dead_end.py
(which P2.14 already names as its guard): *the per-encounter demand after N failed attempts is
non-increasing; the graduated delta is authored on the WORLD (a front advances elsewhere, a
negotiation worsens), never on the encounter you just failed.* This is the exact framing the Sigma
Constraint already uses for randomness ("−1σ floor = no streaks; +1σ ceiling = no droughts"
[COMBAT_ENCOUNTER_SYSTEM L230]) — bounded-persistence is its sibling, and the doctrine already owns
the idiom.
---
Class: WEAKER · Priority: MEDIUM-HIGH · Owner: spec-doc · Workable tag: SPEC-SMALL
What the title set proves. In Hades, God Mode is a *defeat-axis* setting (a cumulative damage
resistance that grows per death) — the difficulty dial and the failure economy are the same design
object. Returnal's assist layer is likewise expressed in defeat terms. Difficulty that says nothing
about losing is only half a difficulty system.
Current state (cited). docs/proposals/DIFFICULTY_SYSTEM.md is RULED and CLOSED ("Josh,
2026-07-04 — *I love these difficulty names; they are perfect*", L95-99) and defines four tiers plus
a prestige tier entirely in terms of vril density, answer-pruning and reach. Positive-controlled term
counts over the whole 111-line doc: vril 15, strand 1 — and defeat 0, death 0,
fail 0, respawn 0, checkpoint 0, retry 0, soft catch 0. The soft catch
exists in exactly two places in the entire repo, both prose: "on Wellspring/Veiled a soft catch (*no
trial can strand you*). On Sundered/Forgotten One the payout is knowledge only — the door stays hard"
[docs/COMBAT_ENCOUNTER_SYSTEM.md L220] and its restatement [docs/translation/T99_Translation_Combat.md
L161]. No mechanic, no magnitude, no data home.
Positive control. soft catch|soft-catch over the whole canon repo = **2 hits, both quoted
above.** Control on the same tool/corpus: Hades = 608 hits across 168 files. The search can match.
Self-refutation attempted. *"Numbers are firewalled to Phase-5M, so this is correctly deferred."*
— Magnitudes are firewalled; SHAPES are not. Phase-5M cannot tune a mechanic that has never been
named, and the difficulty doc is the RULED home where the shape belongs. The Accessibility section of
that same doc proves the doc is the right home: it already carries a non-numeric shape statement
("Attunements … tune how the world's demand reaches you … never how thick the air is, and gate no
content", L84-91).
Reuse-first recommendation. Add one defeat paragraph to DIFFICULTY_SYSTEM.md, structured as the
tiers already are: Wellspring/Veiled name the soft catch as a concrete affordance in the same
vril-reach voice ("home has not let go of you" is already the fiction for it); Fading is the authored
baseline; Sundered/Forgotten One = knowledge-only, door stays hard. This gives HD-1's payout and
HD-3's bound their tier axis, and gives Phase-5M a magnitude slot that currently does not exist.
---
Class: DESIGNED-UNBUILT · Priority: MEDIUM-HIGH (slice) · Owner: P1 (UI) + spec-doc ·
Workable tag: SPEC-TINY, then UI
What the title set proves. The Hades death screen is a designed, permanent, player-facing
artifact — a legible statement of what the run earned. It is not a debug affordance that a shipping
build strips.
Current state (cited). The consolation renders as
FString::Printf(TEXT("DEFEATED (no fail wall) -- %s"), *Consolation) in
Source/Humanity/Private/UI/HumanityDebugHUD.cpp L593-602. The real player HUD widget has no death
surface at all: Downed|Revive|Rescue|Death|death over
Source/Humanity/Private/UI/HumanityPlayerHUDWidget.cpp returns one hit, L476, which is a
boss-stage caption ("Cut what binds them.") — not a death surface. Standing doctrine says the debug
overlay never survives: the debug HUD's kit "never survives into the real UI"
[memory no-mode-taxonomy-on-player-surfaces]. The FORKB brief already names the owning doc as
having no content yet: "T1_UI_UX_Spec (its first real content)" [FORKB L534].
Positive control. The same grep pattern over HumanityDebugHUD.cpp returns the consolation block
— the pattern matches death surfaces where they exist.
Self-refutation attempted. *"Death presentation is explicitly 5090-gated."* — The ART is
(TODO_CANON L225-227, cited at FORKB L501 as C1). The INFORMATION ARCHITECTURE is not: what the
screen states, in what order, and whether it names the boss (which the brief already litigates at
R3, L428) is a spec question answerable today at zero GPU cost, and answering it is what stops the
5090 art wave from illustrating a layout nobody designed.
Reuse-first recommendation. Make the defeat surface the first authored section of the already-named
T1_UI_UX_Spec. No new doc, no new lane; the brief already assigns the doc.
---
Class: DESIGNED-UNBUILT (scheduled) · Priority: HIGH · Owner: P2 / W-SPACE ·
Workable tag: ONE UNTESTED PROPERTY on a scheduled wave
What the title set proves. Where a run restarts is a design decision with a stated rule. Hades
always returns you to the House; Returnal always to the ship. Neither ever computes "the closest
thing to your corpse", because proximity is not intent.
Current state (cited). RespawnAtNearestSite() iterates every AHumanitySiteMarker in the world
and picks the minimum DistSquared, falling back to the spawn point
[HumanityCharacter.cpp L322-341]. There is no checkpoint concept: re-verified this run,
[Cc]heckpoint over C:\dev\Humanity\Humanity\Source = 1 hit, in
Public/Combat/HumanityWorldDemandAttributeSet.h — matching the brief's own finding, "`grep
Checkpoint` over Source → 0 hits; there is no checkpoint to revive at" [FORKB L472, item A1]. It
IS scheduled: PG-5 "recharge-well-as-checkpoint actor + autosave" is BUILD-NOW
[docs/PRE_5090_BUILD_PLAN_VOL2.md L863], as are P2.7 and P2.14. The data home exists already —
T0_Vril_Site_Registry carries 42 rows with site_class / vril_function /
mastery_tier_required, and the vril site is the ruled save + recharge + loadout sanctum.
Positive control. Respawn|SiteMarker|DeathFade over the same Source tree = 60 hits across 12
files. The corpus is searchable; Checkpoint really is a single incidental hit.
Self-refutation attempted. *"SM64-9 and the FORKB brief already own this; it is a duplicate."* —
The *build item* is theirs and I do not re-propose it. What neither states is the **directional
hazard**: nearest-by-distance is not merely imprecise, it is capable of advancing the player past a
failed gate (a marker on the far side of the arena is nearer than the one you entered from), which
silently converts a defeat into a skip and corrupts the graduated-persistence read in HD-3. That is a
distinct property and it is the one the QA tooth must assert.
Reuse-first recommendation. No new work item: adopt A1 as written (vril site as the anchor), and
carry the brief's own already-drafted tooth as the acceptance criterion — "checkpoint return lands at
the anchor, not nearest-marker-by-distance (a nearer marker must NOT win)" [FORKB L541]. Add
one clause: the anchor is the LAST-TOUCHED site (ws.last_vril_site_touched, mint item 2, already
specified), never a recomputed nearest.
---
Class: MISSING (design) · Priority: MEDIUM · Owner: spec-doc / canon-author ·
Workable tag: ONE FIELD-LEVEL CLAUSE on an already-minted ledger
What the title set proves. In a run-based defeat economy the *return path* is a permanent
fixture. If the return is diegetic and personal, its owner must be permanent, or the design must say
what happens when the owner is gone.
Current state (cited). J-3 rules the healer's child is "THE RESCUER: the one who brings you
back to the revival location / checkpoint / recharge (save) zone. The let-go/timeout path becomes
diegetic and HERS" [docs/spine/DECISIONS_PENDING_JOSH.md L478-480]. The slice CLOSES on her joining
(Prologue→Ch 13, "the slice closes at Ch 13 with the healer's child joining + the departure"
[project CLAUDE.md, model-seats block]). And her departure is an open canon decision fifty-two
chapters later: D-23, "the healer's-child (CHAR_0002) Departure/Continuation Decision at the Ch-65
path-lock threshold" [DECISIONS L1727]. So the diegetic owner of the most-repeated system in the game
can exit the party, and no doc says whether the mechanic degrades, transfers, or silently becomes
impersonal.
Positive control. Downed|Revive|Rescuer|Rescue over the game Source = 42 hits across 5 files,
none of them a rescuer/reviver actor (they are HumanityEncounterVolume + W9 state tests) — the
runtime side is unbuilt as expected, which is why this is a canon clause, not a code fix.
Self-refutation attempted. *"Post-slice, therefore defer."* — The AUTHORING is post-slice; the
one-line rule is not, because the slice's final beat is the moment she joins, and the natural-voice
pass is about to write her rescue strings. Writing a personal system with an undeclared succession
rule is the cheapest possible future rewrite to avoid.
Reuse-first recommendation. One clause on the already-minted defeat ledger: reviver_ref is
already a field on the ruled WS_044 row [FORKB L518], and the outcome enum already contains
checkpoint_return alongside ally_revive / ally_revive_unavailable. Declare the fallback chain
(named rescuer → any present companion → familiar → the site itself resolving as
checkpoint_return). Zero new schema; it is a domain statement on fields that exist.
---
Class: DESIGNED-UNBUILT · Priority: MEDIUM-HIGH · Owner: QA loop ·
Workable tag: ENROLL AN ALREADY-DESIGNED LEDGER
What the title set proves. The genre's balance work is done on run telemetry: attempts-per-boss,
payout-per-attempt, the distribution of outcomes. Without it, the comeback economy is argued rather
than measured — and the JOSH GATE means the AI QA loop is our only player.
Boundary declaration (binding). SM64-9 already claims RecordRetryLatency — "t from defeat/fail
state to next player-controlled frame" — as a diagnostic on the QS-13..18 family, scoped to
per-attempt EXECUTION-surface latency [LENS_sm64-movement-camera-onboarding_DRAFT.md, SM64-9,
Declared-overlap block]. This finding does not re-land that field and does not touch latency. It
claims the orthogonal axis: what the defeat PAID and whether the world MOVED.
Current state (cited). The instrumented feel family is `RecordAttackPhase / PlayerAnswer /
InputLatency / HitStop / Stagger / CameraSample` (QS-13..18, BUILD-NOW)
[docs/proposals/QA_WATCHING_PROGRAM.md L362, hooks enumerated L110-113]. Nothing in it is a defeat
outcome. The only thing a death emits today is a single free-text telemetry event,
Telemetry->RecordQuestEvent(TEXT("player_death_consolation"), PendingDeathConsolation)
[HumanityCharacter.cpp L295-298] — a string, un-typed, with no outcome class, no encounter ref and
no payout field. The soak lane has no coverage either: "grep death run_soak.py → 1 unrelated hit.
Player death has ZERO coverage today — all 55 UE automation tests assert BOSS defeat"
[FORKB L478, item A7].
Positive control. Record[A-Z] over QA_WATCHING_PROGRAM.md returns the six-name family plus
QS-19 — the naming convention is reachable and the absence of a defeat-outcome record is real.
Self-refutation attempted. *"The QA program's own rule is that new fields enter as diagnostics,
so this is premature."* — Agreed, and that is exactly the ask: enter as a diagnostic. The stronger
point is that the FIELD SHAPE IS ALREADY DESIGNED — WS_044 carries `{event_id, chapter_ref,
site_ref, encounter_ref, outcome, reviver_ref, capability_ref, vril_paid_ref, wait_duration_ref,
combat_end_provenance, world_delta_ref, relationship_delta_ref}` [FORKB L518]. This is enrolment, not
invention.
Reuse-first recommendation. Enrol the ruled WS_044 defeat ledger as a telemetry-visible surface
alongside QS-13..18, and assert two properties the loop can check without any magnitudes: **(1) no
attempt paid nothing (every ledger row has a non-empty payout), (2) the world delta applied
exactly once per attempt** (the idempotency the brief already demands at L546). Both are the
executable form of HD-1 and HD-3. Watch the named landmine: APPEND_LEGAL_IDS must be extended in
the same commit or the WS_044 deviation repeats verbatim [FORKB L518;
MINT_APPLY_CRITIC_2026-07-27.md §A].
---
Class: DIVERGENT-BY-DESIGN (favourable) · Priority: RECORD-ONLY · Owner: none
Recorded so this audit is not read as all-gaps. Hades resets the world on death; the run is
disposable. We do the opposite by ruling: the boss keeps its Composure damage, defeat state and
withdrawal across the player's respawn [HumanityCharacter.cpp L349-352], and the doctrine states
the improvement explicitly — "Strictly better than Hades' currency drip: the death-reward is
diegetic knowledge that lowers the *next* attempt's skill floor without lowering the boss's demand —
you improve because you *learned the tells*: the Souls fantasy paid out on the Hades cadence"
[docs/COMBAT_ENCOUNTER_SYSTEM.md L221]. The environmental-boss protocol's graduated-consequence
failure is the canon seed [T99_Translation_Combat §2.5 L157-164]. This is a genuine design win and
it is already implemented on the boss side; HD-1 and HD-3 are the two properties that keep it honest.
---
---
Class: DESIGNED-UNBUILT · Priority: HIGH (3-4 of them land in the slice) ·
Owner: schema-data / P5-factory · Workable tag: EXTEND-EXISTING-REGISTRY
What the title set proves. The run is the unit of content, so the run is the unit of DATA:
biome, length, room budget, reward class and re-entry rule are rows, because balance is done across
runs, not inside one.
Current state (cited). The twelfth sitting rules "**TWENTY authored rift dungeons across the full
arc** carry a bounded capacity piece (ten Vril + ten Health…)", with the granularity lock "one
dungeon = one PIECE" and "the slice's share rises to roughly three or four bounded dungeons across
Prologue→13" [docs/spine/DECISIONS_PENDING_JOSH.md L19-42]. The eighth sitting rules the shape:
"rifts can be DUNGEONS in the BotW-shrine register: authored ones granting health / vril / stamina /
other stat upgrades … PLUS randomly-spawning POP-UP dungeons with rewards and rarity tiers" [ibid.
L233-235]. Against that: T0_Hollow_Codex holds one row (HW_0001, `spawn_locus_type =
drain-deadzone, region_id = central_africa_congo, containment_reward = vril-restore; lore`) and
its 14 columns carry no run properties at all — no tier, length, room budget, entry/exit, capacity
piece or re-entry rule.
Positive control. dungeon over registries/ = 11 occurrences across 4 files —
T0_Chapter_Index (1), T0_Hard_Lines (3), T0_Boss_Encounter_Registry (1),
T0_Source_Material_Registry (6). The term matches in registries; none of those is a dungeon table.
Control: realm over the same corpus = 212 occurrences across 22 files.
Self-refutation attempted. *"This is DESIGNED-UNBUILT, so it is not a finding."* — Correct on the
class, and it is reported as such. The finding is the SEQUENCING risk: 3-4 of the twenty land inside
the slice, the slice is the only thing Josh will ever play first, and the integration record already
warns that the capacity arithmetic "must be DERIVED before authoring, not chosen and reconciled
after" [docs/pipeline_review/HOLLOW_EXPANSION_INTEGRATION_2026-07-27.md L151-152, C-11 / worklist X-2].
A container with no row cannot be derived against.
Reuse-first recommendation. Do NOT mint a Dungeon registry. The integration record already scopes
the genuinely-new list to four items, of which the container is one — "the ENTERABLE RIFT as a
container (section 10, C-1); the stat-upgrade SOURCE and its budget arithmetic; INSTANCED,
REPEATABLE, RANDOMLY-PLACED content inside Tier A; and a DUNGEON-GRADE rarity axis — a fourth axis on
T0_Rarity_Grade" [ibid. L137-141]. Extend T0_Hollow_Codex (which already carries region,
chapter_window, contain_verb, containment_reward) with the run fields and let the declared fourth
rarity axis carry the pop-up tier. One registry, one declared mint, no new lane.
---
Class: MISSING (design) · Priority: MEDIUM-HIGH · Owner: spec-doc ·
Workable tag: THREE FIELDS + ONE EXISTING GATE
What the title set proves. Every roguelike names three things about a run: how you leave it early,
what state the world is in when you do, and whether the reward re-rolls. Get any one wrong and the
content is either a trap or a farm.
Current state (cited). The pop-up tier is ruled as "randomly-spawning POP-UP dungeons with rewards
and rarity" [DECISIONS L233-235] and the integration record classes "INSTANCED, REPEATABLE,
RANDOMLY-PLACED content inside Tier A" as genuinely new — a new content shape for the solo arena
[HOLLOW_EXPANSION_INTEGRATION L138]. Nothing in the corpus states what happens when the player leaves
or dies inside one.
Positive control (two directions). (1) `re-entry|reenter|re-enter|despawn|expire|repeatable|
one-shot|bail|abandon over docs/pipeline_review/` returns 30 hits — the vocabulary is fully
reachable — and the only *re-entry* hit is REALMARC_PATTERN_CANDIDATES_2026-07-27.md L274
("re-enterable from the road"), which is about realms, not rifts. (2) The anti-exploit reasoning IS
present in the same integration doc for the adjacent problem: "the farm the cap exists to prevent"
appears twice (L403, L572) — applied to the stat-upgrade CAP, never to re-entry.
Self-refutation attempted. *"The Sigma Constraint and Gate 27 already police rewards."* — They
police the DISTRIBUTION of a roll, not the NUMBER of rolls. A bounded-fair table rolled an unbounded
number of times is still a farm, and the rarity firewall would stay green throughout.
Reuse-first recommendation. Three fields on the same T0_Hollow_Codex extension proposed in
HD-10: reentry_class ∈ {persistent, expiring, one_shot}, on_exit_state, reward_reroll_rule —
and bind reward_reroll_rule to machinery that is already built and already named in the integration
record: T1_RNG_Sigma_Constraint_System (whose declared scope "already covers ambient world events"),
T0_RNG_Drop_Table, WS_046 item_instance_ledger, and **Gate 27 harness/check_rarity_firewall.py,
already policing the ladder** [HOLLOW_EXPANSION_INTEGRATION L133-136]. No new gate; one predicate on
an armed one.
---
Class: MISSING (design) · Priority: MEDIUM · Owner: spec-doc + P2 ·
Workable tag: ONE RULING-SHAPED CLAUSE
What the title set proves. Repeatable content needs a stated relationship to player power, or it
decays into either trivia or a wall. Hades solves it with player-elected Heat; Returnal with tiered
biome escalation. Both are explicit; neither leaves it to level arithmetic.
Current state (cited). Our difficulty authority is ruled and is deliberately place-keyed:
"Difficulty density keys off REALM AND SITE — never elevation/latitude"
[docs/translation/T99_Translation_Combat.md §2.2 L126] and the dial is "the vril dial, in full,
zero stat inflation" [COMBAT_ENCOUNTER_SYSTEM.md §9 L236]. Meanwhile the leveling model is ruled
as value-scaling: "level and character progression raises WHAT EACH BAR IS WORTH … Bar and layer
COUNT growth is sourced from the FOUND WORLD entirely" [DECISIONS L28-34]. Compose the two and a
late-game player re-entering an early-region pop-up rift meets an early-region density with a
late-game per-bar value — a trivialised run, in the one content class ruled to be repeatable and
randomly placed.
Positive control. `level.scal|scales to the player|player level|level-appropriate|downscal|
overlevel over docs/` returns 4 hits, all of them GRAPHICS scalability
(ENGINE_OPTIMIZATION_DOCTRINE §7.3 "three-level scalability architecture", D5) plus one
FOUNDATION_ENHANCEMENT_ROADMAP line — the pattern matches text in this corpus, and content-level
scaling is genuinely absent.
Self-refutation attempted. (a) *"Level-scaling is a design smell (Oblivion) and rejecting it is
correct."* — Agreed, and I am not proposing it. The ask is a DECLARED authority, and the ruled
vril-density dial is the obvious candidate: a pop-up rift can spawn at a density band rather than
inheriting its host region's. That is the existing dial pointed at a new content class, not a new
system, and it preserves "answer-pruning, never number inflation" verbatim. (b) *"The 20 authored
dungeons are arc-placed, so this only bites the pop-up tier."* — True, which is exactly why it is
MEDIUM: the exposure is the random tier, which is also the tier with no rows yet (HD-10).
Reuse-first recommendation. One clause: **a pop-up rift declares its own vril_density_band
rather than inheriting the region's**, drawn from the existing env_density_band_default enum, and
the band is what the fourth (dungeon-grade) rarity axis keys against. Reuses the ruled dial, the
existing enum and the already-declared rarity axis.
---
---
Class: DESIGNED-UNBUILT · Priority: MEDIUM (Realm Wave 3, pre-5090) · Owner: schema-data ·
Workable tag: POPULATE-EXISTING-COLUMNS
What the title set proves. Biome identity is legible because it is *declared per biome*: what the
air does, how you move, what the place is made of. It is data, not adjectives.
Current state (cited). T0_Region_Index is 76 rows keyed by node_kind: **base 50 · revisit 9 ·
mythic_realm 9 · atlantic_waypoint 6 · story_anchor 1 · bookend 1**. The realm road is already rowed —
atlantis (Ch 66), pohljar (67), tiamarath (68), maatherion (69), hades (70), xibalba
(71), naraka_meru (72), annwn (73), yggdrasil (74) — plus fairy_realm (Prologue, Ch 1,
Ch 75-77, Epilogue) as story_anchor. Those rows already own the environment-identity columns
env_density_band_default, ambient_elemental_affinity, weather_cycle_profile,
terrain_feature_class_ids, movement_modifier, terrain_permanence_default,
terrain_integrity_skin. **Population, measured this run: 0 of 10 realm rows on every one of those
seven columns** (and 4 of 50 base rows). fairy_realm carries env_profile_status = stub; the nine
realm rows carry nothing at all.
Positive control. The same script reads chapters = 10/10 and time_period = 10/10 on those same
realm rows, so the rows and the reader are both fine; the seven env columns are genuinely blank.
Self-refutation attempted. *"Realms are gated to the post-5090 art wave."* — The ART is; the
IDENTITY DATA is Wave-3 "world-repair, pre-5090, mostly deterministic"
[docs/proposals/REALM_DESIGN_PROGRAM.md §5.4 L1272]. This is the cheapest possible input to that
wave and it is zero-token.
Reuse-first recommendation. Point the Realm Wave-3 world-repair pass at these seven existing
columns before it authors anything new, and add a divergence tooth: **a mythic_realm row must
differ from every base row on at least N of the seven identity columns.** That is the Hades lesson
made executable — a realm that reads identically to Peru on every environment axis is a skin — and it
rides registry_fidelity.py --emit-baseline discipline with no new gate family.
---
Class: WEAKER (reuse defect) · Priority: MEDIUM-HIGH (**cheap now, expensive after the Wave-2
mint freezes) · Owner: spec-doc · Workable tag:** ONE FK LINE BEFORE A MINT
What the title set proves. One home per fact. Two homes for "what this world is like" produce two
answers.
Current state (cited). §2.3 proposes "a new T0_Realm_Ruleset_Registry as the machine layer with
T1_Vril as the binding authority", eleven rows, and an identity family of "realm_id, realm_name,
chapter_ref, road_position; source_tradition, tradition_primary_corpus **as a foreign key into
T0_Research_Corpus_Registry** so the provenance tooth has a real target rather than a prose string"
[docs/proposals/REALM_DESIGN_PROGRAM.md L441-465]. So the charter applies exactly the right FK
discipline to provenance — and never to the realm's own world row.
Positive control. Term counts over the whole 1657-line charter: registry 47, gate 79
(controls) versus region_index 1, region_id 0, node_kind 0, mythic_realm 0.
The charter is thorough and searchable; the ten live realm rows in T0_Region_Index are simply not
in its field of view.
Self-refutation attempted. (a) *"The charter deliberately rejected extending an existing registry
and gave its reasons."* — It did, for T0_Environment_Grammar_Registry, and the reasoning is sound
and specific: "that registry is PER-FEATURE (a lava vent, a waterfall) and this is PER-WORLD"
[L442-444]. T0_Region_Index is exactly PER-WORLD and was never considered. (b) *"A new table is
still right; the ruleset is law, the region row is geography."* — Probably true, and the
recommendation therefore does not merge them; it links them and declares the split.
Reuse-first recommendation. Two lines in the Wave-2 mint, before it freezes: add region_id as a
soft-FK to T0_Region_Index (the same discipline the charter already applies to
tradition_primary_corpus), and state the ownership split — **T0_Region_Index owns the RENDERABLE
environment profile (the seven columns in HD-13); T0_Realm_Ruleset_Registry owns the LAW delta
(holds/bends, signature laws, taboos)**. Without it the two homes drift and the realm road ends up
described twice.
---
Class: MISSING (design) · Priority: MEDIUM-HIGH · Owner: spec-doc + P5-factory ·
Workable tag: THREE COLUMNS + ENROL AN EXISTING CHECK
What the title set proves. This is the single sharpest lesson in the title set. Tartarus,
Asphodel, Elysium and Styx differ far less in *physics* than in *encounter grammar* — the enemy
families, the hazard class, the room vocabulary and the reward mix. The same weapon plays differently
per biome because the OPPOSITION changes, not because gravity does.
Current state (cited). The realm-ruleset field families are: identity/provenance · **the physics
delta** (gravity, light, time, matter, thermodynamic, fluid, acoustic + holds/bends over vocabulary V)
· the vril profile · the metaphysical laws (signature law, trigger, physical_expression, exploit,
reprise_of) · the taboo constraints · the intensity block · the art-direction hooks · the QA block
[REALM_DESIGN_PROGRAM.md L460-542]. Term counts inside that 8,914-character block: reward 1
and roster 1 (the controls that prove the search matches) versus enemy 0, creature 0,
encounter 0, boss 0, hazard 0, fauna 0, loot 0, drop 0. The rules
that DO govern encounter identity are per-CHAPTER, not per-realm: "No two consecutive chapters share
dominant combat type", "Every 5-chapter window ≥3 distinct combat types", "Ten encounter categories
rotate", "Win-condition + verb rotation", with "Enforcement point = the mode_variety_check registry,
run per node by the cascade" [COMBAT_ENCOUNTER_SYSTEM.md L77-82].
Self-refutation attempted. (a) *"The charter's EXPLOIT field covers it — a law the player turns
into a tool IS combat identity."* — Partly, and it is a genuinely strong field ("what keeps the realms
from reading as corridors of rules", L524). But an exploit is the player's side of the verb; it says
nothing about the opposition roster or the reward mix, which is where Hades' biome identity actually
lives. (b) *"Ch 66-74 are chapters, so mode_variety_check already covers them."* — It covers
CONSECUTIVE-CHAPTER variety, which is a different property from per-realm identity: nine realms could
each rotate correctly against their neighbour and still field the same bestiary. (c) *devil's advocate
against timidity*: is asking for a bestiary per realm care-inflated or scope-inflating? The opposite —
the eighth-sitting Hollow ruling already puts Hollows in "the astral/spirit/mythological realms"
(DECISIONS L229-232), so the realms already have a declared native opposition class with nowhere to
record it.
Reuse-first recommendation. Three columns on the same Wave-2 ruleset row, each a soft-FK to a
registry that already exists: native_hostile_families → T0_Creature_Roster; hazard_class →
T0_Environment_Grammar_Registry (the PER-FEATURE registry the charter correctly kept separate — this
is the right way to reference it); reward_mix_class → T0_RNG_Drop_Table. Then **enrol the nine
realm rows in the existing mode_variety_check** so the Ch 66-74 stretch is measured for
encounter-grammar divergence exactly as chapters already are. No new gate, no new registry.
---
Class: COVERED · Priority: RECORD-ONLY · Owner: none
Recorded so the realm cluster is not read as all-gaps. "Each realm introduces exactly ONE
signature law and at most two supporting deltas, and from road position three onward each realm
reprises at least two laws already learned. By Ch 74 the player is fluently juggling eight learned
laws… **Unlimited novelty per realm produces nine tech demos; one signature law plus reprises
produces a road.**" — and it is measurable off the registry ("count signature laws per realm, count
reprise_of references per realm") with the tooth T-RLM-COMPOUND already named
[REALM_DESIGN_PROGRAM.md §2.6 L640-648, §2.7 L655-660]. Hades has no equivalent: its biomes teach in
parallel, not cumulatively. The V-adequacy positive-control probe [L497-503] is likewise stricter
than anything the teacher does. Nothing to fix; HD-15's three columns are the one family this
otherwise excellent schema is missing.
---
---
Class: MISSING (design) · Priority: HIGH · Owner: schema-data + spec-doc ·
Workable tag: DATA-ONLY (existing columns, new rows)
What the title set proves. Hades' gift loop works because affection is a BUILD component: Nectar
buys a Keepsake, a Keepsake occupies a slot, and the slot changes how you fight. Relationship is not a
number in a menu — it is a decision you make about your build.
Current state (cited). The ladder is ruled, symmetric and nine-banded — "Nemesis −100/−90 ·
Hostile −89/−70 · Wary −69/−40 · Cool −39/−10 · Neutral −9/+9 · Friendly +10/+39 · Honored +40/+69 ·
Revered +70/+89 · Exalted +90/+100 … one numeric ladder across faction standing / NPC bond_state /
companion loyalty_score", with THE BOND labels ending at Family and a ruled calibration
target: "on a sustained best-play generative run, **Ntala reaches Family (+90) at ~the Ch-65
path-lock**; Ana peaks at Trusted; a merely-good run misses Family"
[docs/spine/DECISIONS_PENDING_JOSH.md L1820-1830]. Now the schema: T0_Character_Index (164 rows)
carries loyalty_model, loyalty_state, loyalty_belief_axis, loyalty_departure_threshold,
loyalty_join_trigger, loyalty_notes — **join, leave, and the risk of leaving. There is no column
anywhere for what a high band YIELDS.**
**Positive control (the strongest kind — the pattern already exists in this repo, for the other
class). T0_Familiar_Bond_Ability carries bond_ability_id, familiar_id, bond_level**,
bond_threshold, ability_name_text, ability_effect_summary, grants_class,
eam_pair_ref, element_affinity_required, command_permission, integrity_band_gate — a real
bond→capability ladder, currently 5 rows (against the 22×5=110 that Gate 29 B2 polices). **Familiars
have a payoff table; companions do not.** So the shape is expressible in this schema stack today, and
the omission is specific rather than architectural.
Self-refutation attempted. (a) *"Family is a story payoff; mechanising it cheapens it."* — The
opposite risk is documented in our own record: the ruling itself carries a live warning that a top
band nobody can reach becomes "dead content silently" (DECISIONS L1826-1827), and the whole point of
the Ch-65 calibration target is that reaching Family should MEAN something at the path-lock. A band
that changes no verb and no number is a label. (b) *devil's advocate against timidity*: an R-17 AAA
game with a nine-band relationship ladder that yields no mechanical consequence is under-designed by
the standards of every comparator on our own roster, not tastefully restrained.
Reuse-first recommendation. No new table. T0_Bonus_Option_Registry already carries
unlock_gate_ref, condition_expr, role_tags, spec_purpose_refs, build_defining and
expected_pick_band_ref — band-gate a small set of picks on bond_state. Two consequences fall
out for free: Family becomes a build decision rather than a label, and the picks enter the ruled
Phase-5M/5H build-space sweeps automatically, where a never-picked bond bonus reads as a balance
defect under the AAAAA doctrine [COMBAT_PROGRAM_ADDENDUM.md §10]. Zero new systems; the sweep teeth
are already armed.
---
Class: MISSING (design) · Priority: MEDIUM-HIGH · Owner: spec-doc + P5-factory ·
Workable tag: VERB ON AN EXISTING SURFACE
What the title set proves. Hades' Nectar is a *spendable*: the player decides who to invest in,
and the investment is scarce, so it is a real choice. That is the entire engine of the relationship
loop; without a spend, relationship is weather.
Current state (cited). Our ladder moves on the moral axis by ruling: the departure scalar is
"computed from the integrity band (never from observed deeds — integrity is a real property,
§2.2)" [DECISIONS L1821, RULED 3]. The one investment channel that exists is Josh's ruled companion
loadout parity — you equip a companion, and "a departing companion returns the gear (the moral weight
stays on the relationship, never a loot punishment)"
[docs/COMBAT_PROGRAM_ADDENDUM.md §9]. So gear-investment and bond-investment are disjoint axes:
you can arm a companion to the teeth and move the bond zero.
Positive control (and the reuse home). gift over docs/ returns 317 hits across 109 files,
almost all narrative usage; the canonical "THE GIFT" in our corpus is the amulet passing at Ch 13
— "the amulet passes to the healer's child AT THE CH-13 DEPARTURE — the gift and the goodbye as one
beat" [docs/ROADMAP_POST_5090_TO_SHIP.md L579-581] — a one-off narrative beat, running player→NPC,
the inverse of the Hades direction. Meanwhile a culturally-native reciprocity surface **already
exists**: T0_Festival_Registry (16 rows) has 7 rows whose gameplay_hooks are offering economies —
FST_0001 Penti "attend and take a role at the spring offering; … FORK_CH03_A community read hears how
the player carried themselves"; FST_0010 canang sari "fold the young coconut-leaf frame, lay the
porosan…"; FST_0011 Galungan "festival ambience, offering economy and community standing";
FST_0014 Batak "attend respectfully to raise community standing and open the augury minigame".
Self-refutation attempted. (a) *"A gift-for-affection meter is a foreign import and cheapens a
game about integrity."* — This is the timid read and I am ruling against it. Reciprocity and
gift-exchange are real cross-cultural institutions and are already authored into our own festival
hooks with community-standing consequences; the import would be a *menu* of hearts, not the verb. The
recommendation is the verb, expressed in each region's own idiom. (b) *"RULED 3 forbids deeds moving
the relationship."* — RULED 3 governs the departure scalar specifically ("never from observed
deeds"), which is the *belief-distance* computation. It does not say the positive band is unreachable
by player action, and loyalty_score is already ruled as separate "capped inertia" in the same
paragraph. Flagged as CONTESTED for the director — if the intent is that nothing the player
GIVES may move a bond, then this finding converts to DIVERGENT-BY-DESIGN and should be added to the
register's divergence list so no future lens re-litigates it.
Reuse-first recommendation. Land the give/offering verb on the **existing festival + persona
surfaces** rather than a new relationship system: the 7 offering-economy rows already carry the
occasion, the region and the community-standing consequence. Value it through the ruled per-region
mixed-exchange economy (no universal coin), and route the payoff through HD-17's band-gated picks so
the loop closes into the build system that already exists. One verb, three registries already
populated.
---
Class: DESIGNED-UNBUILT · Priority: MEDIUM (slice-adjacent — it is a Prologue item) ·
Owner: schema-data + spec-doc · Workable tag: FIELD-LEVEL
What the title set proves. A Keepsake is the object where relationship and build meet. It is
equipped, it is legible, and its effect is stated.
Current state (cited). T0_Equipment_Registry holds exactly one row, and it is the amulet:
EQ_0001, `equip_name_text = "[PLACEHOLDER … the mother's concealment ward, no proper name minted
(Josh's call)]", string_status = placeholder, equip_slot = unassigned_stat_slot`,
item_class = wearable, base_rarity_class = signature, region_native = fairy_realm,
canonical_chapter_acquisition = CH_PROLOGUE. Its canon is heavy and fully ruled — J-6 makes it "a
SACRED PROTECTION AMULET from the realm keeps her safe and hidden on the field" [DECISIONS L490] and
the provenance chain is authored in the row's own notes (mother → protagonist at the birth → the
catastrophe → crossing at the Ch-1 seam). **So the item that mechanically enables the ruled RESCUER to
survive the field carries unassigned_stat_slot and no effect field at all** — and the registry has
no effect columns to put one in (effects live on T0_Imprint_Affix).
Positive control. The scan of all 1 row × 26 columns is exhaustive by construction; the row
matched on both gift and amulet and is quoted above.
Self-refutation attempted. *"The natural-voice pass owns the string, and magnitudes are Phase-5M."*
— Both true, and neither is the gap. The gap is the SLOT and the EFFECT CLASS: unassigned_stat_slot
is an honest placeholder that becomes a silent hole the moment HD-1's defeat axis needs to ask "is the
rescuer protected right now?".
Reuse-first recommendation. Assign the slot and route the effect through the already-built imprint
lane (T0_Imprint_Affix, the ruled BL4/Diablo-register affix system,
COMBAT_PROGRAM_ADDENDUM.md §8) rather than adding effect columns to T0_Equipment_Registry. Then
name it as the worked example of the keepsake class: **an item given to an NPC that changes what that
NPC can do for you in combat** — which is our own, better version of the Hades keepsake, because ours
runs outward.
---
Class: WEAKER · Priority: MEDIUM · Owner: spec-doc + P5-factory ·
Workable tag: SCHEMA-SMALL + FACTORY RULE
What the title set proves. Hades' story is delivered in the hub, paced by run count, with a
guaranteed-new-line budget so returning is never dead air. The hub is not a menu; it is where the
game's writing lives.
Current state (cited). We have the hub by ruling — the vril site is the save + recharge + loadout
sanctum ("the well = save+recharge+loadout sanctum",
docs/COMBAT_PROGRAM_ADDENDUM.md §9), it is the proposed checkpoint anchor (HD-6), and it is rowed:
T0_Vril_Site_Registry = 42 rows with site_id, site_class, vril_function,
thread_anchors, mastery_tier_required, plus mesh/SFX pipeline columns. What it has no column for
is who is there, what they say, and how that refreshes on the Nth visit. The player will visit
these sites more than any other class of place in the game — they are the save point, the recharge,
the loadout bench and (per A1) the death anchor — and nothing schedules content against visit count.
Positive control. The 25-column read of T0_Vril_Site_Registry above is exhaustive; there is no
persona, dialogue, scene or cadence column among them. Control: the repo DOES have a scene home —
T0_Scene_Spec_Registry (ACTIVE) — so the absence is a wiring gap, not a missing capability.
Self-refutation attempted. (a) *"Ours is an open-world journey, not a hub game; the between-run
hub is a roguelike-shaped import."* — Correct as a whole-structure claim, and I am not proposing a
House of Hades. The narrow, transferable lesson is the return-cadence budget: a place the player
re-enters dozens of times must have authored change, or it becomes the dead air Hades specifically
engineered against. (b) *"The persona system already gives every entity depth."* — It gives depth per
ENTITY; nothing binds depth to REVISIT COUNT at a specific place, which is the property in question.
Reuse-first recommendation. One soft-FK from T0_Vril_Site_Registry into the existing
T0_Scene_Spec_Registry, keyed on visit index, plus a factory rule in the /spine-chapter cascade:
every vril site in a chapter carries at least one authored change-on-return beat. Both halves
already exist — the scene registry and the cascade — so this is a wiring rule, not a system.
---
| Class | Count | Findings |
|---|---|---|
| MISSING | 7 | HD-3, HD-7, HD-11, HD-12, HD-15, HD-17, HD-18 (contested) |
| DESIGNED-UNBUILT | 7 | HD-1, HD-5, HD-6, HD-8, HD-10, HD-13, HD-19 |
| WEAKER | 4 | HD-2, HD-4, HD-14, HD-20 |
| COVERED | 1 | HD-16 |
| DIVERGENT-BY-DESIGN | 1 | HD-9 (favourable — we are ahead of the teacher) |
| TOTAL | 20 |
HD-18 converts to DIVERGENT-BY-DESIGN if RULED 3's "never from observed deeds" is intended to bar
player-initiated bond movement as well as the departure computation — director call, see below.
By priority: HIGH 6 (HD-1, HD-2, HD-3, HD-6, HD-10, HD-17) · MEDIUM-HIGH 6 (HD-4, HD-5, HD-8,
HD-11, HD-14, HD-15, HD-18) · MEDIUM 5 (HD-7, HD-12, HD-13, HD-19, HD-20) · RECORD-ONLY 2 (HD-9,
HD-16).
Slice-relevant (Prologue→Ch 13), therefore outranking at equal weight: HD-1, HD-2, HD-5, HD-6,
HD-10 (3-4 rift dungeons land in the slice), HD-19 (a Prologue item), HD-7 (the slice's closing beat).
---
1. HD-18 — does RULED 3 bar player-initiated bond movement? The ruling's "never from observed
deeds" is written about the *departure* belief-distance scalar. If Josh's intent extends to the
positive direction (nothing the player GIVES may move a bond), HD-18 is DIVERGENT-BY-DESIGN and
belongs in DESIGN_GAP_REGISTER's divergence list so no future lens re-litigates it. If it does
not extend, HD-18 stands as MISSING and is the highest-leverage relationship finding in this lens.
2. HD-3 — is bounded persistence a re-litigation of a ruled doctrine? I read it as an unstated
invariant *inside* the ruled doctrine, not a change to it. Director call before it enters Gate 9.
3. HD-12 — declaring a pop-up rift's own density band touches the ruled "difficulty keys off realm
and site" line (T99 §2.2). I read a self-declared band as compatible (the rift IS a site), but the
reading should be confirmed rather than assumed.
RecordRetryLatency → SM64-9 (already landed;HD-8 is deliberately the orthogonal outcome/economy axis).
here only as a boundary: the integration record already positive-controls it as GREENFIELD
("Scheduled seasonal or weekly live-ops cadence has NO canon… neither ever denotes a live-ops
content schedule", HOLLOW_EXPANSION_INTEGRATION_2026-07-27.md §1.6).