Urban Vitality P7 | UE5 Population Orchestration: Stable Identity, Tiered Scheduling, and Representation Leases

Urban Vitality series · P7 · UE5 Logic Demo

P1 examined stable identity, regional population, tiered budgets, and representation handoff in a mature open-world runtime. P7 moves to the UE5 reconstruction: a runnable, saveable population-orchestration prototype with Full, Simulated, and StubTier logic tiers. Pedestrian movement belongs to P10; the presentation design and its L2 implementation belong to P13 and P19.

Previous foundation: Urban Vitality P1 | Open-World Population Orchestration

Introduction: Logical Population Before Character Presentation

Population prototypes often begin by spawning many characters. A few dozen moving objects can fill a scene, but they do not establish identity ownership, district population targets, regional migration, representation budgets, or save/load behavior.

P7 establishes a logical population independently of character presentation, then assigns selected identities to pooled Actors or batched instances. The acceptance map uses placeholder geometry. Identity, zones, schedules, tiers, and persistence continue to run with presentation disabled.

In this article, “three-tier degradation” refers to logical scheduling and is independent of mesh scaling or visibility. Full, Simulated, and StubTier determine update frequency and gameplay eligibility. Actor, ISM, Marker, and None are presentation choices. The reference runtime’s Entity Stub is a persistent identity foundation across representations; it is not the same as the UE enum’s lowest-frequency StubTier. All three UE logic tiers retain an AgentId and a Zone record.

The article follows five operations in LargeBlock_Demo. Each operation connects a source-runtime observation to the UE5 reconstruction and an acceptance result.

Demo operation	Evidence to inspect	Reference-runtime basis	UE5 reconstruction
Start PIE	All 72 identities are bound and all three tiers coexist	A stub precedes an entity; identity is independent of representation	AgentId, Zone records, and SOA
Press F1–F5	Communities move through home, commute, work, and leisure phases	Community, time periods, and EntrySpawner	JSON schedules, work sites, and Schedule Coordinator
Press F6	Target gaps, pending work, and active population converge over several steps	Registration, spawning, and attachment are accepted in stages	Bounded lifecycle batches, dormant reactivation, and deferred counters
Move the player	Requested tier, capacity target, applied tier, and representation lease change progressively	Importance competition, attachment budgets, and static LOD	Full/Simulated/StubTier, hysteresis, capacity targets, and transition budgets
Quick Save/Load	The current PIE session restores the population snapshot and observer position, then rebuilds presentation	Community, stub, and entity-ID persistence	Zone snapshots, session-scoped observer state, schema gate, and representation rebuild

From the Reference Runtime to UE5: Porting Runtime Semantics

P1 covered the reference population system. This reconstruction selects five semantics that directly determine implementation: identity precedes presentation, demand precedes spawning, requests are budgeted, representations can be attached and released repeatedly, and failure and reclamation have explicit states. It neither reproduces every internal type nor claims the full production feature set.

Population as a Coordination Layer

The population module in the reference runtime coordinates much more than individual NPC creation. Its source tree includes population pools, communities, community entry spawners, street crowds, distant crowds, response-unit spawning, visibility, budgets, teleportation, and persistence. The central system connects:

• authored community and schedule data;
• lightweight stubs that exist before entities;
• the runtime entity-spawn service;
• lane slots used by street crowds and the road-topology foundation shared with vehicles;
• distant-crowd rendering data;
• persistence and cross-system events.

The call relationships require a matching stub before an entity can be registered. The registration request then enters the population pool and is processed by a later pool update.

Entity add request
    → confirm that an Entity Stub exists
    → enter registration
    → append to the population registration queue
    → process during a later pool update

A successful add call means that the request was accepted. It does not mean that the entity has been constructed, inserted into the world, or equipped with AI, animation, and interaction state. A UE5 reconstruction therefore cannot treat the return value of SpawnActor as the complete population lifecycle.

Community Demand, Lane Slots, and Stable Stub Identity

Communities are one major source of regular population. Community data describes entries, activity regions, time periods, and spawn phases. When a region streams in, its communities enter an activation queue. An entry spawner then finds a spatial basis for every member. For work-oriented entries, it reserves an AI spot and obtains its world transform before requesting a new or restored stub.

Stub creation is asynchronous. The entry spawner retains a creation token and continues only after the “stub created or restored” result. No free position, failed reservation, region streaming out, entry deactivation, and creation failure are all normal states. Some failures use timed retries; deactivation must cancel callbacks that have not run. An orphan-container handoff is available when an entity must survive beyond the lifecycle of its original community entry.

Street background population enters through a different path. A crowd controller requests slots from traffic-lane segments and creates stubs around those slots; pedestrians may also reference work points. Because a slot can disappear while a stub is being created, completion must validate dependencies again. The source stub controller retains raw stub pointers and removes mappings through deletion callbacks under a lock, so stub lifetime is an explicit system responsibility.

The two demand sources converge on the same order of operations:

Community entry / street-crowd demand
        ↓
Valid spatial slot or work point
        ↓
Create or restore Stub
        ↓
Register with the population system
        ↓
Request an entity representation under budget

Schedules Produce Demand, Not Immediate Character Batches

A community schedule consists of time periods and spawn phases. A phase records a count, spawn markers or spots, and whether work is processed in order. When configuration changes, the time-period manager unregisters the old callback, applies the period for the current game time once, and then registers the new time notification. Midnight transitions wrap to the last valid period. Frame-number deduplication prevents multiple switches in the same frame.

Region streaming and community activation use tasks and bounded budgets. A region becoming available means that its communities may begin progressing; it does not mean that every stub and entity is ready. Authored demand can change by a large amount at once while the runtime fulfills it at its own cadence.

Registration, Construction, and Attachment Are Separate Stages

After registration reaches the population pool, pool updates process registration and unregistration, evaluate the importance of unattached records, and decide which entities to request. Construction creates a spawn context, writes a token to the spawn queue, and returns. Its callback only marks that the completed object should be inspected. A later pool update reads the finished token, obtains the entity, and schedules attachment.

Stub Create / Restore Request
    → StubRequestCompleted
    → Stable Entity Stub
    → Population Registration Queue
    → Entity Spawn Request
    → EntitySpawnCompleted (not attached)
    → Attach Budget / Queue
    → EntityAttached
    → GameplayReadyFlags become valid individually

Every stage can wait, fail, or be canceled. If removal targets an object still being spawned, the associated token is canceled, but cleanup must still wait for the token to reach a finished state. The attach event can also precede some downstream side effects, so “attached” does not imply that every gameplay-ready flag is valid.

The reference runtime also limits throughput within each phase. When a background queue reaches a pressure threshold, weaker requests can be canceled to release capacity for higher-importance work. Work beyond the current budget continues in later frames.

Budgets for Entity Existence and Attachment

The population pool tracks separate usage and limits for attached and unattached entities. A completed entity that cannot yet attach may remain in an unattached collection. When an expensive slot becomes available, the pool selects a candidate to attach. If the unattached collection is also full, weaker objects must be reclaimed or further queue growth rejected.

Candidate selection can include static type, source, distance, height difference, visibility, areas of interest, and request policy. The pool uses importance to decide whether to release an unattached slot, reclaim a low-priority entity, or permit visible spawning. Visible, soon-to-be-visible, and invisible objects follow different paths to reduce representation churn during camera rotation.

Static LOD can filter components after attachment. Crowd, Simple, and Occupant tiers differ by more than mesh choice: low-cost tiers may remove status effects, squad logic, perception, dismemberment, projectiles, and carried-object support. Degradation can therefore reduce entity count, per-entity simulation, and component composition at the same time.

P7 reconstructs the logic behind entity count, simulation cost, and representation leases. It does not reproduce a component-filter table that placeholder characters cannot verify. That work belongs after production gameplay and L2 presentation components are available.

Removal Also Uses Evaluation, Queues, and Handoff

RemoveEntity enters an unregister path and cancels incomplete spawning for the same identity. Existing entities may be disposed immediately, enter a fade queue, or wait because they remain visible. Immediate-removal logic distinguishes unattached records, fading entities, and currently visible entities; a removal request does not imply disappearance in the same frame.

Street crowds define additional cleanup reasons: lane streaming out, leaving the spawn range, traffic stalls, dead ends, spawn errors, excessive density, or remaining without an entity for too long after entering view. These causes converge on one slot-and-stub removal phase. A traffic-stalled object must also satisfy distance and invisibility conditions before reclamation.

Distant crowds use a separate visual-data path. Their controller selects lanes over multiple frames, updates a point buffer, and submits it to rendering. When disabled or short of valid lanes, it submits an empty result. A distant point may trigger a regular crowd request at a suitable location, but the point itself has no stable identity, gameplay state, or entity-completion semantics.

dot → stub → NPC is not an identity-transformation chain in the reference runtime. Distant points supply visual density, Stubs supply stable identity, and attached entities supply interaction capabilities.

Preserving Semantics Without Copying Internal Shapes

The reconstruction uses a project-owned SOA and does not depend on Mass Entity, MassTraffic, or ZoneGraph for its population mainline. UE-native frameworks can carry large crowds, but P7 prioritizes semantics that a general framework does not automatically provide.

Reference mechanism	UE5 P7 implementation	Deliberate difference
Dynamic Entity Stub	AgentId, active/dormant Zone records, and SOA state	Identity fields are distributed across project structures rather than copying the source type hierarchy
Community and EntrySpawner	JSON community schedules, Schedule Coordinator, and work-site slots	The demo tests three communities and deterministic spatial slots, not the complete AI-spot system
Registration queue, spawn token, attach scheduling	Bounded lifecycle queue, representation handoff requests, and Actor-pool sync	P7 does not imitate multithreaded async tokens; an observable fixed-step queue preserves the same budget boundary
Attached/unattached capacity	Logic-tier capacity and representation-lease capacity	Both stage cost decisions, but their states are not one-to-one equivalents
Static LOD component filtering	Not implemented	A verifiable filter table requires production character components in the L2 phase
Lane stubs and exceptional cleanup	Zone lifecycle, dormancy, and regional migration	P7 establishes identity continuity; pedestrian spatial graphs and avoidance belong to P10
Distant crowd dots	Outside the P7 identity layer	Anonymous distant density remains presentation work and is not conflated with Stubs
Community and population persistence	Zone records, an independent community snapshot API, and Demo SaveGame	Quick Save writes Zone records but not the community-member table

P7 uses runtime contracts as the unit of reconstruction. Deterministic SOA storage, Zone lifecycle, logical LOD, and representation pools verify three properties: identity does not depend on an Actor, work can be deferred when budgets are exhausted, and presentation can be rebuilt from logical state.

---

Identity and the Data Foundation

Four Identifiers with Different Lifetimes

The project uses AgentId, active-array index, stable slot ID, and representation-pool slot. All four locate data, but their lifetimes differ.

AgentId is the logical identity used across layers. Regional migration, schedule changes, tier transitions, and save restoration all match records through it. An active-array index only addresses the current SOA columns. The arrays use swap removal to stay compact, so removing a record moves the last record into its position. An active index must never become a persistent reference.

A stable slot ID belongs to logical storage. When a record is removed, its slot enters a free list. A new record can reuse that slot but receives its own AgentId. A representation-pool slot identifies only the Actor currently under lease. When an identity moves from Full to Simulated, the Actor slot can be released and reassigned while the logical identity and stable slot remain intact.

PIE validates identity binding with runtimeBound=72, duplicateAgentIds=0, and missingAgentIds=0. Swap removal may change an active index, degradation may release an Actor slot, and migration may change the Zone. AgentId alone must survive all of them. Persistence writes identity and required logical state, not reconstructible array indices or Actor-pool slots.

State ownership is explicit:

State	Authoritative owner
AgentId, community, Zone, occupation, active/dormant state	Zone population record
Position, velocity, route progress, fixed-step count	SOA
Current schedule demand	Schedule Coordinator
Requested tier, capacity target, and applied tier	LOD Resolver output; the Zone retains the latest result
Actor, ISM, and Marker lease	Representation Pool
SaveGame	Serialized projection of Zone state; excludes the independent community-member table

Position and scheduling fields written from the SOA back to a Zone are handoff snapshots for migration, persistence, and presentation. They do not transfer authority over motion state away from the SOA.

A Project-Owned Population SOA

Mass Entity, MassTraffic, and ZoneGraph are not mainline population dependencies in the current implementation. Earlier compatibility experiments may remain, but authoritative state belongs to project-owned structure arrays, fixed-step scheduling, regional records, and presentation interfaces.

The SOA stores fields by column:

struct FCyberPopulationSoAState
{
    TArray<FName> AgentIds;
    TArray<FVector> Positions;
    TArray<FVector> Velocities;
    TArray<float> SpeedsCentimetersPerSecond;
    TArray<int32> RouteOffsets;
    TArray<int32> RouteCounts;
    TArray<int32> CurrentTargetIndices;
    TArray<int32> AgentFixedStepCounts;
    TArray<int32> StableSlotIds;
    TArray<int32> FreeStableSlotIds;
};

The actual structure also contains speed, route-loop policy, completion flags, a shared route-point buffer, and an AgentId-to-active-index lookup table. Logical position does not live in a Scene Component, and route progress does not depend on a character-movement component. Presentation consumes these columns but cannot write its own Transform back as population truth.

Zones, coordinators, and presentation bridges may still use UE Actors for level integration, but one logical pedestrian does not require one ticking UObject. A future change in the batch-compute carrier can preserve AgentId, regional ownership, scheduling, and representation-handoff contracts.

Shared Route Buffer and Column Layout

Routes are not stored as one nested TArray<FVector> per active record. The SOA uses one shared route-point buffer and stores offset, count, and current target index per identity. This layout supports contiguous access and defines the exact fields involved in spawning, swap removal, and save conversion.

Configuration has two entry points. Regular Configure selects a route template through a stable hash of AgentId. ConfigureAssignedRoutes restores already-assigned per-agent routes and requires equal-length arrays for AgentIds, routes, initial positions, target indices, speeds, and loop policies. Both produce the same SOA layout. Incomplete input rejects configuration rather than continuing with misaligned columns.

ApplyLifecycleBatch handles lifecycle changes. It validates the current SOA, swap-removes requested identities, appends valid spawn requests, and prefers slots from the free list. Its result reports requested and completed work, slot reuse, and final structural validity.

LifecycleResult ApplyLifecycleBatch(DespawnIds, SpawnRequests)
{
    if (!ValidateState(Current)) return Failed;
    RemoveUniqueAgentsAndRecycleSlots();
    AppendValidAgentsAndReuseFreeSlots();
    RebuildAgentIndex();
    Result.bSucceeded = AllRequestsApplied() && ValidateState(Current);
    return Result;
}

bSucceeded=false may still accompany state changes. A duplicate removal, invalid spawn, or failed postcondition can occur after some removals and additions have completed, and the function has no change log or snapshot rollback. The Boolean states only that every request was fulfilled and the final state passed validation; it is not a transaction commit flag. A caller must treat failure as a possible partial commit and stop rather than retrying the whole batch. A production interface should distinguish RejectedNoChange, Committed, PartiallyCommitted, and InvariantFailure. Atomic batches also require complete prevalidation or validation in temporary state before commit.

Tiered Multi-Rate Fixed Steps

The runtime maintains one scheduler frame number. A tier stride or an external admission mask decides whether an identity advances on a given fixed step. In the demo, Full updates every fixed step, Simulated every two steps, and StubTier every eight. AgentId, last position, target index, and per-agent fixed-step count remain queryable when an identity is not admitted.

When a low-frequency identity receives an update, maximum displacement is Speed × FixedDelta × Stride, and velocity is divided by the same simulated duration. A single route segment therefore compensates for skipped steps rather than reducing actual speed to one-half or one-eighth. If one displacement reaches a path point, however, the current implementation stops at that point and changes targets without consuming the remaining distance. Existing tests verify the 1/2/8 strides and update counts; they do not prove equal elapsed-time progress through multi-turn routes. Strict time conservation and visual interpolation remain P10 work.

An external mask can suspend movement without changing presentation tier. Fixed-step results report requested, advanced, skipped, and route-completed counts by tier, together with stride and frame number. This distinguishes “not admitted on this step” from “identity missing.” The 1/2/8 configuration demonstrates multi-rate scheduling; it is not a final platform profile.

Removing an Active Record Does Not Destroy Identity Semantics

The active SOA uses compact arrays. Every column performs swap removal at the same index, the last record fills the gap, affected AgentId indices are rebuilt, and the released stable slot enters the free list. Spawn batches reject empty AgentIds, invalid routes, invalid speeds, and duplicate identities before taking a free stable slot.

This preserves contiguous batch traversal without leaving long-lived holes after repeated spawn and reclamation. Stable slots expose logical-storage reuse for diagnostics without turning a volatile array index into identity.

Lifecycle validation checks:

• equal length across all SOA columns;
• unique AgentIds and correct lookup indices;
• unique active slot IDs;
• unique free slot IDs with no overlap with active slots;
• active plus free slots covering the allocated slot range.

Automation removes one identity, inserts a replacement, continues fixed-step updates, and releases another identity to test the free list. Acceptance requires unique identities, continuing route progress, and a valid structure after reuse; an unchanged array count is only a surface result.

---

Zones, Schedules, and Lifecycle Work

Zones Own Population Records, Not One Management Actor per Person

A population Zone is the convergence unit for schedule demand and lifecycle work. One Zone Actor stores a density budget, active population records, dormant records, flow paths, and presentation budgets. These records carry state in the UE demo; they are neither source-runtime Entity Stubs nor scene Actors.

When a Zone first receives population requests, it limits acceptance by density capacity, then creates stable identity, prototype, Zone, logic tier, and flow position for each accepted record. Its state reports active and dormant counts, pending spawn and reclaim gaps, and capacity rejections from the previous step.

The Zone does not decide time-of-day demand. It receives target counts and performs bounded batches of reactivation, creation, or reclamation. The Schedule Coordinator owns demand.

Schedule Coordinator: required population type and count per Zone and time
Zone: converge current population under capacity and per-step limits
SOA: advance active logical population
Representation Pool: display approved representations

Zone records contain community, occupation, schedule, work site, and lifecycle flags. The SOA contains position, speed, and route progress. AgentId joins the two. A fixed step writes only the required handoff snapshot back to the Zone. State construction fails when counts, identities, or Zones disagree.

A regional update runs in these phases:

Receive target count
    → coordinator processes cross-Zone migration (currently unbounded)
    → Zone reactivates or creates under growth allowance
    → Zone moves records to dormant under reclaim allowance
    → update active and dormant records
    → configure or repair SOA state
    → run fixed steps by logic tier
    → resolve new LOD requests
    → produce representation-handoff snapshots

Schedule Data Produces Demand Rather Than Characters

The acceptance map loads project-owned JSON for three communities, three occupations, and three work sites. Market vendors, office workers, and maintenance staff each have a full-day schedule. Every interval specifies phase, activity, target Zone, target work site, and active-density scale.

Schedules are validated before use. Every hourly midpoint must match exactly one entry. Zone, community, and occupation IDs must be non-empty, and density scales must be valid. A valid schedule resolves to demand:

Community + current hour
    → Home / CommuteToWork / Work / Leisure / CommuteHome
    → target Zone
    → target work site
    → target active population

Target count is the community base count multiplied by the interval’s density scale and clamped between zero and the base count. A schedule transition changes how many people should be in each location; it does not spawn every Actor in the same function.

ValidateSchedule requires a valid target Zone, hours within 0–24, density within 0–1, and exactly one match at each of 24 hourly midpoints. A start time greater than the end time represents a midnight wrap. Because the data model permits fractional hours but validation does not inspect every interval endpoint, the test proves uniqueness only at those 24 samples. It cannot exclude a short gap or overlap between samples. The frozen JSON uses integer boundaries and is valid for current acceptance. Production validation should split wrapped intervals, sort endpoints, and prove continuous coverage of [0,24).

TargetActiveAgentCount = Clamp(
    Round(BasePopulationCount * ActiveDensityScale),
    0,
    BasePopulationCount);

Each test community contains 24 people and each work site exposes 24 slots. Matching capacities make schedule demand and spatial acceptance easy to distinguish; they are not a production rule. When work sites are undersupplied, the coordinator can report occupancy and waiting, but it cannot yet reassign occupations or select another work site dynamically.

F1 through F5 switch the map to 06:00, 08:00, 12:00, 18:00, and 22:00. Each switch resolves community targets, then migrates or reactivates existing members. The HUD reports occupation, target, active, dormant, and migration counts. AgentId sets should remain continuous. The three occupations are data-driven fixtures, not a general labor-economy simulation.

JSON Overrides and Failure Policy

The acceptance scene first builds a runnable default dataset, then attempts to load JSON overrides for work sites and community schedules. A missing file or JSON syntax failure emits a Warning and retains compile-time defaults. Only a successfully parsed non-empty field replaces its default.

Overrides cannot bypass project-data validation. A work site requires a valid occupation, Zone, position, and positive slot count. A schedule’s target Zone must exist in the scene registry. After coordinator configuration, the runtime counts every Zone referenced by the schedules and rejects startup if the resolved set does not match expectations.

Successful parsing does not imply valid semantics. Parsed overrides must still pass dataset, schedule, and scene-binding checks. If a present file contains invalid references, the system fails closed instead of silently returning to the default schedule. Missing files and syntax failures use explicit Warning-plus-fallback behavior; semantic failures after parsing stop population-scene configuration.

Bounded Zone Lifecycle Work

When schedules move from morning to work hours, target counts can change in several Zones at once. Fulfilling every gap immediately concentrates spawning and presentation sync in one frame. Removing every excess record immediately produces a visible batch disappearance.

At a fixed lifecycle interval, the Schedule Coordinator writes target counts and growth/reclaim limits to each Zone. Dormant reactivation and new-record creation share the growth allowance. Moving an active record to dormant consumes the reclaim allowance:

1. reactivate an old identity from the dormant set when demand increases;
2. create a new logical record if no suitable dormant record remains;
3. move farther active records to dormant when demand decreases;
4. retain unfinished differences for the next lifecycle step;
5. report counts rejected because the target exceeds Zone capacity.

This queue is not a background thread and does not imitate the reference runtime’s multi-token asynchronous spawn chain. It is an explicit bounded-batch protocol for the UE5 prototype. HUD fields separate pending spawn, pending reclaim, deferral, and capacity rejection so that “demand submitted” cannot be confused with “object ready.”

The default lifecycle interval is 0.25 seconds, with growth and reclaim allowances of two per Zone. F6 reduces each allowance to one and sets the interval to 0.35 seconds, making the Zone difference observable. The representation pool consumes handoff results only after logical processing.

Lifecycle state distinguishes at least target gap, pending spawn, pending reclaim, capacity rejection, and per-step deferral. If a target rises from 8 to 24 while the current step can create only 2, the result is “2 completed, 14 deferred,” not “14 failures.” Reporting deferral as failure would cause higher layers to resubmit work and eventually overpopulate the Zone.

P7 does not copy the reference entity-token implementation. Logical identity creation currently has no resource streaming or production-character asynchronous loading, leaving a token state machine without a verifiable asynchronous object. The current implementation retains queue acceptance, budget deferral, failure counts, and delayed presentation. Production Actor streaming and attachment can replace those phases when real character assets are integrated.

F6 proves that Zone-local reactivation, creation, and dormancy are bounded. It does not prove bounded migration between Zones.

Migration, Reactivation, and Creation Order

When a target Zone has a deficit, the coordinator first migrates members of the same community from other Zones. It then transfers excess active or dormant records from elsewhere. Only after those transfers does the target Zone reactivate local dormant records or create new identities under its growth allowance.

These operations do not all share one budget. The frozen implementation extracts and accepts cross-Zone records in batches before entering each Zone’s lifecycle queue. Community migration uses an unbounded request. Extraction, target acceptance, and ownership updates do not consume growth or reclaim allowance, so one schedule change can move many records synchronously. This path also does not update the independent community-member table held by the presentation runtime. Migration has failure return, but there is no MaxMigrationsPerStep. Production code needs a separate migration budget or must include migration in a unified LifecycleWorkBudget.

Falling demand does not release identity immediately. Excess active records become dormant and can later be accepted by the same community in another Zone. Commute transitions therefore change population ownership and activity state before expanding total identity count.

The implementation coordinates in deterministic Zone order and uses AgentId to break ties. The current contract has one authoritative coordinator: Zone-local growth and reclaim are bounded, while cross-Zone migration can still occur in batches. Parallel multi-district processing requires migration budgets and concurrent-transaction semantics.

Reclamation Enters Dormancy First

P7 reclamation is not final destruction. When a Zone must reduce active population, it prefers more distant candidates, moves records from active to dormant, marks them inactive, hides presentation, and retains AgentId, community, occupation, and recoverable state.

When demand rises again, dormant identities reactivate before new identities are created. This reduces identity churn across schedule transitions. Moving between 06:00 and 12:00 should preserve the AgentId sets of existing community members.

Five concepts must remain separate:

• an Entity Stub is the reference runtime’s identity foundation across representations;
• StubTier is the demo’s lowest-frequency active logic tier;
• a dormant record is outside the current active target and has no visible representation;
• releasing an Actor means losing full presentation, not becoming dormant;
• anonymous distant dots are outside P7’s identity lifecycle.

Dormant sets currently remain inside Zone Actors. This is sufficient for single-block and multi-Zone migration contracts. A city-scale runtime would need to shard, stream, or aggregate inactive regional data in higher-level storage; P7 does not validate that production concern.

Migration Transfers Record Ownership

A schedule target may reside in another Zone. The coordinator finds active or dormant members of the relevant community outside the target, extracts their state records from source Zones, and offers them to the target. Records that the target cannot accept are returned to their original Zone so that interrupted migration does not orphan identity.

The presentation runtime also holds an independent member table for community-continuity acceptance. It stores AgentId, community, Zone, last portal, and migration count, and supports its own snapshot validation. Schedule-driven cross-Zone migration does not update this table. P7 Quick Save writes only Zone snapshots, so the table, portal, and migration count are not restored or rebuilt from the Demo SaveGame.

The map divides 72 logical identities among three communities. One automated result records 48 identities that passed through portal migration. This establishes ownership continuity but does not cover production World Partition streaming. The project-owned portal contract tests source release, target acceptance, and rollback after failure; it is not a real city-partition loader.

---

Three-Tier Degradation and Representation Leases

Requested Tier, Capacity Target, and Applied Tier

The tier manager receives AgentId, distance, current tier, and ForceFull. Enter and exit thresholds combine with the current tier to produce a hysteretic distance request. This article calls that pre-capacity result DistanceRequestedTier.

Capacity is assigned through a stable ranking. Forced Full candidates come first, followed by candidates whose requested tier already matches their current tier, then distance and AgentId tie-breaking. Ordinary Full requests beyond the Full target fall back to Simulated; Simulated requests beyond the Simulated target fall back to StubTier. The article calls this result CapacityTargetTier. Current code does not retain it in a separate field; the capacity-adjusted value overwrites RequestedTier.

CurrentTier + Distance + Hysteresis + ForceFull
        ↓
DistanceRequestedTier
        ↓
Stable quota ranking + Full / Simulated target capacity
        ↓
CapacityTargetTier (capacity-adjusted RequestedTier in code)
        ↓
Promotion / degradation ordering + per-step transition budget
        ↓
AppliedTier + Deferred

Target capacity is not a hard per-step ceiling. When the transition budget is exhausted, identities awaiting degradation retain their old tier and are marked deferred. Applied Full or Simulated counts may temporarily exceed the target and converge over several steps. ForceFull can exceed ordinary Full capacity without consuming ordinary promotion slots, and the runtime counts it separately. The frozen demo has no absolute forced-count limit. Production code needs a MaxForcedFullSafetyCap with telemetry for forced and excess counts. Mission semantics may bypass ordinary quota, but not the system safety limit.

Capacity ranking and transition execution use different ordering. Capacity ranking protects a current tier that remains legal. Execution promotes by forced status, proximity, and AgentId, while degradation orders by greater distance and AgentId. Ties use the cross-process-stable lexical comparison FName::LexicalLess, not internal indices, hash-table traversal, or object creation order.

Moving the player changes distance requests, capacity targets, and budgeted transitions at the same time. HUD fields for tier transitions, deferred work, leased pool slots, and unassigned requests distinguish unresolved logic-tier work from a high-cost representation request that found no free Actor slot. Acceptance verifies changes by AgentId rather than treating a regional color shift as identity-level evidence.

The LOD resolver does not receive scene Actors as input. Its output aggregates applied Full, Simulated, and StubTier counts, promotions, degradations, deferrals, and forced Full. DistanceRequestedTier and CapacityTargetTier are explanatory names rather than three implemented member fields. A HUD that must expose distance request and capacity result separately needs additional diagnostic fields.

Capacity Stability and Current-Tier Preference

Distance-only quota assignment can make two nearby candidates exchange slots repeatedly at a boundary. The capacity ranking gives priority to a candidate whose request still matches its current tier. Spatial enter/exit hysteresis controls distance oscillation; current-tier preference controls quota oscillation. They address different sources of churn.

ForceFull is intended for a small number of mission-critical or near-interaction identities. It consumes no ordinary promotion count and may exceed regular Full capacity. Because the frozen implementation reports forced count but has no absolute limit, marking an entire crowd ForceFull would exceed the normal budget. Production code must constrain authored content and enforce a runtime safety cap whose overflow is reported as a capacity error.

Each step reports completed promotions, degradations, and deferrals. The HUD and tests can therefore distinguish “no tier change was required” from “a change was postponed by budget.”

Logic Tier and Representation Lease Are Independent Decisions

Full, Simulated, and StubTier govern update frequency and gameplay eligibility. Actor, ISM, Marker, and None are selected by presentation policy and resource budgets. Two independent enums are connected through handoff requests; there are no three permanent one-to-one mappings.

Logic tier	Zone presentation-budget result	If the Actor pool fails again
Full	Actor; if Actor budget is unavailable, ISM, then Marker	An Unassigned Actor request becomes None for this sync; the pool does not perform another fallback
Simulated	ISM; if instance capacity is unavailable, Marker	Does not compete for Actor-pool slots
StubTier	Debug Marker in P7; may be None in product	Does not compete for Actor-pool slots

Presentation is resolved twice. The Zone first writes RequestedRepresentation under visible-Actor and simplified-instance budgets. Full prefers Actor and may degrade to ISM or Marker at this stage. Simulated competes only for ISM; StubTier uses a debug Marker. The representation pool later produces AppliedRepresentation and allocation status.

The StubTier Marker retains a stable AgentId and exists only for capture and acceptance. It is unrelated to anonymous distant crowds in P1 and P6. A product build may disable the Marker without removing logical identity.

Full representation comes from a pre-created Actor pool. During sync, the runtime collects AgentIds that currently request Actors and compares them with existing leases. Identities that still require Actors preserve slots, obsolete leases release slots, and new identities acquire free slots. Actor position comes from the handoff request; presentation components may not overwrite SOA position.

An ISM identity has no per-person Actor, collision, or Tick. Each instance uses the logical identity’s current position. Presentation sync also counts duplicate AgentIds. If the same identity appears twice in one handoff, the system accepts only the first request, reports an error, and prevents two visible representations from coexisting.

At configuration, the pool pre-creates a fixed number of full Actor slots and initializes two instance components: one for simplified presentation and one for StubTier debug markers. Each sync clears the current ISM and Marker instances, then scans handoff requests. Invalid, not-ready, or duplicate requests are rejected or counted. Actor requests enter the desired-lease set; simplified and marker requests submit instance transforms directly.

The pool then synchronizes AgentId leases into four outcomes:

• Preserved: the identity leased a slot last sync and still needs an Actor;
• Released: the identity left the Actor representation and returns its slot;
• Assigned: a new Actor identity receives a free slot and its prototype and position are configured;
• Unassigned: the Zone requested an Actor but no pool slot exists; identity remains valid, has no Actor this sync, and the pool does not fall back to ISM or Marker.

For every slot, the pool locates its handoff request and configures prototype, debug presentation, and world position. A missing request or failed configuration hides the slot and disables collision. HUD output includes capacity, leased and free slots, simplified-instance count, StubTier logical and marker counts, the four sync outcomes, and duplicate-identity count.

A Full identity can receive ISM or Marker during Zone budget resolution, or it can request Actor and end as Unassigned + None when the pool is exhausted. These are separate results. Full grants high-frequency logic eligibility only. Gameplay that requires per-person collision, animation, or interaction must also require AppliedRepresentation == Actor; Full cannot stand in for Actor Ready.

The frozen demo retries unassigned requests on the next sync but has no consecutive-failure count, grace duration, or forced-exit policy. A persistent mismatch between Zone Actor-request capacity and pool capacity can leave Unassigned + None indefinitely. Production code should track ConsecutiveUnassignedSteps and UnassignedReason. After MaxUnassignedGraceSteps, it should re-enter Zone presentation policy or report a capacity configuration error. Actor-dependent interaction must remain not-ready throughout that interval.

Representation Handoff Carries a Snapshot

A handoff request contains AgentId, Zone, prototype, position, flow index, logic tier, lifecycle state, and desired representation. To avoid confusion with the source runtime’s entity-readiness states, this article calls the code field bReady RepresentationSnapshotReady. It means that the handoff fields are complete enough for presentation sync. It does not mean EntitySpawnCompleted, EntityAttached, or any GameplayReadyFlags. The representation pool does not acquire population ownership and cannot change active/dormant Zone membership.

Actor-pool sync reports preserved, released, assigned, and unassigned leases. An unassigned identity retains AgentId and logical position and can retry later. The system can therefore inspect logical Full count, Zone Actor requests, and actual leases as three separate facts.

ISM and Marker instances are rebuilt from handoff snapshots every sync and expose no persistent per-person component handle. Interaction must locate logical state by AgentId and acquire a suitable representation; it cannot infer persistent identity from an instance index. This is the rendering-side form of the same rule that forbids treating an active-array index as identity.

---

Spatial Slots and Save Restoration

Work Sites Are Currently Deterministic Spatial Slots

Project data defines each of three work sites by ID, occupation, Zone, position, slot direction, count, and spacing. The coordinator calculates demand, available occupancy, and waiting count. The presentation layer chooses a location directly through Hash(AgentId) % SlotCount.

Market staff line up at stalls, office staff gather near an office anchor, and maintenance staff occupy a utility area. The V, O, and M labels are demo diagnostics for occupation and activity; they are not authoritative population state.

The hash is repeatable, but the implementation has neither open addressing nor a unique occupancy table. Different identities can select the same slot. OccupiedJobSlotCount is min(Demand, SlotCount), a capacity statistic rather than proof of unique visible placement. P7 verifies mapping from schedule demand to deterministic anchors. Unique allocation, waiting queues, animation alignment, preemption, and failure recovery remain unimplemented.

Persistence Stores Regional Population, Not Transient Presentation

Demo SaveGame stores a schema version, current hour, and population-state records for each Zone. Actor leases, ISM indices, and Markers are excluded. During the same PIE session, QuickSaveCity separately caches the observer Transform, controller rotation, and camera mode on the player character. That state is not part of UCyberPopulationDemoSaveGame and is not cross-process persistence.

The reference runtime persists primarily around communities, entry spawners, and stub state. Loading also handles version branches, saved entity IDs, community mappings, and objects still held by other systems. P7 does not reproduce that complete format, but follows the same principle: save logical facts from which presentation can be regenerated, not rendering objects.

Schema 1 of UCyberPopulationDemoSaveGame contains only current hour and an array of Zone snapshots. The effective field sources are:

State	Current source and Load behavior
AgentId, prototype, Zone, active/dormant	Applied from the Zone snapshot first; Zone and activity may later be rewritten by reconciliation
CommunityId	Deserialized with the Zone record; does not mean the independent member table was restored
Occupation	Deserialized, then may be reassigned by community schedule configuration
Activity, JobSite	Saved scheduling results that immediate reconciliation may rewrite
JobSlot	Demo placement result derived from stable hashing; not a unique reservation fact
Route position, target index, fixed-step phase	Restored from the Zone record
PlayerDistance, LOD	Restored as snapshot data, then subject to observer updates
LastPortal, MigrationCount, community-member table	Not restored by Demo SaveGame
Actor slot, ISM index, Marker	Not saved; rebuilt after load

This format mixes persistent facts, recoverable simulation state, and derived caches. PlayerDistance and LOD are not long-lived world facts. A production format should recompute them or explicitly define a protocol that restores a scheduler snapshot and then validates it against the current observer.

Save iterates every Zone. Load validates the schema and then applies records Zone by Zone. If one Zone fails, the function returns without rolling back Zones already applied. ApplyPopulationScheduleHour then runs an immediate reconciliation: it may migrate, reactivate, create, make dormant, and rewrite occupation or activity rather than only setting the clock. Finally, presentation data and the representation pool are synchronized.

The load result has three distinct stages. SnapshotApplied means Zone records were deserialized and passed base validation. ScheduleReconciled means demand and population relationships were recomputed at the saved time. RepresentationRebuilt means representations were leased from the reconciled logical state. The final result is a new valid runtime state derived after snapshot application; it does not promise byte-for-byte equality for Zone, occupation, Activity, JobSite, JobSlot, and LOD fields.

The independent community-member table is outside this Quick Load path. It is neither restored from SaveGame nor rebuilt from Zone records, and the presentation runtime retains the member-table state that existed before loading. CommunityId in Zone records remains available to scheduling, but LastPortal, MigrationCount, and the independent member index do not roll back. P7 Quick Load is therefore not complete community-ownership restoration.

Save: time + ZoneId + population-state records

Load: schema validation
    → SnapshotApplied: apply population records Zone by Zone
    → ScheduleReconciled: immediately reconcile at saved time
    → RepresentationRebuilt: rebuild leases and instances

The current session-scoped Quick Load first calls LoadPopulationDemoState, including Zone application, schedule reconciliation, and presentation sync. It then restores player Transform, controller rotation, and camera mode. The recorded sequence saves at 12:00 from a near position, moves the observer far enough to drive identities from Full toward Simulated and StubTier, and then switches to an unsaved 06:00 state. Quick Load returns to 12:00, 72 active identities, and a 24/32/16 tier split. The snapshot contains three Zones and 72 pedestrian records; measured observer-position error after restoration is 0.0 cm.

The video validates the successful path for Zone logical snapshots and presentation reconstruction. Version migration, derived-state revalidation, the community-member table, and large partitioned saves remain outside the current scope.

Loading has no global transaction pause and no “restore time without dispatch” mode. The current order guarantees only that Zone records precede schedule reconciliation and representation rebuilding. A production loader still needs complete prevalidation, temporary Zone and community-index state, suspended dispatch while time and observer-dependent tiers are recomputed, and an atomic commit after validation.

Observer restoration has an ordering gap: population load restores snapshot PlayerDistance and LOD values and synchronizes the representation pool before QuickLoadCity restores player Transform. The video proves exact final position restoration within one PIE session and eventual three-tier convergence, but the load may briefly use snapshot distance or the old observer state. Post-load validation must recheck AgentId uniqueness, active/dormant ownership, Zone capacity, distance, and tiers. Actor-pool slots are rebuildable caches and do not participate in consistency. Observer data exists only in volatile player-character memory and cannot be recovered from Population Demo SaveGame after restarting the process.

---

Demo Acceptance and Capability Boundaries

Runtime, Scene, and Scale Are Tested Separately

P7 acceptance has three layers—runtime, PIE scene, and scale. Visible characters are one result within that evidence set, not the completion criterion by themselves.

The first is the pure runtime contract: consistent SOA columns, a valid free list, functioning fixed-step tiers, one matching schedule at each of 24 hourly midpoints, convergent Zone-local lifecycle queues, valid migration ownership, a consistent successful save/load path, and no accidental dependency on experimental plugins in the population mainline.

The second is the PIE scene contract. The frozen map requests 72 pedestrian identities. Automation confirms that all 72 bind to runtime state with no duplicate or missing IDs. Full, Simulated, and StubTier coexist and have debug presentation; occupation and work-site labels are present; player movement changes tiers per identity rather than recoloring a whole group uniformly. One saved acceptance report also records three communities and 48 migrated identities.

The third is the scale contract. Multi-region automation covers 1,024 pedestrians and 128 vehicles and runs a 2,048/256 pressure configuration. Acceptance evaluates logical counts, unique identity, community ownership, work limits, and restoration results. Runtime duration is diagnostic only and does not establish a cross-machine performance benchmark.

Pure runtime tests construct failures that screenshots cannot expose. The SOA lifecycle test removes a middle record, verifies that the swapped identity’s lookup index changes correctly, creates a replacement to test free-list reuse, and then resumes simulation. Schedule tests cover normal and midnight-wrapped intervals. They prove unique midpoint coverage for the frozen integer-hour fixture and reject the gaps, overlaps, and invalid densities represented in test samples. Strict coverage for arbitrary fractional endpoints still requires sorted-endpoint continuity validation. LOD tests place candidates at equal distance and use AgentId tie-breaking to verify repeatability. Dependency-isolation tests scan the population mainline to prevent later code from silently reintroducing Mass, MassTraffic, or ZoneGraph assumptions.

PIE tests verify level wiring beyond class implementation. They require the GameMode, population presentation Actor, Zones, roads, crossings, and other authoritative objects; all 72 requested identities must have runtime bindings; all three logic tiers and the representation pool must be live. Occupation labels, community migration, route progress, and player-distance tiers are read from scene state, not inferred only from C++ return values.

Scale tests use aggregate state and deterministic summaries, so validating 2,048 logical pedestrians does not require the same number of Actors. This isolates identity and scheduling correctness at larger scale. It does not replace rendering, animation, navigation, or target-platform frame-rate testing; its scope is population ownership and bounded per-step work.

The P7 frozen baseline verifies this article, while the P7–P12 closure baseline confirms correspondence across the logic-demo series. Specific commits, map blobs, test reports, and warning counts remain in the private evidence index. The public article retains only results a reader can reproduce in the demo.

After the freeze, the shared project integrated pedestrian movement, intersection reservation, and cross-system work. Some LargeBlock presentation code changed without resaving the map. Those changes belong to later articles or integrated acceptance and do not expand P7 retroactively. P8–P12 use independent acceptance maps so that their captures and claims remain tied to explicit versions.

A Complete Demo Walkthrough

Open LargeBlock_Demo and start PIE. The HUD shows 72 runtime identities and counts for Full, Simulated, and StubTier. Cyan objects come from the full Actor pool, amber objects are simplified instances, and short magenta markers identify active population in the lowest-frequency tier. Counts change with player position; one capture is not a fixed configuration.

As the player moves along the street, nearby identities enter higher tiers individually and distant identities leave them progressively. Acceptance checks four facts: total logical identity remains 72, the pool has no duplicate lease, per-step budgets limit tier transitions, and the AgentId set is unchanged. Color changes do not constitute success if identity count or duplicate diagnostics fail.

F1 through F5 expose morning, commute, work, leisure, and return-home states. V, O, and M identify the three occupations, while label color and HUD activity show the current schedule. During work hours, market, office, and maintenance communities migrate toward their target Zones. Returning to morning moves some records to dormant or back to the residential Zone.

After F6, growth and reclaim allowances are one per Zone. HUD targets change first; Zone-local reactivation, creation, and dormancy converge progressively. Cross-Zone migration can still complete in a batch during reconciliation and is not part of the F6 bounded-work evidence. F6 also does not test production spawn tokens, resource loading, or an Attach Ready chain.

Run Quick Save, move the observer, change time, and then run Quick Load. This verifies Zone snapshot application, valid AgentIds and base records, schedule reconciliation at the restored time, and representation rebuild. Actor slot IDs are not persisted. The video additionally verifies player-position restoration to 0.0 cm within the same PIE session. That Transform is volatile state in the player-character wrapper, not Population Demo SaveGame data. The sequence does not prove field-by-field preservation of every Zone, occupation, work site, and tier before the final image, complete community-member restoration, or atomic visibility during load.

Acceptance Warnings and Test Scope

The saved P7 PIE report succeeds with zero errors but contains one render-thread console-variable warning, so the correct claim is not “all runtime logs are warning-free.” The P7 acceptance document records zero errors and warnings for build, Smoke, and ValidationAll at the frozen baseline. The later P7–P12 integrated ValidationAll report contains four known warnings. Results from different dates and test scopes must remain separate.

Different suites own different responsibilities: pure runtime tests validate data contracts, PIE validates level connections, and rendering warnings belong to the scene runtime environment. Collapsing them into “everything passed” would hide both scope and diagnostics.

What the Demo Establishes

P7 verifies the following runtime chain in UE5:

• logical population exists independently of per-person Actors;
• AgentId remains stable across schedules, tiers, presentation, and regional migration;
• dormant reactivation, new-record creation, and dormancy converge through bounded Zone lifecycle batches; cross-Zone migration has ownership handoff and rollback but remains unbounded per step;
• Full, Simulated, and StubTier use different update frequencies under target capacities and transition budgets;
• Actor pools, ISM, Markers, or no drawing can consume the same logical-population snapshot;
• save restoration does not depend on serializing transient presentation objects;
• independent maps, HUD diagnostics, automation, and Git baselines can reproduce those results.

It does not establish production character meshes, animation, local avoidance, crossing quality, distant crowds, or final audiovisual presentation. P10 covers the pedestrian-movement prototype, P13 develops the presentation design for pedestrian scheduling, and P19 integrates that design with UE5 L2 presentation assets.

These boundaries separate identity, scheduling, and budget defects from animation, material, and camera defects. Placeholder geometry is not evidence of final presentation quality; it verifies that the population runtime does not depend on finished assets.

---

Conclusion: Delivering the Population Prototype as Runtime Contracts

P7 delivers a set of runtime contracts. AgentId maintains stable identity. The SOA owns movement state. Zones own regional records. The Schedule Coordinator submits population targets. Zone lifecycle batches limit local growth and reclaim. The LOD manager controls simulation cost. The representation pool leases transient resources. Demo SaveGame stores a mixed snapshot rather than a production persistence model.

These contracts allow character assets, animation systems, and batch-compute carriers to change independently. If identity and presentation remain bound to one Actor, every presentation upgrade continues to modify identity and lifecycle code.

P8 applies the same acceptance method to vehicle identity, garage requests, fixed-step scheduling, and autonomous-driving policy in a UE5 logic demo.

---

AI Collaboration Retrospective

• AI contribution: organized project task records; searched the population SOA, Zone lifecycle, schedules, community migration, LOD, representation pool, persistence, and automated tests; and compared the earlier implementation draft against current code.
• Major corrections: separated Entity Stub from StubTier, capacity target from applied tier, and snapshot readiness from gameplay readiness; verified Stride × FixedDelta, midpoint-only schedule validation, unbounded migration, no second fallback after Actor Unassigned, and the absence of the community-member table from Quick Save.
• Human decisions: kept Entity Stub, UE StubTier, debug Markers, and anonymous distant dots distinct; separated active indices, stable slots, and AgentId; and limited work-site, SaveGame, and scale claims to the prototype’s acceptance scope.
• Verification: every public claim maps to runtime code, the frozen demo, acceptance documents, automated reports, the P7 version tag, or the 8230d49c integrated baseline. Conversation-level completion statements were not used as code evidence.
• Remaining risks: equal-time progress through multi-turn routes, strict schedule-interval validation, bounded migration, unique work slots, atomic SOA batches, and transactional community persistence remain unimplemented. Diagnostic runtime measurements are not substitutes for target-platform profiling.