LENS_fortnite-liveops-funnel_DRAFT.md

pipelines/LENS_fortnite-liveops-funnel_DRAFT.md

Comparator lens audit — FORTNITE (BR · Zero Build · Festival · LEGO · Rocket Racing) + its season/event layer

Lens id: fortnite-liveops-funnel · WAVE P1-B · read-only audit of C:\dev\humanity-forgotten (canon) and

C:\dev\Humanity\Humanity (built reference).

Wave focus honored: onboarding funnel · session cadence · event-calendar craft, mined for what is PORTABLE

to a premium single-player-now / MMO-later posture. The F2P season economy (battle pass, cosmetic storefront,

seasonal monetization) is pre-registered DIVERGENT-BY-DESIGN per docs/proposals/COMPARATOR_LENS_PROGRAM.md

L57 ("fortnite-liveops teaches F2P season economics, divergent by construction") and is not re-litigated below —

only its separable craft halves are (measured funnels, scheduled spectacle, rotation-as-anti-meta, cross-mode

reuse, ladder legibility).

Method law held. Every finding names our current state with a file + section/line citation; every zero is

positive-controlled with the same tool over the same corpus; DESIGNED-UNBUILT is never reported as MISSING;

every recommendation names the existing system it lands on. Dedupe baseline read in full and respected:

docs/DESIGN_GAP_REGISTER.md (9 ranked + recovered rows 10-19 + v1.1 rows 20-45), the ranked queue at

docs/PRE_5090_BUILD_PLAN.md ▶ THE PRE-5090 WINDOW PLAN (ranks 1-30 + the slice rescope), the ruled Hollow

axes (docs/spine/DECISIONS_PENDING_JOSH.md eighth sitting + docs/pipeline_review/HOLLOW_EXPANSION_INTEGRATION_2026-07-27.md),

docs/COMBAT_PROGRAM_ADDENDUM.md §§9-12, and docs/FACTORY_CONTRACT.md + docs/factory_contract.json

(67 riders). Findings that died under self-attack are recorded in §"Refuted and dropped" rather than deleted.

Format exemplar followed: docs/pipeline_review/LENS_BG3_2026-07-27.md.

---

FINDINGS (15) — MISSING ×8 · WEAKER ×7

LOF-1 — The teaching order is repaired by hand, per chapter, with no contract and no tooth

Class: WEAKER (a real discipline with no home) · Priority: HIGH · Owner: spec-doc (factory-contract

rider, window-plan rank 2.5) + schema-data (rank 13) · Wave: pre-5090, before rank 13 freezes

What the title set proves. Fortnite's first-session funnel is tuned on tens of millions of starts, and its

core discipline is trivially portable: *a verb is never demanded before the beat that teaches it*, and the

teaching order is an artifact somebody owns, not an emergent property of content order.

Current state (cited). We know the discipline — we discovered a violation of it by hand. docs/FUN_REBUILD_PLAN.md

R4.3 "the teaching-order inversion fixed" (L175-182): *"today B03 asks the player to 'attune the breath' (a vril

action) before B04 teaches vril gathers back; order the unlocks to their diegetic causes: Ember Strike @ first

combat B03, Stone Skin @ first vril use B04, Tremor Stomp @ B08 … Cloaking pre-placed before the B05 evade OR the

first Ebu Gogo evade is tool-less (fun critic: Cloaking IS the evade tool, so evade-1 can't depend on it)."* That

is four ordering defects in ONE chapter, each found by a critic reading prose, none found by a gate. Nothing

generalizes the fix: docs/factory_contract.json carries 67 riders and zero on teaching/introduction order

(term counts over that file: teach 0, tutorial 0, onboard 0, first time 0; the two introduc hits are

FR-013 companion stat spreads and FR-052 naming). The data that would feed such a rider is itself empty — 153 of

185 abilities carry no unlock chapter (register entry 32; window-plan rank 13).

Positive control. Same file, same method: festival returns 5 hits (rider FR-039's festival-window

obligation) and difficulty 1 — the search can match rider text, so the zero on teaching is real.

Why it is the highest-value funnel finding. The slice IS the funnel: Ch 2-13 is what an EA buyer plays first

and the only thing they judge. Ch 2 got a hand pass because a fun critic happened to read it; Ch 3-13 are being

authored now by the same factory that has no rider for this.

Reuse-first recommendation. No new system and no new registry. (a) Add ONE rider to the existing register:

*"Declare the verbs this chapter first demands and the beat that teaches each; no beat may require a verb whose

teaching beat is later in the chapter's beat order."* Scope all, status SEED at v1 (advisory), lane

schema-data. (b) Give it a tooth inside gate 30 factory_contract by joining two tables that already exist —

T0_Ability_Tree_Registry.unlock_chapter/unlock beat (rank 13's own output) against DT_Beat order — so the

rank-13 data pass emits the ordering check for free instead of being retrofitted. This is exactly the

"ranks 13-17 emit rider rows at freeze time rather than retrofitting them" sequencing rule the window plan

already states for rank 2.5.

---

LOF-2 — The QA loop can measure the build's content and its combat feel, but not the player's progress through it

Class: MISSING (instrument class) · Priority: HIGH · Owner: qa-teeth (QS-0 / QS-13..18 / T2-6) ·

Wave: BUILD-NOW, and it must land with QS-0

What the title set proves. The single most transferable live-service artifact is not the battle pass — it is

the instrumented first session: time-to-first-verb, time-to-first-fight, where a first-timer stalls. It is a

number, produced by the same session that produces everything else.

Current state (cited). Our two measurement families both stop short of it. (1) Feel telemetry is combat-only:

docs/proposals/QA_WATCHING_PROGRAM.md §1.5 enumerates the funnels instrumented — RecordAttackPhase,

RecordPlayerAnswer, RecordInputLatency, RecordHitStop, RecordStagger, RecordCameraSample (QS-13..18 in

the §5 table). Every one is inside a fight. (2) The scorecard family counts CONTENT, not traversal:

docs/PRE_5090_BUILD_PLAN_VOL2.md QT-17 is "the measured budget vector read from the DTs" (sites, beats,

bosses, forks, minigames…) and QT-19 gates "content ≥ the chapter-band floor" — a per-node inventory, not a

player-progress read. The density ruling itself is a *completion-hours* target (VOL2 §A.1: ≈100-200h main) with

no instrument that observes an actual traversal's shape. The Tier-2 agent already walks the surface — the

charter schema T2-6 ships "finish-the-chapter" (§5 table) — so the traversal happens; nothing records where it

went slowly or where it stopped.

Positive control. Source/Humanity/Public/QA/ contains exactly three subsystems (BenchSampler, QACapture,

TerrainShot) and the only per-frame time field in QACapture is SessionId — the telemetry lane is still a

design, not code, which is the point below.

Why now. QS-0 is the ONE per-frame record schema and the program's own rule is that it "lands before any

C++" (§5 table, QS-0; §1.1 "before either lane's first line of C++"). A progression field family added now

costs nothing; added after both lanes are written it is a schema migration across two consumers. Under THE JOSH

GATE the AI loop is the only player of the funnel — an instrument it lacks is a question nobody can answer.

Reuse-first recommendation. (a) Extend the QS-0 per-frame vocabulary with a small progression group —

chapter_id, beat_id, objective_state, t_session_elapsed — beside the existing clock group

(frame_index, t_game, t_wall). (b) Add RecordProgressionMarker to the QS-13..18 funnel family, fired at

the beat-completion site UQuestSubsystem already owns. (c) Add one charter field to T2-6 so a

finish-the-chapter session emits per-beat elapsed. Per §1.5's own ladder it enters as a diagnostic and

becomes a tooth only by explicit graduation — no tuned number is gated on arrival, and the tuning firewall is

untouched. The honest first product is a baseline table, not a pass/fail.

---

LOF-3 — The player's only pre-Ch-13 continuity surface is blank at exactly the moment it is needed: it does not survive a save/load

Class: MISSING (persistence) · Priority: HIGH · Owner: engine-code (WS-3 save seam) · Wave: slice,

small

What the title set proves. A live-service title's first job on re-entry is to tell you where you were and

what changed. In a 100-200h premium campaign the same job is bigger, not smaller — the gap between sessions is

days or weeks, and an EA buyer returns per patch.

Current state (cited). The surface exists and is BUILT — this is not a design gap. Source/Humanity/Public/Discovery/HumanityClueSubsystem.h

header: *"The field-sense is a lightweight re-read of the last N in-place SENSATIONS — NOT a journal (HL_0070/HL_0096:

the journal does not open until Ch 13)… the held-key HUD overlay lists the last 5"*, bound to IA_QuestLog

(J / gamepad Back) at HumanityCharacter.cpp L1262-1283, designed at docs/FUN_REBUILD_PLAN.md R3.5. **But its

state is transient.** The subsystem's privates are TMap CluePlayerTextById, TSet<FName> FiredClues,

TArray<FString> Sensations (ring cap 16) with no Save/Load path, and Source/Humanity/Public/Quest/QuestSaveGame.h

persists exactly five fields — ChapterId, CompletedBeats, LocalFlags, ChosenForks, LastChosenForkId.

Two consequences follow mechanically: on resume the overlay is empty (the returning player's only "what have

I seen" read is gone), and FiredClues resets, so an already-fired clue can fire and toast again — the exact

idempotence defect PRE_5090_BUILD_PLAN_VOL2.md CN-6 exists to prevent for scenes ("a seen-scene set so scenes

are idempotent per playthrough"), one lane over and unnoticed.

Positive control. grep -rln "SaveGame" Source/ returns QuestSubsystem, WorldStateSubsystem and their two

SaveGame headers — the seam exists and is used twice; the clue lane simply was never enrolled. The zero is real,

not a search artifact.

Self-refutation attempted. *"The greybox seed re-populates it."* — SeedGreyboxSensations is chapter-scoped,

idempotence-guarded and explicitly a pre-DT_Clue dev seed ("the seed is consumed canon, not invented"); it

restores authored Ch-2 lines, not the player's own history, and it will be removed when DT_Clue imports.

*"Journal canon forbids persistence."* — HL_0070 gates the journal (Ch 13); R3.5 deliberately built a lighter

affordance below it. Persisting five sensation strings does not open the journal. Survives.

Reuse-first recommendation. Bump UQuestSaveGame to SaveVersion = 2 with two fields — FiredClueIds and

RecentSensations — and serialize them at the same call sites the quest subsystem already uses. No new save

slot, no new subsystem, no canon touched. It also closes the clue-side half of CN-6's idempotence contract.

---

LOF-4 — The ceiling tutorial teaches four faculties the early kit cannot inherit, and no verb lineage is declared

Class: WEAKER (structural under-specification) · Priority: HIGH · Owner: schema-data (rank 13) +

canon-author · Wave: before rank 13 freezes; the Prologue itself builds at slice-end

What the title set proves. A first session's job is to put the verbs you will keep into the player's hands.

Fortnite's opening minutes hand you the exact verbs of hour 300. Ours deliberately does the opposite — and that

is canon, not a defect. What the lens exposes is the craft rider that makes the inversion *work*: the taught

motion must have a recognizable descendant, so the muscle memory survives even when the power does not.

Current state (cited). docs/spine/CH_PROLOGUE.md L254: *"the four SOVEREIGN faculties are given in full as

the ceiling tutorial (Sovereign Vril Projection, Rift Sealing, Temporal Sight, Familiar Communion — T3_Core §6.4)

and are STRIPPED at the Ch-1 rift-fall (the player plays 75 chapters rebuilding toward them); no persistent

unlock carries past the fall (the ceiling is the reference, not a kept kit)."* The early kit it hands off to is

Ember Strike @ B03, Stone Skin @ B04, Tremor Stomp @ B08, Cloaking (FUN_REBUILD_PLAN.md R4.3) plus the

vril-recharge loop (R4.2). Of the four ceiling faculties, Familiar Communion has a live descendant (the Child

Familiar, docs/spine/CH_02.md CH02_B01), Temporal Sight's descendant Vril Sight is Ch-15-gated

(FUN_REBUILD_PLAN.md open item 4: registry unlocks A_E3_002 at "Ch_15 Zelator T2"), and Rift Sealing — the

Prologue's climactic set-piece (CHPRO_B09) — has no early-arc descendant at all until the Hollow/rift content

tier, which is ruled but unbuilt. Nothing anywhere declares the mapping.

Positive control. T0_Ability_Tree_Registry has no lineage/descendant column, and the ability data pass

(rank 13) is specced as "unlock chapters ×153, costs, cooldowns, classes" — no lineage field is planned, so the

column will not appear by accident.

Reuse-first recommendation. One column on the registry rank 13 is about to populate: ceiling_lineage on

each early ability, naming which Prologue faculty it is the depleted form of (and, at the far end, which

post-Ch-77 form restores it). It costs one enum-ish string per row, it turns the Prologue from a power fantasy

into a *promise the player can feel being kept*, and it gives the Prologue's build — which happens LAST, at

slice-end, per the ruled build order — a target instead of a blank page. Where a faculty has no descendant (Rift

Sealing), the column's emptiness is the finding, surfaced to the author rather than discovered in a playtest.

---

LOF-5 — The ruled event layer has no schedule schema and no data home; the schema it needs already exists one registry over

Class: MISSING (schema/data home for a RULED design) · Priority: MEDIUM-HIGH · Owner: schema-data ·

Wave: post-slice content, but the schema is free to mint now

What the title set proves. A season is a *schedule object*: windows with start/end, a repeat class, a

declared change, and a place. Everything else (economy, pass, storefront) is optional garnish that we have

already ruled out.

Current state (cited). The design is RULED and unusually well-specified — this is not DESIGNED-UNBUILT being

mislabeled: docs/spine/DECISIONS_PENDING_JOSH.md eighth sitting axis 6 (*"Hollow-driven LARGER EVENTS at every

scale: SOLO … TEAM (once the MMO releases), RANDOM world events, and SET-SCHEDULED seasonal or weekly

challenges"*), hardened at docs/pipeline_review/HOLLOW_EXPANSION_INTEGRATION_2026-07-27.md §1.6 with a real

tooth (*"Every scheduled event row declares a changed_law_ref, and a window reusing the immediately preceding

window's law FAILS the gate"*) and a naming policy at §8.5. **But changed_law_ref names a column on a row in a

registry that does not exist.** The same record states the zero: §1.6 *"GREENFIELD, positive-controlled.

Scheduled seasonal or weekly live-ops cadence has NO canon… Nothing in T1, CVD or T0 defines a rotation."*

The reuse nobody has noticed. registries/T0_Festival_Registry [DRAFT v0.1]/Sheet1.csv is **already the

schedule schema**, in production, with 16 rows: `festival_id, festival_name, tradition, region_id, chapter_range,

window_kind, window_spec, site_anchor, player_participation, gameplay_hooks, care_note, sources, notes` — and

window_kind is a live enum with real values (calendar_annual ×6, event_triggered ×5, pawukon_cycle ×3,

lunar ×1, daily ×1), player_participation another (opt-in-participate ×11, observe ×4, assist ×1).

That is a window model, a repeat model, a place anchor, a participation model and a care lane, already

critic-gated and already carried by factory-contract rider FR-039.

Care guard, stated explicitly. The Hollow record is emphatic that *"No Hollow event borrows, overlays, or

imitates a real living festival"* (§ care line, L1289). Cloning the SCHEMA into a separate registry is what

keeps that firewall intact — shared columns, disjoint rows, no possibility of a live-ops window landing on a

living tradition's row.

Reuse-first recommendation. Mint T0_Event_Window as a sibling of the Festival registry with the same

column vocabulary plus three: changed_law_ref (the §1.6 tooth), repeat_class (see LOF-7) and arena_scope

(solo / party / tier_c). Enrol both in docs/fk_spec.json on region_id/site_anchor. Zero new schema design

work; the §1.6 novelty gate becomes runnable the day the first row lands.

---

LOF-6 — Two clocks, unreconciled: real-clock live windows against an in-world festival calendar and a fixed story timeline

Class: MISSING (one spec clause) · Priority: MEDIUM · Owner: spec-doc (Tier C §7.3 + the Hollow

integration record) · Wave: with LOF-5

What the title set proves. Fortnite's calendar is real-world time and nothing else runs on any other clock,

which is why it never collides with anything. We are about to run two clocks at once and have not said so.

Current state (cited). Clock A is diegetic: festival windows are authored against the world's own calendar —

FST_0001 *"timed to the agricultural year (SHAPE only, exact window lands with the LW-3 runtime)"*, FST_0008/0011/0012

run on pawukon_cycle, FST_0009 on lunar. Clock B is real: the ruled event layer is "SET-SCHEDULED seasonal or

weekly challenges" — a wall-clock live-ops cadence. Nothing states which clock an event window reads, and the

collision is concrete: a solo player mid-Ch-3 (in-world dry season, walking geography, walked pilgrimage per

WGM §4/§6.7) receiving a real-clock seasonal rift window has two calendars asserting different truths about the

same world. The one law that *is* written protects completion, not fiction: the denominator rule

(HOLLOW_EXPANSION_INTEGRATION §1.7 THE OFFLINE TEST — "disconnect the machine and every Tier-A axis must still

reach 100%").

Reuse-first recommendation. One ruled clause, no machinery: **event windows are real-clock and enter the

world through the rift/Hollow layer only** — which is world-state, not story-time — while festival windows stay

on the in-world calendar and the story timeline never moves. The rift layer is already the canonically

non-narrative surface (T1_Vril §1 defines a rift as a pressure-threshold EVENT; the Hollow record §1.6 seats

events there), so the fiction is free. Implement as the window_kind value set on the new registry

(realtime_seasonal, realtime_weekly) held disjoint from the Festival enum, plus a sentence in the Tier C

§7.3 world-state-modulation section. This protects the narrative for exactly the cost of writing it down.

---

LOF-7 — Every event we have designed is repeatable; the one-time communal beat has no class

Class: MISSING · Priority: MEDIUM · Owner: schema-data (rides LOF-5) · Wave: post-slice

What the title set proves. The lesson WoW's raid cadence does not teach: the *unrepeatable* scheduled

spectacle — the thing that happened once, that you were there for or you were not — is the strongest memory

device live service has produced, and it is almost pure design cost (one authored beat), not art volume.

Current state (cited). Positive-controlled zero: a single regex over all **/*.md for

one-time event|non-repeatable|once-only event|event calendar|event schedule|weekly challenge|seasonal event|live-ops

returns 20 hits, every one on the recurring-window terms (PRE_5090_BUILD_PLAN.md L479, the Hollow record

L279/L1119/L1142/L1799, DECISIONS_PENDING_JOSH.md L247, COMPARATOR_LENS_PROGRAM.md L57/L115/L141) and zero

on the one-time terms. Same tool, same corpus, same query — the search could match and did, so the zero is real.

(Note for the critic: a naive FOMO search is poisoned — it matches *Fomorians* across the Celtic corpus.)

We already own the perfect vehicle. Axis 7's world cleansing meter is a threshold ladder

(DECISIONS_PENDING_JOSH.md axis 7; HOLLOW_EXPANSION_INTEGRATION §1.7), and a threshold crossing is by nature

a once-only world event. The denominator rule already guarantees a once-only live beat cannot punish a

completionist: live-ops cleansings "accumulate on a separate seasonal tally that never enters the completionist

denominator", and the OFFLINE TEST holds every Tier-A axis reachable at 100% offline. So the FOMO objection —

the reason one-time events are toxic in a premium single-player game — is *already answered by a ruled law*.

Reuse-first recommendation. Add repeat_class {recurring | seasonal | once_only} to the LOF-5 schema and

reserve one once_only beat per meter threshold. No new system, no new law, and the guard is pre-existing.

Stated plainly for the record: once_only may never carry an ability, a mastery lane, a completion denominator

row, or any Tier-A progression — it carries spectacle and memory, which is exactly what the lens teaches.

---

LOF-8 — Tier C names meta-collapse as its highest pressure and fields only two counterweights; the third is already half-built

Class: WEAKER · Priority: MEDIUM · Owner: spec-doc (one clause in Tier C §8.9) · Wave: post-slice,

free now

What the title set proves. Item-pool rotation is a live anti-meta lever: you do not nerf the player's build,

you change what the encounter asks. It is measurement's complement — sweeps *detect* collapse, rotation

*prevents* it.

Current state (cited). T1_Tier_C_MMO_Spec [ACTIVE v1.0] §8.9: *"Tier C carries the highest meta-collapse

pressure of any arena because server communities converge on shared solutions, so the two canonical

counterweights are the per-server strategy variation at §8.5, which keeps solutions plural across servers, and

the sweeps, which measure whether the plurality is real."* Both are real; neither *changes* anything at runtime.

Positive-controlled zero on the third: rotation across docs/**/*.md returns 20 hits and not one is an

item/ability pool rotation — they are combat win-condition/verb rotation (COMBAT_ENCOUNTER_SYSTEM.md L81-82),

agility-course biome rotation (L431), sun rotation (ENGINE_OPTIMIZATION_DOCTRINE.md L976), familiar-roster

rotation (INGEST_GDD.md L101) and subscription-account rotation. The Hollow record states it independently:

"Nothing in T1, CVD or T0 defines a rotation."

The divergent half, stated so it is not proposed. Rotating the *player's* pool — nerfing or vaulting builds

between seasons — is flatly incompatible with the premium single-player posture, the anti-grind ruling and the

AAAAA doctrine's "mathematically-OP builds allowed" (COMBAT_PROGRAM_ADDENDUM.md §10). Not recommended, at

either tier.

Reuse-first recommendation. Rotate the encounter's law, not the player's kit — which the event layer's

changed_law_ref tooth already does by construction (§1.6: each window changes one rule of the site's law,

reusing the realm signature-law grammar). Two sentences of work: (a) name the event layer's law rotation as the

third canonical counterweight in Tier C §8.9; (b) extend the §8.9 sweep clause so viability breadth is

scored *per active law window*, not only in aggregate — a build that is dead in every window is a defect the

current aggregate sweep can hide. Machinery: none new; both halves exist.

---

LOF-9 — Tier C promises an entry path for a player who has never played the game, and the entry architecture being decided this month does not know they exist

Class: MISSING (spec) · Priority: MEDIUM (timing-critical, not player-impact-critical) · Owner:

josh-brief (rides window-plan rank 18's bundled brief) + spec-doc · Wave: now, because it is cheap now

What the title set proves. One account, one identity, one progression spine across genre-different modes is

the commercial proof of the Tier-A/B/C reuse bet — and the funnel INTO each mode is designed separately, because

the player arriving at Festival has not played BR.

Current state (cited). T1_Tier_C_MMO_Spec §3.3 makes the promise explicitly: *"A player who has never

completed Chapter 1 can participate in Tier C World Bosses, territory control, and competitive PvP."* The shared

spine is genuinely designed (§8.7 one role taxonomy read at two arena sizes; §8.9 the single-player party as raid

training ground; §12.2 Magus prerequisites reading Tier-A Magister Templi), which is a real COVERED. What is

absent is the cold start: what abilities, mastery level, weapons, familiar slots or character-creation surface a

never-played-Ch-1 account holds when it walks into a 100-player World Boss. Positive control: over the whole

spec, new player matches once (§8.4 "casual and new player difficulty floor in the region lowers" — a kill

benefit, not an entry spec) and entry point/onboard/starting state/character creation return zero, while

the control term guild returns 66 — the doc is searchable and the zero is real.

Why the timing matters more than the priority. The entry architecture is being decided in this window:

PRE_5090_BUILD_PLAN.md (window-plan dependencies) carries P2.11 character creation "and the prepend-safe entry

architecture… with the selection surface becoming the returning-player skip path", and states the economics

outright: *"The mechanical half is cheap NOW and expensive after players have saves."* A Tier-C cold start is a

third entry state into the same surface. Adding it to that decision costs a bullet; adding it after shipped

saves costs a migration.

Reuse-first recommendation. Do not spec Tier C. Add ONE line to the P2.11 entry-architecture item in rank

18's bundled brief: the entry surface serves three states — new campaign, returning player (skip), and

(deferred, Phase 7+) Tier-C-only account — so the architecture is *shaped* for the third even though it is not

built. Then one sentence in Tier C §3.3 naming the cold-start spec as an explicit Tier-C-build-phase item, so

the promise is not read as covered.

---

LOF-10 — The minigame galaxy has no festival, event or arena link — and the data already contains the join

Class: WEAKER · Priority: MEDIUM · Owner: schema-data (window-plan rank 30 populates this registry) ·

Wave: with rank 30

What the title set proves. Cross-mode reuse is where live-service content economics actually come from: one

spine, many surfaces. Our minigame galaxy is the closest thing we own to a library of self-contained,

replayable, low-art-cost activities — which is exactly what an event window needs.

Current state (cited). docs/proposals/systems/minigame-galaxy.md §5 specs the MG_ schema with four FK

lanes — chapter_id, region_id, boss_link (boss-as-game fusion), situation_link (the WS6 era-rhyme

registry) — and §2.7 defines ~6 reusable engine families so games ship at quality. There is **no festival link,

no event link and no arena scope**; a grep for Tier C / MMO / event routing over that file returns nothing.

Meanwhile the join already exists in the live data, unmodelled: T0_Festival_Registry FST_0004 is *"Caci contest

season"* (window_kind = event_triggered, `gameplay_hooks = "the whip-and-shield contest circuit; seats the

player's first off-hand Shield (WPN_033) and grounds the CH_03 main-boss PARRY verb; climb for community

standing and reward"*) and T0_Minigame_Registry MG_0001 is *"Caci (whip-and-shield honour duel)"*, tier

marquee, engine family duel-parry, same region, same chapter. Two registries describing one activity with no

key between them. Registry state: Festival 16 rows / 4 regions; Minigame 2 rows — rank 30's "populate the six

1-3-row system registries" is where the schema is decided.

Reuse-first recommendation. Before rank 30 populates it, add two columns to the proposed MG_ shape:

festival_link (FK → T0_Festival_Registry, null default) and arena_scope (tier_a | tier_c | event,

default tier_a). Enrol festival_link in docs/fk_spec.json so a mis-named key fails loudly per the repo's FK

discipline. That single tag turns the marquee/structured tiers into the event layer's ready-made content pool

(an event window can *be* a caci season or a patolli tournament) with no new content authored, and it makes the

existing caci relationship checkable instead of implicit.

---

LOF-11 — Achievements are declared as a ship feature with no design, and they will be minted at P4 under launch pressure against three doctrines they can violate

Class: MISSING (design) · Priority: MEDIUM · Owner: spec-doc + zero-token-script · Wave: declare

now, build at P4

What the title set proves. The transferable half of a battle pass is not the purchase — it is the **legible

finite ladder**: visible progress with a declared end. That half is free of the economy we have rejected.

Current state (cited). docs/ROADMAP_POST_5090_TO_SHIP.md P4 lists Steamworks integration —

*"achievements, cloud saves over the existing WorldState SaveGame stack, the overlay, and controller/input"* —

and the P4 exit requires "Steamworks features function (achievements/cloud-save/overlay/input verified by the QA

fleet)". No achievement design exists anywhere. Positive control: achievement across all **/*.md returns

hits that are (a) this P4 line, (b) T1_Combat_System_Spec L300/L308/L336 agility-course "cosmetic achievements

with integrity-band variants" in MMO contexts, (c) HOLLOW_ADMISSION_BRIEF L47 listing "achievements" among

surfaces the descriptive-naming policy must carry, and (d) dozens of ordinary-English uses in the region corpus

("the Ile-Ife achievement") — the term is highly matchable, so the design zero is real. Three doctrines are in

the blast radius: the no-scoreboard/integrity-invisible rule (FUN_REBUILD_PLAN.md R5.2 — no integrity number on

any surface), the cleansing-meter denominator rule and its offline test, and CVD §17.12's ratified minigame

top-score completion.

Reuse-first recommendation. Do not author an achievement list. Derive it: the legible ladders already

exist and are already gated — the minigame bronze/silver/gold + platinum-ghost spine (minigame-galaxy.md §2.2)

and the "Games Master" chase (§2.4), the twelve mastery levels with their 5→6 and 11→12 questline gates, the

cleansing meter's thresholds, and the trade gates. Add a steam_achievement boolean (or a derived-list emitter

script) on those existing rows and generate the Steam list from the registries at cook time, the same way the

checklist is emitted rather than hand-typed (harness/emit_chapter_checklist.py is the working precedent). A

derived list cannot drift from canon and cannot invent a scoreboard the doctrine forbids. Declare the

constraint now — one paragraph in the P4 section — so it is not decided at launch.

---

LOF-12 — No player-expression verbs — and the capture machinery to build one already ships in the QA lane

Class: MISSING · Priority: MEDIUM-LOW for Tier A, rising to HIGH the day Tier C exists · Owner:

spec-doc + engine-code · Wave: post-slice

What the title set proves. Emote / pose / showcase / photo is a retention and community surface with zero

power attached — the cleanest possible separation of expression from progression, and the aspect the roster

itself flags as uncovered (COMPARATOR_LENS_PROGRAM.md cluster note: *"MISSING ASPECT: player expression verbs

(emote/pose/photo/showcase) — distinct from presentation/identity"*).

Current state (cited). What we have is *creation-time* identity, not expression: CVD §8.1 four selections and

T3_Core_Characters L77 "standard appearance customization across face, body, skin tone, hair, clothing, and

gender presentation", explicitly kept brief by §8.3 ("long character creation surfaces… commit the player to a

protagonist they have not yet met"). Positive-controlled zero on the verbs: `photo mode|photomode|emote|

transmog|wardrobe over all **/*.md returns only MetaHuman *wardrobe* (asset pipeline, T99_Translation_UE5_Build.md`

L193) and cosmetic *titles* (T1_Combat_System_Spec L300-336) — the query matched adjacent vocabulary, so the

zero is real. T1_UI_UX_Spec [DRAFT v0.1] is a byte-level empty stub (register entry 22; window-plan rank 20),

so there is not even a home.

Devil's advocate, against timidity. The instinct here is to treat expression as a §17.1 risk and defer it.

That is the timid read and it is wrong twice over: this is a rated-M game whose players will photograph

everything regardless, and *expression is how a player says what a place meant to them* — the thesis surface,

not a threat to it. The care work is data (which gestures a site's own tradition would recognize as respect),

not prohibition; the answer is a site-appropriate verb set, never a lock.

Reuse-first recommendation. Reuse the already-built capture stack: Source/Humanity/Public/QA/HumanityQACaptureSubsystem.h

already owns the screenshot path, station framing and a manifest writer. A player photo mode is that subsystem

with a player-facing camera and the debug overlays suppressed — an ENGINE harvest for game #2 by the standing

reuse goal. For gestures, seat a small observance/expression verb set on the existing persona + site data rather

than a cosmetic store, and let the site's care_tier (already a column on both the Festival and Minigame

registries) drive which gestures a place recognizes. Land the spec in T1_UI_UX_Spec when rank 20 authors it,

so it does not need its own doc.

---

LOF-13 — Early Access is a cadence product and we have four launch lanes, zero update lanes

Class: WEAKER · Priority: LOW-MEDIUM · Owner: spec-doc (a fifth lane in the existing marketing

program) · Wave: P4-adjacent

What the title set proves. The strict live-service half is divergent for us, but one structural fact is not:

a released-but-unfinished product retains players on the strength of a visible, kept update rhythm. The

rhythm is the retention mechanic; the storefront is not.

Current state (cited). The EA posture is ruled and firm: ROADMAP_POST_5090_TO_SHIP.md P4 — *"the Early

Access base is the full 15-node slice. No early cut"* — with honest framing rules ("the first 15 nodes,

complete," never "a sample"). The public surface program docs/MARKETING_WEB_PROGRAM.md defines exactly four

lanes — Capture, Asset, Web skeleton, i18n — all launch-asset lanes; a grep for `cadence|patch|update|roadmap|

community|discord` over that file returns only the positive-control note recording what does NOT exist and one

pointer to P4's store page. P4's own exit criterion stops at "a day-0 patch path exists and runs through the bug

ledger". So: how often anything ships after launch, what a buyer is promised, and where that promise is

published have no home.

Reuse-first recommendation. No new program. (a) Add a fifth lane to the marketing program — *update beats*:

a public roadmap page and a per-release note, generated from the artifacts that already exist (the bug ledger's

fixed set and the progress ledger). (b) Name the cadence UNIT we already own: ROADMAP_POST_5090_TO_SHIP.md P5

is "the chapter factory: the proven pipeline, per chapter, for 60-plus" — one chapter is one update, which is

a rhythm no other studio could offer and which is exactly the promise an EA buyer of a 15-node slice wants.

(c) Keep the P4 business brief that already exists (go-live timing) as the owner of *dates*; this lane owns

*structure*. No date is invented here.

---

LOF-14 — Nothing in the pacing stack describes a SITTING

Class: WEAKER · Priority: LOW · Owner: qa-teeth (a derived read on the existing QT-17 scorecard) ·

Wave: with LOF-2

What the title set proves. Fortnite's atomic unit is a match: a bounded, legible, self-contained sitting with

a clean stop. A campaign cannot copy that, but it must answer the same question — what does one evening contain,

and where can I put it down?

Current state (cited), and the dedupe. Register entry 9 (rest / safe-site session-anchor loop) already owns

the *anchor* half and is not re-reported; Josh's ruling gives it teeth (vril sites = save + recharge + loadout

sanctum, factory rider "Let this chapter's vril sites serve as loadout sanctums", status PARTIAL). What no entry

covers is the *read*: every pacing instrument we have is either arc-scale or chapter-scale. CVD §16.1 is the

mountain range across 77 chapters, §16.2 mode variety per chapter, §16.3 anti-staleness across the arc; the

density model is completion-hours (PRE_5090_BUILD_PLAN_VOL2.md §A.1, ≈100-200h main); QT-17 counts per-node

content. There is no unit between "beat" (minutes) and "chapter" (many hours), so nothing can be asked whether a

sitting ends somewhere satisfying.

Reuse-first recommendation. Derive it, do not design it. QT-17 already reads DT_Site, DT_Beat and the

anchor sites per node; add a derived column — beats-between-anchors, and anchor count per node — reported (never

gated, per the tuning firewall) beside the existing budget vector. Combined with LOF-2's elapsed markers it

answers "how long is the walk between stop-points" with arithmetic on tables that already exist. If the number

is ugly the fix is content placement, which the factory already does per chapter.

---

LOF-15 — The event layer's novelty tooth is unbounded authoring cost, and the record already warns about the sibling case

Class: WEAKER · Priority: MEDIUM · Owner: spec-doc / canon-author · Wave: with LOF-5

What the title set proves. Fortnite's rotation works because the pool is FINITE and re-combined — novelty per

window comes from selection and combination, not from authoring a new thing every window. A studio of one cannot

run any other model.

Current state (cited). The tooth is good design and the record even argues its economics: HOLLOW_EXPANSION_INTEGRATION

§1.6 — *"Each event window changes one RULE of the encounter — the site's law… Every scheduled event row declares

a changed_law_ref, and a window reusing the immediately preceding window's law FAILS the gate… Novelty by rule

costs design time rather than art time, which is the right trade for a solo build."* But nothing bounds the law

POOL, so at weekly cadence the gate demands a fresh law indefinitely. The same record names exactly this hazard

for the naming lane and calls it out honestly — *"THE DISCLOSED PERPETUAL COST… a seasonal calendar authored

against a marketing cadence generates player-facing vocabulary indefinitely, and each new season needs its own

§17.1 read"* (§8.5) — and does not extend the observation to the law lane, which has the same shape.

Reuse-first recommendation. Bound the pool and rotate combinations, exactly as the lens teaches. Declare the

law set as a finite, versioned enum drawn from the realm signature-law grammar the road already authors (the

same grammar §1.6 cites), and restate the gate as *no repeat within N windows* over the declared enum rather

than "never reuse the previous law". Then novelty is laws × sites × repeat_class — combinatorial, measurable,

and payable by one person. Land it as a note on the changed_law_ref column definition when LOF-5's registry is

minted; it is one sentence and it is the difference between a cadence that runs and one that stops in season 3.

---

COVERED — where this lens finds us already good (so the audit is not read as "everything is missing")

consequence*, which is the stronger version of the same value: five world-state versions per location

(ENTITY_PERSONA_SYSTEM.md L100 world_state_variants; CANDIDATE_RESOLUTIONS.md L227 WS1 Luminous → WS5

Corrupted; INGEST_GDD.md L124 "77 regions, each with 5 world-state versions by integrity"), plus the Ch 59-65

revisit arc showing ground "recovered or damaged by the protagonist's own earlier choices" and persistent

walked geography. COVERED, and better.

arenas), §8.9 (single-player party as raid training ground), §12.2 (Magus reads Tier-A Magister Templi). The

reuse bet Fortnite proves commercially is architecturally in place; only the cold-start entry (LOF-9) is open.

difficulty dial is the fairy realm's reach measured as vril density, five named tiers, "the dial is ONLY vril

density; NEVER HP / damage / resistance inflation", plus judgment-free always-available Attunements that gate

no content (docs/proposals/DIFFICULTY_SYSTEM.md, RULED and CLOSED). Different mechanism, same function.

participation modes, care notes per row, carried by a factory rider. Most single-player RPGs have nothing here.

and the offline test; the minigame bronze/silver/gold + platinum-ghost spine and "Games Master"; twelve mastery

levels with quest gates. The transferable half of a battle pass is already ours — LOF-11 only asks that the

ship surface be derived from these rather than re-invented.

A (the Ch-2 opening asks a buyer to grieve a familiar they never chose) and §8.2, resolved by the ruled EA

boundary (origin ships first, in designed order, for every buyer). The funnel's *content order* is ruled; LOF-1/2

address its *discipline* and its *measurement*, which the ruling does not touch.

DIVERGENT-BY-DESIGN (pre-registered; not re-litigated)

construction (COMPARATOR_LENS_PROGRAM.md L57) against the ruled premium/EA + permanent-discount posture.

balance doctrines (COMBAT_PROGRAM_ADDENDUM.md §10: OP allowed, meta-collapse banned). Only encounter-law

rotation is proposed (LOF-8).

(CVD §17.12 ratifies minigame top-score completion as the exception, and LOF-11 respects it).

Tier-A completion hostage; LOF-7's once_only class is bound by the same law.

Refuted and dropped (attacked before writing; these died)

1. *"No re-entry / recap surface for a returning player."* — REFUTED by the built repo. The field-sense

overlay ships (HumanityClueSubsystem + IA_QuestLog held key + HumanityPlayerHUDWidget FieldSense rows,

FUN_REBUILD R3.5), and the HUD carries a QuestObjective line. Only the persistence half survived → LOF-3.

2. *"No onboarding/teaching design at all."* — REFUTED. FUN_REBUILD R4.1/R4.2/R4.3 are teaching-beat design

of real quality. The finding narrowed to the missing *contract* → LOF-1.

3. *"No difficulty or accessibility model."* — REFUTED. DIFFICULTY_SYSTEM.md is RULED and CLOSED with a

separate assist layer.

4. *"No in-world calendar / seasonal rhythm."* — REFUTED. T0_Festival_Registry with a live window_kind

enum; it became the reuse target for LOF-5 instead of a gap.

5. *"The event layer is missing."* — REFUTED as MISSING; it is RULED and specified (axis 6 + §1.6 with a

novelty tooth). Only its schema/data home and its schedule model are absent → LOF-5/6/7/15.

6. *"World mutation is missing."* — REFUTED. Five world-state versions per location (see COVERED).

7. *"Cross-mode progression continuity is missing."* — REFUTED. Tier C §8.7-§8.9 + §12.2. Narrowed to the

cold start → LOF-9.

8. *"A completionist ladder is missing."* — REFUTED. Cleansing meter + Games Master + mastery gates.

9. *"One-time events are FOMO and should not be proposed."* — self-refuted the other way: the denominator

rule and offline test already neutralize the objection, so declining to propose it would have been the timid

error the care doctrine warns about.

Section counts

Boundary stated honestly per finding: LOF-2 and LOF-5 are MISSING *inside* programs that exist and are strong

(the QA watching program; the ruled Hollow event layer) — the absent thing is an instrument class and a data

home respectively, never the design. No finding reports a DESIGNED-UNBUILT item as MISSING.

rank 18); everything else is execution within the locked vision.

subsystem or program.

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