Phase 5 step 1

docs/PHASE_5_LIVE_STATE_LAYERING_DESIGN.md

@@ -7,8 +7,8 @@ Phase 1 named the subsystems. Phase 2 added the typed event substrate. Phase 3 m
 ## Status
 
 - Phase 5 design package: proposed.
-- Phase 5 implementation: not started.
-- Current alignment: Phase 3 introduced the first pure composition boundary and transient OSC overlay owner, but committed runtime values are still physically stored through `RuntimeStore`/`LayerStackStore`, and transient OSC overlay state is applied through render-facing helpers rather than through a first-class layered state model.
+- Phase 5 implementation: Step 1 started.
+- Current alignment: Phase 3 introduced the first pure composition boundary and transient OSC overlay owner, and Phase 5 now has a small `RuntimeStateLayerModel` inventory that names the current state categories. Committed runtime values are still physically stored through `RuntimeStore`/`LayerStackStore`, and transient OSC overlay state is still applied through render-facing helpers rather than through the final layered composition contract.
 
 Current live-state footholds:
 
@@ -18,6 +18,7 @@ Current live-state footholds:
 - `RuntimeLiveState` owns transient OSC overlay bookkeeping, smoothing, generation tracking, and commit-settlement policy.
 - `RenderStateComposer` combines base render states with live overlay state and returns final per-frame layer states plus settled commit requests.
 - `RuntimeServiceLiveBridge` drains OSC ingress/completion queues and applies them to render live state during frame preparation.
+- `RuntimeStateLayerModel` names the Phase 5 state categories and classifies current fields as base persisted, committed live, transient automation, render-local, or health/config state.
 
 ## Why Phase 5 Exists
 
@@ -239,9 +240,9 @@ Document and/or encode where each current state category lives:
 
 Initial target:
 
-- identify which fields are durable, committed-live, transient automation, render-local, or health/config
-- update subsystem docs where the current ownership is misleading
-- add small tests for classification if a pure helper exists
+- [x] identify which fields are durable, committed-live, transient automation, render-local, or health/config
+- [x] update subsystem docs where the current ownership is misleading
+- [x] add small tests for classification if a pure helper exists
 
 ### Step 2. Name The Layered Composition Input
 

docs/subsystems/RenderEngine.md

@@ -109,6 +109,8 @@ Examples:
 
 This state should remain render-local even when it influences visible output.
 
+Phase 5's `RuntimeStateLayerModel` explicitly keeps temporal history, feedback state, accepted input frames, staged output frames, preview staging, and screenshot/readback staging in the render-local category. These are deliberately outside the persisted/committed/transient-automation parameter composition rule.
+
 ### 5. Shader Build Application
 
 Compilation itself may eventually move into a separate build service, but once shader build outputs exist, `RenderEngine` owns:

docs/subsystems/RuntimeCoordinator.md

@@ -80,6 +80,8 @@ The coordinator decides which state category a mutation affects:
 
 The design rule is that classification belongs here, not in the ingress layer and not in render code.
 
+Phase 5 has started codifying the shared vocabulary for this classification in `RuntimeStateLayerModel`. The current model records committed session parameter values, layer bypass state, and runtime compile/reload flags as committed-live/session coordination state, even though some of those values are still physically backed by `RuntimeStore` during migration.
+
 ### 4. Snapshot publication requests
 
 When a mutation changes render-facing state, the coordinator asks `RuntimeSnapshotProvider` to publish a new snapshot or mark one dirty for publication.

docs/subsystems/RuntimeStore.md

@@ -95,6 +95,8 @@ Those are coordinator concerns, not store concerns.
 
 `RuntimeStore` should own the following state categories.
 
+Phase 5 names this boundary in code through `RuntimeStateLayerModel`: persisted layer stack data, saved parameter values, and stack presets are classified as base persisted state. Operator/session values may still be backed by the store during migration, but their mutation policy is committed-live policy owned by the coordinator, not durable-store policy by default.
+
 ### Runtime Configuration
 
 Examples: