T0_VRIL_DEVICE_REGISTRY_PROPOSAL.md

supernatural/T0_VRIL_DEVICE_REGISTRY_PROPOSAL.md

T0_Vril_Device_Registry — the mint proposal

Status: PROPOSAL-TIER v0.2, 2026-08-07 (v0.1 same day; the critic-fix revision is logged at §10). Authored by the A16 homes-wave lane. NOTHING IS MINTED BY

THIS DOC. No file under registries/ was created, no xlsx was touched, no T0 row was edited.

0. Canon subordination header

This proposal REALIZES canon; it does not author it. The canon it realizes is

_source/01_Tier_1_Foundation/T1_Vril_and_Magic_System_Master [ACTIVE v2.2].md §2, §3, §4 and

§12.1, with T1_Ability_Tree [ACTIVE v1.4].md §10, T1_Combat_System_Spec [ACTIVE v1.0].md

L121-130, T1_CVD_Creative_Vision_Document [ACTIVE v1.4].md §19.5, and the ratified hard-line row

HL_0119. **Where this proposal and any of those disagree, they win and this document is the

defect.** Every proposed cell below carries the file-and-line it derives from; every cell canon does

not answer is left EXPLICITLY EMPTY with the reason, and is never filled by inference.

The LOCKED numerical canon this doc must not move: **seven devices — six vril-seat-coupled plus one

Vimana; six vril-seat positions at Enhanced Ability Mastery per playthrough; one at standard

twelve-level progression per playthrough** (T1_Vril §12.1 L492; HL_0119). This proposal proposes

SEVEN device rows. It proposes no eighth device and no device the corpus does not already carry.

0.1 READ THIS BEFORE THE BRIEF — you are being asked to approve a DIFFERENT table than the ledger names

docs/PIPELINE_LEDGER.md §11 VETOABLE 4 asks for a registry called T0_Vril_Device_Bonding,

keyed on the BONDING and shaped (seat, device, chapter, forced/choice, element, EAM state). **This

brief declines that name and that shape** and recommends a registry called

T0_Vril_Device_Registry, keyed on the DEVICE, at seven rows.

The reason in one paragraph, argued in full at §8 alternative B. A bonding-keyed table needs one row

per device-seat POSSIBILITY — 1 Vimana + 3 forced + (4+3+2) player-choice = sixteen rows — and every

per-device static fact (energy_class, activation_class, respec_eligible,

unlocks_ability_refs, the acquisition window) then repeats across each of a device's possibility

rows, four copies for Device 2 alone. That is the denormalization whose failure mode is one copy

edited and three left stale, which is the drift the mint exists to stop. Worse, a possibility row is

the shape of a RUNTIME option list, so the table would be half static canon and half save-game

state — the exact conflation §5.2 separates by routing the mutable half to

T0_Worldstate_Variables. And the authored bonding-ritual beats a bonding table would serve do not

exist yet: T1_Vril §3 L172 defers them to the T2 cascade, so most of the sixteen rows would land

with their content columns empty.

The decline carries its revival trigger. If the T2 cascade authors the bonding-ritual beats as

distinct scenes with per-option content, that content IS row-shaped and a child bonding table

becomes correct at that point — the device registry's primary key is already the foreign key it

would hang from. Nothing here forecloses the ledger's shape; it defers it until there is content to

put in it.

Router note (SUBAGENT_CONTRACT clause 2). python harness/route.py carries no work-kind for a

registry-SCHEMA proposal. The two nearest kinds were resolved and both were read: registry

(read-set: CLAUDE.md "Authority hierarchy"; docs/REGISTRY_ROW_STRUCT_SPEC.md §1, §2, §2.1, §3, §4,

§4.1, §5; docs/registry_extensions.json; docs/fk_spec.json; docs/generation_lifecycle.json)

and program-doc (read-set: the canon the program serves first; docs/DOC_MAP.md;

docs/START_HERE.md "The hard size cap"; docs/SUBAGENT_CONTRACT.md). The canon nodes read in

place of a chapter node are the four T1 docs and the CVD section named above, plus the four live

registries this schema joins to.

---

1. The gap, stated and cited

docs/PIPELINE_LEDGER.md §2 row A16 records it: the vril architecture is **fully authored in

canon and no device, seat, or bonding registry exists anywhere in the 75 registry directories**

under registries/. The ledger's own words: *"NO structured registry owns the bonding state —

searched all 75, NONE FOUND"* (docs/PIPELINE_LEDGER.md L105). docs/PIPELINE_LEDGER.md §11

VETOABLE 4 (L277-279) escalates it: *"A LOCKED canon count (7+6+1) with no data home anywhere in 75

registries is a drift risk, but minting a registry is a canon-adjacent act and is named here rather

than done silently."* This document is the brief that VETOABLE 4 asked for.

An independent re-verification of the ledger's claim was run for this lane and CONFIRMS it, with one

refinement the ledger did not carry. The device axis has NO home. The SEAT axis has a PARTIAL one:

registries/T0_Equip_Slot_Registry [DRAFT v0.1]/Sheet1.csv carries seven seat_mapping rows

(SLOT_0013-SLOT_0019) with seat_ref and element_ref populated — Root/Earth, Sacral/Water,

SolarPlexus/Fire, Heart/Air, Throat/Ether, ThirdEye/Ether, Crown/Ether — landed under Josh's

2026-08-05 THE-16 ruling (docs/spine/DECISIONS_PENDING_JOSH.md L3646-3671). And the ABILITY axis

has a live join token: T0_Ability_Tree_Registry.eam_pair_eligibility carries the closed vocabulary

EAM-on-bonded-{Root,Sacral,SolarPlexus,Heart,Throat,Crown,ThirdEye} across 111 of 185 rows, plus

EAM-pair-when-bonded (18), EAM-on-trade-mastery (24) and trade-mastery-only (21). So 185

ability rows already point at a device-bonding fact that no row anywhere states.

1.1 Which LOCKED facts have no data home today

Each of these is stated in prose in a T1 doc and is stored in NO registry cell anywhere.

• The device roster itself — that there are exactly seven, exactly one of which is the Vimana

(T1_Vril §2 L145, L151-152; §12.1 L492).

• The shared device class: infinite-free-vital-energy with no depletion and no external power input;

deep-time origin predating the protagonist's arrival; activation-rather-than-construction

(T1_Vril §3 L166).

• Which three bondings are FORCED and to which Ether seat, and which three are PLAYER-CHOICE over

which element pool (T1_Vril §2 L153, §4 L195-197; CVD §19.5 L1324-1329; T1_Ability_Tree §10.2

L643-648, §10.3 L656-658).

• The per-device acquisition chapter or chapter WINDOW, and which of the seven are still

T2-pending (T1_Vril §3 L172; T1_Ability_Tree §10.2 L644, L646, L647).

• The story abilities each forced bonding unlocks — Astral Projection plus Item Rift at Crown,

Probability Sight at Third Eye, True Voice at Throat (CVD §19.5 L1324, L1326, L1328;

T1_Ability_Tree §10.3 L656-658). All four exist as live ability rows (A_C_001, A_C_005,

A_E3_005, A_T_006) and none of them names the device that grants it.

• Respec eligibility: forced bondings cannot be respec'd, player-choice bondings can, the Vimana

device is not respec-affected (T1_Vril §12.1 L494; CVD §19.5 L1341).

• The Ether sub-category per Ether seat — Transcendence and Connection at Crown, Perception and

Insight at Third Eye, Communication and Manifestation at Throat (T1_Ability_Tree §10.1 L633-635).

This is the one seat-axis fact T0_Equip_Slot_Registry does NOT carry.

1.2 The measurable drift the gap has already produced

This is not a hypothetical risk. THREE numbering statements about the same seven objects are live in

the corpus right now and they do not agree, because no row forces them to.

• The Vimana is "Device 1" and also "the seventh device." T1_Vril §3 L168: *"Device 1: the

Vimana device."* Ten lines later, T1_Vril §3 L178: *"Ch 55 Atacama — Vimana device activation. The

seventh device."* T1_Vril §11.2 L444 repeats the second reading: *"Vimana device activation as the

seventh of seven."* CVD §19.5 L1331 carries the first: *"Device 1 of 7 in Vril §3 numbering."*

• Two numbering systems overlap on the token "Device 1." T1_Vril §3 L168 assigns Device 1 to the

Vimana and L170 assigns "Devices 2-7" to the six seat-infusion devices as an unindexed BLOCK.

T1_Vril §4 L195, T1_Vril §12.1 L492, CVD §19.5 L1324 and T1_Ability_Tree §10.2 L643 all use a

SECOND numbering in which "Device 1" is the Ch 15 Crown forced bonding and the six run 1-6. CVD

§19.5 L1331 is the only line in the corpus that names the collision, and it names it obliquely

("in Vril §3 numbering") rather than resolving it.

• T1_Vril §3 carries pre-§19.5 residue that §4 contradicts. §3 L177: *"Ch 38 Azores — vril

stabilization sequence, not a device activation."* §4 L195, §12.1 L492, CVD §19.5 L1326 and

HL_0119 all place Device 3's forced Third-Eye bonding at Ch 38. §3's own L172 flags itself as

the older layer (*"Specific canonical chapter beats … are pending T2 cascade"*), so the most

likely reading is that the §19.5 refinement propagated into §4 and §12.1 and not into §3's anchor

list. This proposal does not resolve it and may not (SUBAGENT_CONTRACT clause 6). It is

recorded in §7 as a finding for the director and modelled per §4/§12.1/§19.5/HL_0119, which is

the reading the hard-line row mirrors.

• One further stale line, lower stakes: T1_Combat_System_Spec L130 still reads *"One vril-seat

position remains at standard Mastery — the player chooses which per playthrough,"* which is the

choice-through-OMISSION mechanic that CVD §19.5 L1316-1320 explicitly inverted to

choice-through-BONDING. The end state matches; the mechanism sentence is pre-refinement.

A registry with a stable primary key and two explicitly separate index columns represents all three

readings without choosing between them, and turns "which numbering is this sentence using?" from a

re-derivation every reader performs into a cell every reader reads.

---

2. What the schema must join to (the real edges, verified live)

• T0_Equip_Slot_Registry [DRAFT v0.1] — 35 rows, 17 columns. Seven slot_axis = seat_mapping rows

carry the seat and element axis; the device registry's equip_slot_ref targets slot_id there.

Verified vocabulary: Crown, ThirdEye, Throat, Heart, SolarPlexus, Sacral, Root.

• T0_Ability_Tree_Registry [ACTIVE v0.1] — 185 rows. eam_pair_eligibility is the token the

device rows must be able to produce; ability_id is the target of unlocks_ability_refs.

• T0_Chapter_Index [ACTIVE v1.2] — 79 rows, chapter_id in CH_NN / CH_PROLOGUE form. Target

of acquisition_chapter_ref and the two delimited chapter-list columns.

• T0_Vril_Site_Registry [ACTIVE v0.1] — 42 rows, site_id in VS_CHNN_NNN form. Target of

vril_site_ref. Only ONE device row can populate it today (see §4).

• T0_Hard_Lines [ACTIVE v0.2] — target of hard_line_ref. HL_0119 is the 7+6+1 architecture

lock; HL_0019 is the Vimana location lock.

• T0_Familiar_Bond_Ability [DRAFT v0.1] — 5 rows, and it already carries an eam_pair_ref column

that is EMPTY in all five. That column is a pre-declared inbound edge to exactly this data. It

needs no schema change; it needs a target to point at.

• T0_Worldstate_Variables [ACTIVE v0.1] — 48 rows. One row is device-adjacent and must be named

rather than missed: WS_044 bonus_respec_ledger (type object) declares

respec_kind (bonus | mastery_point | device_bonding) and cites T1_Ability_Tree §5B.2 as part

of its canonical authority. So the respec EVENT axis for device bonding already has a home. What

has NO home is the CURRENT-STATE axis: no row anywhere stores which base-element seat each of

Devices 2/4/6 is bonded to right now. That is the second half of the gap and is addressed in §5.2,

where the split between the two is stated so neither is built as a copy of the other.

---

3. The proposed schema

Registry name: T0_Vril_Device_Registry. Directory `registries/T0_Vril_Device_Registry [DRAFT

v0.1]/Sheet1.csv`, single tab — every one of the 75 live registry directories holds exactly one CSV,

verified, so a two-tab shape would be the first of its kind and is not proposed.

Primary key device_id, format VD_NNN, min_values 7. Three digits follows the small-roster

precedent in T0_Schema_Dictionary [ACTIVE v1.3] §2.7 (REG_NNN, WPN_NNN, INSC_NNN), and the

prefix VD does not collide with the roster's existing VS (vril site).

32 columns, of which the last six are the peer-class TAIL adopted verbatim from the recent DRAFT

mints this registry most resembles — source_ref, populated_from, notes, extensions,

version, last_updated, in that order, as carried by T0_Bonus_Pool_Registry,

T0_Role_Axis_Registry, T0_Spec_Purpose_Registry and T0_Composure_Routing (headers read live).

The integer-sentinel declaration (resolved here rather than left to import). vril_s3_index,

acquisition_index and eligible_seat_count all infer int32 under

docs/REGISTRY_ROW_STRUCT_SPEC.md §2 rule 4, and an empty integer cell imports as 0. **0 means

NOT-ASSIGNED in both index columns**, which is safe because their legal value ranges are 1-7 and 1-6

respectively, so no real value collides with the sentinel. eligible_seat_count needs no sentinel:

it is populated in all seven rows, and its single 0 (on VD_001) is a REAL zero determined by

binding_mode = vimana_integrated. This is chosen over routing the two index columns through

docs/row_struct_overrides.json column_types as FString, which would work but would trade a

typed integer for a string in order to express a distinction the value range already expresses.

Naming-law conformance (docs/REGISTRY_ROW_STRUCT_SPEC.md §2.1): every column below is qualified

where it sits near the keyword set, and NO column name is a C++ or UE reserved word — checked

against class, default, register, operator, template, union, case, enum, new,

delete, export, inline, struct, public, protected. energy_class, origin_class,

activation_class and respec_site_class all take the _class qualifier the law mandates.

3.1 populated_from — a correction to this document's own first draft

**v0.1 of this proposal claimed populated_from "is carried by NO live registry in the corpus" and

declined the column on that basis. THAT CLAIM WAS FALSE and is struck.** A corrected live sweep of

all 75 registry directories finds **22 registries carry populated_from and 19 of them populate it

in every row** — including T0_SFX_Registry (680/680), T0_Promise_Ledger (125/125),

T0_Composure_Routing (53/53), T0_Quest_Definition_Registry (17/17), T0_Bonus_Pool_Registry

(7/7), T0_Role_Axis_Registry (7/7) and T0_Spec_Purpose_Registry (6/6). Those small recent DRAFT

mints are this proposal's exact peer class. The column is therefore CARRIED, along with the rest of

the peer tail.

The failure is worth recording because it is a named defect class in this repo rather than a

one-off: the original sweep globbed registries/*/ and then d + '*.csv', and every registry

directory name contains a version tag in SQUARE BRACKETS — which glob reads as a character class.

Fifty-odd directories silently failed to match, and the search reported zero. That is exactly the

"search-that-cannot-match-reports-zero" class T1_Vril §1.2.2 names as having burned this repo four

times. The corrected sweep enumerates with os.listdir and no pattern matching.

One real divergence survives the correction and is stated rather than smoothed over.

T0_Schema_Dictionary §2.2 specifies populated_from as a JSON object mapping field name to a

source array. No live registry does that — the live convention across all 22 is a PLAIN CITATION

STRING (T0_Role_Axis_Registry row 1: docs/COMBAT_PROGRAM_ADDENDUM.md §§7-12 (Josh 2026-07-26)).

This proposal follows the live convention, not the dictionary's declared shape, per CLAUDE.md's

trust-content-not-labels discipline — and the divergence is added to §7 as a finding, because a

universal convention that no registry implements as specified is a dictionary defect, not

seventy-five row defects.

3.2 Four columns deliberately NOT proposed, and why

• cultural_memory_anchor. T1_Vril §3 L166 states that *"each device's site corresponds to a

documented cultural-tradition vril content anchor"* — but canon assigns no per-device anchor, so

the column would be empty in all seven rows. A column empty in every row is dead schema. The fact

is recorded as a registry-level INVARIANT in §6 instead, and becomes a column the moment T2

assigns per-device sites.

• lifecycle and superseded_by. Carried by three of the four peer-tail registries, and declined

here on a structural fact rather than on taste: the device roster is CLOSED at seven by HL_0119,

so no row can ever be superseded, retired or replaced. A lifecycle column on a hard-lined closed

roster is a column with one legal value forever.

• The generation-lifecycle columns (generation_status, generation_prompt_hash, and peers). This

registry produces no asset. docs/generation_lifecycle.json enrols registries whose rows carry

meshes, textures, or audio; a device is a mechanic, and enrolling it would put seven permanently

pending cells in front of the lifecycle gate for nothing.

• A T0_Vril_Device_Bonding bonding-option table. Steelmanned and declined in §8, alternative B.

---

4. The proposed rows

Seven rows — the LOCKED count. A note on the lane brief's arithmetic: the brief that commissioned

this doc asked for *"all 7+6+1 = 14 device rows."* That reads the architecture as three groups of

devices summing to fourteen. Canon reads it as ONE group of seven: *"Seven infinite free vital

energy devices exist canonically. One powers the Vimana craft. The remaining six acquire across the

arc"* (T1_Vril §2 L145), restated as *"Seven devices total"* (L151) and locked at §12.1 L492 and

HL_0119. Fourteen device rows would invent seven devices and break the hard line. Seven rows are

proposed. This is flagged rather than silently corrected, per §7.

Notation: EMPTY means canon does not answer, with the reason given; it is never a default and

never an inference.

VD_001 — the Vimana device

VD_002 — forced Ether bonding, Crown, Ch 15 Egypt

VD_003 — player-choice base-element bonding 1, window Ch 19-23

How to read VD_004 through VD_007 (the delta rows). The four rows below are written as DELTAS

against a base row of the same binding_mode — VD_004 and VD_006 against VD_002 (forced Ether),

VD_005 and VD_007 against VD_003 (player choice). **A delta row INHERITS the base row's per-column

citation for every column it does not restate.** The inheritance is legitimate because the inherited

cells are exactly the ones canon states class-wide rather than per-device — device_kind,

energy_class, origin_class, activation_class (T1_Vril §3 L166), the vril_s3_index emptiness

(§3 L170), respec_eligible and respec_site_class (§4 L195-196, §12.1 L494), and the peer tail.

Every cell that differs per device is restated with its own line citation. The full empty-cell

enumeration at §4.1 is written out per row, so the coverage claim is auditable without expanding the

deltas.

VD_004 — forced Ether bonding, Third Eye, Ch 38 Azores

Identical in shape to VD_002, with: acquisition_index 3; bound_seat_ref ThirdEye;

ether_subcategory Perception and Insight (T1_Ability_Tree §10.1 L634); equip_slot_ref

SLOT_0018 (diadem_seat, T1_Ability_Tree §10.1 L634 "Third Eye vril-seat. Diadem equipment

slot"); acquisition_chapter_ref and window CH_38 (T1_Vril §4 L195; CVD §19.5 L1326);

chapter_assignment_status assigned; unlocks_ability_refs A_E3_005 (Probability Sight, CVD

§19.5 L1326, T1_Ability_Tree §10.3 L657); eam_token EAM-on-bonded-ThirdEye; respec_eligible

FALSE; vril_site_ref EMPTY.

notes on this row carries the §1.2 conflict verbatim: T1_Vril §3 L177 reads *"Ch 38 Azores — vril

stabilization sequence, not a device activation,"* against §4 L195, §12.1 L492, CVD §19.5 L1326 and

HL_0119. The row is modelled on the four agreeing sources and the conflict is escalated, not

resolved here.

VD_005 — player-choice base-element bonding 2, window Ch 47-50

Identical in shape to VD_003, with: acquisition_index 4; eligible_seat_count 3 (CVD §19.5

L1327 "one of the remaining three unbonded base elements"); acquisition_window_chapter_refs

CH_47|CH_48|CH_49|CH_50 (T1_Vril §2 L153); candidate_chapter_refs CH_47|CH_48|CH_50

(T1_Ability_Tree §10.2 L646 names Ch 47 Mesoamerica, Ch 48 Maya Yucatán, Ch 50 Amazon);

chapter_assignment_status window_pending_T2.

VD_006 — forced Ether bonding, Throat, window Ch 56-57

Identical in shape to VD_002, with: acquisition_index 5; bound_seat_ref Throat;

ether_subcategory Communication and Manifestation (T1_Ability_Tree §10.1 L633); equip_slot_ref

SLOT_0017 (necklace_seat, L633 "Throat vril-seat. Necklace equipment slot");

acquisition_chapter_ref EMPTY; acquisition_window_chapter_refs CH_56|CH_57 (T1_Vril §2

L153; CVD §19.5 L1328); chapter_assignment_status window_pending_T2 (T1_Ability_Tree §10.2 L647

"Specific chapter assignment defers to T2 Chapter Design briefs"); candidate_chapter_refs

CH_56|CH_57 (L647 names Ch 56 Arctic and Ch 57 Australia); unlocks_ability_refs A_T_006 (True

Voice, CVD §19.5 L1328, T1_Ability_Tree §10.3 L658); eam_token EAM-on-bonded-Throat;

respec_eligible FALSE; vril_site_ref EMPTY.

This is the only FORCED row whose chapter is unassigned, and it is the row where the pending status

carries a care consequence: one of its two candidates is Ch 57, the maximum-care Australia node

(T1_Vril §12.5 L516; T1_Combat_System_Spec L420). A forced story bonding landing there is a

care-tier question, not a data question, and is named in §7 rather than pre-empted here.

VD_007 — player-choice base-element bonding 3, Ch 65 Antarctica Return

Identical in shape to VD_003, with: acquisition_index 6; eligible_seat_count 2 (CVD §19.5

L1329 "one of the remaining two unbonded base elements"); acquisition_chapter_ref and

acquisition_window_chapter_refs CH_65 (T1_Vril §2 L153, §4 L196; CVD §19.5 L1329);

chapter_assignment_status assigned; candidate_chapter_refs EMPTY; vril_site_ref

EMPTY — VS_CH65_001 exists and is the Ch 65 gathering site, but canon ties it to the Vimana's

vril-STORAGE mode (T1_Vril §11.6 L464), never to the Device 6 bonding, so pointing at it would be

inference.

4.1 Citation coverage, enumerated cell by cell

224 cells (7 rows × 32 columns). 168 populated, 56 declared EMPTY. Every populated cell carries

the file-and-line it derives from, directly or by the delta inheritance declared above. No cell is

populated by inference and no cell is left blank without a stated reason.

Reason classes, closed at five: S structurally empty (canon says the object has no such

property) · P per-playthrough outcome (runtime state, homed at §5.2) · T T2-pending (canon

declares the deferral) · N no canon assignment (canon could have assigned and has not) · X

numbering not per-device.

Every empty cell, enumerated by row so the arithmetic is checkable:

Row totals 11 + 5 + 10 + 5 + 10 + 5 + 10 = 56. Class totals **S 18 · N 17 · P 12 · X 6 · T 3 =

56. The two derivations agree, and 224 − 56 = 168 populated**.

Two reads worth taking from the table rather than from the totals. VD_006 is the only FORCED row

with a T-class empty, which is the one place a story-critical bonding is still chapter-unassigned.

And every X cell is the same column — vril_s3_index on the six seat rows — so the entire

numbering-collision cost is six cells in one column, which is what makes finding 3 in §7 a cheap

close rather than a schema problem.

---

5. Two companion moves that are NOT part of the veto

These are named here so the director sees the whole package, but neither is a canon-adjacent act and

neither needs Josh's signature. Both are ordinary declared-extension execution.

5.1 Three extension columns on T0_Equip_Slot_Registry. The seven seat_mapping rows carry

seat_ref and element_ref and stop there. Three seat facts have no cell anywhere:

ether_subcategory (T1_Ability_Tree §10.1 L633-635 — duplicated onto the device rows above only

because the device is where a forced bonding names it; the SEAT is where it belongs),

standard_progression_eligible (bool — TRUE on the four base-element seats, FALSE on the three

Ether seats, per T1_Vril §4 L213 "Ether vril-seat positions are never the standard-progression

vril-seat" and §12.1 L492), and forced_device_ref (FK back to VD_002/VD_004/VD_006, EMPTY on

the four base seats). Landing them is the declared-extension path: a docs/registry_extensions.json

entry attributing all three to this system, plus added_columns in docs/fidelity_baseline.json

refreshed with --emit-baseline in the same commit.

CAUTION for the director: T0_Equip_Slot_Registry was ruled and rebuilt on 2026-08-05

(docs/spine/DECISIONS_PENDING_JOSH.md L3640-3671) and is a hot surface. Confirm no sibling lane is

mid-edit before touching it.

5.2 One row on T0_Worldstate_Variables — and the split against the row that already exists.

The per-playthrough bonding state — which base-element seat each of Devices 2/4/6 is bonded to right

now, and which seat therefore emerged as standard-progression — is runtime state, not static canon,

and belongs where the other 48 runtime variables live.

**WS_044 bonus_respec_ledger already exists and is device-adjacent, so the split has to be stated

rather than assumed.** WS_044 is typed object, its domain declares `respec_kind (bonus |

mastery_point | device_bonding), and its canonical_authority cites T1_Ability_Tree §5B.2` — the

Device Bonding Respec mechanic itself. Its notes say so explicitly: *"ONE ledger shape for the

ruled dual respec … and the §5B.2 Device Bonding respec."* The two axes are:

• WS_044 = the append-only respec EVENT HISTORY. What was rebonded, from what to what, where, at

what cost, refundable or not. It is a log; entries are added and never edited.

• The proposed device_bonding_state = the CURRENT STATE. Which seat each of the three

player-choice devices holds at this moment. It is a single object, overwritten on each bonding.

Neither derives the other BY COPY, and that is the point of naming both. Current state is in

principle replayable from the event log, but only if the log is complete from the first bonding —

and the first bonding is not a respec, so it never enters WS_044 at all. Reconstructing state from a

log that structurally omits the initial write is the defect this split prevents.

Proposed shape, following the WS_043 / WS_045 object precedent: device_bonding_state, type

object, keyed on device_id (VD_003 / VD_005 / VD_007) with values drawn from the seat

vocabulary, default {}, canonical_authority = T1_Vril §4 + CVD §19.5, consumers the EAM

resolver, the respec resolver and the save state. The emergent standard-progression seat is DERIVED

from it and never stored twice (T1_Vril §4 L197; T1_Ability_Tree §10.5 L677).

Recording this split is half the value of the whole exercise. The ledger's phrase "bonding state"

conflates a static canon fact, an event log that already exists, and a save-game variable that does

not; separating the three is what stops the registry from acquiring a mutable column that no gate

can check.

5.3 What is DERIVED and must not be stored. T1_Ability_Tree §10.4 L668-671 enumerates the four

playthrough configurations with their emergent standard seat and signature combo trio. All four are

derivable from eligible_seat_refs plus the bonding state plus the Layer-B combo rows already in

T0_Ability_Tree_Registry (48 Layer-B rows keyed element = "Earth+Water" and peers, verified

live). No configuration table is proposed. A stored copy of a derivable fact is the drift this

whole exercise exists to prevent.

---

6. Registry-level invariants a gate can check on day one

Stated so the mint arrives with teeth rather than with a promise of teeth. Each is a mutation-provable

assertion over the seven rows.

• Exactly 7 rows; exactly 1 with device_kind = vimana_integrated; exactly 6 with seat_infusion.

This is clause 1 of HL_0119 — *"Seven vital energy devices canonical: six vril-seat-coupled

devices plus one Vimana"* — made checkable. It is clause 1 alone, not the whole hard line.

• **Clauses 2 and 3 of HL_0119 — six seats enhanced, one seat standard — made STATIC-checkable

without any runtime data, from two columns.** The three forced_ether rows carry

bound_seat_ref ∈ {Crown, ThirdEye, Throat}, three distinct Ether seats bonded in every

playthrough. The three player_choice_base_element rows carry eligible_seat_count descending

4 → 3 → 2 over a four-seat eligible_seat_refs pool, which forces exactly three distinct

base-element seats bonded and exactly one left unbonded, whichever the player picks. Three plus

three is six enhanced; four minus three is one standard; and the one standard is necessarily a

base-element seat, which is HL_0119's and T1_Vril §4 L213's Ether-never-standard clause falling

out as arithmetic rather than needing its own assertion. The tooth reads two columns of the

registry and needs neither T0_Worldstate_Variables nor the §5.1 companion move.

• Integer sentinel: vril_s3_index and acquisition_index treat 0 as NOT-ASSIGNED (legal ranges

1-7 and 1-6). eligible_seat_count has no empty cell, so its single 0 on VD_001 is a real value

and the tooth must not read it as a sentinel.

• Exactly 3 rows with binding_mode = forced_ether, and their bound_seat_ref set is exactly

{Crown, ThirdEye, Throat} with bound_element_ref = Ether on all three. T1_Vril §12.1 L492.

• Exactly 3 rows with binding_mode = player_choice_base_element, respec_eligible = TRUE on

exactly those three and FALSE on the other four. T1_Vril §12.1 L494.

• eligible_seat_refs on every choice row is exactly the four base-element seats, and

eligible_seat_count descends 4 → 3 → 2 in acquisition_index order. CVD §19.5 L1325-1329.

• energy_class is infinite_free_vital_energy on all seven. T1_Vril §3 L166.
• The seven eam_token values that ARE populated appear verbatim in

T0_Ability_Tree_Registry.eam_pair_eligibility — a live cross-registry vocabulary check that

today nothing performs.

• Every non-empty acquisition_chapter_ref, equip_slot_ref, unlocks_ability_refs,

vril_site_ref and hard_line_ref resolves in its target registry.

• The registry-level INVARIANT with no column (§3.2): every device's site corresponds to a

documented cultural-tradition vril anchor (T1_Vril §3 L166). Unenforceable until T2 assigns

sites; recorded so it is not lost.

---

7. Findings for the director — NOT edits (SUBAGENT_CONTRACT clause 6)

1. The Vimana is "Device 1" in four places and "the seventh device" in two. T1_Vril §3 L168 and

CVD §19.5 L1331 against T1_Vril §3 L178 and §11.2 L444. A living-source clarification in T1_Vril

§3 would close it. Not this lane's to make.

2. **T1_Vril §3 L177 contradicts §4 L195, §12.1 L492, CVD §19.5 L1326 and HL_0119 on whether Ch 38

carries a device bonding.** Most likely §19.5-propagation residue in §3's anchor list. The

registry models the four-source majority and flags the fifth.

3. "Devices 2-7" at T1_Vril §3 L170 is an unindexed block. Six cells of vril_s3_index are

therefore permanently empty until canon indexes them or the §3 numbering is retired in favour of

the §19.5 one. Retiring one of the two numberings is the cleanest close and is a director call.

4. T1_Combat_System_Spec L130 carries the pre-§19.5 choice-through-omission sentence. End

state is unaffected; the mechanism sentence is stale.

5. The lane brief's "7+6+1 = 14 device rows" misreads the architecture. Seven devices is the

locked count; fourteen would break HL_0119. Corrected here rather than executed.

6. Chapter-ref encoding divergence. T0_Ability_Tree_Registry.unlock_chapter_ref uses Ch_15;

T0_Chapter_Index.chapter_id uses CH_15. This proposal uses the FK-target form throughout. The

divergence is a live FK-canon-graph item of the same family as CLAUDE.md "Known issues" item 3.

7. VD_006's window includes Ch 57. A FORCED story bonding at the maximum-care Australia node is

a care-tier question for whoever ratifies the T2 assignment; it is not pre-empted here.

8. T0_Familiar_Bond_Ability.eam_pair_ref is an empty pre-declared inbound edge to exactly this

data across all 5 rows. If the mint lands, that column becomes fillable without a schema change.

9. The EAM name drifts in three directions across three authorities. T1_Vril §3 L183-185 and

§2 L145 say Enhanced Ability Mastery; the ratified hard-line row HL_0119 rule_text says

Enhanced Active Mastery; T1_Combat_System_Spec L130 says Enhanced Mastery. The acronym

EAM is used throughout as if one expansion were settled. The registry is agnostic — it stores the

eam_token values, which are stable — but a hard-line row disagreeing with the T1 doc it cites

is worth a living-source pass.

10. A live numerical divergence on the mastery ladder, adjacent to CLAUDE.md Known-issue 2.

T1_Ability_Tree §10.5 L679 places Magister Templi at "Tier 9" and Magus at "Tier 10";

T1_Vril §12.1 L496 and §9 L383-384 place them at level 11 and level 12 under the

ratified grade-band mapping (GRADE_BAND_MAPPING_2026-07-28, Josh YES), where the ten grade

NAMES band the twelve LEVELS. CVD §19.5 L1337 carries the Ability-Tree form. This is the ten-

names-versus-twelve-levels confusion that Known-issue 2 records as RESOLVED at the doctrinal

level but that is still un-propagated in at least two places. Outside this lane's scope; it

touches no device cell.

11. **T0_Schema_Dictionary §2.2's populated_from JSON-object spec is implemented by no live

registry.** All 22 that carry the column use a plain citation string. A universal convention that

zero of seventy-five registries implements as written is a dictionary defect rather than

seventy-five row defects, and the dictionary is .md living-source and therefore gate-safe to

correct. See §3.1.

12. **A method finding, recorded because it nearly put a false claim into a checked-claims

document.** This proposal's first draft asserted a corpus-wide negative ("no live registry

carries populated_from", "no registry is smaller than 7 rows") produced by a sweep that globbed

directory names containing SQUARE BRACKETS — which glob reads as a character class, so ~50 of

75 directories silently failed to match and the search reported zero. Every registry directory in

this repo carries a bracketed version tag, so ANY glob-based corpus sweep over

registries/*/* is exposed to this. Recommend the harness grow a shared registry-enumeration

helper using os.listdir, so the next lane does not re-derive the bug.

---

8. THE MINT BRIEF (CLAUDE.md four-step decision protocol)

Josh's call per docs/PIPELINE_LEDGER.md §11 VETOABLE 4. Four steelmanned alternatives, each

deep-dived against CVD, the tier docs and the drift record, then adversarially reviewed.

Alternative A — mint T0_Vril_Device_Registry as specified above (7 rows, 32 columns), plus the two §5 companion moves

Deep dive. The device is the entity canon actually describes: seven objects with a shared class, an

acquisition schedule, a binding mode and a respec rule. A seven-row table with a stable PK is the

smallest structure that holds all of that without duplicating anything. It resolves the numbering

collision by REPRESENTING both numberings in two typed columns rather than picking one — which is

the only move available to a lane that may not change canon. It gives 185 ability rows' worth of

eam_pair_eligibility tokens a table to resolve against, and gives

T0_Familiar_Bond_Ability.eam_pair_ref a target. It arrives with eight checkable invariants (§6),

so HL_0119 stops being a sentence nothing reads. It routes the mutable half of the problem to

T0_Worldstate_Variables where mutable state already lives.

Pros: canon-shaped; the LOCKED count becomes machine-checkable; the three live numbering

contradictions become one readable cell each; no duplicated facts; the mint surface is one directory

plus one fk_spec block plus one baseline entry.

Cons: it is a

permanent new surface — an fk_spec entry, a added_registries line, a row struct, a gate surface —

for facts with no engine consumer today (the A16 ledger row records ZERO built and NOT WIRED); and

three cells land T2-pending and will need a second pass.

A con that was asserted in v0.1 of this brief and is WITHDRAWN as false: that seven rows would make

this the smallest registry in the corpus. Ten live registries are smaller — T0_Hollow_Codex (1),

T0_Motif_Registry (1), T0_Dwelling_Registry (2), T0_Minigame_Registry (2),

T0_Loadout_Set_Definition (3), T0_Role_Composition_Rule (4), T0_Vehicle_Registry (4),

T0_Dungeon_Class_Reference (5), T0_Familiar_Bond_Ability (5), T0_Imprint_Affix (5) — and three

more sit at 6. A seven-row registry is unremarkable here; small closed-roster registries are

established precedent, not an exception this proposal would be asking for. (The false claim came

from the same glob bug recorded at §7 finding 12.)

Alternative B — mint T0_Vril_Device_Bonding exactly as the ledger names it: one table of device×seat bonding possibilities

Deep dive. VETOABLE 4's own words are *"(seat, device, chapter, forced/choice, element, EAM state)"*

— one table keyed on the BONDING rather than on the device. Shape: 1 Vimana row + 3 forced rows +

(4+3+2) player-choice possibility rows = 16 rows. It makes the choice SPACE explicit as data, which

a bonding-ritual scene would want to read.

Pros: matches the ledger's stated intent verbatim; the ritual's option list is a query rather than a

delimiter split.

Cons, and they are decisive. Every per-device static fact — energy_class, activation_class,

respec_eligible, unlocks_ability_refs, the acquisition window — repeats across each of a

device's possibility rows, four copies for Device 2 alone. That is textbook denormalization, and the

defect class it produces (one copy edited, three left stale) is the same class this repo's wiring

doctrine exists to prevent. Worse, the possibility rows are the SHAPE of a runtime option list, so

the table would be half canon and half save-game — the exact conflation §5.2 separates. And the

authored bonding-ritual beats it would serve do not exist: T1_Vril §3 L172 defers them to the T2

cascade, so most of the sixteen rows would land with their content columns empty.

Alternative C — no new registry: extend T0_Equip_Slot_Registry only

Deep dive. Put every device fact as columns on the seven seat_mapping rows. Zero new registries,

zero new fk_spec blocks; the seat axis is already there and was ruled six weeks ago.

Pros: the cheapest possible landing; declared-extension mechanics only, no canon-adjacent act, no

veto needed at all.

Cons. The Vimana device has NO seat (T1_Vril §2 L162), so it has no row to live on — the seventh of

seven, the one carrying HL_0019 and the Ch 55 hard line, would be homeless, and "seven devices"

would be representable only as "six device columns plus a note." That alone disqualifies it. Beyond

that: the three player-choice devices bond to a seat chosen at runtime, so a device column on a

seat row would be a mutable cell in a static registry; and it would push a registry Josh personally

enumerated on 2026-08-05 from an equipment roster into a hybrid equipment-and-device table, which is

a scope drift on a hot surface.

Alternative D — leave it prose-only (the status quo)

Deep dive. The T1 docs already state everything; nothing is lost that a careful reader cannot

reconstruct. Registries are not free — each is a permanent surface that must be kept current, and

the corpus has 75 already, several of which are DRAFT stubs.

Pros: zero mint cost; zero new veto surface; nothing to keep current; and the honest observation

that the engine has no consumer for this data today, so the registry would sit unread until the

seat/device/EAM systems are built.

Cons. The drift the mint prevents is not hypothetical — it has ALREADY OCCURRED, three times, and is

catalogued at §1.2 with line numbers. Every reader of the vril architecture re-derives which

"Device 1" is meant, and one of them will eventually get it wrong in a build pack. HL_0119 is a

hard line with no tooth: nothing in the harness can currently detect a document that says "seven

vril-seats enhanced." And the 185 ability rows carrying EAM-on-bonded-* tokens point at a fact no

row states, which is precisely the orphan-reference class check_ledger_integrity.py was built to

find in the doc layer and has no equivalent for in the registry layer.

Adversarial review

Against B: it is the ledger's own proposal, and overriding a ledger recommendation needs a reason

stronger than taste. The reason is data-modelling and it is stated in the ledger's own terms — the

ledger's stated goal is to stop drift, and a table that stores four copies of Device 2's respec rule

is a drift GENERATOR. B is not wrong about what needs a home; it is wrong about the key.

Against C: the cheapest option is genuinely attractive and the timid-bias warning in CLAUDE.md cuts

BOTH ways here — declining a mint to avoid a veto is exactly the over-conservative move the care

doctrine names as the more costly error. But C fails on a structural fact, not on nerve: the Vimana

has no seat row, and the count is seven.

Against D: the strongest form of D is "wait for the engine consumer." It is answerable. A registry

minted BEFORE the T2 beats are authored is what makes the T2 output checkable when it lands; a

registry minted after has nothing to check against, and the five T2-pending cells are the artifact

that makes the pending-ness visible. chapter_assignment_status exists precisely so an empty cell

reads as a declared deferral rather than as an omission.

Against A: the honest residual is that A adds a permanent surface for a system with zero built

consumers, and A's own §5 already shows that the mutable half — the part a runtime would actually

read first — does not need the registry at all. If someone wanted to argue A is premature, that is

where they would stand.

RECOMMENDATION

Alternative A. Mint T0_Vril_Device_Registry at 7 rows and 32 columns exactly as specified in

§3 and §4, with the ten §6 invariants landing as a checker in the same commit, plus the two §5

companion moves (three declared extension columns on T0_Equip_Slot_Registry, one

device_bonding_state row on T0_Worldstate_Variables). Decline the ledger's

T0_Vril_Device_Bonding name and shape, and record the decline with its revival trigger: if the T2

cascade authors the bonding-ritual beats as distinct scenes with per-option content, that content is

row-shaped and a child table becomes correct at that point — the device registry's PK is already the

FK it would hang from.

THE STRONGEST OBJECTION

**Three of the seven rows carry a chapter WINDOW rather than a chapter, and one of them is a FORCED

story bonding — so the registry cannot yet answer the question a consumer will actually ask, which

is "what happens in this chapter."** T1_Vril §3 L172 defers the beats to the T2 cascade;

T1_Ability_Tree §10.2 defers three chapter assignments to T2 briefs. A skeptic can fairly say the

mint is being scheduled ahead of the canon that would fill it, that the corpus already carries DRAFT

registries populated at 0 rows, and that this would be another table that looks answered while

three-sevenths of its acquisition column is a shrug.

The counter, offered so Josh can weigh both: the drift at §1.2 is measurable TODAY and does not

depend on the T2 beats at all — the numbering collision, the §3-versus-§4 Ch 38 contradiction, and

the toothless HL_0119 are all present now and all closed by the seven rows as specified. The

pending cells are three, not thirty, and each is DECLARED pending in its own column rather than left

ambiguous. If Josh judges the timing wrong, the reversible half-step is to take the §5 companion

moves alone (they need no veto), leave the device registry unminted, and revisit when the first T2

device beat is authored.

---

9. Landing mechanics if the mint is approved

Recorded so whoever executes does not re-derive them.

• Create registries/T0_Vril_Device_Registry [DRAFT v0.1]/Sheet1.csv with the csv module only —

never string surgery (route.py registry gate note).

• Declare the registry in docs/fidelity_baseline.json added_registries (currently 46 entries;

this becomes 47) and refresh with harness/registry_fidelity.py --emit-baseline IN THE SAME

COMMIT, or the gates go red (CLAUDE.md, Phase 0 note).

• Add an fk_spec block in docs/fk_spec.json: primary_key device_id; id_formats pattern

VD_\d{3} with min_values 7; FK edges for acquisition_chapter_ref → T0_Chapter_Index,

equip_slot_ref → T0_Equip_Slot_Registry, vril_site_ref → T0_Vril_Site_Registry,

hard_line_ref → T0_Hard_Lines. The three pipe-delimited ref columns

(acquisition_window_chapter_refs, candidate_chapter_refs, unlocks_ability_refs) are DEFERRED

to the canon-graph pass per that file's own scope note on pipe-separated anchors, and the deferral

is declared rather than silent.

• Register the VD_ prefix in T0_Schema_Dictionary [ACTIVE v1.3] §2.7. §2.8 makes the §2.7

roster the collision-avoidance MECHANISM — *"Each PREFIX value is unique per registry; no two

registries share a prefix"* — so a prefix that is not in the roster is a prefix nothing protects.

_source/00_Tier_0_Master_Indices/T0_Schema_Dictionary [ACTIVE v1.3].md is a .md living-source

tier doc, not the frozen T0 xlsx, so editing it is gate-safe per CLAUDE.md. A MINOR version bump

per §2.3 (new registry added, no consumer broken).

• Declare the three T0_Equip_Slot_Registry extension columns in docs/registry_extensions.json

under one owning system, with a _column_doctrine entry saying what belongs in each — a column

whose meaning lives only in a commit message gets populated by guess.

• No docs/generation_lifecycle.json enrolment (§3.2). No docs/canon_derivation.json enrolment

either: that gate's artifacts list covers produced ASSET artifacts, and neither this proposal

nor a registry CSV is one of its kinds.

• python harness/run_gates.py exits 0 before the commit; read the output unpiped.
• Register this proposal in docs/DOC_MAP.md in the same commit. Note for the director:

harness/check_ledger_integrity.py reports 69 orphans on the current tree and this file makes 70

until that row lands.

10. Provenance

Revision v0.2, 2026-08-07 — the fresh-context critic returned GO-WITH-FIXES and its eight

findings are all applied here. Three of them corrected FALSE corpus-state claims this document had

asserted as verified: that no live registry carries populated_from (22 do, 19 fully — §3.1), that

no worldstate variable is device-adjacent (WS_044 is — §2, §5.2), and that seven rows would be the

corpus minimum (ten registries are smaller — §8). All three came from one glob bug, now recorded as

§7 finding 12 so the next lane inherits the lesson rather than the defect. Also applied: the peer

tail and populated_from carried (28 → 32 columns), bound_element renamed bound_element_ref to

match the sibling axis, the integer sentinel declared, HL_0119 clauses 2 and 3 made

static-checkable as a new §6 invariant, the coverage arithmetic re-derived cell-by-cell and now

reconciling two ways (§4.1), the delta-row citation inheritance stated explicitly, the schema-

dictionary §2.7 prefix registration added to the landing mechanics, two adjacent canon divergences

recorded as §7 findings 9 and 10, and the decline of the ledger's T0_Vril_Device_Bonding name and

shape moved to the TOP of the document at §0.1 so Josh meets it before the brief rather than inside

it. The recommendation is unchanged.

Authored 2026-08-07 by the A16 homes-wave lane under docs/SUBAGENT_CONTRACT.md with the director's

landing override in force (write the target file; no commit, no DOC_MAP edit — the director lands

the wave). Canon read in full: T1_Vril_and_Magic_System_Master [ACTIVE v2.2] (600 lines);

T1_Ability_Tree [ACTIVE v1.4] §10 L621-700; T1_Combat_System_Spec [ACTIVE v1.0] L121-130 plus a

device/EAM sweep of the whole doc; T1_CVD_Creative_Vision_Document [ACTIVE v1.4] §19.5 L1314-1345.

Registries read live: T0_Equip_Slot_Registry (35 rows), T0_Ability_Tree_Registry (185),

T0_Vril_Site_Registry (42), T0_Familiar_Bond_Ability (5), T0_Chapter_Index (79),

T0_Hard_Lines, T0_Worldstate_Variables (48 rows, WS_044 read in full). At v0.2 a corrected

full-corpus sweep enumerated all 75 registry directories with os.listdir for the populated_from,

row-count and peer-tail claims. Contracts read:

docs/REGISTRY_ROW_STRUCT_SPEC.md, docs/registry_extensions.json, docs/fk_spec.json,

docs/fidelity_baseline.json, docs/generation_lifecycle.json, docs/canon_derivation.json,

_source/00_Tier_0_Master_Indices/T0_Schema_Dictionary [ACTIVE v1.3].md §2.

docs/spine/DECISIONS_PENDING_JOSH.md was swept for vril-device and seat rulings: the 2026-08-05

THE-16 equip-slot ruling and D-21 (the chakra → vril-seat rename, count preserved) are the two that

touch this lane, and NOTHING about the device registry has been ruled. No canon file was edited.

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