pipelines/genre_baseline_audit.json
{
"lanes": [
{
"lane": "character-animation",
"items": [
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:285 (character-creature gap 0) + :362 (required_additions[0])",
"what_we_treat_as_open": "That no view count, camera height, lighting or background exists for a being plate, and that the set of four (ortho_front/side/back/three_quarter) is an \"authored judgement\" needing justification because \"no repo doc rules a view count\".",
"industry_default": "The character/creature model sheet is one of the oldest fixed conventions in the industry: orthographic front, side and back at identical camera height, lens, scale and framing on a flat neutral ground, plus one 3/4 hero view. Nobody boards the view count; it is the deliverable's definition.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The turnaround is the standard four-view model sheet — orthographic front, side, back at one camera height, lens, scale and neutral flat light, plus a 3/4 hero view — required on every model-bearing being row; this is the industry deliverable, not a repo ruling."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:397 (required_additions[7], THE NEUTRAL-POSE RULE)",
"what_we_treat_as_open": "That a per-morphology \"declared neutral pose\" has to be authored as a new rule, with chimeric morphologies \"declaring their own\".",
"industry_default": "A-pose for bipeds is the universal default (UE5 Mannequin, MetaHuman and every auto-rigger in the 3D-gen stack ship and expect A-pose; T-pose survives only where a legacy retarget demands it). Quadrupeds stand square, serpentines relax in an open S, avians perch with wings half open. This is rigging hygiene, not a design call.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Neutral pose follows the standard: A-pose for bipeds (matching the UE5/MetaHuman skeleton the whole lane retargets into), quadruped standing square, serpentine relaxed open S, avian perched wings half open — behaviour and attack poses are always additional plates and never the geometry input."
},
{
"surface": "registries/T0_Equipment_Registry [DRAFT v0.1]/Sheet1.csv (single row EQ_0001, equip_slot=\"unassigned_stat_slot\") + docs/PRE_5090_BUILD_PLAN.md:427 (P2.6 \"Equip/stash/weight SPEC is a Josh gap\")",
"what_we_treat_as_open": "The equipment slot vocabulary is literally unassigned on the only row, and the equip spec is filed as a Josh gap in the sec-12 bundle (item 26, PRE_5090_BUILD_PLAN.md:621).",
"industry_default": "The action-RPG paper doll is a fixed slot set: head, shoulders, chest, hands, waist, legs, feet, back/cloak, two accessory (ring/amulet), main-hand, off-hand — layered over the base body. Josh's thirty-second-sitting layering ruling already presupposes it; the slot list is the layering system's alphabet, not a separate decision.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "equip_slot closes on the standard paper-doll enum (head, shoulders, chest, hands, waist, legs, feet, back, accessory_1, accessory_2, main_hand, off_hand) layered over the undergarment base body per the thirty-second-sitting ruling; only whether the game carries an encumbrance/weight model at all stays a design call worth boarding."
},
{
"surface": "docs/concept_art/density_model.csv:32 (D1-31 missing_inputs: \"T0_Character_Index carries exactly ONE mesh_id_ref - the schema structurally cannot express a second outfit\") + build_sufficiency_review.json required_additions[15] (costume_set_ref)",
"what_we_treat_as_open": "That per-region companion outfitting is \"NOT RULED\" and that a second outfit is a schema hole requiring a new costume_set_ref variant-key axis, because one character row carries one mesh id.",
"industry_default": "Outfits are never a second character mesh. The base body is one skinned mesh on one skeleton; every garment is an equipment-layer mesh on that same skeleton, so N outfit states are N sets of equipment rows, not N character meshes. Josh's ruling already stated this architecture for the protagonist — it generalizes to every character without a further ruling.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Outfit states are equipment layers, not character meshes: mesh_id_ref stays the base body for every character and each outfit state resolves to a set of equipment-layer rows, which retires D1-31's \"schema structurally cannot express a second outfit\" and the costume_set_ref variant-key proposal along with it."
},
{
"surface": "docs/ART_PIPELINE_SUFFICIENCY_PROGRAM.md:83 (B3 \"attach-point/functional-part authoring\") + build_sufficiency_review.json:640 (props required_additions[6] invents gen_socket_plan with grip_root / grip_axis / tip / sheath_root / haft_second_grip / draw_origin markers)",
"what_we_treat_as_open": "Attach points are queued as an authoring item to be designed, and a fresh marker id-space is being minted for weapons. Corpus-wide there is no socket convention: grep for socket|attach.point|hand_r over docs/ returns only these two queue mentions (positive control: mesh_id_ref resolves across the same doc set).",
"industry_default": "Character skeletons carry a fixed named socket set (weapon sockets on the hand bones, sheath/holster sockets on spine and pelvis, FX and rider sockets), and every wielded mesh is authored with its origin AT the grip and a declared forward axis. Placement is then convention, not per-asset measurement — this is exactly why UE ships sockets on the Mannequin skeleton.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Adopt the standard socket convention — named sockets fixed on the canonical skeleton (weapon_r, weapon_l, sheath_back, sheath_hip, rider, FX) and every wielded mesh authored origin-at-grip with +X forward — so the socket plate becomes a QA overlay confirming the convention rather than a new marker id space."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:2461 (GAP-201: \"no facial, viseme, lipsync, line-count or duration column\"; \"a facial-bearing flag + rig class\") + build_sufficiency_review.json:377 (expression_sheet \"six cells\")",
"what_we_treat_as_open": "That the facial rig class, the blendshape set and the lipsync data home all have to be specified, and that an expression-sheet cell count must be authored.",
"industry_default": "ARKit's 52 blendshapes is the de-facto facial standard and is precisely what MetaHuman ships; lipsync is solved from audio at runtime/bake (MetaHuman Animator, Audio2Face), never from an authored viseme table per line. Since named NPCs already route MetaHuman-first (docs/translation/T99_Translation_AssetGen.md:82), the rig class question is answered by the routing that is already ruled.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Facial follows the MetaHuman/ARKit-52 standard by inheritance from the already-ruled MetaHuman-first NPC routing, and lipsync is audio-driven — so the only artifact concept art owes is a small emotion reference sheet (neutral plus the states the persona layer actually drives), with no facial rig class, viseme column or per-line facial data home to design."
},
{
"surface": "docs/ASSET_DROPIN_CONTRACT.md §2 asset-class table (eleven classes; grep animation|montage over the file = 0, positive control mesh_id_ref present) + docs/pipeline_review/tech_research/PIPE_ANIMATION_2026-07-29.md:102,108 (\"animation is NOT one of DR-2's eleven asset classes\"; proposes \"a twelfth §2 row\", in a doc whose line 4 says \"Nothing here is repo canon until the director lands it\")",
"what_we_treat_as_open": "Whether animation is an asset class at all is sitting unratified in a pre-canon research doc, so the frozen drop-in contract has no animation row, no placeholder, no path convention and no swap.",
"industry_default": "AnimSequence/AnimMontage is a first-class shipped asset class in every engine pipeline, with its own id, placeholder, convention path and swap mechanism — exactly like meshes, audio and materials. No AAA team would ship an asset contract without it.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Animation/montage lands as a first-class asset class in the drop-in contract on the same shape as the mesh classes — canon id = ability/attack id plus presentation_tier_ref, placeholder = the stock locomotion bind, drop path /Game/Animations/<class>/AM_<id>, path takeover, resolver key (canon id, presentation_tier_ref) with fallback down to the nearest authored tier."
},
{
"surface": "docs/pipeline_review/tech_research/PIPE_ANIMATION_2026-07-29.md:124 (\"THE RULING THIS NEEDS (PC-5, already recommended, still unruled): the canon ROW is authoritative and the montage is retimed to it\")",
"what_we_treat_as_open": "Whether the gameplay data row or the animation clip owns windup/active/recovery timing is carried as an unruled decision.",
"industry_default": "The data row owns the timing and the animation is retimed and notify-placed to it. Every data-driven combat game works this way, because the alternative silently rewrites balance whenever an artist re-exports a clip. The tooth (notify-vs-row tolerance check) is likewise standard.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The canon attack row is authoritative over montage timing and every montage is retimed and notify-placed to its row, with the notify-vs-row tolerance check shipping now as a must-not-fire fixture — this is the standard data-driven combat convention and needs no ruling."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:2493 (GAP-204: T1_Combat_System_Spec contains animation x0 and VFX x0 against a parry x14 positive control; root motion / cancel window / hit reaction / commit window / AnimNotify appear in 9 docs, none of them a law)",
"what_we_treat_as_open": "The animation craft law is filed as a HIGH-register finding that \"no rank owns\", i.e. the defaults for root motion, cancel windows, hit reactions and commit windows are treated as needing original authorship.",
"industry_default": "Root motion on attacks, dodges and traversal specials; in-place capsule-driven locomotion (or motion matching); AnimNotify-driven damage and cancel windows; hit reactions as additive/slot montages selected by hitzone direction and stagger magnitude. These are the defaults of the genre; only the per-move millisecond values are project-specific — and those are already inside the declared tuning firewall.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The animation craft law adopts the genre defaults verbatim — root motion on attacks/dodges/traversal specials, in-place locomotion, AnimNotify-driven damage and cancel windows, directional additive hit reactions — so the only thing the craft-law pass authors is where we deviate, with per-move timings left to the existing tuning firewall."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:2450 (GAP-200: \"Mocap-vs-keyframe routing has no owner, no ruling, and no column\"; \"No registry column routes an id to generated / studio-mocap / hand-key / Cascadeur-assisted\")",
"what_we_treat_as_open": "That per-item animation sourcing must be routed by a registry column and that PIPE_ANIMATION routing \"by LANE CLASS, never per item\" is a defect.",
"industry_default": "Animation sourcing is a class policy, not a per-asset field: bulk locomotion/ambient/traversal comes from a library or capture; hero beats, signature abilities and care-gated motion are hand-authored. Per-item routing columns exist only as sparse overrides, and most studios do not carry one at all. PIPE_ANIMATION's lane-class routing IS the standard.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Animation sourcing routes by class policy as PIPE_ANIMATION already states (bulk ambient/traversal generated or library; hero beats, ladder keys and care-gated motion hand-authored), with animation_source carried only as a sparse per-item override — the routing question is closed, only the owner seat needs assigning."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json character-creature what_build_needs (\"retargeting needs a declared skeleton/proportion profile\") + docs/pipeline_review/tech_research/PIPE_ANIMATION_2026-07-29.md:183 (Q4 SOMA 77-joint to UE5 Manny retarget fidelity); build repo C:/dev/Humanity/Humanity/Source/Humanity/Private/Core/HumanityCharacter.cpp:137 and HumanityBossCharacter.cpp:140 both bind SKM_Manny_Simple",
"what_we_treat_as_open": "That no canonical skeleton or proportion profile has been declared for the humanoid roster, leaving retarget targets undefined.",
"industry_default": "Exactly one canonical humanoid skeleton is the retarget hub for the whole game (here the UE5 Mannequin hierarchy, which MetaHuman is built compatible with), every humanoid is authored to its proportions, and every motion source gets one IK Rig plus one IK Retargeter into it. The engine already ships the convention and the build already binds that skeleton in two places.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The UE5 Mannequin/MetaHuman-compatible skeleton is declared the single canonical humanoid rig and retarget hub — every humanoid mesh is authored to its proportions and every motion source lands through one IK Rig plus IK Retargeter into it — which is what the build already does and needs only to be written down."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:392-393 (rig_notes overlay for \"the 182-row non-humanoid roster\") + docs/pipeline_review/tech_research/PIPE_3D_2026-07-29.md:223 (Q5: does UniRig rig non-humanoid anatomy \"or does the 132-creature roster need a paid point-solution after all?\")",
"what_we_treat_as_open": "The non-humanoid rigging problem is scoped per creature — 182 rows each needing an auto-rig to succeed or a paid rig purchased — with a per-plate rig_notes overlay proposed to steer the auto-rigger row by row.",
"industry_default": "Bestiaries are rigged per MORPHOLOGY ARCHETYPE, not per creature: five to eight hand-built skeleton templates (biped, quadruped, serpentine, avian, multi-limb/arachnid, amorphous/tentacular) carry a roster of hundreds, and each new creature is a proportion retarget onto its archetype with its animation set inherited. Per-creature rigging is what studios build archetypes to avoid.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Creature rigging is archetype-first: hand-build roughly six morphology skeleton templates with their own shared animation sets and retarget every roster row onto its archetype by proportion, which turns the auto-rig question from 182 unknowns into six known templates and reduces rig_notes to an archetype declaration on the registry row."
},
{
"surface": "Corpus-wide absence: grep -riE \"physicsasset|chaos cloth|ragdoll|apex cloth\" over _source/ and docs/ returns zero (positive control: \"collision\" hits _source/01_Tier_1_Foundation/T1_Build_Pipeline_Contracts [ACTIVE v1.0].md and four other tier docs); docs/translation/T99_Translation_AssetGen.md:237 rules collision hulls and LOD chains but names no physics asset, ragdoll or cloth",
"what_we_treat_as_open": "Nothing treats it as open — it is entirely absent, which is worse: no doc, queue item, gate or density class owns physics assets, ragdoll, or cloth/secondary motion for any of the 713 being rows, while D1-31-class garment accretion and a 182-creature bestiary are being sized.",
"industry_default": "Every skeletal mesh ships a Physics Asset (auto-generated bodies then hand-tuned) driving ragdoll, per-bone hit volumes and secondary motion; loose cloth, hair and appendages use Chaos Cloth painted on the mesh or a short kinematic bone chain with a physics-blend weight. This is a per-asset craft checklist item, not a design decision.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Every skeletal mesh ships a hand-tuned Physics Asset for ragdoll, per-bone hit volumes and secondary motion, with loose cloth/hair on Chaos Cloth or a kinematic bone chain — added to the finishing pipeline checklist beside collision and LOD, since the corpus currently names neither."
},
{
"surface": "docs/concept_art/density_model.csv:34 (D1-33 \"Vehicles and mounts\", SHEET_3, 3 vehicle rows, no rider artifact) + docs/proposals/systems/creature-system.md:179 (FORK 5 boards \"does the VH_ registry formally adopt ... the creature-mount class\" for Josh's nod) + docs/proposals/whole_arc/phase1_A3_ch70_73.md:55 (a mounted Wild-Hunt chase set-piece planned)",
"what_we_treat_as_open": "Whether the creature-mount class is adopted is boarded for Josh, and no rider/mount attachment, skeleton or animation-set convention exists anywhere while mounted set-pieces are already being written into chapters.",
"industry_default": "The rider is a separate skeletal mesh attached to a named socket on the mount's skeleton; the mount owns locomotion (idle/walk/canter/gallop/turn/jump/mount/dismount) and the rider layers an additive or override pose set, with mounted combat reusing the same weapon sockets. Rideable creatures are a content roster question; the rig architecture is not.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Mounts follow the standard rider-on-socket architecture — rider as a separate skeletal mesh on a named mount socket, mount owning locomotion and the rider layering an additive pose set with weapon sockets unchanged — so only WHICH creatures are rideable stays Josh's content scope, not how riding is built."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:315 (gap 6, no scale/proportion/anatomy column on any being registry) + :432 (required_additions[14], NEW height_m)",
"what_we_treat_as_open": "That a height column is a schema addition to be justified and that scale exists only inside an image until one is minted.",
"industry_default": "Every character and creature sheet carries a canonical height in metres before modelling starts, and the scale-comparison plate against a ~1.75 m human silhouette is the standard second view. Collision capsules, LOD targets, camera framing and encounter staging all read it. No studio starts a bestiary without it.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "height_m (plus a length axis for serpentine and quadruped forms) is written on every being row before any plate renders, and the scale plate is rendered against it — the standard model-sheet discipline, not a schema negotiation."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:345 (gap 12, plate_role is unvalidated free text) + :447 (required_additions[17], close the vocabulary and bind required roles per density class)",
"what_we_treat_as_open": "That \"a creature sheet is three plates\" is prose rather than a property, and that the per-class deliverable set must be designed.",
"industry_default": "Every studio ships a closed, named set of concept deliverables per asset class (model sheet/turnaround, callout, expression sheet, material study, scale comparison) and the sheet arity is a property of the class in the tracker. Closing the vocabulary is production bookkeeping, not a design question.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "plate_role closes on the standard deliverable vocabulary with a required-role set bound per density class, treated as production bookkeeping — the honest consequence being that boss and protagonist plate counts go up, which is expected, not a finding."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json gap 13 (roster drift: live T0_Creature_Roster 182 rows vs density_model D1-15 \"150 minted\" vs PIPE_3D \"132 creatures / 22 familiars\" vs T3_Creatures_Tameable 420+ ceiling)",
"what_we_treat_as_open": "Four live numbers for one roster, with rigging, plate and GPU-night budgets each computed against a different one.",
"industry_default": "One registry owns the count and every budget document derives from it at read time rather than restating it. Restated counts drifting apart across planning docs is a known failure mode with a known fix; nobody boards which number is right, they point everything at the owner.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The live T0_Creature_Roster row count is the single owner of the creature number and every budget, plate-count and schedule doc derives from it rather than restating it, with the 420+ ceiling carried only as a target on the registry itself."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:407 (required_additions[9], THE IDENTITY-LOCK RULE; per-subject LoRA vs multi-reference chain) + docs/work_queue.json:314 (WQ_0031 makes the view-consistency mechanism LANE-BLOCKING before any model-ready claim)",
"what_we_treat_as_open": "Cross-plate, cross-chapter, cross-cinematic character identity is framed as an image-generation problem to be solved by a LoRA or a multi-reference chain before the character wave can run.",
"industry_default": "In a 3D pipeline the MESH is the identity. Concept art establishes the design once; after the model is approved, every subsequent image of that character — costume variants, expression sheets, cinematic frames, marketing shots — is a RENDER of the model, not a fresh generation. Identity drift across plates is a pre-production-only window, not a shipping risk.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Identity is held by the approved mesh, not by the generator: concept art locks the design once, and every later view of a subject is rendered from its model — so the LoRA-vs-multi-reference question narrows to the pre-mesh design window only and stops being lane-blocking for the character wave."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:362-376 (required_additions[1], geometry_driver — exactly one plate per (canon_id, variant_key)), grounded in docs/pipeline_review/tech_research/LOCAL_3D_ASSET_GEN.md:116 (\"Do not plan a multi-view-first pipeline around TRELLIS.2\")",
"what_we_treat_as_open": "Designating exactly one image as the geometry driver, with the other turnaround views demoted to verification only.",
"industry_default": "A modeller is handed the whole turnaround and builds against all views; no view is privileged. Our single-driver rule is not the standard — it is forced by the installed image-to-3D generator consuming one image, with multi-image conditioning measuring worse.",
"verdict": "GENUINE_DEVIATION",
"recommended_text": ""
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:621 (sec-12 item 26 bundles \"locomotion/traversal verbs (Pillar 10 regional movement)\" among specs that \"None exist as specs today\"), against docs/PRE_5090_BUILD_PLAN.md:422 (P2.1 already BUILD-NOW with walk/run/sprint/jump/crouch)",
"what_we_treat_as_open": "The whole locomotion verb set is filed as a missing spec awaiting a UX/systems pass, including the base third-person set the build has already implemented.",
"industry_default": "The third-person action-RPG locomotion set is fixed: idle, walk, jog, sprint, crouch, jump, fall, land, dodge-roll, mantle, climb, swim, plus a stagger and a knockdown/getup. Only genuinely novel movement verbs get specced; the base set is assumed and built.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The base locomotion set is the genre standard (idle/walk/jog/sprint/crouch/jump/fall/land/dodge-roll/mantle/climb/swim plus stagger and knockdown-getup) and builds without a spec; the item-26 locomotion entry narrows to the Pillar-10 regional traversal verbs, which are the only genuinely ours."
}
]
},
{
"lane": "ui-systems-progression",
"items": [
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:427 (P2.6 row: \"*(Equip/stash/weight SPEC is a Josh gap.)*\"), re-quoted at docs/DESIGN_GAP_REGISTER.md:1450",
"what_we_treat_as_open": "The entire inventory/equip/stash/weight model is marked a JOSH GAP on the build row itself, so P2.6 (`UHumanityInventoryComponent`) has been sitting BUILD-NOW-but-unspecced since 2026-07-23. Nothing in the repo states a container model, a weight posture, or a stash.",
"industry_default": "A 100-hour third-person action-RPG uses category-tabbed LIST inventory (not a Diablo/RE spatial grid), a soft carry limit that slows movement rather than blocking pickup and never applies to quest/key/currency items, a shared stash at safe sites/home, and equipment as a paper-doll of named body slots plus weapon slots. This has been the settled shape since Dragon Age/Witcher 3/Horizon; a team assumes it and boards only deviations (e.g. Resident Evil's grid, Death Stranding's load physics).",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Inventory follows the 100-hour action-RPG standard by default — category-tabbed list inventory, a soft carry limit that slows rather than blocks and never applies to quest, key or exchange-medium items, a shared stash reachable at every vril-recharge/safe site, and equipment as a paper-doll of named body slots plus weapon slots — and only departures from that shape get a brief."
},
{
"surface": "registries/T0_Equipment_Registry [DRAFT v0.1]/Sheet1.csv:2 (the one live row, `equip_slot=unassigned_stat_slot`); enum described at docs/DESIGN_GAP_REGISTER.md:2103 and docs/fk_spec.json:829",
"what_we_treat_as_open": "The `equip_slot` enum is `seat_1..seat_7` plus six named stat slots plus three `unassigned_stat_slot` placeholders — a STAT-slot axis. There is no body-slot axis at all, and fk_spec.json:829 records the three unnamed stat slots as \"OPEN-2 ... surfaced, not ruled\". Josh's thirty-second-sitting ruling (base body + equipment layers, DECISIONS_PENDING_JOSH.md:11-16) presupposes a body-slot roster that no registry carries.",
"industry_default": "The paper-doll roster is genre-standard and near-universal: head, torso/chest, hands/gloves, waist/belt, legs, feet, back/cloak, plus one or two accessory slots, on top of the weapon/off-hand slots. Every layered-equipment character pipeline in the industry keys its layer art to exactly this set.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "T0_Equipment_Registry.equip_slot mints the standard paper-doll BODY-slot roster (head, chest, hands, waist, legs, feet, back, accessory ×2) as a second axis beside the existing seat/stat axis, because the ruled base-body-plus-equipment-layers architecture already requires it and the D1-23/D1-26 layer plates key to it."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:424 (P2.3 row: \"*(Control-scheme SPEC is a Josh gap.)*\") + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"input/control-scheme (gamepad + KBM)\") + docs/DESIGN_GAP_REGISTER.md:1855 (GAP-147)",
"what_we_treat_as_open": "The control scheme is a named Josh gap, and U11.8 (gamepad parity) has no reference mapping to build against; shipped prompts hardcode key names (HumanityPlayerHUDWidget.cpp:612/:623) and the reveal test's MustPass list certifies them.",
"industry_default": "The UE5 third-person action-RPG mapping is effectively standardised: left stick move / right stick camera; A-cross jump; B-circle dodge; X-square light; Y-triangle heavy; RS-click lock-on; shoulders/triggers for abilities and hold-radial; D-pad quick-slots; Options pause; a WASD+mouse mirror; and prompts drawn from a device-keyed glyph provider (never a literal key string) with full remap on both devices.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The control scheme is the standard UE5 third-person action-RPG mapping on gamepad with a WASD+mouse mirror, every player-facing prompt resolved through a device-keyed glyph token rather than a literal key name, and full remap on both devices — leaving only the game-native verbs (the ModeSwitch radial and the six-option dialogue wheel) as real design picks."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:425 (P2.4 row: \"*(UI/UX IA spec is a Josh gap.)*\") + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"HUD/UI information architecture\")",
"what_we_treat_as_open": "HUD information architecture is a named Josh gap, blocking rank 20's T1_UI_UX_Spec (docs/PRE_5090_BUILD_PLAN.md:128) which is still a 37-byte stub at _source/01_Tier_1_Foundation/T1_UI_UX_Spec [DRAFT v0.1].md.",
"industry_default": "Action-RPG HUD layout is settled: vitals bottom-left, ability/quick-slot cluster bottom-right, boss/elite bar top-centre shown only on engage, collapsible objective tracker top-right, world-space interact prompt at the target, floating damage numbers, compass/minimap top strip, and per-element visibility + opacity toggles in options.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The HUD adopts the standard action-RPG layout by default (vitals bottom-left, ability cluster bottom-right, boss bar top-centre on engage, collapsible tracker top-right, world-space prompts, floating damage numbers, compass strip, every element toggleable in options), so the spec's actual content is the L1/L2/L3 reveal-gating and the vril-bubble resource grammar — not the placement."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1773-1780 (GAP-144: \"~13 further ruled screens ... have no build item, no IA and no denominator\")",
"what_we_treat_as_open": "Thirteen named screens — inventory/equipment, character sheet, loadout manager, Rune Forge, imprint crafting, bonus selection, familiar roster, reputation ladder, vendor/barter + ledger, personal dimension, vehicles/base building, achievements, festival calendar — are treated as an unenumerated bill of materials with no owner, and the gap proposes authoring a screen roster from zero.",
"industry_default": "The AAA RPG screen roster is a known set that no team re-derives: inventory/equipment, character sheet, skill/ability tree, quest log, map, journal/codex, vendor, crafting, settings, achievements, save/load. Studios enumerate it in an afternoon and spend the design budget only on the title's own screens.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The screen roster is standard-by-default for its standard members (inventory/equipment, character sheet, ability tree, quest log, map, journal, vendor, crafting, settings, save/load, achievements) and needs no ruling to enumerate; only the game-native screens — Rune Forge, Grimoire, imprint crafting, familiar roster, personal dimension — carry real IA design work."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1888-1898 (GAP-150: \"No UI visual design system — no design tokens\") + docs/concept_art/density_model.csv:35 (D1-34 = the whole game's UI at 67 plates) + docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:920 (the proposed D1-45 producer class)",
"what_we_treat_as_open": "The UI design SYSTEM is treated as absent in whole — no tokens, no component set, no state model — with the fix framed as authoring a design system from nothing inside rank 20.",
"industry_default": "The token inventory of a UI design system is standard and portable: one colour ramp with semantic roles (surface/text/accent/danger/disabled), a type scale, a spacing scale, corner radius, elevation, focus ring, state colours, and an icon grid with fixed stroke weight — plus the component/state-grid/screen review triad the art review already proposes. Only the VALUES are a look pick.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The UI token schema is the standard design-system inventory (semantic colour roles over one ramp, type scale, spacing scale, radius, elevation, focus ring, state colours, icon grid + stroke weight) and lands with rank 20 as schema; only the token VALUES go to a board, and the component/state_grid/screen plate triad is their review surface."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1833-1843 (GAP-145: Attunements names five option FAMILIES and \"enumerates ZERO individual options\") + docs/proposals/DIFFICULTY_SYSTEM.md:218-228 + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"accessibility breadth\")",
"what_we_treat_as_open": "The accessibility option ROSTER is treated as unauthored design work needing a T0_Attunement_Option mint plus a spec fill before anything can be built, with the individual options apparently to be invented.",
"industry_default": "The 2026 AAA accessibility baseline is published and near-universal: subtitles on by default with size/background-opacity/speaker-name controls, full remap on both devices, hold-vs-toggle on every hold action, per-axis sensitivity and invert, camera-shake / motion-blur / FOV controls, reduce-flashing, UI scale, aim/target assist strength, and colourblind modes backed by a redundant non-colour channel. It is a checklist, not a design problem.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Attunements ship the published AAA accessibility baseline as their default option roster (subtitle size/background/speaker name, full remap, hold-vs-toggle, per-axis sensitivity and invert, camera-shake/motion-blur/FOV, reduce-flashing, UI scale, assist strength, colourblind modes with a redundant non-colour channel), and the only game-specific entry is the already-ruled non-negotiable vril-polarity multi-channel readability requirement."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1899-1909 (GAP-151: \"No controller-only navigability contract and no handheld/deck legibility target\")",
"what_we_treat_as_open": "Whether every screen must be controller-navigable, and what legibility target class the UI is authored against, are treated as open questions with no contract, despite a ruled Early-Access Steam ship.",
"industry_default": "Controller-only navigability with a visible focus state and a consistent confirm/back pair is a console-cert requirement and a de-facto PC standard; Steam-shipping titles author to a two-class legibility target (desktop 1080p at desk distance + a 7-inch ~1280x800 handheld) as a matter of course, because Deck Verified review happens whether or not the handheld is a named platform.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Every screen is fully operable controller-only with a visible focus state and a consistent confirm/back pair, and the UI is authored to the standard two-class legibility target (desktop 1080p at desk distance and a 7-inch 1280x800 handheld), with a per-screen gamepad-only completion assertion in the QA loop."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1910-1920 (GAP-152: \"No save-slot or New Game+ presentation model\") + docs/PRE_5090_BUILD_PLAN_VOL2.md:866-867 (PG-4 save-slot UX / PG-5 autosave, both BUILD-NOW with no spec)",
"what_we_treat_as_open": "The slot model, autosave cadence, autosave indicator, cloud-conflict UI and NG+ entry surface are all treated as unspecified, and GAP-152 routes the NG+ half to a Josh brief (\"§12 #28 ... added to the next bundled Josh brief\").",
"industry_default": "Single-player RPG save conventions are settled: manual slots plus a rolling autosave ring (typically three) plus one quicksave; autosave fires on objective/beat complete, area transition, pre-boss and on quit; slot cards show chapter, location, playtime, timestamp and a progression read with a screenshot; a non-blocking save indicator; cloud conflicts are surfaced for player choice and never auto-merged.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Saving follows the standard single-player RPG model — manual slots plus a three-deep rolling autosave ring plus one quicksave, autosaving on beat-complete, area transition, pre-boss and on quit, slot cards carrying chapter/location/playtime/timestamp/integrity band and a screenshot, a non-blocking save indicator, and cloud conflicts shown for player choice and never auto-merged — and the NG+ entry surface builds against the already-ruled #28 carry table rather than waiting on a new brief."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN_VOL2.md:887 (PG-11 \"difficulty-as-UX\", cross-referenced with no owner spec) + docs/proposals/DIFFICULTY_SYSTEM.md:1-37 (names + presentation ruled) and :218-228",
"what_we_treat_as_open": "The difficulty NAMES, lore backgrounds and presentation pattern are ruled and closed, but the selection SURFACE mechanics — when the choice is offered, what is preselected, whether it can be changed mid-run, whether changing it penalises anything — are nowhere stated.",
"industry_default": "Offer the tier once at new game before the first playable moment, preselect the developer-intended tuning, allow change at any time from the pause menu with no penalty and no achievement/trophy lock, and keep accessibility options on a separate always-available tab. Prestige/permadeath-class modes are the one standard exception: entry-locked at run start.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Difficulty is offered once at new game before the first playable moment, preselected to Fading (the true tuning), changeable at any time from the pause menu with no penalty and no achievement lock, with Attunements on a separate always-available tab — and only The Forgotten One is entry-locked, because it is an earned NG+ door rather than a menu row."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:808 and :885 (D1-34's pick framed as \"13 individually plausible colours\" / \"all 13 by 5 cells\") + docs/concept_art/density_model.csv:35 (D1-34 P0) + registries/T0_Rarity_Grade [DRAFT v0.1]/Sheet1.csv (colour_ref 0/13)",
"what_we_treat_as_open": "The whole rarity colour grammar is queued as a P0 board pick where Josh approves thirteen colours, with the review's own worry being that he will approve thirteen colours that do not read as a progression.",
"industry_default": "The loot-game rarity ramp is one of the most settled conventions in the medium — grey/white common, green uncommon, blue rare, purple epic, orange/gold legendary — stable from Diablo II through WoW, Borderlands, Destiny and every looter since. Players read it without a tutorial, and a title that reassigns it pays a comprehension cost for nothing.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The rarity ramp takes the settled loot-game grammar (common grey, uncommon green, rare blue, epic purple, legendary orange/gold) as ratified default, so the D1-34 board picks only the two off-ladder grades — mythic and the unique signature class — plus the shape/beam/pickup-SFX hooks, and the ladder plate exists to prove monotonicity rather than to re-choose six known colours."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:426 (P2.5 row: \"*(Loc STRATEGY is a Josh gap.)*\") + docs/PRE_5090_BUILD_PLAN_VOL2.md:750 (U11.24) + docs/DESIGN_GAP_REGISTER.md:1866-1875 (GAP-148: zero font/typeface mention anywhere in 20 T1 docs)",
"what_we_treat_as_open": "\"Localization strategy\" is one undifferentiated Josh gap covering the engineering contract, subtitle standards, font stack and the shipped-locale list together — so the engineering half (which is standard and time-critical, since FText cannot be retrofitted) waits behind a business question.",
"industry_default": "The localization ENGINEERING contract is standard and universally applied from the first widget: every player-facing string an FText from a String Table with a build-failing tooth on literals, a ~40% string-expansion layout allowance, a declared font stack with CJK/RTL/Indic fallback chain and licence records, and subtitles meeting the Game Accessibility Guidelines baseline (size, background opacity, speaker attribution, line length).",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Split the item and close the engineering half now: every player-facing string is an FText from a String Table with a gate that fails on literals, layouts carry a 40% expansion allowance, the font stack declares a CJK/RTL/Indic fallback chain with licence records, and subtitles meet the Game Accessibility Guidelines baseline — none of which waits on the locale list."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"localization strategy (target languages ...)\") + docs/DESIGN_GAP_REGISTER.md:1830 (\"the shipped-locale ring added to the rank-18 bundled brief\")",
"what_we_treat_as_open": "Which languages ship at Early Access and at 1.0.",
"industry_default": "None exists. EFIGS+ is common but is a market/budget decision per title, not a convention — an indie-scale solo build ships English-only at EA far more often than not, and the choice interacts with VO scope and the per-region pricing already ruled.",
"verdict": "GENUINELY_OPEN",
"recommended_text": "No default exists — keep the shipped-locale ring as a one-line business question on the rank-18 bundle, sized against the FText contract that closes independently of it."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN_VOL2.md:1535 and :1537 (EC-vendor tagged *(BLOCKED-ON-BRIEF)* in two live wave rows) + docs/DESIGN_GAP_REGISTER.md:1409-1462 (GAP-138) + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"economy/currency/vendor loop\")",
"what_we_treat_as_open": "The vendor loop as a whole is held blocked, and GAP-138's proposed home routes an \"item-sizing brief\" plus a T0_Vendor_Registry mint through Josh, even though the only genuinely cardinal half — the exchange MEDIUM — was ruled Option B on 2026-07-24.",
"industry_default": "Vendor mechanics are standard once the medium is known: a two-pane trade screen, sell-back at a fixed fraction of buy value, a buyback list, timed restock, per-vendor accepted-goods and stock lists, quest/key items unsellable, and a repair/upgrade tab where the game has one. Item COUNT is genuinely authorial; item LOOP is not.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The vendor loop takes the standard shape — two-pane trade screen, sell-back at a fixed fraction of buy value, a buyback list, timed restock, per-vendor accepted-goods and stock lists, quest and key items unsellable — layered on the already-ruled per-region diegetic media plus presentation-only value lens, so EC-vendor unblocks on the Option-B ruling and only the item COUNT remains an authorial scope call."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:48 (\"the two live slice briefs — D-ECONOMY-MEDIUM · D-DEFEAT-AXIS — both **Josh-pending**\") + docs/PRE_5090_BUILD_PLAN_VOL2.md:105 (H7 \"JOSH-PENDING everywhere\") + :960 (\"§11.6.4 is the AUTHORITATIVE pending-Josh stance\") + :884 + :927 + docs/FACTORY_CONTRACT.md:205 (FR-062 tooth `NONE(the defeat-axis brief is Josh-pending)`)",
"what_we_treat_as_open": "Two rulings that landed on 2026-07-24 are still labelled Josh-pending on six live surfaces, and the same file that records D-ECONOMY-MEDIUM as RULED Option B (:334, :1641) and D-DEFEAT-AXIS as RESOLVED (:1619, :1669) also holds them open — so lanes reading the queue keep treating settled ground as a brief.",
"industry_default": "Not an industry question — this is a stale-marker defect of exactly the class under audit: the pipeline re-derives a decision it already has because the marker outlived the ruling.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Strike the Josh-pending labels on both: D-ECONOMY-MEDIUM was ruled Option B and D-DEFEAT-AXIS was overruled and implemented, so EC-medium and EC-vendor read UNBLOCKED everywhere, FR-062's tooth gets a real data_home, and the three surviving BLOCKED-ON-BRIEF tags come off in the same commit."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN_VOL2.md:742 (U11.21 in-game map/minimap/compass/waypoint, BUILD-NOW, no spec) + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"world-map/fast-travel/navigation\")",
"what_we_treat_as_open": "The map/minimap/compass/waypoint screen is one undifferentiated unspecced item, which reads as if the navigation UX itself were undecided — when the only genuinely game-specific rule (walked geography; cross-region travel Vimana-gated at Ch 55; markerless navigation explicitly rejected in favour of a wayfinding legibility floor) is already ruled.",
"industry_default": "Open-world map screen conventions are settled: a zoomable region map with discovered/undiscovered shading, category-filterable pins, one player-placed custom marker, a legend, a fast-travel node list once unlocked, and a compass strip carrying the tracked objective's bearing plus nearby points of interest.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The map screen takes standard conventions — zoomable region map with discovered/undiscovered shading, category-filterable pins, a player-placed custom marker, a legend, a compass strip carrying the tracked objective's bearing — while the canon travel rule (walked geography, cross-region travel Vimana-gated at Ch 55, no pre-Ch-55 fast-travel network) stands exactly as ruled and is the only part that ever needed one."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:2108-2116 (GAP-169: \"The ten trades have no product catalog\"; T0_Equipment_Registry.recipe_ref points at no table) + docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"crafting/gathering runtime\")",
"what_we_treat_as_open": "The recipe layer is carried as an open design gap with no home, and #26 still asserts crafting/gathering has no spec — though FL-3, MN-6, TR-1 and LW-WIRE are live BUILD-NOW runtime items (docs/PRE_5090_BUILD_PLAN_VOL2.md:1029, :1090), so what is actually missing is one table shape.",
"industry_default": "The crafting recipe table is a standard schema everywhere it appears: recipe_id, output item + quantity, an inputs list of item_ref × quantity, required trade/discipline and tier, required station or site class, and a discovery/known state. Nothing about it is title-specific.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Mint T0_Recipe with the standard schema — recipe_id, output_item_ref + quantity, inputs[item_ref × quantity], required trade + tier, required station/site class, discovery state — as a schema act rather than a design question, leaving only the recipe CONTENT as authoring; and correct #26, whose crafting/gathering member already has a runtime owner."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:621 (#26 \"tutorial/onboarding ... None exist as specs today\") vs docs/PRE_5090_BUILD_PLAN_VOL2.md:777 (U11.30 authors docs/proposals/UX_TEACHING_SPEC.md) and :774-776 (U11.27-29, the ruled diegetic teaching spine)",
"what_we_treat_as_open": "#26 still claims tutorial/onboarding has zero coverage, but the doctrine is ruled (prompt-light, diegetic, first-use contextual, never a wall of tooltips) and U11.30 owns the spec; the file docs/proposals/UX_TEACHING_SPEC.md does not exist yet, so the item reads as unowned rather than as unwritten.",
"industry_default": "Contextual first-use prompts that are skippable, non-modal, shown once, and re-readable from a controls/help screen — the standard since roughly 2015; a dedicated tutorial level is the deviation, not the default.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Close #26's tutorial/onboarding member against U11.30's existing ownership and assume the standard shape — contextual first-use prompts, shown once, skippable, non-modal, always re-readable from a controls/help screen — so UX_TEACHING_SPEC.md writes the game-specific teaching beats (forced-run bear, first-water attunement, telegraph shape channel) rather than the convention."
},
{
"surface": "docs/DESIGN_GAP_REGISTER.md:160-172 (comparator entry 8: between-gates practice feedback, \"Ruling: No (bounded)\") + the WoW/Elden Ring divergence rows at :209-211 and :228-230",
"what_we_treat_as_open": "Whether progression shows a visible skill-up read at all — the register's own constraint says a visible skill-up scoreboard would contradict CVD §12.1's practitioner framing.",
"industry_default": "Visible XP bars and per-action skill-up numbers on craft/use (WoW, Skyrim, most RPGs); also markerless discovery (Elden Ring) and rested-XP return loops (WoW), both explicitly rejected here.",
"verdict": "GENUINE_DEVIATION",
"recommended_text": "Do NOT close this one with the default — CVD §12.1's \"becoming a practitioner rather than levelling up a stat\" makes the absent skill-up scoreboard load-bearing canon, so the between-gates read lands as diegetic learned-knowledge; it is correctly held, and is the counterweight showing the audit is not closing everything."
}
]
},
{
"lane": "world-rendering-tech",
"items": [
{
"surface": "docs/DESIGN_GAP_REGISTER.md:1690 (GAP-142 \"Proposed home\"); reinforced by docs/DESIGN_GAP_REGISTER.md:1662 and docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:102 (env gap 8)",
"what_we_treat_as_open": "GAP-142 boards \"a director brief (never bare — alternatives + recommendation) on the interior-geometry vector (Mesh Terrain re-target vs authored mesh-kit/level-instance interiors)\", on the premise that \"the vertical axis is ruled OUT: T99_Translation_Terrain §2 Step 7 imports classic heightfield Landscape... the only geometry that represents overhangs and caves\", so caves/interiors reportedly \"have no geometry representation at all\".",
"industry_default": "Heightfield terrain has never represented caves or overhangs in any shipping engine — that is not a limitation to be solved, it is the definition of a heightfield. Every open-world team since the early 2000s does the same thing: interiors, caves and overhangs are authored STATIC MESH geometry (a modular cave/architecture kit assembled in a Level Instance or streamed sublevel), placed against the Landscape, with a landscape visibility/hole mask punching the entry and mesh collision + nav authored on the meshes. Mesh/voxel terrain is the exception path taken only by games whose core loop is terrain deformation. The repo's own doctrine already lands on this (docs/ENGINE_OPTIMIZATION_DOCTRINE.md:1008 — Mesh Terrain \"EVALUATE, DON'T DEPEND | Prototype only; heightfield + Nanite is the safe path\").",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Interiors, caves and overhangs are authored mesh geometry — a modular kit assembled as a Level Instance / streamed sublevel, placed against the heightfield Landscape with a landscape visibility-mask hole at the entry and collision + nav authored on the meshes — so no interior-geometry brief is required; Mesh Terrain stays a prototype-only evaluation, and the W-SPACE tooth is amended to refuse DEM slope as evidence for any zone whose zone_space_class is interior_authored."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/e2e_compat_pass.json:549 (engine-factory RC 12; violation at :476)",
"what_we_treat_as_open": "\"Decide and record whether the engine consumes concept art at all\" — offered as a genuine two-way fork: build an art twin of import_audio_assets.py that writes a ue_texture_asset_path/previz_plate_ref back onto registry rows, OR declare concept art human-facing-only. Raised as a BLOCKER-adjacent because 76 plates would otherwise be \"orphans under the standing anti-orphan rule\".",
"industry_default": "No. Concept art is a pre-production, human-facing artifact. It lives in the reference library (PureRef boards / Perforce / ShotGrid / the art bible) and is never imported, cooked or shipped. The only 2D art that enters the engine is UI/HUD/icon/texture art, which is a different asset class with its own pipeline (and the drop-in contract already has a HUD-art row). The engine-side counterpart of a concept plate is the blockout and the finished asset it produced — the plate's consumers are the DCC/3D-gen lane, the art bible and the critic, not a UE import.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Concept art is a human-facing pre-production artifact and is never engine-imported: its declared consumers under the anti-orphan rule are the art bible, the DCC/3D-gen conditioning lane and the review critics, and the only 2D art with a UE import path is the separately-classed UI/HUD/texture art already in the drop-in contract."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:77 (env gap 3) and :154 (env addition 4, \"The layout sidecar and its writeback\")",
"what_we_treat_as_open": "That \"no layout plate is spatially binding\", answered by inventing a new spatial data format: a <plate_role>__<hash12>.layout.json sidecar carrying pads/thresholds/affordance points, a new harness/emit_pad_manifest.py that transforms approved sidecars into Tools/sculpt/pads_<region>.json, and a GATE 43 sidecar-sha tooth — i.e. a picture becomes the source of truth for terrain the player walks.",
"industry_default": "The BLOCKOUT (greybox) built in-engine is the spatial source of truth, full stop — it is authored at real scale against the player's metrics, walked, and iterated to final; the 2D layout drawing is a communication artifact and is never machine-parsed back into level data. Reviews of layout are done on orthographic top-down and flythrough CAPTURES of the blockout, so the image derives from the data rather than the data from the image. Round-tripping a painted plan into pad polygons is a bespoke mechanism no shipping team maintains.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The in-engine blockout is the spatial authority: layout review plates are orthographic top-down and flythrough CAPTURES emitted from the blockout (so approving a layout is approving the pads themselves), and no image-side sidecar, pad-emitter or sidecar-hash tooth is built."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:548 (props gap 1) and :184 (env addition 10, mesh_ortho: \"AUTHORED JUDGEMENT (PIPE_3D specifies no input requirements at all)\") and :615 (props addition 1, gen_primary)",
"what_we_treat_as_open": "That \"the repo specifies nothing, anywhere, about what an image→3D conditioning image must look like\", so the whole conditioning-plate spec (single subject, neutral ground, matte, no baked light, scale figure, view set) is authored fresh as a novel repo judgement, with the corpus-wide zero-hit grep offered as evidence of a real hole.",
"industry_default": "The MODEL SHEET is a century-old convention and it is the universal modeling-reference handoff, in hand-modelled, photogrammetry and image-to-3D pipelines alike: single subject isolated on a neutral mid-value seamless backdrop, flat/diffuse even lighting with no cast shadow and no rim, no lens effects, orthographic front/side/back plus one three-quarter, a human or graduated-rod scale reference on a SEPARATE plate, and an alpha matte. Photogrammetry practice adds the same rules (cross-polarised, de-lit, no specular). None of this is an authored judgement — it is what every character/prop reference sheet has looked like for decades, and it is why the failure modes the review predicts (fused ground, baked highlights, second subjects becoming geometry) are known ahead of any benchmark.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The conditioning/reference plate follows the standard model-sheet convention — single isolated subject on a neutral mid-grey seamless backdrop, flat even lighting with no rim, cast shadow, bloom or lens effects, alpha-matted PNG-RGBA, orthographic front/side/back plus one three-quarter, and the scale reference on its own separate plate — and is written down as adopted practice rather than derived as a repo-original ruling."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:553 (props gap 2, \"VIEW COUNT IS UNRULED AND THE OBVIOUS ANSWER IS FORBIDDEN\")",
"what_we_treat_as_open": "A deadlock presented as needing a ruling: TRELLIS.2's multi-image conditioning is reportedly worse than single-image, but InstantMesh/HY-World are multi-view-native, so \"neither 'one canonical view' nor 'a four-view turnaround fed as multi-view' is correct, and nothing rules the split.\"",
"industry_default": "Two different questions have been fused. The ART deliverable is settled: the full four-view model sheet is always authored, because it is the human, critic and retopo reference and the only artifact that can falsify a hallucinated back face — its existence never depended on any model consuming it. Which subset of those views is fed to a given generator is a per-backend BENCHMARK PARAMETER measured on the day, exactly like a texture-compression setting; no shipping team treats it as a design decision.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "The four-view model sheet is authored for every hero-tier subject regardless of backend (it is the critic and retopo reference, not a model input), and the number of views actually fed to each image-to-3D backend is a measured benchmark parameter recorded per backend rather than a ruling."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:563 (props gap 4) and :665 (props addition 11, bbox_m)",
"what_we_treat_as_open": "\"NO SCALE ANCHOR ANYWHERE ON THE OBJECT PATH\" — T0_Weapon_Registry has zero size/dimension columns and \"generators emit unit-normalized meshes\", surfaced as a MAJOR gap needing a new schema decision.",
"industry_default": "Every asset in every AAA pipeline carries real-world dimensions and is modelled to real scale; in UE 1 unit = 1 cm and importing at wrong scale is a build error, not a style choice. Art requests have carried a dimensions field since the first asset tracker. A unit-normalised generator output is rescaled to the authored bounding box on import — that is a two-line import step, not a design question.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Every prop-bearing registry carries real-world dimensions (bbox_m, L×W×H in metres) as a required authored field, and the mesh import step rescales unit-normalised generator output to that box — assets are built to real scale by default, with 1 uu = 1 cm."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:518 (AG7.4 mesh_finish.py — \"Retopo... + UV unwrap + texture bake + export + LOD chains + convex-hull collision\"); positive-controlled corpus grep: zero hits for \"texel\" across docs/ and _source/ (control term \"lightmap\" returns docs/ENGINE_OPTIMIZATION_DOCTRINE.md:973)",
"what_we_treat_as_open": "Not boarded as open — ABSENT. The finishing harness UV-unwraps and bakes textures with no density target, the art program budgets 17,876 plates and a material lane, and no doc, gate, queue item or rider anywhere names a texel-density standard.",
"industry_default": "A project-wide texel density (pixels per centimetre) is set BEFORE asset one and is one of the first three numbers on any world-art style guide — commonly 5.12 px/cm as the world standard with a hero tier at 10.24 px/cm and a background tier at 2.56 px/cm, validated with a UV checker pass in the mesh QA step. Without it, tiling materials shift resolution between adjacent assets and the fix is a re-UV and re-bake of everything already produced.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Adopt a project texel-density standard now — 5.12 px/cm world standard, 10.24 px/cm hero, 2.56 px/cm background/vista — as a declared field on the asset class and a UV-checker tooth in mesh_finish.py, so no asset is authored or baked against an unstated density."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:92 (env gap 6) and :174 (env addition 8, \"time_of_day (a NEW closed enum...)\"); docs/FACTORY_CONTRACT.md:217 (FR-074, tooth NONE)",
"what_we_treat_as_open": "That lighting/time-of-day \"have no data home at any grain\" and the answer is to mint T0_Environment_State_Table with time_of_day as a NEW CLOSED ENUM alongside a nine-token weather vocabulary, with per-beat weather_required on the beat grammar.",
"industry_default": "Time of day is a CONTINUOUS normalized scalar (0–24 or 0–1) driving keyframed lighting/sky curves — in UE that is Sun Position Calculator + Sky Atmosphere + Volumetric Clouds + a light-curve asset — with named PRESETS (dawn / noon / golden hour / dusk / night) as sampled points on that curve, not as the storage type. Weather is a blendable state set with weights and transition times, not a discrete label. Storing TOD as a closed enum is the one shape that has to be re-derived the first time a sunset transition, a storm rolling in, or a beat that begins at dusk and ends at night is needed — and a per-beat authored TOD is a standard cinematic override on top of the continuous clock, not a replacement for it.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Time of day is a continuous normalized scalar driving keyframed sky/lighting curves with named presets as sample points, and weather is a weighted blendable state set with transition times — canon rows and beats reference the preset name and an optional override, and no closed time_of_day enum is minted as the storage type."
},
{
"surface": "docs/FACTORY_CONTRACT.md:216 (FR-073, data_home NONE_YET(GAP-142), tooth NONE); docs/DESIGN_GAP_REGISTER.md:1670 (\"the real water pass (actual water system/material, shore interaction) remains open\")",
"what_we_treat_as_open": "That water has \"no water class, depth, current or navigability column anywhere\" and \"the real water pass remains open\" with \"no plan row\" — framed as an unowned open problem while a live rank builds a baray-flow mechanic and a Ch-8 dhow set-piece on open water.",
"industry_default": "Water is an engine system, not an open problem: UE's Water plugin ships Water Body Ocean / Lake / River / Custom actors with water zones, a spline-driven river/shoreline, Gerstner-wave and single-layer-water materials, terrain carving into the landscape, a buoyancy component and swimmable/underwater post-process volumes, all keyed to an absolute surface height. The design side needs only which bodies exist, their absolute surface elevation, and whether each is swimmable / navigable / hazardous — a handful of columns on rows that already exist, not a research pass.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Water builds on the engine's water system — Water Body Ocean/Lake/River actors with water zones, buoyancy and a swimmable/underwater volume, at an absolute surface elevation from the heightmap's absolute encoding — and the canon side carries only water_class, surface_elevation_m, navigable/swimmable and shore_type, so FR-073's data home is a column pack on existing zone rows rather than an open pass."
},
{
"surface": "docs/FACTORY_CONTRACT.md:176 (FR-033: \"NONE(the slope assertion and navmesh continuity teeth are game-repo side)\"); docs/PRE_5090_BUILD_PLAN.md:466 (W4.6 names \"headless HLOD/minimap/navmesh builders\"); positive-controlled grep of the build repo returns ZERO hits for NavMesh|Recast|NavModifier|NavLink across Source/, Config/ and Tools/ (control: AbilitySystemComponent matches in Source/Humanity/Private/Combat/)",
"what_we_treat_as_open": "Not boarded as open — named once as a builder and once as a NONE tooth, with no owner, no config, no convention and no queue rank. No document states a collision convention either (the only collision reference in the plan is convex-hull generation inside mesh_finish.py).",
"industry_default": "Navigation and collision conventions are set at project start and are entirely standard: a Recast nav mesh built per World Partition cell as part of the same overnight bake as HLOD, nav modifier volumes for terrain the AI must avoid or prefer, nav-link proxies for jumps/ledges/ladders, and agent radii declared per creature class; collision uses simple primitives or convex hulls on props with complex-as-simple banned on gameplay-bearing surfaces, and landscape collision authored at a declared (usually coarser) resolution. None of it needs a decision — only writing down.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Navigation and collision follow standard practice — a Recast nav mesh built per World Partition cell in the same overnight builder pass as HLOD, nav modifier volumes and nav-link proxies for non-walk traversal, per-creature-class agent radii, simple-primitive or convex-hull collision on props with complex-as-simple banned on gameplay surfaces, and a declared landscape collision MIP — written into the engine doctrine as adopted convention so FR-033's teeth have a spec to bind to."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:107 (env gap 9, \"No vista/landmark/HLOD authority\") and :180 (env addition 9, the vista plate role)",
"what_we_treat_as_open": "That \"the distance layer... is authored by nobody, so it will be whatever the auto-LOD produces\", and that a new plate-role class must declare \"which silhouettes are navigational anchors or how the region reads at 2/10/30 km\" before HLOD/imposter budgets can be spent.",
"industry_default": "Two standard, separately-owned things, neither of them open. (a) HLOD and imposters are an AUTOMATED bake against a per-level budget — the repo's own doctrine already ADOPTS exactly this (docs/ENGINE_OPTIMIZATION_DOCTRINE.md:986: \"Overnight CI job, never an interactive step\"), so the distance layer is not left to chance, it is left to a budgeted builder. (b) Landmark and sightline authoring is the standard level-art COMPOSITION PASS — every open world since the mid-2000s marks its wayfinding beacons and vista lines at blockout, on the blockout, and validates them by walking the golden path. It is a normal level-design deliverable, not a new art-plate class needing an authority ruling.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "HLOD and imposters stay the budgeted automated overnight bake already adopted in the engine doctrine, and landmark/sightline authority is the standard level-art composition pass done ON the blockout at blockout time — marked beacons, vista lines and silhouette reads validated by a golden-path walk — with any vista plate being a capture of that pass rather than its source."
},
{
"surface": "docs/ASSET_DROPIN_CONTRACT.md:83 (the single \"Vril-site / prop / environment mesh\" row) and :92 (\"Eleven asset classes\")",
"what_we_treat_as_open": "The frozen per-asset-class contract table carries eleven classes, of which exactly ONE covers the entire environment (\"a single static mesh per vril site\"). There is no landscape/terrain class, no modular architecture kit, no foliage/vegetation, no decal, no water body, no interior level/sublevel and no animation class — and the review's env lane then re-derives the kit and interior classes from scratch as new mints.",
"industry_default": "The asset taxonomy of an open-world action-RPG is well-known and stable: terrain/landscape, modular architecture kit, prop/static mesh, foliage and vegetation, decal, water body, level/sublevel (interiors and set-pieces), skeletal mesh, animation set, material/texture set, VFX, audio, UI. Missing classes are not gaps to be discovered per-lane — they are the standard list, and every one of them inherits the same id → convention path → resolver → placeholder invariant the table already defines.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Extend the per-asset-class table to the standard open-world taxonomy — landscape/terrain, modular architecture kit, prop, foliage/vegetation, decal, water body, interior level/sublevel and animation set alongside the eleven already listed — each inheriting the existing id → convention path → resolver → placeholder invariant unchanged, so no lane re-derives a missing class as a novel mint."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:568 (props gap 5) and :640 (props addition 6, gen_socket_plan)",
"what_we_treat_as_open": "That \"no attach-point or functional-part authoring exists\" and the answer is a new drawn plate role (gen_socket_plan) overlaying named markers — grip_root, grip_axis, tip, sheath_root — on an orthographic side view, so a headless Blender step can place empties.",
"industry_default": "Sockets are authored ON THE MESH, in the DCC or the engine's Static Mesh / Skeleton editor, under a project naming convention (grip, muzzle, tip, sheath, fx_*), and read by the equipment and animation systems. That is where they live in every engine, because a socket must sit in the mesh's own transform space — a drawing on an orthographic view cannot be that authority, only a note to whoever places them. The drawing is optional communication.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Sockets and attach points are authored on the mesh itself under a fixed naming convention (grip / grip_axis / tip / sheath / fx_*) in the DCC or Static Mesh editor and read directly by the equipment and animation systems; any socket-plan drawing is optional reference and is never the authority."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:558 (props gap 3, \"THE PBR LANE IS DETERMINISTIC AND HAS NO INPUT PLATE\") and :630 (props addition 4, gen_material_callout — \"one per distinct material on the object (a katana = blade steel + ray-skin grip + lacquer saya = three)\")",
"what_we_treat_as_open": "That the deterministic PBR path (Material Maker / Materialize) has no plate class feeding it, answered by minting a per-OBJECT, per-material flat crop plate — a plate count that multiplies with the object roster (72 weapons × ~3 materials, plus equipment).",
"industry_default": "PBR materials live in a shared MATERIAL LIBRARY, authored once per material and referenced by every asset that uses it: a master material with instances, tiling texture sets, and trim sheets, with per-culture/per-region variant sets. Bronze is authored once for the whole game, not three times because three objects contain it. Keying material inputs to the OBJECT rather than to the MATERIAL is the one shape that makes the library impossible and guarantees the same bronze reads differently on a blade and a door hinge.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Material inputs are keyed to a shared material library — one authored entry per material token (bronze, iron, obsidian, lacquer, hardwood, ochre…), with per-culture variant sets and a master-material/instance structure — and an object's registry row references library entries rather than owning its own per-material plates."
},
{
"surface": "docs/pipeline_review/art_pipeline_reviews_2026-08-03/build_sufficiency_review.json:122 (env gap 12, \"Every measured render tier is square (1024/1344/2048)\")",
"what_we_treat_as_open": "That plan and vista plates are \"aspect-wrong in a square frame\" and the proposed §7.1 aspect-conformance tooth \"has no per-role aspect target to check\", so an aspect_target column must be invented per role.",
"industry_default": "Concept plates are authored at the aspect of their USE, and always have been: 16:9 (or 2.39:1) for vistas, establishing shots, key art and anything destined for marketing; square or 4:5 for prop and character lineups; north-up orthographic at a declared metres-per-pixel for plans and layouts. The aspect follows the deliverable — this is a render-setting default, not a schema decision.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Each plate role renders at the aspect of its use by default — 16:9 for vista/establishing/key art, square or 4:5 for prop and character lineups, north-up orthographic at a declared metres-per-pixel for plans — set as a per-role render default in the dispatcher rather than boarded as an open schema question."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:211-214 (DEPENDENCIES block, \"THE fairy_realm INVENTED-TERRAIN PROTOTYPE\")",
"what_we_treat_as_open": "\"coordinates: N/A (dimensional) — the deterministic bbox→DEM→WorldCover→import→dress→stage chain has no input, and the path has never been run once\", carried as an unranked dependency and framed as a measurement whose outcome is unknown.",
"industry_default": "Fictional terrain is AUTHORED, not derived — this is the ordinary case, not the exception, and every fantasy game does it. A heightmap is synthesised in the same tools already in this stack (Gaea/World Machine procedural noise + erosion, or sculpted in-engine with Landscape or Modeling Mode), exported as the same 16-bit heightmap the DEM leg produces, and enters the identical import → dress → stage chain from that point on. Only the DEM fetch leg is skipped, and the WorldCover classification is replaced by hand-painted or authored layer weights. There is no unknown to measure — the chain has one substituted input.",
"verdict": "CLOSE_WITH_DEFAULT",
"recommended_text": "Invented terrain enters the existing chain from an AUTHORED heightmap — synthesised in Gaea or sculpted in-engine and exported as the same 16-bit absolute-elevation PNG the DEM leg emits, with hand-authored layer weights standing in for WorldCover — so the fairy realm skips only the DEM fetch leg and needs no separate path or prototype ruling."
},
{
"surface": "docs/PRE_5090_BUILD_PLAN.md:621 (§12 item 26, the missing-shipping-RPG-SPECS bundle: \"world-map/fast-travel/navigation... None exist as specs today\")",
"what_we_treat_as_open": "Fast travel and world-map navigation are bundled with ten other systems as specs that \"none exist\" for, sitting in the Decisions-needed-from-Josh section rather than being assumed.",
"industry_default": "Discovered-node fast travel is universal in the genre: a node unlocks on first arrival, travel is invoked from the world map or a map-screen list, is blocked in combat and usually in interiors/dungeons, and costs a load rather than time. It exists specifically so that BACKTRACKING is not replayed. The already-ruled deviation here (FORK C, docs/spine/DECISIONS_PENDING_JOSH.md:1594 — travel segments are playable, compressed, geographically accurate, with important crossings becoming staged dungeons) governs FIRST crossings; it says nothing about return trips, and the same completionist logic that ruled the NG+ dimension transfer (\"the completionist does not do it all over again\") points the same way.",
"verdict": "GENUINE_DEVIATION",
"recommended_text": "First crossing of every seam is the ruled FORK C playable compressed segment (the genuine deviation, already ruled); RETURN travel to any already-visited node is standard discovered-node fast travel from the map screen, blocked in combat and inside interiors — so the only thing that needs specifying is the unlock and block rules, not the mechanic."
}
]
}
]
}