T99_Translation_UE5_Build.md

world/translation/T99_Translation_UE5_Build.md

T99_Translation_UE5_Build

Translation Doc — UE5 Pipeline. Realizes T1_Build_Pipeline_Contracts §1's fourteen-subsystem

UE5 roster as concrete Unreal Engine 5.8 build mechanics — the platform-specific runtime layer

T1_Build_Pipeline_Contracts §0 always deferred. Status: ACTIVE v1.0 (flipped 2026-07-15 — the three-critic fresh-context pass PASSED, the fix-forward and the contracts-corrections pass both landed: the §0 flip condition). First authored pass —

derived from the adjudicated research chain ahead of any real region build. Several dependent

engineering spikes are still open (§4); nothing below is licensed to be read as settled where a

spike names it. Repo-native home: docs/translation/T99_Translation_UE5_Build.md — the first of

the six initial Translation Docs the Pipeline Contract names (UE5, Meshy, AIVA, ElevenLabs,

Cinematic, SFX).

Cited short-form below: UE_BUILD_AUTOMATION = docs/pipeline_review/tech_research/UE_BUILD_AUTOMATION.md

· RESEARCHED_STACK = docs/pipeline_review/RESEARCHED_STACK.md · ALTERNATIVES_MATRIX =

docs/pipeline_review/ALTERNATIVES_MATRIX.md · NEOSTACK_AI = docs/pipeline_review/tech_research/NEOSTACK_AI.md

· T1_Region_Page_Template = _source/01_Tier_1_Foundation/T1_Region_Page_Template [ACTIVE v2.0].md

· T1_Build_Pipeline_Contracts = _source/01_Tier_1_Foundation/T1_Build_Pipeline_Contracts [ACTIVE v1.0].md

· SPINE_SCHEMA_v3 = docs/SPINE_SCHEMA_v3.md.

---

1. Scope + authority

This doc is the runtime realization layer under T1_Build_Pipeline_Contracts §1 (the UE5 Pipeline

Contract) — it turns the fourteen-subsystem canon-to-engine roster (§1.2) into concrete APIs,

commandlets, seams, and per-step artifacts. It does not carry canonical authority of its own.

Authority hierarchy, per Contracts §0: subordinate to the CVD on world canon; subordinate to

T1_Build_Pipeline_Contracts on foreign-key mapping, required columns, and state-machine behavior

— this doc never contradicts those, it only supplies mechanism; subordinate to

T1_Region_Page_Template on the page-side input contract this doc consumes (the Machine Blocks,

Section 17). Where the Contract is silent on platform-specific runtime-parameter inference, this

doc owns the inference layer [SRC: T1_Build_Pipeline_Contracts §0].

Versioning discipline it inherits: Translation Docs version per platform update; a UE version

revision produces a new Translation Doc version, while the Pipeline Contract surface stays stable.

This is v0.1 against a stack that itself still carries open spikes (§4) — "iterate as build

experience accumulates" is the governing posture, not a one-shot lock [SRC:

T1_Build_Pipeline_Contracts §0].

The reconciliation this doc performs: Contracts §1.2 was authored against UE 5.7 and named

Cesium for Unreal, Gaea2Unreal, and SRTM Heightmap Import as three separate terrain-import

pipelines. The since-ADJUDICATED research (RESEARCHED_STACK, ALTERNATIVES_MATRIX Slot 1) supersedes

that specific tool split on the terrain leg with a single DEM-GDAL-Landscape backbone (Gaea narrowed

to its erosion-detail role; classic heightfield Landscape held over 5.8's Experimental Mesh Terrain)

and pins UE 5.8 throughout. This is exactly the "platform volatility absorption" Contracts §0

anticipates: the fourteen subsystems (the WHAT) are unchanged; §3 below supplies the HOW at the

currently-ruled tool selection. T0_Region_Index.terrain_pipeline_type's `cesium/gaea/srtm/hybrid/

custom enum stays schema-valid — this doc defaults new regions to the gaea/hybrid` path per the

ruling, which is a Translation Doc call, not a Contract amendment [SRC: T1_Build_Pipeline_Contracts

§1.2, §1.6; RESEARCHED_STACK Chain 3 + ADJUDICATED v2; ALTERNATIVES_MATRIX Slot 1].

Scope boundary: covers the fourteen §1.2 subsystems as they resolve into the region-build chain

(§3). Does not cover the other nine Pipeline Contracts except where UE5 consumes their output as an

opaque foreign key (mesh_id_ref, voice_signature_ref) — those get their own Translation Docs.

Does not invent canon or schema: every field, column, and enum this doc names is one already

defined by T1_Build_Pipeline_Contracts, T1_Region_Page_Template, or SPINE_SCHEMA_v3 — this doc

supplies mechanism, never a new FK, column, or numerical fact.

---

2. THE RULED CONSTRAINTS

2.1 Engine version — UE 5.8 pinned

UE 5.8 is confirmed current and the last planned major UE5 release (shipped 2026-06-17; UE6 Early

Access targeted late 2027, full release 12-18 months after). Do not target 5.9 (maintenance-only if

it ships at all) and do not design against pre-EA UE6. Several APIs moved across the 5.x line

specifically relevant here — EditorLevelLibrary deprecation (split across

EditorActorSubsystem/LevelEditorSubsystem/UnrealEditorSubsystem), MetaHuman's cloud-to-in-editor

migration (5.6+), PCG's Experimental-to-Production-Ready climb (5.7) — re-check every API name

against 5.8-era documentation specifically, not older tutorial-era assumptions [SRC:

UE_BUILD_AUTOMATION §0; RESEARCHED_STACK Chain 3].

2.2 Claude Code drives NeoStack, schema-bound

Ruled principle, verbatim-faithful: Claude Code drives NeoStack with every action — code,

Blueprints, PCG, LLM-placed generation — matched to OUR SCHEMA. The v3 spine graph

(SPINE_SCHEMA_v3 §3) plus region pages (T1_Region_Page_Template) plus registries are the input

contract; NeoStack never generates freehand against an unstructured prompt. Every step in §3 traces

its input artifact to a named schema field for exactly this reason [SRC: RESEARCHED_STACK ADJUDICATED

v2; ALTERNATIVES_MATRIX "Fixed constraints"].

2.3 The three-seam routing rule

Not a single tool — three seams, routed by step CLASS, never by preference:

Fallback: chongdashu/unreal-mcp (OSS, 2,034 stars, actively maintained) is the pinned fallback

for the NeoStack interpretive seam if the pre-flight install verify fails. **Two pre-flight gates

bind before any region build** (§4): gate 1, NeoStack-on-5.8, is SATISFIED (verified 2026-07-19) —

NeoStack is installed as source in the project Plugins/, rebuilt against the engine BuildId

(55116800), and its MCP channel (http://127.0.0.1:9315/mcp, server unreal-editor) was

smoke-tested end-to-end (actor spawn + viewport screenshot); the chongdashu/unreal-mcp fallback is

now dormant, not the active branch. Gate 2 still binds — impose a human-in-the-loop checkpoint policy

in the orchestrator, since NeoStack's only built-in safety is undo, not pre-approval. The checkpoint policy must define

its own mandatory-pause triggers explicitly — at minimum, any operation touching hard-line/§17

content and any bulk/destructive operation — since the tool itself does not enforce that boundary

[SRC: ALTERNATIVES_MATRIX Slot 4; UE_BUILD_AUTOMATION §3.6; NEOSTACK_AI "What the Translation Doc

needs to specify"].

2.4 Localization-ready strings, from the first asset

Every player-facing string lands in a string table (FText, never a hard-coded FString/literal),

starting with the FIRST asset built, not retrofitted later — the ship-everywhere ruling makes this

non-negotiable [SRC: T1_Region_Page_Template §17]. Mechanically this is already partially

load-bearing in Step 2's codegen convention: every player-facing column in a generated USTRUCT

(FBossRow.DisplayName, dialogue text, quest objective text) types as FText, never FString — a

DataTable-imported FText field participates in UE's text-gather/localization pipeline by

construction. The exact String Table (UStringTable/LOCTABLE) authoring and gather-commandlet

automation surface was not covered by any source read for this doc and is not confirmed here —

treat the FText-column convention as the binding rule and the specific String Table mechanism as

an open item (§4) before the first asset ships text [SRC: T1_Region_Page_Template §17;

UE_BUILD_AUTOMATION §4.2; RESEARCHED_STACK "Missing lanes opened"].

---

3. THE CHAIN, STEP BY STEP

Contracts §1.2 subsystem to chain-step index (what this doc realizes, and where):

A pre-step precedes Step 1 on every build: site/beat/fork/scene/SQ rows live embedded in typed

markdown inside docs/spine/CH_NN.md, not as standalone tables. A markdown-table-extraction step

(our own tooling, not an Epic API) pulls them into the same CSV/JSON shape as the registries before

Step 2 can run [SRC: UE_BUILD_AUTOMATION §9 Pre-step].

Step 1 — Project + plugin baseline (one-time)

• Input: none directly — which plugins to enable is dictated by the fourteen subsystems above plus the three-seam routing (§2.3).
• Format: .uproject plugin references + Config/DefaultEngine.ini entries.
• Mechanism (seam: native, one-time): enable "Python Editor Script Plugin" + "Editor Scripting Utilities" for the embedded Python 3.11.8 surface; enable "Remote Control API" (+ optionally "Remote Control Web Interface"), bound to localhost only (HTTP 30010 / WS 30020 by default — auth is light, never expose past LAN/VPN); enable the MetaHuman Creator plugin + install MetaHuman Creator Core Data; PCG ships bundled and Production-Ready since 5.7; World Partition is default for new levels. Install NeoStack (the interpretive seam) as source in the project Plugins/ and rebuild it against the engine BuildId — a prebuilt or marketplace binary drop-in re-breaks on a BuildId mismatch, so prebuilt drops are forbidden (verified 2026-07-19); load Epic's Experimental Unreal MCP plugin (ModelContextProtocol, server unreal-mcp, default http://127.0.0.1:8000/mcp — enabled but NOT auto-started, no toolset enabled yet) + its PCG toolset + the mandatory "PCG graph generation skill." Install chongdashu/unreal-mcp as a dormant fallback.
• Output: a bootable 5.8 project with every subsystem's plugin dependency enabled and all three seams reachable.
• Verification: the two §2.3 pre-flight gates — NeoStack-on-5.8 install verify (SATISFIED 2026-07-19 — installed as source, MCP channel smoke-tested end-to-end); the human-in-the-loop checkpoint policy imposed in the orchestrator.
• [SRC: UE_BUILD_AUTOMATION §0, §1.1-1.2; ALTERNATIVES_MATRIX Slot 4]

Step 2 — Registries to USTRUCTs to DataTables

• Input: every T0 registry UE5 reads per Contracts §1.3 (Boss_Encounter, Creature_Roster, Weapon_Registry, Worldstate_Variables, Questline_Index, Character_Index, Antagonist_Network_Registry, Vril_Site_Registry, Inscription_Spine, Hard_Lines, Ability_Tree_Registry, Familiar_Registry, Trade_Registry, Language_Script_Registry) plus the extracted spine typed layer (beat rows, site rows, fork_node + option tables, boss thin index, SQ beats, scene rows — SPINE_SCHEMA_v3 §3) plus the region page's Zone Catalog + Derived Indexes.
• Format: generated C++ headers, one USTRUCT : FTableRowBase per registry/table (FBossRow, FCreatureRow, FSiteRow, FBeatRow, FForkRule, FSceneRow, …) with player-facing text fields typed FText (§2.4); generated Config/Tags/*.ini for the GameplayTag taxonomy (THREAD_01..22 refs, ws.* keys, the closed enums from SPINE_SCHEMA_v3 §4); CSV for flat rows, JSON wherever a row nests (boss phases, fork option tables).
• Mechanism (seam: native, bulk): a bespoke in-house codegen script (no Epic-official CSV-to-USTRUCT generator exists) emits headers + ini from the CSV/schema headers; one compile/hot-reload cycle (Blueprint-only structs are rejected by the DataTable importer — Epic bug UE-152346 — this C++ step is not optional). Then headless Python (UnrealEditor-Cmd.exe -run=pythonscript) via unreal.CSVImportFactory/unreal.AssetImportTask for first creation and unreal.DataTableFunctionLibrary.fill_data_table_from_json_file/_csv_file for refresh, producing DT_Bosses, DT_Creatures, DT_Sites, DT_Beats, DT_ForkRules, DT_Scenes. Cross-registry FKs resolve via FDataTableRowHandle (1:1) or UDataRegistrySubsystem (the many-to-many namespace across the ~30-registry graph).
• Output: compiled DT_* DataTable assets + a registered GameplayTag taxonomy (tags load at engine init only — this step must complete before the editor/game next boots).
• Verification: RowName = the registry's own stable ID (boss_id, beat_id, site_id — never a display name or positional index); re-import fully overwrites the DataTable and silently breaks any FDataTableRowHandle keyed to a renamed row. DataTables are binary .uassets, not git-diffable — the CSV/JSON stays source of truth; the .uasset is a regenerable build artifact.
• [SRC: UE_BUILD_AUTOMATION §4.1-4.8, §9 Step 0-1 + Pre-step; SPINE_SCHEMA_v3 §3-4; T1_Region_Page_Template Machine Blocks]

Step 3 — World Partition setup

• Input: region page Region Identity header (region_id, chapter_set) + Zone Catalog area_bounds.
• Format: one World-Partitioned .umap per region_id (~69 total).
• Mechanism (seam: native/commandlet, bulk): WorldPartitionConvertCommandlet (sets CellSize — default runtime cell 25,600 cm via RuntimeGrid/RuntimeHashSet in World Settings — plus HLOD defaults) or Tools > Convert Level; no clean scripted "set WP grid size" call exists, this is a level/World-Settings property. Builder commandlets (-run=WorldPartitionBuilderCommandlet -Builder=<Name>) handle HLOD, minimap, and navmesh headlessly. Data Layers tag the Zone Catalog's protected sites into a SafeZone layer via unreal.DataLayerEditorSubsystem (create_data_layer, add_actor_to_data_layer, set_data_layer_is_loaded_in_editor) — cleanly Python-scriptable, no flag.
• Output: a WP-enabled .umap per region, protected zones already tagged for downstream hostile-suppression.
• Verification: PCG's headless bake (Step 6) requires a WP level — standardizing every region on WP is what makes that bake possible; non-WP levels have no single-shot commandlet equivalent.
• [SRC: UE_BUILD_AUTOMATION §2.4, §9 Step 2 + Step 6]

Step 4 — Landscape import (the C++ shim, honestly scoped)

• Input: a per-region heightmap sized to a valid vertex dimension (505², 1009², 2017², 4033², or 8129² per the fixed section/component-count table), synthesized externally from the region's terrain_type (SPINE_SCHEMA_v3 §3b site rows) via Copernicus GLO-30 DEM → GDAL/rasterio reproject/resample/carve → a Gaea erosion-detail pass, per the terrain chain the region page's Section 1 points to. 16-bit grayscale only (PNG16 or .r16 — 8-bit terraces visibly; EXR is not a supported classic-heightmap format, a common trap since Gaea/Houdini/World Machine default to EXR for other exports).
• Format: ALandscape::Import() C++ call parameters — bounds, sections-per-component, quads-per-section, a TMap<FGuid,TArray<uint16>> of height data, an FLandscapeImportLayerInfo array for initial per-layer weightmaps.
• Mechanism (seam: bespoke engineering, built once, then native/bulk per region): no stock Python call creates a Landscape and imports a heightmap at full fidelity. spawn_actor_from_class yields a LandscapePlaceholder that supports no heightmap operations; unreal.LandscapeSubsystem exists but exposes no documented one-call import; the landscape.landscape_import(...) calls surfacing in search results belong to a deprecated third-party plugin, not the official API. The one confirmed path is C++: World->SpawnActor<ALandscape>() → Landscape->Import(...) → RegisterAllComponents() → PostEditChangeProperty(...), wrapped as a UFUNCTION(BlueprintCallable) shim callable from a commandlet/Python (reference implementations: FDatasmithLandscapeImporter::ImportLandscapeActor, FLandscapeEditorDetailCustomization_NewLandscape::OnCreateButtonClicked), or a third-party plugin (TAPython's unreal.PythonLandscapeLib).
• Output: an ALandscape actor per region, textured with its initial WorldCover-derived weightmaps (feeds directly into Step 5).
• Verification: the single highest-priority engineering dependency in the whole chain — write it once, budget it as a discrete engineering task, reuse across all ~69 regions. No region's Step 4 runs before the shim exists and is tested against at least one real region's heightmap.
• [SRC: UE_BUILD_AUTOMATION §2.1-2.3, §9 Step 3-4; T1_Region_Page_Template §1; RESEARCHED_STACK Chain 2 items 1-4]

Step 5 — Landscape materials from WorldCover weightmaps

• Input: ESA WorldCover 10 m landcover (11 classes) per region, cross-referenced against the Zone Catalog's terrain field per zone/site.
• Format: a landscape master material using LandscapeLayerBlend/LandscapeLayerWeight/LandscapeLayerCoords nodes, self-assigning layers by slope/height/WorldCover-class (no manual painting) — or per-layer weightmaps supplied at Step 4's import call.
• Mechanism (seam: NeoStack once, then native/bulk): the auto-material is authored ONCE, in-editor, mapping WorldCover class + slope/height to layer-blend rules (a judgment task — NeoStack drafts it from the class-to-material intent, reviewed once); it then applies automatically to every landscape at creation via the initial weightmaps or its own self-assigning logic — zero per-region authoring. PCG Biome Core (engine-bundled) is the other confirmed lever: it reads WorldCover-derived layer weights and spawns biome-appropriate flora directly, distinct from the encounter/creature spawning in Step 6.
• Output: a textured landscape per region whose material layers reflect real landcover without hand-painting.
• Verification: no first-class public API paints layers on an already-created landscape via Python — the only confirmed paths are (a) weightmaps at import time, (b) the auto-material, (c) PCG samples the landscape and writes layers. Design around these three. PCG Biome Core is versioned v0.2 and Experimental as of this research — verify runtime performance before shipping it (§4).
• [SRC: UE_BUILD_AUTOMATION §2.5, §3.1, §9 Step 5; RESEARCHED_STACK Chain 2 item 5; T1_Region_Page_Template §1]

Step 6 — PCG graphs from the Zone Catalog + DataTables

• Input: region page Zone Catalog rows (zone_id | source site_id(s) | terrain | gameplay functions | ambient_threat | vril_density | climactic_affordances | protected | area_bounds | build_priority) + DT_Creatures/DT_Bosses etc. from Step 2.
• Format: a PCG graph TEMPLATE per biome/terrain_type (authored once, reusable), using Load Data Table (point data/attribute set) and Data Table Row to Attribute Set — one zone row to one Attribute Set, parameterizing that zone's graph: density from ambient_threat, creature-tier filter from vril_density, boss/set-piece marker placement from climactic_affordances.
• Mechanism (seam: split three ways): template AUTHORING is Epic's first-party MCP PCG toolset (its one strong, sanctioned toolset, with the mandatory "PCG graph generation skill" loaded); per-zone INSTANTIATION/PARAMETERIZATION/EXECUTION is native Python (unreal.PCGComponent.generate() — silently fails if called before the owning actor has a valid world/transform, sequence after actor spawn); whole-region HEADLESS BAKE runs via UnrealEditor.exe -run=WorldPartitionBuilderCommandlet -Builder=PCGWorldPartitionBuilder -IncludeGraphNames=... -Unattended -AllowCommandletRendering. Raw-Python graph authoring (add_node_of_type/add_edge) exists but is brittle — templates plus parameterization is the reliable path by design choice, not a hard blocker.
• Output: populated zones — flora/fauna/creature/boss-encounter-MARKER placement (trigger/spawner actors referencing DT_Bosses by RowName), protected zones suppressing hostiles via the Step 3 Data Layer.
• Verification: community-reported edge-case bugs in PCGWorldPartitionBuilder (iterative cell loading + a Grid Size node can throw an executor error) — test against the SPECIFIC template graphs before CI reliance. A PCG-spawned boss marker is not a fight — everything downstream of "a boss exists here" (attack patterns, phase transitions) is bespoke gameplay code, flagged separately at §4 and comparable in scope to Step 4's shim.
• [SRC: UE_BUILD_AUTOMATION §2.4, §3.2-3.6, §9 Step 6-8; T1_Region_Page_Template Machine Blocks]

Step 7 — NPC placement (MetaHuman batch, the cloud round-trip budget)

• Input: region page Section 12 (persona fields, three-path outcomes) + Section 4 (appearance ranges, dress-and-adornment per culture/era/role) + T0_Character_Index/T0_Antagonist_Network_Registry rows (mesh_pipeline_type defaults metahuman for these two registries per Contracts §1.5.1).
• Format: MetaHuman Character assets for named/principal NPCs (face/body parametrics, wardrobe, skin material); the Experimental MetaHuman Crowd plugin or classic modular/instanced characters for background faction rosters.
• Mechanism (seam: NeoStack designs the sampling script once, native Python executes at scale): the documented Python Scripting for MetaHuman Creator API (added 5.7, extended 5.8) via the MetaHuman Character Editor Subsystem — create-asset, set body/face/wardrobe/material properties, GetFaceModelCoefficients/SetFaceModelCoefficients (5.8's PCA conform-to support) as the concrete lever mapping persona/appearance-range data to parametric face variation. request_auto_rigging + request_texture_sources round-trip Epic's CLOUD per character for the rig/texture bake — this is not scriptable away.
• Output: one MetaHuman Character asset per named/principal NPC; Crowd-plugin or modular actors for the rest of the roster.
• Verification: cloud auto-rig/texture throughput at "hundreds of NPCs" scale is undocumented by Epic — budget latency, require connectivity, validate empirically before committing to a MetaHuman-per-NPC pipeline at this project's roster size (§4). The Crowd plugin is Experimental — "use caution when shipping" — keep a classic modular-NPC fallback ready. No published hard cap on simultaneous MetaHumans exists; the real constraint is groom (strand hair) VRAM residency.
• [SRC: UE_BUILD_AUTOMATION §5.1-5.6, §9 Step 9; T1_Region_Page_Template §4, §12; T1_Build_Pipeline_Contracts §1.5.1]

Step 8 — Quest wiring from the spine graph

• Input: this region's extracted beat rows (objective/actors/systems/threads/in:/out:/reveal), fork_node + ACTION-keyed option tables (direction/delta/axis_value/mark_write/relationship-faction/opportunity_effects/ws_writes), and SQ beat rows (sq_id · questline · stage · gate {condition-expr} · beats · reward) — SPINE_SCHEMA_v3 §3a/§3c/§3d.
• Format: Blueprint quest-graph nodes / State Tree Enter Conditions per fork and SQ gate; the gate {condition-expr} mini-grammar (has(local.key), at(site_id), flag(local.key), ws.key {==|>=|<=|in} val, read(surface), boolean &/|, produce-before-consume) is the literal condition surface both targets translate — SPINE_SCHEMA_v3 §5.3.
• Mechanism (seam: NeoStack drafts, native repeats): NeoStack drafts the FIRST Blueprint/State-Tree graph per quest/fork pattern from the beat's structured row — canon intent to asset graph, the textbook NeoStack case; once a pattern is set, translating repeat gate-grammar tokens to Branch/Enter-Condition nodes across the rest of the same questline is bulk/native. Reads T0_Questline_Index, T0_Worldstate_Variables, T0_Chapter_Index, T0_Character_Index, T0_Antagonist_Network_Registry, T0_Ability_Tree_Registry, T0_Trade_Registry, T0_Vril_Site_Registry, T0_Inscription_Spine, T0_Hard_Lines per Contracts §1.3's Quest System dependency line.
• Output: quest-trigger Blueprint/State-Tree logic wired to this region's beats/forks; every ws_writes/out: delta becomes a call into the Step 10 WorldStateSubsystem.
• Verification: local.* produce-before-consume is already gate-checked upstream at the spine layer (harness/check_spine_graph.py) — the UE graph must not introduce a token the spine gate didn't already resolve. State Tree is the right consumer for RUNTIME reaction to ws.* (Property Bindings read AND write a tag) but the wrong PARADIGM for the stateless rule-row table itself — do not re-author fork tables as tree nodes.
• Flag: mark_write's shape ({community_id, valence, persistence, forward_track:[CH_NN]}) is richer than a scalar ws.* value — whether it lives in its own DataTable-backed ledger or extends the WorldState map is unresolved by any source read for this doc; it is scoped into the Step 10 validation spike, not decided here.
• [SRC: SPINE_SCHEMA_v3 §3a, §3c, §3d, §5.3; UE_BUILD_AUTOMATION §7.4, §9 Step 8; T1_Build_Pipeline_Contracts §1.2 Quest System, §1.3]

Step 9 — Scene rows to Sequencer

• Input: this region's extracted scene rows — the executed seven-column shape scene_anchor_id | beat_ref | scene_type | path_bucket | anchor_type | participant_refs | hard_line_relevance (uniform across all 79 live nodes; the intent trio thematic_anchor / audio_priority_layer / scene_audio_intent defers by rule to the Scene_Spec population pass, per each node's own §13 preamble — SPINE_SCHEMA_v3 §3d is corrected to this shape, 2026-07-15) — plus the region page's own ambient-cinematic additions (the only scene rows a page may author, per its Derived Indexes Scene index).
• Format: Level Sequence assets, duplicated from scene_type "shot template" sequences (pre-authored camera-cut tracks/cadence, one per the 11 VERBATIM scene_type values).
• Mechanism (seam: NeoStack authors templates once per scene_type, native Python populates per row): scene_anchor_id becomes the generated sequence's asset name/path (also the idempotent-regeneration key); beat_ref selects which parent sequence's MovieSceneSubTrack (Shots/Takes) this shot slots into; scene_type selects which template gets duplicated (the highest-leverage mapping — templates carry the camera blocking that should not regenerate per row); the level/sub-level the sequence renders against (MapName in the MRQ command line) comes from the beat→site→region join (beat_ref → §3a site → region map — corpus-corrected 2026-07-15: anchor_type is the TRIGGER-CONDITION class scene_entry/beat_transition/dialogue_initiation/branch_decision_point/reveal, consumed by trigger wiring, never a map anchor); participant_refs resolve to possessable (add_actors) or spawnable (add_spawnable_from_class/instance, create_camera) bindings against the Step 7 NPC/MetaHuman assets. Audio tracks populate from dialogue SoundWave assets and facial animation from MetaHuman Animator's audio-driven mode where a dialogue/VO source exists.
• Output: an assembled Level Sequence per scene row; headless QA-render via Movie Render Queue (-MoviePipelineConfig=... -windowed -resx -resy -log -notexturestreaming, or MoviePipelinePythonHostExecutor for a fully scripted pipeline).
• Verification: hard_line_relevance (the executed 7th column — HELD/LIFTED + HL refs) has no renderable engine equivalent — it is the care/reveal-discipline trace, consumed as a QA/verification signal on the generated sequence, never a track; thematic_anchor is not a spine column at all (deferred to the Scene_Spec pass with the audio pair). Camera blocking, timing, and cut rhythm are not in the schema at all — they come from the scene_type templates or a separate heuristic step; this is the single biggest gap between "scene row" and "finished cinematic." The schema carries no dialogue/audio line reference — a dialogue-to-SoundWave linkage is a genuine schema gap, not a UE limitation, if auto-populated audio + lip-sync is wanted.
• [SRC: UE_BUILD_AUTOMATION §6.1-6.5, §9 Step 11; SPINE_SCHEMA_v3 §3d]

Step 10 — Save/worldstate wiring (the ws.* subsystem — ORIGINAL ENGINEERING)

• Input: extracted fork-table ws_writes/mark_write values, beat rows' in:/out: ws.* deltas, T0_Worldstate_Variables (WS_NNN).
• Format: a DT_ForkRules DataTable (condition key/comparator/value, target key, set value, scope) ingested via Step 2's standard mechanism; a custom UWorldStateSubsystem : UGameInstanceSubsystem holding TMap<FGameplayTag, FWorldStateValue> (FWorldStateValue a small tagged-union struct — enum discriminator + bool/int/enum payload, so all three ws.* types share one map); a UWorldStateSaveGame : USaveGame persisting the map via AsyncSaveGameToSlot.
• Mechanism (seam: none of the three — bespoke hand-written C++, built once): ORIGINAL ENGINEERING, not an Epic-documented pattern. Epic's USaveGame docs cover basic serialization only, with no architectural guidance for dozens of independently-tracked flags; Lyra — Epic's own flagship sample — ships no save/persistence reference at all. State Tree is a CONSUMER of ws.* at runtime (Enter Conditions/Property Bindings can read and write a tag) but the wrong paradigm for the rule table itself — fork tables are stateless per-node rows evaluated at story beats, State Tree is a hierarchical state machine; forcing ~39 keys times per-chapter rules into tree nodes is an impedance mismatch. GAS is unsuited for a different reason — loose tags model booleans only, not the enum/int payloads ws.* needs, and are not auto-persisted.
• Output: a runtime worldstate authority (GameInstance-scoped, survives level loads by construction) plus a persisted save slot mirroring T0_Worldstate_Variables.
• Verification: **run a validation spike — wire 3-4 real ws.* keys end to end — before committing the full ~39-key architecture** (§4). Never report this subsystem as settled; it is a synthesized recommendation built from verified subsystem-lifecycle facts, not a cited Epic pattern.
• Flag: mark_write's shape ({community_id, valence, persistence, forward_track:[CH_NN]}) is richer than a scalar FWorldStateValue — whether it needs its own DataTable-backed ledger or an array extension is unresolved by any source read for this doc; fold it into the same spike rather than deciding it here.
• [SRC: UE_BUILD_AUTOMATION §7.1-7.7, §9 Step 10; SPINE_SCHEMA_v3 §3c; RESEARCHED_STACK Chain 3]

Step 11 — Cook/package (RunUAT)

• Input: the fully assembled + validated region level(s) — Steps 3-10 repeated per region_id across all ~69 regions — then this step runs once over the whole project (or per-region for iteration).
• Format: cooked platform-specific content + .pak.
• Mechanism (seam: native/CI, zero judgment, Epic-sanctioned at scale): -run=DataValidation first (extensible with custom UEditorValidatorBase subclasses in C++/Blueprint/Python), then RunUAT.bat/.sh BuildCookRun -project=... -noP4 -platform=Win64 -clientconfig=Shipping -cook -allmaps -build -stage -pak -archive -archivedirectory=... -nocompileeditor -utf8output -unattended -nosplash, fully headless (-nullrhi for pure data/cook work, -RenderOffScreen if a GPU-dependent step like lighting is involved). Epic's own Horde system (BuildGraph XML, Unreal Build Accelerator for distributed compilation) is the proven at-scale orchestration pattern for exactly this step — heavy to stand up fully for a solo dev, but the BuildGraph/UAT/commandlet primitives it wraps are what this pipeline calls directly.
• Output: a packaged, shippable build (per-region iteration build or full-project release).
• Verification: the DataValidation pass is the gate; re-run per commit during development and on every release build, per Contracts §1.4's build-time export cadence.
• [SRC: UE_BUILD_AUTOMATION §1.3-1.5, §9 Step 12-13; T1_Build_Pipeline_Contracts §1.4]

---

4. THE SPIKES + UNKNOWNS

Every row is a genuine open question — none of these outcomes are settled by this doc, and none

should be treated as settled by anyone reading it. Trigger = what gates the spike; Owner = who

resolves it.

---

5. Per-region build checklist

The repeatable loop a Build Ready region page drives. Precondition: the page's status field reads

Build Ready, harness/check_region_page.py is green, and every chapter in chapter_set passes

harness/check_spine_graph.py. Scope mirrors T1_Region_Page_Template's own Consumer Loading

Pattern for UE5 Build: the Machine Blocks + Sections 1, 2, 3, 4, 6, 7, 9, 12, 17, 18 [SRC:

T1_Region_Page_Template "Consumer Loading Patterns"].

1. Extract — pull this region's site/beat/fork/scene/SQ rows from every docs/spine/CH_NN.md in chapter_set into CSV/JSON; pull the region page's Zone Catalog + Derived Indexes (Step 2 pre-step).

2. Ingest — refresh/create this region's DataTable rows (Step 2); verify RowName stability against the last build.

3. Scaffold — convert/create the region's .umap, set CellSize, tag protected zones into the SafeZone Data Layer (Step 3).

4. Terrain — synthesize the region's heightmap (DEM → GDAL → Gaea) at a valid vertex size; run the Landscape-import shim with WorldCover-derived initial weightmaps (Step 4).

5. Materials — confirm the pre-authored auto-material self-assigns correctly for this region's WorldCover mix; spot-check for terracing/mismatched layers (Step 5).

6. Populate — instantiate + parameterize the biome-matched PCG template(s) per zone; run the headless per-region PCGWorldPartitionBuilder bake (Step 6).

7. NPCs — batch-generate this region's named/principal MetaHuman roster from Section 12 persona data; assign Crowd/modular actors for background factions; budget the cloud round-trip (Step 7).

8. Quests — wire this region's beat/fork/SQ rows into Blueprint/State-Tree quest logic; confirm every ws_writes/mark_write calls the WorldStateSubsystem (Steps 8, 10).

9. Cinematics — duplicate scene_type templates for this region's scene rows (spine-bound plus the page's own ambient-cinematic additions); resolve participant_refs to the Step 7 NPC assets (Step 9).

10. Validate — run -run=DataValidation against this region's new/changed assets plus custom validators (RowName integrity, reveal-ladder compliance, hard-line checks) (Step 11).

11. Iterate or cook — fold into the next full-project BuildCookRun, or cook this region alone for fast iteration (Step 11).

12. Record — note this region's build state against §4: a region can reach Build Ready on the page and still be blocked by an unresolved spike (no landscape shim yet means no region clears Step 4, regardless of page status).

This doc updates as spikes resolve and as the first real region build surfaces edge cases the

adjudicated research couldn't anticipate — per the versioning discipline in §1, that is a Translation

Doc refinement, not a Pipeline Contract amendment, unless a region build surfaces an actual canonical

schema gap.

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