READ THAT CANON FIRST — open it and derive from it before you build anything from this document.
If this document disagrees with canon, CANON WINS and this document is the defect — fix the
document, never the canon. Nothing here is applied until it is ratified into canon.
Proposal, cascade v2.4, DRAFT. Architecture only — this invents no canon and edits no canon doc. It proposes the schema, the state model, the generation strategy, the registry wiring, and the phased build plan for the layer Josh named on 2026-07-08: every entity — person, faction, animal, place, and thing — carries a detailed persona (personality, background, history, its own life), and every faction/NPC/ally/enemy carries a relationship status that the player's integrity and decisions evolve, opening and closing opportunities but never blocking or gating progression. Josh authors chapter, numerical, naming, hard-line, and Component canon; this proposes the grounded structured framework for his confirmation. Every mechanism traces to an existing system, registry, or CVD anchor, cited inline.
Amended 2026-07-30 — the DAILY-RHYTHM AXIS. Section 5.2 gained subsection 5.2.1: the
machine-readable projection of own_life (schedule states, home and work sites, presence windows,
occupation and trade), the two child tables that hold a rhythm one row cannot (T0_Persona_Schedule,
T0_Persona_Bucket), and the ambient-population band on the Zone Catalog and Region_Index rails.
The amendment closes the SCHEMA half of DESIGN_GAP_REGISTER GAP-139 (CRITICAL, npc-simulation)
before rank 11 mints, so a persona is authored once against the complete shape rather than authored
and then retrofitted. It authors no persona content and mints no registry.
0. Why this exists, and what it is not
Josh set the depth mandate directly: the game's content goes far beyond the 30M-word chapter spine, to roughly 90-120M words once the dictionaries, lore, creative bibles, per-entity descriptions, dialogue choices, and story paths are counted (every-entity-detailed-persona-nonblocking-paths). Every entity the player meets, fights, tames, walks through, or picks up has its own life. And the living, faction, and ally/enemy entities carry a relationship that the player's integrity and choices reshape — opening and closing opportunities — under one hard rule: it never blocks or gates progression, because people need to be able to play through in different ways.
This document is the architecture for that layer. It is a downstream tier: the Story Spine and the T0 registries anchor every entity with a canonical row, and this layer is the creative-bible expansion of those anchors plus the relationship engine that makes them react. It is deliberately the counterpart, on the entity side, to what SIGNIFICANCE_LENSES.md is on the region-weave side and what RELATIONSHIP_COMBAT_SYSTEMS_NOTE.md flagged on the systems side — the three compose into one lens on the same world.
What this is not: it is not a rewrite of any existing system. The integrity, path, world-state, mark, faction-standing, and six-option-dialogue architecture is already canonical and fully specified at T1_Integrity_Paths_Worldstates_Master; the runtime strategy-token layer over every entity is already designed at docs/RUNTIME_GENERATIVE_LAYER.md; the significance lenses and their relevance filter are already proposed. This doc composes those into the persona-and-relationship layer, adds only the connective structure they leave open (the persona schema, the opportunity model, the non-gating invariant, the persona registry and doc set), and holds the do-not-invent line throughout.
1. The two things this layer adds
The layer has exactly two deliverables, and everything below serves one of them.
The persona — a detailed creative bible per entity: who or what it is, its personality, its background and history, its own life and daily rhythm, its motivations, its relationships to other entities and to the player, its voice or perceptual register, the significance lenses it embodies, and its place in the relational web. The persona extends an anchor registry row; it never replaces it.
The relationship / integrity / opportunity engine — the runtime state that evolves an entity's disposition toward the player from the player's integrity and decisions, and that opens and closes opportunities as a function of that relationship, the integrity band, and the mark the protagonist has left, while guaranteeing that no opportunity ever gates progression.
2. The persona schema
2.1 The premise — the persona extends the anchor row, it does not replace it
Every entity already has, or will have, exactly one canonical anchor row in a T0 registry: persons at T0_Character_Index (118 rows) and antagonist operatives at T0_Antagonist_Network_Registry (62 rows), creatures at T0_Creature_Roster (132 rows), places at T0_Region_Index (67 rows), and things distributed across T0_Weapon_Registry (72 rows), T0_Vril_Site_Registry, T0_Inscription_Spine, and the Thread-20 sacred-object content. The anchor row is the canonical skeleton — the FK-clean identity, the chapter assignment, the thread involvement, the hard-line and care-band flags, the voice reference. It is the do-not-invent surface: Josh authors it, the harness verifies it, and the fidelity gate protects it.
The persona is the creative-bible expansion of that row. It is a structured document, one per entity, that grows the row's terse fields into the full life the mandate calls for. The relationship between them is exactly the relationship between a Character_Index row's voice_signature_notes cell and the actual authored voice of that character across a chapter — the cell anchors, the persona realizes. The anchor row stays the single source of canonical fact; the persona is downstream of it and can never contradict it (the same containment the runtime context pack enforces, where the LLM voices a character but owns zero of their facts, RUNTIME_GENERATIVE_LAYER §A.2).
2.2 The common persona spine — the fields every entity carries
Every persona, regardless of class, carries a common spine of thirteen fields. The class-specific extensions in §2.4 add to this spine; they never remove from it.
anchor_ref — the FK to the entity's canonical registry row (character_id, operative_id, creature_id, region_id, weapon_id, and so on). This is the persona's identity and its do-not-invent tether; the persona owns no fact the anchor row does not already carry or that Josh has not authored.
identity — the entity's name under its own self-naming per §17.1 (no stereotyped descriptor, and for cultural entities the culture's own term), its class, and a one-line essence of what it is.
significance_lenses — which of the 33 significance lenses the entity embodies, drawn from SIGNIFICANCE_LENSES.md §2, with the primary lens marked. A creature registers under Ecology-and-fauna; a diviner under Esoteric-and-occult plus Philosophy; a sacred stone under Sacred-landscape plus Sacred-objects. The lenses are how the persona connects to the arc rather than sitting as museum-flavor, and they are the relevance ticket in §2.3.
web_position — the entity's edges in the relational web (regions-are-relational-webs-not-villages): for a person, kin, teachers, faction ties, rivalries; for a place, its trade partners, allies, enemies, and neighbors; for a creature, its ecological relationships and its bonded-familiar edges; for an object, its lineage of holders. Each edge points to another persona or registry row, mirroring the Cross_Cultural_Link_Graph edge model.
background_history — the documented real-world grounding (per the primary-source record, Frame A, no hyperdiffusion) plus the in-world backstory that places the entity in the arc. Grounded content only; do-not-invent binds, so where new backstory would touch chapter, naming, or hard-line canon it is flagged, not authored.
own_life — the entity's daily rhythm and independent existence, class-shaped: a person's routines and season; a place's markets, calendars, pilgrimage cycles, and world-state drift; a creature's ecological niche, territory, and migration; an object's life as a used and inherited thing (the keris passed down and charged as pusaka across generations, per Thread 20). This is the field that makes the world feel populated rather than staged. The prose here stays the authority on what a life MEANS; its machine-readable projection is the daily-rhythm column set in 5.2.1, which is what a runtime component can actually read.
motivations — the entity's goals, drives, and needs; for a person, what they want and fear; for a faction, its campaign objective; for a creature, its survival and territorial drives; for a place, the pressures acting on it; for an object, what it is for and what it seeks (a legendary weapon's condition of use).
personality — the disposition prior: 4-8 terse traits and a temperament, in exactly the form the runtime context pack consumes (RUNTIME_GENERATIVE_LAYER §2.1 persona card). For non-living entities this is the entity's character-of-place or character-of-object — a mountain's austerity, a market's clamor, a blade's hunger.
voice_register — how the entity is heard or perceived: a person's speech register and their six-option dialogue coloring per §2.4; a place's atmospheric read; a creature's vocalization-and-behavior flavor; an object's inscription-and-lore voice. References T0_Voice_Registry where a synthesized voice exists.
relationships_to_player — the entity's relationship-status coupling: whether it holds a relationship ledger with the player at all (persons, factions, companions, bonded creatures do; ambient objects and most places do not), its starting disposition, and which opportunities its relationship gates. This field is the hinge into §3.
care_band — the §17.1 care tier (standard / elevated / high-care) and the protected-status flag, resolved from T0_Hard_Lines. High-care and elevated-care entities carry the stricter authenticity bar and, for the runtime layer, the authored-only-at-launch default (RUNTIME_GENERATIVE_LAYER §A.2 recommendation).
layer_surfacing — how the entity appears across the three layers (Pillar 12): its Layer-1 playable presence, its Layer-2 investigatable depth, and its Layer-3 substrate meaning, never declared. A persona that has no Layer-1 or Layer-2 presence is Layer-3 texture and is scoped accordingly.
runtime_binding — which of the six runtime entity classes the entity binds to (RUNTIME_GENERATIVE_LAYER §A), its strategic-tick cadence, what is authored versus generated for it, and its authored fallback. This is the field that connects the persona to the on-device generative delivery in §4.4.
2.3 The relevance gate — not every entity earns a deep persona
The mandate is depth, not sprawl. The same five-gate relevance filter that bounds the region weave (SIGNIFICANCE_LENSES.md §4) bounds persona depth, so effort follows significance. Persona depth is tiered:
Flagship personas — full creative bibles: the protagonist, the companions and familiars, the main antagonists and Cassius Velheim, the Grand Sage, the high-care community teachers, the boss personas, the legendary species, the flagship regions, and the named legendary objects. Authored, Josh-in-loop for the high-care set, critic-gated.
Supporting personas — substantial but bounded: the per-chapter teaching NPCs, faction operatives, recurring allies, significant sites, and chapter-anchored creatures and objects. Grounded expansion, critic-gated, mostly build-generated against the anchor row and the enrich pack.
Ambient personas — thin, pooled, and largely templated: crowds, vendors, background townsfolk, common fauna, incidental objects. These bind to the runtime Class-1 pooled model (a crowd of forty sharing six persona buckets, RUNTIME_GENERATIVE_LAYER §A.1); they get a persona bucket, not an individual bible. The bucket's row home is T0_Persona_Bucket (5.2.1), keyed from the region page's Section-4 people-and-culture prose and its Section-12 role entries, so a pooled crowd is a roster rather than an unrowed intention.
The gate assigns a tier to every entity: an entity that clears the real-tie, lens, arc-service, layer-fit, and care gates at high value earns a flagship or supporting bible; one that clears only the ambient bar gets a bucket. Nothing that fails the care-and-Frame-A gate is kept-and-sanitized — it is cut, per the Gate-5 discipline.
2.4 The five authoring classes and their extensions
Josh named five entity classes — person, faction, animal, place, thing. Each maps onto the runtime taxonomy's six classes (RUNTIME_GENERATIVE_LAYER §A, which splits person into ambient / named / partner and treats environment as its own class) and onto a home registry. Each adds a class-specific extension to the common spine.
2.4.1 Person
Home registry: T0_Character_Index, with antagonist operatives cross-referenced to T0_Antagonist_Network_Registry. Runtime classes: 1 (ambient), 2 (named), 4 (partner/companion/familiar-handler). Extension fields:
age_stage_presence — which of the protagonist's three age stages the person appears in, and how they age across revisits (a cousin of someone helped at Ch 11 responds differently at Ch 39, per §4.9 accumulation).
faction_affiliations and awareness_tier — the person's faction ties and, for an operative, their House-of-Velheim awareness tier (UNAWARE through the inner council), governed by the pattern-reveal discipline: the player does not perceive the family behind the institution until roughly the modern chapters (antagonist-pattern-reveal-timing).
teaching_role — the trade home base, ability, or worldview the person teaches, if any, and the mastery-tier progression they gate. The occupational fact itself is normalised onto occupation_ref and trade_ref (5.2.1) rather than left inside the role slug, so the question of who practises a trade here, at which site, on what rhythm has an answer a query can reach.
six_option_register — how this person's dialogue realizes the canonical six options (Truly Good, Truly Bad, and the four biography-shaped: Sympathetic, Detached, Curious, Defiant) in their cultural and personal register per §6 of T1_Integrity_Paths.
assimilation_stance — the person's role in the concealment arc: whether they extend trust and take the protagonist in, whether they read her vital force and hold her secret in confidence (the babalawo pattern) or turn it against her (a hostile recognizer), and whether the culture's morally-complex practice makes this person the site of an assimilation-integrity choice per §5.5.
companion_or_familiar_mechanics — for a traveling companion or a familiar handler, the bond-progression and shared-combat behavior, deferred to the registry per-slot mechanics as the spine already defers them.
The living-faithful protection binds this class hardest: a faithful community member is never a combat target and never the antagonist, and no sacred proper name sits on a mortal (the Kxao rule) and no revered real person is recast as a villain (the Liqä rule) — §17.1.
2.4.2 Faction
Home registry: T0_Antagonist_Network_Registry for the Velheim apparatus; protected communities and other groups are carried as faction rows referenced from T8 region pages Section 8 and from Character_Index faction_affiliations (there is no standalone faction registry today — see §5.2). Runtime class: 5 (societies/factions), the strategic heart of the generative layer. Extension fields:
sector_and_operational_type — for a Velheim faction, its inner-council sector and its operational category (the six modern operational types); for a community, its institutions and social order.
faction_intent_repertoire — the authored enum of postures the faction can hold toward the player (surveil, pressure, intercept, entrench, retreat, negotiate), the closed vocabulary the runtime director selects among (RUNTIME_GENERATIVE_LAYER §A.5). A faction never invents an intent outside this set.
standing_model — how the player's treatment of this specific group moves its standing, independent of the protagonist-level integrity score (§8.7): high standing with one faction may produce low standing with its rivals, because faction relationships are locally real, not symmetrically modeled.
member_roster — the persona edges to the named persons who belong to or lead the faction.
protected_wall — the hard, deterministic marker for a protected community: it has no faction_intent that can target the player as combat; where combat reaches a protected space it is antagonist intrusion, and at Ch 57 the faction director is disabled entirely (§17.1; RUNTIME_GENERATIVE_LAYER §A.5). This is a wall, not a generated policy.
2.4.3 Animal / creature
Home registry: T0_Creature_Roster (132 rows, already carrying folklore_behavior_substrate, folklore_attribution_source, integrity_visible_aesthetic_shift, and vril_substrate_response columns). Runtime class: 3 (fauna). Extension fields:
species_and_tier — species class, tier classification, and legendary-versus-regional status; familiar-slot eligibility and Trade-8 tameability.
folklore_behavior_substrate and attribution — the culture's documented mythological behavior where it diverges from documented zoology, always with its primary-source attribution, the discipline that keeps a creature off generic-monster slop (§8.9.4; HL_0002).
substrate_responses — the creature's integrity_visible_aesthetic_shift (how it reads the protagonist's integrity band, from reduced flight distance at Truly Good to active withdrawal at Pure Evil) and its vril_substrate_response (how it reads regional vril density). CORRECTED 2026-08-14, because the earlier wording said both were "already canonically specified at §8.9" and that is half true in a way that cost a build. What §8.9.2 of T1_Integrity_Paths_Worldstates_Master specifies is the FAUNA-WIDE LADDER — five bands, five named behavioural registers, and an explicit prey-versus-predator fork at L5 — and it specifies it completely. What is NOT specified is the per-species cell: measured on the live registry, integrity_visible_aesthetic_shift is filled on 0 of 187 rows, as are vril_substrate_response, spawn_rate, and vril_density_modifier. Twenty-five bestiary sheets had already independently boarded that gap. So the runtime reads the fauna-wide ladder as the DEFAULT, which gives all 187 rows a real response today, and treats the per-species cell as an OVERRIDE that outranks the ladder the moment a row is authored; the derivation string on every evaluation says which of the two produced the answer. Building it the other way round — reading the empty column as the source — would have produced a system returning nothing on every creature in the game while reporting success. Familiar candidacy is the same shape and §8.9.2 names the right authority: it joins through T0_Familiar_Registry.creature_ref (7 of 22 slots resolve), never through the roster's own familiar_slot_eligible mirror (2 of 187 rows). Engine consumer: Source/Humanity/Public/World/HumanityFaunaResponse.h.
ecology_and_life — the creature's real ecological niche, territory, trophic role, and migration behavior, including the living-ecology consequence rule: over-hunting degrades an area and pushes fauna to migrate, except where the creature is progression-critical (a legendary-material source or a unique bond target), which is immune to ecological change (generative-entity-system-vision).
bonding_window — the chapter bonding window, the binding-stone mechanic, and the familiar-slot assignment, with bonding success deterministic (skill plus item plus window), never generated.
2.4.4 Place
Home registry: T0_Region_Index (67 rows). Runtime class: 6 (environments/world-state). A place is a persona: it has a character, a history, a life, and — per the Nemesis-class persistent-memory vision — a memory of the player. Extension fields:
web_edges — the place's trade partners, allies, enemies, and neighbors, and the significant connected sites woven in through them under the distance-decay budget (SIGNIFICANCE_LENSES.md §4.2). This is the field that realizes regions-are-relational-webs-not-villages; a place's persona is largely its web.
canonical_zones_and_vril — the place's zones, their vril_density bands, and its vril-site anchors, feeding the fauna substrate and the recharge network.
significant_sites — the place's story-load-bearing sites and their gameplay function and layer tags, per CHAPTER_BUILD_TARGET §6.
world_state_variants — the place's five world-state presentations (Luminous through Corrupted) driven by the protagonist's cumulative integrity, per §4, plus the cross-chapter accumulation that lets the Ch 59-65 revisits show the place recovered or damaged by the protagonist's own earlier choices (§4.9).
place_memory — the Nemesis-class persistent memory: the place remembers the protagonist's passage — which entrances she used to raid a fortress, whether she defended or abandoned a town — carried as world-state and faction record (generative-entity-system-vision).
environmental_boss_presence — whether the place carries an environmental-and-atmospheric boss (the non-damage-win protocol), the playable Layer-1 combat layer for protected and relief chapters (§8.8; the L1-always-playable ruling).
the_mark — the community-specific record of what the protagonist did while she was one of them, the durable local consequence layer distinct from the five-band world state (§5.5.4). The mark lives on the place persona because it is the place that remembers.
2.4.5 Object / thing
Home registries: T0_Weapon_Registry (72 rows), T0_Vril_Site_Registry, T0_Inscription_Spine, and the Thread-20 sacred-object content; objects are the one class whose anchors are distributed, and the persona layer unifies them through the T0_Persona_Index in §5.2. Runtime binding: objects are mostly deterministic props; a legendary or charged object carries a thin generated read akin to the environment class. Extension fields:
object_class_and_function — what the object is (weapon, sacred object, inscription, artifact, vril node, ceremonial or everyday made-object) and its mechanical function.
lineage_and_life — the object's life as a used and inherited thing across generations: the keris as multi-generation pusaka, a legendary weapon's chain of holders, an inscription's chain of readers. This is the object's own life field.
vril_and_progression — vril-couple eligibility and charge, and the progression-critical immune flag for objects that gate an achievement or the main path (legendary-weapon materials, quest-gate artifacts), which never vanish under ecological or consequence change (generative-entity-system-vision).
inscription_and_lore — the object's inscription content or lore, its Layer-2 investigatable substrate, and any inscription-spine or Vimana-coordinate role.
provenance_and_care — the object's real-world provenance and its care band: protected property (AIATSIS-registered artwork, ceremonial content) is referenced, never reproduced (§17.1).
3. The relationship / integrity / opportunity engine, and the non-gating invariant
3.1 What already exists — the state model this engine drives
The relationship engine is not built from scratch; it drives state variables that are already canonical and already rowed in T0_Worldstate_Variables:
integrity_score (WS_001), integrity_level (WS_002), world_state_current (WS_003), and path_bucket (WS_004) — the continuous integrity signal, its five bands, the five world states, and the three-path lock-in at Ch 65. Fully specified at T1_Integrity_Paths §2-4.
relationship_history (WS_008) — the per-NPC ledger object, carrying bond_state, integrity_signature_at_last_encounter, and encounter_count, with familiar bond and healer's-child relationship as the highest-priority entries.
familiar_bond_state (WS_012) — the per-familiar bond object driving the Ch 58 reunion branching.
faction_standing_per_faction (WS_021) — the per-faction standing object on the -100 to +100 range, distinct from integrity but interacting at the NPC-reaction layer per §8.7.
the mark — the community-specific persistent world-state texture and faction record of what the protagonist did while assimilated, per §5.5.4, carried on the place persona (§2.4.4).
The engine adds one new state class to this set — the opportunity flag — and the invariant that governs it.
3.2 Relationship tiers — the disposition ladder
An entity that holds a relationship with the player (persons, factions, companions, bonded creatures) carries a disposition on a ladder. The ladder is descriptive here; the numerical bands are Josh's to set and are not invented in this doc, consistent with the do-not-invent rule and with the way faction standing already runs on an authored -100 to +100 range.
The positive arm runs from a neutral or wary first meeting, through acquaintance and earned trust, to a bonded found-family tier (the recurring teaching communities each chapter leaves behind, and the traveling companions and familiars that grow with the protagonist).
The negative arm runs from suspicion, through hostility, to a locked-out enemy tier (a companion the deterministic relationship state machine locks out at an authored threshold, RUNTIME_GENERATIVE_LAYER §A.4; a faction turned rival).
Movement along the ladder is driven by three inputs read together: the protagonist's integrity band (which conscious beings read directly as a real vril-signature property, not as reputation bookkeeping, §2.2), the specific decisions the player has made toward this entity and its group (the faction-standing and relationship-ledger accumulation), and the mark the protagonist has left on the entity's community.
Because integrity is read as a real property, an entity notices who the protagonist has become even without having observed her deeds — the disposition is generated fresh each encounter from the current state (RUNTIME_GENERATIVE_LAYER §A.2). A skilled player cultivates dispositions; they can never configure an entity in a menu, and they can never jailbreak canon out of a persona.
3.3 Opportunities — what opens and closes
An opportunity is a bounded, non-progression-critical affordance that a relationship, an integrity band, or a mark opens or closes. The engine adds opportunity_flags as a new worldstate-variable class (a per-opportunity object: opportunity_id, open/closed state, and the relationship/integrity/mark conditions that set it). Opportunities are, by construction, the texture and the kit around the spine, never the spine itself. They include:
Kit and progression opportunities — a trade home base a trusted teacher opens, a familiar bond a creature offers at high integrity, a weapon or ability a faction grants, a recharge site that responds fully at a luminous signature and reluctantly at a corrupted one (§8.6, a difficulty modulation, explicitly not a gate).
Route and content opportunities — a side-questline branch a faction's standing opens, an ally who travels a stretch with the protagonist, a piece of Layer-2 lore a relationship unlocks, a market or passage a community's trust grants.
Relationship opportunities — a deepened found-family bond, a companion's protective combat disposition (which shifts how they fight beside the player, RUNTIME_GENERATIVE_LAYER §A.4), a community that remembers being protected and greets the protagonist accordingly at the Ch 59-65 revisit.
Opportunities close symmetrically: participating in a raid from inside a community's trust closes the found-family opportunity there and burns standing with the victims; behaving corrosively closes the recharge-site and familiar-approach opportunities as the world reads the negative signature. Closure is real and consequential — it reshapes relationships, the mark, and the available texture. What closure never does is stop the game.
3.4 The hard rule — the non-gating invariant, designed concretely
Josh's rule is absolute: opportunities open and close, but they never block or gate progression; the player must be able to play through in different ways, with no dead-ends. This is not a hope pinned to careful authoring — it is an invariant enforced by four concrete mechanisms and one automated gate.
The invariant, stated. For every spine node N, and for every reachable combination of integrity band, relationship state, faction standing, and mark, at least one through-line to N and onward to the Epilogue remains open. No decision, and no closed opportunity, can reduce the set of paths forward to empty. Progression belongs to the spine; opportunities vary the texture around it.
Mechanism 1 — the progression-critical immune set. Anything whose loss would stop progression, an achievement, or 100% completion is tagged progression_critical on the canon graph and is immune to closure (generative-entity-system-vision, the ecology immune-set rule generalized to the whole opportunity layer). A legendary-weapon material, a quest-gate resource, a unique required NPC, and the main-quest beat itself cannot be closed off by any relationship, integrity, or ecological state. Opportunities are, by definition, the complement of this set: only non-progression-critical affordances are allowed to be opportunity-flagged at all.
Mechanism 2 — the three playstyle through-lines. Every node's core objective is reachable by at least three distinct playstyle through-lines, grounded in the assimilation-integrity mechanic (§5.5) and the three paths: participate-alongside the culture's harm (the corrosive, murder-and-pillage register that accumulates toward Evil), subvert-from-inside while holding cover (the generative deceive-and-be-good register), and honorable-open (the generative register played without concealment). Each through-line closes some opportunities and opens others — participating earns standing with the harming faction and forfeits the victims' trust; subverting keeps the harming faction unaware and earns the victims a hidden positive mark; honorable play may burn the harming faction and win the victims openly — but each independently completes the node. Different ways to play through is a structural guarantee, not a difficulty setting.
Mechanism 3 — opportunity conservation (substitution). For any opportunity that a decision closes, at least one alternative opportunity of an equivalent reward class (kit, route, relationship, or lore) is reachable on the divergent path. A blacksmith who closes his forge to a corrupted-signature protagonist is matched by a smuggler, a rival smith, or a scavenged cache that yields equivalent-class kit on the darker path. Closure re-routes the player to a different-flavored equivalent; it never removes a reward class from the run. The Evil path and the Good path are equally weighted in production scope precisely so this holds (§17.4).
Mechanism 4 — consequence as difficulty and texture, never as a wall. Where a relationship or integrity state makes progress harder, it modulates difficulty and texture, not passage: recharge sources respond reluctantly rather than not at all on the main path, protected sites withhold their fullest response rather than the objective, and a hostile faction raises the encounter tempo rather than sealing the route (§8.6 establishes this as canonical difficulty modulation without explicit integrity-gating).
The one reconciliation this requires is with §8.7, which says faction standing gates certain questline entries. Read within the invariant, that gating is on optional side-questline branches and their specific rewards — which variant runs, which ally appears, which reward tier drops — never on main-spine progression, and every gated branch has a parallel ungated route to the node's completion under Mechanism 3. The proposal is to formalize this reading: opportunity flags and faction gates apply to the optional and the textural, and the harness enforces that they never touch the progression_critical set.
3.5 The no-dead-end gate — automating the invariant
The invariant is only trustworthy if it is checked, not asserted (the repo's hard-won verify-with-fan-out lesson). The proposal adds a no-dead-end reachability gate to the harness, run alongside the fidelity gate:
It walks the spine graph and, for every node and every reachable state combination, confirms at least one open through-line to the Epilogue. Any state that would empty the forward set is a hard fail.
It confirms every opportunity_flag targets a non-progression-critical affordance, and that nothing progression_critical is reachable only through a closable opportunity. A progression-critical target behind an opportunity gate is a hard fail.
It confirms opportunity conservation: every closable opportunity has a declared equivalent-class alternative on the divergent path. A missing alternative is a soft fail flagged for authoring.
This mirrors the runtime validator's role — the sim always runs a valid token because an invalid one is caught and replaced with an authored fallback (RUNTIME_GENERATIVE_LAYER §2.3-2.4). Here the build always ships a playable-through world because a dead-end is caught and flagged before it can reach the player.
4. Generation and scale — how 90-120M words get produced
4.1 The three production modes, and what is authored versus generated
The corpus is produced in three modes, and the distinction between them is the load-bearing scale decision.
Authored (canonical, human and Claude-in-loop, critic-gated, frozen as canon). The anchor registry rows; the flagship personas; the six-option dialogue at the Foundational beats; all §17.1 high-care and elevated-care content, authored-only at launch with the model assisting authoring and not runtime speech, because every cultural claim must trace to a primary source the model cannot supply (RUNTIME_GENERATIVE_LAYER §A.2 recommendation; HL_0002); the fallback line banks; and the per-chapter mark and opportunity specifications. This is the smaller, highest-stakes fraction of the words and the whole of the canonical fact surface.
Build-generated (Claude deep-research plus agent fan-out, canon-graph-guardrailed, normalize-doc critic-gated, then scattered to the persona docs and registries). The long-tail persona bibles — the background, history, daily-life, motivation, and relationship expansions for the hundreds of supporting and ambient entities — plus the per-entity descriptions, the L2 grimoire and journal lore, the dictionaries, and the creative-bible bulk. This is where most of the 90-120M words live. It is produced the way the cascade already produces substrate: the enrich pack as the single grounded source, deep research for gaps, a fresh-context adversarial critic before anything is trusted (deep-research over buying books; enrich-pack-completeness-determines-authoring). It is content on disk, and it is authored-quality because it is critic-gated; it is called generated only because the drafting is agent-assisted, not because it is loose.
Runtime-generated (on-device 14B-reference LLM, strategy-token, deterministic-first). This mode produces no words on disk. It is the reactive delivery over the authored and build-generated personas — the barks, disposition shifts, faction intents, ambient moods, and behavior flavor that make a persona feel alive and make each playthrough diverge (RUNTIME_GENERATIVE_LAYER, whole doc). It is the replayability layer, not part of the 90-120M authored corpus; it is the thing that animates it. Keeping this distinct from the disk corpus is essential to an honest scale read: the 90-120M is authored-and-build-generated content; the runtime layer is how that content breathes.
4.2 The scale decomposition — why 90-120M is plausible
The figure is Josh's target; the decomposition below is an illustrative accounting for his confirmation, not locked canon. It shows the target is reachable without padding, and where the bulk sits.
The chapter spine and its quest prose — the ~30M-word narrative backbone across 79 nodes, the invariant the rest hangs on.
Per-entity persona bibles — hundreds of supporting personas at supporting depth plus the flagship set, across roughly a thousand-plus named entities once every chapter's roster is expanded; the single largest new tranche.
Dialogue trees — the six fully-authored options per beat (four biography-shaped plus Good plus Evil, none procedural, §17.8), multiplied across every dialogue-bearing beat and every path variant, is inherently multiplicative and large.
The mark and opportunity content — the community-specific consequence text per chapter across the five world states and the three-path revisits (§4.9, §8.3).
The L2 investigatable substrate — journal entries, Grimoire cross-links, inscription decodings, and primary-source cultural texture, per chapter and per path (the roughly 3,900-source research corpus is the ground truth this draws from).
The dictionaries and language content — the fifteen-plus documented languages, the inscription spine, and the script registries (Pillar 7).
The creature, region, and object bibles — the fauna substrate, the region relational-web expansions, and the object lineages.
The relevance gate (§2.3) is what keeps this from becoming 200M words of sprawl: depth follows significance, ambient entities share buckets rather than getting bibles, and the distance-decay budget bounds how far each region's web reaches.
4.3 The guardrail — every generated persona is canon-graph and Care-Doctrine bound
Build-generation and runtime-generation run the same four-stage guardrail sandwich, at two different times (RUNTIME_GENERATIVE_LAYER §2, §D):
The context pack — every generation is packed from the canon graph outward from the entity's anchor row: its persona card, its resolved hard-line rule vector, its fact whitelist (the only facts this entity may reference, which is how a Ch 10 villager cannot leak a Ch 76 reveal), its cultural-care band, and for strategic entities its closed action vocabulary. The persona owns no fact the pack does not carry.
Constrained generation — output is schema- and grammar-constrained so a malformed structure or an out-of-canon name is unsampleable, with a per-entity canon-vocabulary mask so a retired alias (Agartha for Maatherion) cannot be produced.
Validation — a battery of deterministic checks: the §17.1 forbidden-framing denylist runs first and hard-fails (no Vodou-as-zombie, no shaman-as-mystical-other, no temple-as-trap, no stereotyped descriptor); the hard-line rule vector hard-fails a protected-community combat provocation or a pre-Ch-76 Grand-Sage leak; the canon-graph fact check hard-fails any unresolvable proper noun.
Authored fallback — any hard fail binds the authored default; the world never shows a hole, a hang, or a slop line. The local model is upside, never a dependency.
At build time the critic is the fresh-context normalize-doc adversarial pass (the standing normalization gate) plus the lens-coverage-and-relevance check; at runtime the validator is deterministic and per-call. The Care Doctrine's Gate 5 is a pass-or-cut condition at both times, never a softening. And the do-not-invent rule binds through all of it: generation aligns and expands grounded structure; it never decides chapter, numerical, naming, hard-line, or §17 canon, which stays Josh's, flagged when a persona would need it.
5. How the layer anchors to the spine and the registries
5.1 The spine is the persona manifest
The Story Spine already enumerates, per chapter, exactly the roster this layer expands. The CH_12 entry, for instance, carries a Key ally NPCs section (the babalawo, the python-temple priestess, the Agojie captain, the Hogon elder, and more, each with a role-and-voice sketch), a Boss structure section (the sovereign and the sub-bosses, each an antagonist persona), a companions_and_recurring_npcs mechanical anchor listing every canonical figure by character_id, an antagonist_operative row, a fauna and sites set, and the objects (the Ifa implements, the goldweights, the inscription fragment). That roster is the manifest of which personas Ch 12 needs. The persona layer is the downstream tier the spine anchors: for each entity the spine names, the persona layer holds the bible; for each relationship beat the spine surfaces (the Dahomey Decision as the chapter's assimilation-integrity test), the engine holds the state.
This makes the persona layer live and cascade-coupled in exactly the way the spine is a living backbone (assimilation-integrity-choice-mechanic): as each chapter builds one at a time, its roster's personas are expanded and its relationship and opportunity beats are authored against §5.5 and the non-gating invariant, and the spine entry is enhanced to point at them. The persona layer grows one node at a time, held in alignment by the spine, exactly as the systems in RELATIONSHIP_COMBAT_SYSTEMS_NOTE.md are meant to.
5.2 The new structure — the persona index and the persona doc set
Two new structures hold the layer, both FK-clean and harness-checkable:
T0_Persona_Index — a new registry, one row per entity, that is the FK spine of the persona layer. Each row carries the persona_id, the anchor_ref (the FK to the entity's home registry row), the entity class, the persona tier (flagship / supporting / ambient-bucket), the care band, the significance-lens set, the persona-doc path, the runtime class, and the daily-rhythm axis specified in 5.2.1 (the schedule states, the home and work sites, the presence window, the occupation and trade, the ambient-bucket edge, and the presence class that keeps a schedule non-gating). This is the one place that unifies the distributed object anchors (weapons, vril sites, inscriptions, sacred objects) and resolves the persona-to-anchor mapping for every class. It is the manifest enrich.py reads to pull a chapter's roster personas into the build pack.
The persona doc set — docs/personas/<class>/<entity_id>.md, one document per flagship and supporting persona, holding the common spine and the class extension in prose per the §17.14 authoring discipline (plain prose, single-level dashed bullets, affirmative framing). Node-ified only where granular retrieval earns it, per the repo's node-later rule; ambient buckets live as shared templates, not per-entity docs.
The relationship engine extends the existing T0_Worldstate_Variables rather than adding a registry: it adds the opportunity_flags variable class and formalizes the mark as a first-class variable (today the mark is described in §5.5.4 and carried implicitly in the accumulation variables). No standalone faction registry exists today; the proposal is to add a lightweight faction anchor (either a T0_Faction_Index or a formalization of the faction rows referenced from T8 region pages Section 8) so faction personas have a clean anchor row like every other class, rather than living only in Character_Index faction_affiliations strings.
5.2.1 The daily-rhythm axis — the columns that make own_life readable by a runtime component
Amendment of 2026-07-30, closing the schema half of DESIGN_GAP_REGISTER GAP-139 (CRITICAL,
npc-simulation) before rank 11 mints. The gap in its own terms: the 5.2 column list enumerated
persona_id, anchor_ref, entity class, persona tier, care band, significance-lens set, persona-doc
path and runtime class, and own_life was not among them — so the field 2.2 calls the one that makes
the world feel populated rather than staged lived only as prose in a persona doc, unreadable by a
runtime component. The queued consumer states its own blocker: PRE_5090_BUILD_PLAN_VOL2 LW-8
(ambient-NPC presence and schedule) reads "no schedule field in Character_Index", and
DESIGN_GAP_REGISTER entry 2 recommends one shared schedule component with a three-to-four state enum
covering home, work, social and sleep. Entry 5 asks the matching question for crowds, and no number
exists anywhere for how many people a village, market, port or trade compound holds. Re-measured on
2026-07-30 against the live tree: a header scan across all sixty-five live registry tabs returns ONE
column matching schedule, routine, occupation, population or crowd —
T0_Chapter_Index.ambient_crowd_voice_signature_array, a voice-casting array and a false friend in
exactly the way footfall_surface is a walk-surface foley material rather than an occupancy figure.
The same scan returns twenty-seven trade, home and density columns across eighteen registries, so
the near-zero is a real absence and not a search artifact.
own_life's DEFINITION is unchanged by this amendment: its 2.2 bullet gains one pointer sentence and
nothing else. It remains the persona doc's prose account of a life and the authority on what that
life means. The columns below are its projection: the small, closed,
queryable part a schedule component, a spawner ring and an asset budget can read. This subsection
authors no persona content. Population belongs to rank 11 for named personas and buckets, and to
rank 5 for the crowd budgets that read the population band.
The daily-rhythm columns on T0_Persona_Index, added to the 5.2 list:
schedule_state_set — the states this persona actually occupies, as a semicolon-joined subset of
the closed four-value vocabulary home, work, social and sleep. One shared vocabulary for every
class and every culture, per register entry 2; the cultural specificity lives in the sites, the
hours and the prose, never in a bespoke per-NPC state machine.
presence_window — the persona's default day, inline, as semicolon-joined state-and-hours pairs in
the form state:HH-HH on a twenty-four-hour local clock, wrapping permitted so a sleep window may
read sleep:21-05. This is the common case and it needs no child rows: a weaver at her loom by day
and at home by night is two pairs.
home_site_ref and work_site_ref — where the persona sleeps and where the persona works, each a
prefix-typed site reference: interior:INT_NNNN resolving to T0_Interior_Space_Registry.interior_id,
or zone:<zone_id> resolving to a Zone Catalog row on the persona's own region page. The
prefix-typed form follows the polymorphic-reference precedent the repo already carries at
T0_Dialogue_Line.speaker_ref, T0_Bonus_Pool_Registry.capability_ref and
T0_RNG_Drop_Table.linked_entity_id; the interior half is a declarable foreign key today and the
zone half is an id-format until the carried zone-catalog registry work order gives zone rows a
table, at which point it becomes a second declared key.
occupation_ref — the normalised occupation token, which today lives unnormalised inside the
T0_Character_Index role slug (the aksumite coffee-ceremony mistress, the manggarai cotton-ikat
weaver) where nothing can group or count it. Cited to the region page's own role vocabulary, in the
culture's own term per 17.1 self-naming.
trade_ref — the foreign key to T0_Trade_Registry.trade_id where the occupation is one of the ten
canonical trades, and blank where it is not. This is the join that lets a trade home base with an
upgrade ceiling be staffed by named practitioners instead of reading as a prop.
persona_bucket_ref — the foreign key to T0_Persona_Bucket.bucket_id for an ambient-tier persona,
which is the edge that makes 2.3's pooled model countable rather than aspirational.
presence_nongating_class — the closed three-value guarantee always_present,
alternate_reach_declared or non_progression, described under the invariant below.
T0_Persona_Schedule — the child table for a rhythm one row cannot hold. A persona whose day varies
by calendar day, by world state, or across more windows than presence_window can carry gets rows
here, and those rows are authoritative for the hours they cover while presence_window remains the
fallback for the hours they do not. Its columns: schedule_id as the primary key; persona_ref as the
foreign key to T0_Persona_Index.persona_id; window_ordinal for the ordering within a persona, because
a CSV carries no implicit order; schedule_state from the same closed four-value vocabulary;
window_start_hour and window_end_hour on the twenty-four-hour local clock; site_ref in the same
prefix-typed form as home_site_ref; day_class for the calendar selector, defaulting to every_day and
otherwise carrying the region's own calendar term (the Ch-4 Pawukon day names being the canonical
hard case); condition_expression, validated by docs/CONDITION_EXPRESSION_GRAMMAR.md and
harness/condition_expr.py rather than by this spec, for a window that only exists in some world
states; and the house tail source_ref, notes, lifecycle, superseded_by and extensions.
T0_Persona_Bucket — the ambient tier's roster, which 2.3 has always implied and never rowed. One row
per pooled persona bucket, so a crowd of forty sharing six buckets is six authored rows rather than
forty absent ones. Its columns: bucket_id as the primary key; region_ref as the foreign key to
T0_Region_Index.region_id; zone_ref as an optional narrowing to one Zone Catalog row;
community_or_culture and role_label carrying the region page's own Section-4 and Section-12 role
terms; occupation_ref and trade_ref exactly as on the index; schedule_state_set and presence_window,
because a crowd has a day too and a market that is busy at dawn and empty at dusk is the whole point;
voice_register_ref as the foreign key to T0_Voice_Registry.voice_id, targeting the cultural-register
rows so a bucket speaks in a registered voice rather than a default one; appearance_register for the
dress-and-bearing note; care_band resolved from T0_Hard_Lines exactly as the persona spine resolves
it, since a pooled crowd inside an elevated-care community carries that community's bar; and the
house tail source_ref, notes, lifecycle, superseded_by and extensions.
The ambient-population band, on two rails. ambient_population_band joins the region page Zone Catalog
as a page-authored extension column, at the per-zone grain the crowd mesh and material budgets
actually need, and ambient_population_band_default joins T0_Region_Index as the region-level default a
zone may override — the naming following the env_density_band_default column the same rail already
carries. Both take one closed ordered vocabulary: uninhabited, sparse, occupied, busy, crowded. The
vocabulary is deliberately a MAGNITUDE band and not a head count: the count each band authorises is an
asset-budget decision that belongs with rank 5's crowd mesh and material sizing, and a number invented
here would be false precision of exactly the kind the empty worldcover_biome cells were left blank to
avoid. Village, market and port scale is the target; metropolis density is out of scope, per register
entry 5.
The non-gating invariant, extended to time. The persona layer's absolute rule is that opportunities
open and close but never block progression (3.4), and a schedule is the one persona field that can
break that rule by accident rather than by design: a required teacher asleep behind a locked door at
the hour the player arrives is a dead end that no authored decision chose. So the invariant reads in
time as well as in state. Every persona whose schedule bounds a progression-critical interaction reads
presence_nongating_class as always_present, meaning the schedule never removes them from reach, or as
alternate_reach_declared, meaning a declared alternate route to the same objective is reachable in
every window — a second practitioner, a message left, a waking condition, a different site. Personas
outside the progression-critical immune set read non_progression, and their windows are free. A closed
window is consequence and texture, per Mechanism 4: it changes the flavour, the difficulty and the
route, and it never changes whether the node can be completed. Asserting this over the authored rows
is the no-dead-end reachability gate's job (3.5, harness/check_no_dead_end.py) and is named here as
the tooth that arms with the mint, not as a claim this amendment has already checked.
What lands with the mint. This subsection is the column contract and nothing more; the three tables
are minted by rank 11. In that same commit the foreign keys are enrolled in docs/fk_spec.json —
persona_ref, persona_bucket_ref, trade_ref, region_ref, zone_ref and voice_register_ref as declared
keys, and schedule_state_set, presence_window, the prefix-typed site references,
presence_nongating_class, day_class and the two population bands as id-formats over their closed
vocabularies — the extension columns are declared in docs/registry_extensions.json under the
persona-rhythm owner, and the fidelity baseline is refreshed by re-emission in the same commit, per
the standing declare-in-the-same-commit rule. The population band's two columns and their ownership
declaration land with this amendment, because their rails exist today; the persona and bucket columns
cannot, because their tables do not.
5.3 The FK and graph wiring
The layer is a graph, wired to the existing canon graph so the harness verifies it the way it verifies every registry:
persona.anchor_ref resolves to a row in the entity's home registry (Character_Index, Antagonist_Network, Creature_Roster, Region_Index, Weapon_Registry, Vril_Site_Registry, Inscription_Spine, or the new faction anchor). A mis-named anchor fails loudly, never silently, per the harness contract.
persona.web_position edges resolve to other persona or registry rows and mirror the Cross_Cultural_Link_Graph edge model, so the relational web is a first-class, checkable graph rather than prose.
persona.significance_lenses resolve to the SIGNIFICANCE_LENSES set; persona.care_band resolves to T0_Hard_Lines; persona.voice_register resolves to T0_Voice_Registry; persona.runtime_binding resolves to the six-class taxonomy.
The relationship engine's variables (relationship_history, familiar_bond_state, faction_standing_per_faction, opportunity_flags, the mark) resolve to T0_Worldstate_Variables, which already routes them to their runtime consumers.
The whole set is protected by the fidelity gate (any edit refreshes docs/fidelity_baseline.json in the same commit) and by the new no-dead-end gate (§3.5), and every DRAFT-to-ACTIVE flip runs the normalize-doc critic.
5.4 The runtime binding closes the loop
Each persona's runtime_binding field is what the on-device layer consumes: the persona doc plus the anchor row plus the resolved hard-line vector are baked into the per-entity context pack at load (RUNTIME_GENERATIVE_LAYER §2.1, §D.1), frozen, and KV-prefix-cached once. At play time the strategy-token loop reads that frozen pack and emits the small validated token that the deterministic sim executes — the disposition, the faction intent, the behavior flavor, the ambient mood. The persona is the write-time-structured truth; the runtime token is the read-time-cheap animation of it. The authored and build-generated corpus is the invariant; the runtime layer varies the texture around it, which is the replayability bet made literal.
6. Honest current state
The verified read, matching the pattern the CANON_AUDIT already established for the wider foundation (systems and vision strong; per-chapter structured anchors largely unpopulated):
The system spine is strong and mostly already canonical. The integrity, path, world-state, mark, faction-standing, and six-option-dialogue architecture is fully specified at T1_Integrity_Paths (v2.1), including the assimilation-integrity choice at §5.5. The runtime strategy-token layer over all six entity classes, with the guardrail loop and the on-device sizing, is designed at RUNTIME_GENERATIVE_LAYER. The significance lenses and their five-gate relevance filter are proposed. The relationship and combat systems are held as a per-chapter development roadmap. The worldstate variables that this engine drives — relationship_history (WS_008), familiar_bond_state (WS_012), faction_standing_per_faction (WS_021) — are already rowed and routed to their consumers. This is a substantial, coherent foundation.
The anchor rows exist but are skeletal. T0_Character_Index has 118 rows, T0_Antagonist_Network_Registry 62, T0_Creature_Roster 132 (with the folklore and substrate columns partly populated), T0_Region_Index 67, T0_Weapon_Registry 72. These carry terse fields — role, faction_affiliations, thread_involvement, voice_signature_notes, folklore_behavior_substrate — not personas. Two anchor registries are thin or empty: T0_Voice_Registry holds only 10 rows and T0_Familiar_Registry holds 0.
The persona depth is almost entirely unbuilt. The richest persona content that exists today is the per-chapter roster prose in the spine entries — the CH_12 ally-NPC and boss paragraphs are genuine persona sketches, and the voice_signature_notes cells are light voice sketches. There are no deep per-entity persona bibles, no daily-life or motivation or history layer per entity, no T0_Persona_Index, no persona doc set, no opportunity_flags variable, no formalized mark variable, no no-dead-end gate, and no faction anchor registry. The relationship engine's state variables exist as schema rows but have no per-entity population and no per-chapter relationship beats authored beyond the Ch 12 first-anchor.
The honest one-line read: the architecture and the anchors are in place; the persona-and-relationship content — the bulk of the 90-120M words and the engine that animates it — is the major downstream layer still to build, and it is correctly built cascade-coupled, one node at a time, not up front.
7. Build plan
Five phases, ordered cheapest-and-unblocking-first, coupled to the living cascade, and validated throughout. Each phase names its exit condition.
Phase A — ratify the schema and the invariant. Josh confirms the persona schema (§2), the relationship-tier ladder and opportunity model (§3.1-3.3), the non-gating invariant and its four mechanisms (§3.4), and the new structure (§5.2). Stand up T0_Persona_Index, the opportunity_flags and formalized-mark variables in T0_Worldstate_Variables, the faction anchor, and the no-dead-end gate in the harness. No persona content is authored in this phase; it unblocks everything after it. Exit: the schema is confirmed, the empty registries and the gate exist and are green.
Phase B — complete the anchors. Fill the skeletal and empty anchor rows so every entity that will get a persona has a clean FK anchor first: populate T0_Familiar_Registry (the 22 slots), grow T0_Voice_Registry, add the faction anchor rows, and unify the distributed object anchors under the persona index. This is the manifest the persona expansion hangs on. Exit: every entity named in the spine resolves to a clean anchor row and a Persona_Index row.
Phase C — expand personas, coupled to the cascade. As each spine chapter builds one at a time, expand that chapter's roster personas: flagship personas authored and Josh-in-loop for the high-care set; supporting personas deep-researched, build-generated, and normalize-doc critic-gated; ambient entities assigned buckets. Author that chapter's relationship and opportunity beats against §5.5 and the non-gating invariant, and scatter the structured fields to the persona docs, the Persona_Index, and the worldstate variables. This is where the bulk of the 90-120M words accrues, node by node, in alignment with the living spine. Exit: rolling — each chapter's persona layer lands and is critic-gated as the chapter lands, audited at each Range Review.
Phase D — bind to the runtime. Bake the per-entity context packs (persona plus anchor plus hard-line vector) for the runtime strategy-token layer, following the RUNTIME_GENERATIVE_LAYER staged build plan and the milestone pipeline, with the high-care set authored-only at launch. Exit: the milestone-pipeline chapters run their personas through the validated strategy-token loop with the authored floor intact.
Phase E — validate continuously. Run the no-dead-end reachability gate, the fidelity gate, and the normalize-doc critic across every persona and every chapter; audit persona coverage and the non-gating invariant at each Range Review with a fresh adversarial fan-out (not commit labels). Exit: rolling — the invariant and the coverage hold at every RR.
8. Guardrails held
Do not invent canon. This proposes an architecture — a schema, a state model, a build plan. It assigns no chapter, coins no name, sets no integrity band or magnitude number, and moves no hard line. The relationship-tier bands, the opportunity thresholds, the word-count decomposition, the new registries, and the faction-anchor decision are all proposals for Josh's confirmation. Where a persona would need new chapter, numerical, naming, or hard-line canon, it stops and flags, per the cardinal rule.
The Care Doctrine binds every persona. Represent, do not avoid; historical honesty, not niceness; the living faithful never combat targets; no sacred name on a mortal and no revered figure as a villain; protected property referenced, not reproduced; anti-fringe grounding throughout (§17.1). Gate 5 of the relevance filter makes care a pass-or-cut condition on every generated persona, at build time and at runtime.
Show, don't tell. No persona declares the thesis, and no pre-Ch-76 persona leaks the Grand Sage or the House-of-Velheim pattern; the fact whitelist makes the leak unsampleable (§17.9; antagonist-pattern-reveal-timing).
The non-gating rule is an invariant, not an aspiration. It is enforced by the progression-critical immune set, the three playstyle through-lines, opportunity conservation, consequence-as-difficulty, and the automated no-dead-end gate — so the player can always play through, in different ways, with no dead-ends.
Living source, verified. Personas are living documents, updated in place as the cascade advances so no deprecated reference survives to make a later agent hallucinate; every flip is critic-gated; and coverage is re-derived by fan-out, not trusted from a commit label.
9. Return payload
Doc: docs/proposals/ENTITY_PERSONA_SYSTEM.md
The persona schema: a common thirteen-field spine (anchor_ref, identity, significance_lenses, web_position, background_history, own_life, motivations, personality, voice_register, relationships_to_player, care_band, layer_surfacing, runtime_binding) plus five class extensions (person, faction, animal/creature, place, object/thing), each extending an existing anchor registry row, tiered by the five-gate relevance filter so depth follows significance.
The relationship / integrity / opportunity engine: driven by the already-canonical integrity, world-state, mark, and faction variables plus a new opportunity_flags class; a relationship-tier ladder moved by integrity band, decisions, and the mark; opportunities that open and close as kit, route, and relationship affordances.
The non-gating multi-path design: an invariant (no state ever empties the forward path set) enforced by four mechanisms — the progression-critical immune set, three playstyle through-lines (participate / subvert-from-inside / honorable-open), opportunity conservation, and consequence-as-difficulty — plus an automated no-dead-end reachability gate in the harness.
The anchoring: the spine roster is the persona manifest; a new T0_Persona_Index and docs/personas/ doc set hold the personas; the engine extends T0_Worldstate_Variables; the daily-rhythm axis of 5.2.1 adds the schedule and occupation columns on the index plus the T0_Persona_Schedule and T0_Persona_Bucket child tables and the ambient-population band on the Zone Catalog and Region_Index rails; all FK-clean and protected by the fidelity gate, the no-dead-end gate, and the normalize-doc critic.
The honest current state: system spine strong and mostly canonical; anchor rows present but skeletal (118 / 62 / 132 / 67 / 72 rows; Voice 10, Familiar 0); persona depth almost entirely unbuilt beyond spine-entry sketches and light voice signatures; the deep persona layer and its engine are the major downstream build, correctly cascade-coupled.
The build plan: five phases — ratify schema and invariant, complete anchors, expand personas coupled to the cascade (the bulk), bind to runtime, validate continuously.
Generated by harness/site/structure_site.py — the URL path is the repo path. review root