Phase 5 step 5

docs/subsystems/RenderEngine.md

@@ -113,6 +113,8 @@ Phase 5's `RuntimeStateLayerModel` explicitly keeps temporal history, feedback s
 
 `RuntimeLiveState` now owns transient automation invalidation for render-facing compatibility. It can clear overlays for a target layer/control key and prunes overlays that no longer resolve to the current layer and parameter definitions before applying them to a frame. This keeps shader reload, preset load, and layer removal behavior local to the live-state/composition boundary instead of scattering it through GL drawing code.
 
+Render snapshots now flow through a named `CommittedLiveStateReadModel`, so render-facing committed state is distinct from durable storage even while both are physically backed by the same store during migration.
+
 ### 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

@@ -274,6 +274,8 @@ For OSC specifically, the coordinator should eventually decide:
 
 Phase 5 sets the default settled OSC policy to session-only. `CommitOscParameterByControlKey(...)` updates committed session state through the store with persistence disabled, publishes ordinary mutation/state-change observations, and does not request a persistence write unless a future explicit policy opts into durable OSC commits.
 
+The committed-live concept now has a named read model, `CommittedLiveStateReadModel`. The coordinator remains the owner of whether a mutation should be durable or session-only, while `RuntimeStore` temporarily backs the read model until a physical `CommittedLiveState` collaborator is worth extracting.
+
 ### Health and timing state
 
 The coordinator may emit events like:

docs/subsystems/RuntimeStore.md

@@ -97,6 +97,8 @@ Those are coordinator concerns, not store concerns.
 
 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.
 
+Phase 5 also adds `CommittedLiveStateReadModel` as the named read boundary for current session/operator state. During the conservative migration, `RuntimeStore` still backs that model physically, but snapshot publication consumes the committed-live read model rather than treating render-facing state as raw durable storage.
+
 ### Runtime Configuration
 
 Examples: