Phase 5 step 1

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: