Finished phase 1

docs/subsystems/ControlServices.md

@@ -457,8 +457,8 @@ Likely keep under `ControlServices`:
 
 Should move out later:
 
-- direct `RuntimeHost` polling dependency
-- deferred OSC commit behavior as currently implemented through direct host mutation
+- legacy direct runtime polling dependency
+- deferred OSC commit behavior that has since moved behind coordinator-facing outcomes
 - any remaining direct state-broadcast decisions tied to runtime internals
 
 ### Current `ControlServer`
@@ -513,13 +513,13 @@ The goal is for transports to emit actions, even if temporary adapters still cal
 
 That should move toward a composition root or subsystem host arrangement where render is no longer the owner of control ingress.
 
-### Step 4. Remove Direct `RuntimeHost` Dependency
+### Step 4. Remove Direct Runtime Mutation Dependency
 
-Current polling and deferred OSC commit work directly against `RuntimeHost`:
+Previous polling and deferred OSC commit work directly against runtime storage:
 
 - [RuntimeServices.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/control/RuntimeServices.cpp:194)
 
-That should be replaced with coordinator-facing actions and later event-driven flows.
+That has been routed through coordinator-facing actions; later phases should replace the remaining polling shape with event-driven flows.
 
 ### Step 5. Split Out Observation Delivery
 
@@ -535,7 +535,7 @@ Mitigation:
 
 - keep the boundary strict
 - route mutations through coordinator interfaces
-- treat direct host calls as temporary compatibility only
+- treat any direct runtime mutation calls as migration-only compatibility
 
 ### Risk 2. Service Queues Becoming Hidden State Authority
 

docs/subsystems/HealthTelemetry.md

@@ -4,7 +4,7 @@ This document expands the `HealthTelemetry` subsystem introduced in [PHASE_1_SUB
 
 `HealthTelemetry` is the subsystem that owns operational visibility for the app. Its purpose is to gather health state, warnings, counters, logs, and timing observations from the other subsystems and publish them in a structured way without becoming a second control plane.
 
-Today, those responsibilities are fragmented across `RuntimeHost` status setters, ad hoc `OutputDebugStringA` calls, callback-local warnings, and UI-facing runtime-state payloads. The result is that the app can often detect problems, but it does not yet have one clear place that answers:
+Before the Phase 1 runtime split, those responsibilities were fragmented across `RuntimeHost` status setters, ad hoc `OutputDebugStringA` calls, callback-local warnings, and UI-facing runtime-state payloads. The result was that the app could often detect problems, but did not yet have one clear place that answered:
 
 - what is healthy right now
 - what is degraded right now
@@ -16,14 +16,14 @@ Today, those responsibilities are fragmented across `RuntimeHost` status setters
 
 ## Why This Subsystem Exists
 
-The current code already contains meaningful health and timing signals, but they are spread through unrelated ownership domains:
+The codebase already contains meaningful health and timing signals, but some are still spread through unrelated ownership domains:
 
-- `RuntimeHost` stores signal and timing status:
+- previous `RuntimeHost` status fields stored signal and timing status:
   - `RuntimeHost.h`
   - `RuntimeHost.cpp`
   - `RuntimeHost.cpp`
   - `RuntimeHost.cpp`
-- render and bridge code report timing by writing back into `RuntimeHost`:
+- render and bridge code historically reported timing by writing back into `RuntimeHost`:
   - [OpenGLRenderPipeline.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/pipeline/OpenGLRenderPipeline.cpp:50)
   - [OpenGLVideoIOBridge.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/pipeline/OpenGLVideoIOBridge.cpp:49)
 - backend warning paths still log directly:
@@ -42,7 +42,7 @@ This creates several recurring problems:
 - logging is mostly text-first instead of structured-first
 - recovery behavior is hard to audit because the app does not retain a coherent health snapshot
 
-`HealthTelemetry` exists so later phases can move timing and health concerns out of `RuntimeHost`, out of callback-local logging, and into one subsystem whose only job is observation and reporting.
+`HealthTelemetry` exists so timing and health concerns have one subsystem whose only job is observation and reporting, instead of drifting back into runtime storage, callback-local logging, or UI payload assembly.
 
 ## Design Goals
 
@@ -373,9 +373,9 @@ Expected observations:
 
 The current codebase already contains several telemetry responsibilities that should migrate here.
 
-### `RuntimeHost` Status Setters
+### Previous `RuntimeHost` Status Setters
 
-These are the clearest existing candidates:
+These were the clearest initial migration candidates:
 
 - `SetSignalStatus(...)`
 - `TrySetSignalStatus(...)`
@@ -391,7 +391,7 @@ See:
 - `RuntimeHost.cpp`
 - `RuntimeHost.cpp`
 
-In the target architecture, this kind of state should no longer sit on the same object that owns persistent layer truth.
+In the target architecture, this kind of state should not sit on the same object that owns persistent layer truth.
 
 ### Render Timing Production
 
@@ -403,7 +403,7 @@ That timing sample should conceptually become:
 
 - `RenderEngine -> HealthTelemetry::RecordTimingSample(...)`
 
-not:
+not the old pattern:
 
 - `RenderEngine -> RuntimeHost::TrySetPerformanceStats(...)`
 
@@ -468,7 +468,7 @@ So the design should assume:
 - bounded memory
 - no long-held global mutex that callbacks and render both depend on
 
-Phase 1 does not require lock-free implementation, but it does require the architecture to avoid recreating the `RuntimeHost` problem where health writes share the same lock as durable state and render-facing concerns.
+Phase 1 does not require lock-free implementation, but it does require the architecture to avoid recreating the old problem where health writes share the same lock as durable state and render-facing concerns.
 
 Practical expectations:
 
@@ -494,13 +494,13 @@ Initial responsibilities:
 
 The first implementation can still be backed by simple in-memory structures.
 
-### Step 2: Move New Observations Off `RuntimeHost`
+### Step 2: Keep New Observations Off Runtime Storage
 
-Before removing old setters, route new health-style work into `HealthTelemetry` instead of adding more `RuntimeHost` status fields.
+Route new health-style work into `HealthTelemetry` instead of adding more status fields to runtime storage.
 
 This prevents the old status surface from growing during migration.
 
-### Step 3: Replace `RuntimeHost` Status Setters With Telemetry Producers
+### Step 3: Replace Legacy Status Setters With Telemetry Producers
 
 Refactor:
 
@@ -641,4 +641,4 @@ It should not:
 - coordinate recovery actions
 - become a replacement for the render or backend policy layers
 
-If this boundary holds, later phases can remove timing and warning state from `RuntimeHost` and move toward a much more diagnosable live system.
+If this boundary holds, later phases can keep moving toward a much more diagnosable live system without putting timing and warning state back into runtime storage.

docs/subsystems/README.md

@@ -18,8 +18,8 @@ Parent documents:
 Status note:
 
 - The Phase 1 design package is complete.
-- The codebase has compatibility seams for the named subsystems.
-- The target subsystem extraction is still in progress, so these notes describe the architecture the implementation is moving toward, not a claim that every boundary is already pure.
+- The runtime implementation foothold is complete: the named runtime subsystems exist in code, `RuntimeHost` is retired from the compiled runtime path, and subsystem tests cover the new seams.
+- The whole app is not fully extracted yet, so these notes still describe the architecture later phases should continue toward.
 
 ## Recommended Reading Order
 
@@ -67,4 +67,4 @@ Phase 1 should leave the project with:
 
 Phase 1 does not need to settle every later implementation detail. The subsystem notes intentionally leave some questions open where later phases need room to choose concrete mechanics.
 
-As of the current codebase, those design questions are settled well enough for later work to build against them. Remaining implementation work should be tracked as extraction progress under later phases, especially eventing, the `RuntimeHost` split, render-thread ownership, persistence, backend lifecycle, and telemetry.
+As of the current codebase, those design questions are settled well enough for later work to build against them. Remaining implementation work should be tracked under later phases, especially eventing, render-thread ownership, persistence, backend lifecycle, live-state layering, and telemetry.

docs/subsystems/RenderEngine.md

@@ -2,7 +2,7 @@
 
 This document expands the `RenderEngine` portion of [PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md). It defines the target ownership, boundaries, and migration shape for the rendering subsystem so later phases can move GL work out of today's mixed orchestration paths without inventing new boundaries on the fly.
 
-The intent here is not to force a one-step rewrite. It is to make the target render boundary explicit enough that later work on events, `RuntimeHost` splitting, and backend decoupling all land in the same place.
+The intent here is not to force a one-step rewrite. It is to make the target render boundary explicit enough that later work on events, live-state layering, sole-owner GL threading, and backend decoupling all land in the same place.
 
 ## Purpose
 
@@ -400,11 +400,11 @@ As new features are added, keep:
 - render-local overlays
 - preview state
 
-inside render-owned code paths instead of putting them back into `RuntimeHost` or service layers.
+inside render-owned code paths instead of putting them back into runtime storage or service layers.
 
 ### Step 3. Isolate Snapshot Consumption
 
-Introduce snapshot-facing APIs so render no longer depends on broad `RuntimeHost` state access for frame production.
+Introduce snapshot-facing APIs so render no longer depends on broad runtime-state access for frame production.
 
 ### Step 4. Move Uploads Onto Render Ownership
 

docs/subsystems/RuntimeCoordinator.md

@@ -6,9 +6,9 @@ This document defines the target design for the `RuntimeCoordinator` subsystem i
 
 ## Why This Subsystem Exists
 
-Today the app's mutation path is split across several places:
+Before the Phase 1 runtime split, the app's mutation path was split across several places:
 
-- `RuntimeHost` performs validation, mutation, persistence, render-state invalidation, and some status updates:
+- `RuntimeHost` performed validation, mutation, persistence, render-state invalidation, and some status updates:
   - `RuntimeHost.h`
   - `RuntimeHost.cpp`
 - `OpenGLComposite` currently acts like an orchestration shell and a mutation coordinator at the same time:
@@ -58,7 +58,7 @@ Examples:
 - whether a trigger should update committed state, transient state, or both
 - whether a structural change should preserve compatible transient state such as feedback buffers
 
-This is the main policy surface that is currently spread between `RuntimeHost` methods such as:
+This is the policy surface that used to be spread between `RuntimeHost` methods such as:
 
 - `AddLayer(...)`
 - `SetLayerShader(...)`
@@ -246,7 +246,7 @@ Typical interaction:
 
 This is the coordinator's primary logical domain.
 
-Even if the implementation initially stores committed live state inside `RuntimeHost` or later inside `RuntimeStore`, the coordinator should be considered the policy owner of:
+Even while committed live state is physically stored inside `RuntimeStore`, the coordinator should be considered the policy owner of:
 
 - current layer stack composition
 - current selected shaders
@@ -316,7 +316,7 @@ The coordinator likely needs collaborators conceptually equivalent to:
 - `IRuntimeStore`
 - `IRuntimeSnapshotProvider`
 - `IHealthTelemetry`
-- later, a compatibility shim for still-existing `RuntimeHost` behavior during migration
+- compatibility adapters only where older call shapes still need to be supported during migration
 
 ### Mutation result shape
 
@@ -357,7 +357,7 @@ Methods like:
 
 currently do this pattern:
 
-1. call `RuntimeHost` mutation
+1. call a host/store mutation directly
 2. decide whether to call `ReloadShader(...)`
 3. call `broadcastRuntimeState()`
 
@@ -365,9 +365,9 @@ See [OpenGLCompositeRuntimeControls.cpp](/c:/Users/Aiden/Documents/GitHub/video-
 
 That "call host, then decide reload/broadcast policy" logic is a direct candidate for migration into `RuntimeCoordinator`.
 
-### `RuntimeHost`
+### Previous `RuntimeHost`
 
-`RuntimeHost` currently combines:
+`RuntimeHost` previously combined:
 
 - mutation validation
 - state mutation
@@ -375,7 +375,7 @@ That "call host, then decide reload/broadcast policy" logic is a direct candidat
 - persistence writes
 - render-state dirty marking
 
-Examples in `RuntimeHost.cpp`:
+Examples from the old `RuntimeHost.cpp`:
 
 - `AddLayer(...)`
 - `SetLayerShader(...)`
@@ -452,14 +452,14 @@ The coordinator should be introduced incrementally.
 
 Introduce typed mutation request/result objects without changing most internals yet.
 
-### Step 2. Wrap current `RuntimeHost` mutations behind coordinator entrypoints
+### Step 2. Wrap direct runtime mutations behind coordinator entrypoints
 
-The first implementation can still delegate heavily into `RuntimeHost`, but the call sites should stop deciding policy on their own.
+The first implementation could still delegate heavily into existing runtime mutation paths, but the call sites should stop deciding policy on their own.
 
 For example, instead of:
 
 1. `OpenGLComposite::AddLayer()`
-2. `RuntimeHost::AddLayer()`
+2. direct layer-add mutation
 3. `ReloadShader(true)`
 4. `broadcastRuntimeState()`
 
@@ -470,7 +470,7 @@ the flow becomes:
 3. coordinator returns a result describing snapshot, reset, and persistence needs
 4. composition root dispatches those downstream effects
 
-### Step 3. Move validation and classification out of `RuntimeHost`
+### Step 3. Move validation and classification out of direct mutation helpers
 
 Once coordinator entrypoints are stable, pull up:
 
@@ -480,9 +480,9 @@ Once coordinator entrypoints are stable, pull up:
 
 while leaving raw store operations in place.
 
-### Step 4. Narrow `RuntimeHost` into store and snapshot collaborators
+### Step 4. Split storage and snapshot collaborators
 
-Only after the coordinator is clearly owning policy should `RuntimeHost` be split into real target subsystems.
+Only after the coordinator is clearly owning policy should storage and snapshot responsibilities be split into real target subsystems.
 
 ## Key Risks
 
@@ -498,7 +498,7 @@ Mitigation:
 
 ### Risk 2. Call sites bypass coordinator during migration
 
-If new code continues calling `RuntimeHost` directly for convenience, the architecture will fork into two policy systems.
+If new code bypasses `RuntimeCoordinator` for convenience, the architecture will fork into two policy systems.
 
 Mitigation:
 

docs/subsystems/RuntimeSnapshotProvider.md

@@ -8,13 +8,13 @@ The goal of `RuntimeSnapshotProvider` is to separate render-facing state publica
 
 `RuntimeSnapshotProvider` is the boundary between runtime-owned state and render-consumable state.
 
-It exists to solve three current problems:
+It exists to solve three problems that Phase 1 pulled apart:
 
-- render state is still built directly out of `RuntimeHost` under a shared mutex
-- render reads and refreshes partially mutable cached layer state in more than one place
+- render state was built directly out of `RuntimeHost` under a shared mutex
+- render read and refreshed partially mutable cached layer state in more than one place
 - state publication, state versioning, and dynamic frame-field refresh need explicit ownership
 
-Today the closest current behavior lives in:
+Before the Phase 1 runtime split, the closest behavior lived in:
 
 - `RuntimeHost::GetLayerRenderStates(...)`
 - `RuntimeHost::TryGetLayerRenderStates(...)`
@@ -340,7 +340,7 @@ This is especially important while migrating away from the current lock/fallback
 
 ## Current Code Mapping
 
-The current code suggests the following migration map.
+The current code follows this migration map.
 
 ### Move into `RenderSnapshotBuilder`
 
@@ -370,12 +370,12 @@ Current methods that should become compatibility shims and later disappear:
 
 The previous `OpenGLComposite` cache path:
 
-- reads versions from `RuntimeHost`/store-owned counters
+- read versions from `RuntimeHost`/store-owned counters
 - conditionally calls `TryRefreshCachedLayerStates(...)`
 - conditionally rebuilds full layer state
 - then reapplies render-local OSC overlay state
 
-During migration, that should become:
+The migrated runtime path is:
 
 1. get latest published snapshot from provider
 2. compare snapshot versions produced by `RenderSnapshotBuilder`
@@ -390,12 +390,12 @@ That is a much cleaner split than the current mixed lock/cache/fallback flow in
 ### Step 1: Introduce provider types without changing behavior
 
 - define `RuntimeRenderSnapshot`, `RuntimeRenderLayerSnapshot`, and `RuntimeRenderFrameContext`
-- implement provider methods as thin wrappers over current `RuntimeHost` logic
-- keep `RuntimeHost` as the backing source temporarily
+- initially implement provider methods as thin wrappers over existing behavior
+- completed: replace the temporary `RuntimeHost` backing source with `RenderSnapshotBuilder`
 
 ### Step 2: Route render reads through the provider
 
-- replace direct `RuntimeHost` layer-state reads with provider snapshot reads
+- replace direct host/store layer-state reads with provider snapshot reads
 - preserve current version behavior first, even if internally bridged to existing counters
 
 ### Step 3: Separate structural publication from frame context
@@ -479,7 +479,7 @@ Recommended tests:
 
 `RuntimeSnapshotProvider` can be considered architecturally in place once:
 
-- render no longer reads `RuntimeStore` or `RuntimeHost` render state directly
+- render no longer reads `RuntimeStore` or legacy host render state directly
 - render consumes published snapshot handles rather than rebuilding layer vectors from host state
 - dynamic frame fields are supplied separately from structural snapshot publication
 - snapshot version domains are explicit and observable
@@ -497,4 +497,4 @@ Its contract is:
 - keep frame-local timing separate
 - give render a cheap, lock-light read path
 
-If that boundary is held, later phases can split `RuntimeHost`, isolate render timing, and decouple playout without inventing a second render-state authority.
+If that boundary is held, later phases can isolate render timing and decouple playout without inventing a second render-state authority.

docs/subsystems/RuntimeStore.md

@@ -2,7 +2,7 @@
 
 This document expands the `RuntimeStore` portion of [PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md) into a subsystem-specific design note.
 
-The purpose of `RuntimeStore` is to give the Phase 1 target architecture one clear home for durable runtime data. In the current codebase, that responsibility is spread through `RuntimeHost`, where persistence, mutation entrypoints, render-state building, shader metadata access, and status reporting all share the same object and lock domain. `RuntimeStore` is the design boundary that separates "what the app knows and saves" from "how the app decides to mutate it" and "how rendering consumes it."
+The purpose of `RuntimeStore` is to give the Phase 1 target architecture one clear home for durable runtime data. Before the Phase 1 runtime split, that responsibility was spread through `RuntimeHost`, where persistence, mutation entrypoints, render-state building, shader metadata access, and status reporting all shared the same object and lock domain. `RuntimeStore` is the design boundary that separates "what the app knows and saves" from "how the app decides to mutate it" and "how rendering consumes it."
 
 ## Role In The Phase 1 Architecture
 
@@ -259,7 +259,7 @@ This implies:
 - that mutex should protect durable models only
 - render-facing consumers should eventually read via `RuntimeSnapshotProvider`, not by reaching into the store
 
-One of the main goals here is reducing the current situation where `RuntimeHost` lock scope effectively mixes:
+One of the main goals here is avoiding the old situation where runtime lock scope effectively mixed:
 
 - persistent state
 - status reporting
@@ -296,9 +296,9 @@ The store may emit errors or return result objects, but it should not coordinate
 
 ## Current Code Mapping
 
-Today, `RuntimeHost` contains most of the responsibilities that should move into `RuntimeStore`.
+Before the Phase 1 runtime split, `RuntimeHost` contained many responsibilities that needed to move into `RuntimeStore` or adjacent runtime collaborators.
 
-Key current code paths:
+Previous code paths:
 
 - config load:
   - `RuntimeHost.cpp`
@@ -318,7 +318,7 @@ Key current code paths:
   - `RuntimeHost.cpp`
   - `RuntimeHost.cpp`
 
-Durable-state mutation entrypoints that currently live on `RuntimeHost` but conceptually split between coordinator and store:
+Durable-state mutation entrypoints that previously lived on `RuntimeHost` but conceptually split between coordinator and store:
 
 - layer stack edits:
   - `AddLayer`
@@ -336,7 +336,7 @@ The target split should be:
 - validation/policy/orchestration -> `RuntimeCoordinator`
 - durable state write application -> `RuntimeStore`
 
-Methods that should not move into `RuntimeStore` even though they currently live on `RuntimeHost`:
+Methods that were intentionally not moved into `RuntimeStore` because they belong under other runtime subsystems:
 
 - render-state building and caching:
   - `GetLayerRenderStates`
@@ -361,7 +361,7 @@ Those belong under other target subsystems.
 - `RuntimeConfigStore`
   - runtime host config load and resolved paths
 
-The current codebase has begun this split: `RuntimeConfigStore` owns config parsing, path resolution, configured ports/formats, runtime roots, and shader compiler paths, while `RuntimeStore` keeps compatibility delegates for existing callers.
+The current codebase has completed this part of the split: `RuntimeConfigStore` owns config parsing, path resolution, configured ports/formats, runtime roots, and shader compiler paths, while `RuntimeStore` exposes compatibility-shaped delegates for existing callers.
 - `LayerStackStore`
   - durable layer stack and parameter values
   - layer CRUD/reorder and shader selection
@@ -378,13 +378,13 @@ The current codebase has begun this split: `RuntimeConfigStore` owns config pars
 - `PersistenceWriter` helper
   - synchronous at first, async/debounced later
 
-The current codebase has begun the layer split: `LayerStackStore` owns durable layer state, layer CRUD/reorder, parameter persistence, and stack preset value serialization/load. `RuntimeStore` still owns locking, file IO, and compatibility delegates for existing callers.
+The current codebase has completed the layer split: `LayerStackStore` owns durable layer state, layer CRUD/reorder, parameter persistence, and stack preset value serialization/load. `RuntimeStore` keeps file IO and facade methods for existing callers.
 
-The current codebase has begun the render snapshot split: `RenderSnapshotBuilder` owns render-state assembly, cached parameter refresh, dynamic frame-field refresh, and render snapshot versions. `RuntimeSnapshotProvider` depends on this builder rather than on `RuntimeStore` friendship.
+The current codebase has completed the render snapshot split: `RenderSnapshotBuilder` owns render-state assembly, cached parameter refresh, dynamic frame-field refresh, and render snapshot versions. `RuntimeSnapshotProvider` depends on this builder rather than on `RuntimeStore` friendship.
 
-The current codebase has also begun the presentation split: `RuntimeStatePresenter` owns top-level runtime-state JSON assembly, while `RuntimeStateJson` owns the layer-stack and parameter presentation shape used by runtime state clients.
+The current codebase has also completed the presentation split: `RuntimeStatePresenter` owns top-level runtime-state JSON assembly, while `RuntimeStateJson` owns the layer-stack and parameter presentation shape used by runtime state clients.
 
-The current codebase has also begun the package split: `ShaderPackageCatalog` owns package scanning and registry comparison, while `RuntimeStore` uses it to keep layer state valid and to build compatibility read models.
+The current codebase has also completed the package split: `ShaderPackageCatalog` owns package scanning and registry comparison, while `RuntimeStore` uses it to keep layer state valid and to build compatibility read models.
 
 These can still be presented through one subsystem façade during migration.
 
@@ -413,7 +413,7 @@ The safest migration path is to extract responsibilities by interface, not by bi
 
 ### Step 1: Introduce The `RuntimeStore` Name And Facade
 
-Create a façade interface that wraps the durable-data parts of `RuntimeHost`.
+Create a facade interface for the durable-data parts that used to live in `RuntimeHost`.
 
 Initial likely contents:
 
@@ -422,7 +422,7 @@ Initial likely contents:
 - preset load/save access
 - package catalog read access
 
-This stage is now past the initial compatibility point: `RuntimeStore` owns its durable/session backing fields directly rather than wrapping a `RuntimeHost` object.
+This stage is complete: `RuntimeStore` owns its durable/session backing fields directly rather than wrapping a `RuntimeHost` object.
 
 ### Step 2: Move Pure Persistence Helpers First
 
@@ -587,4 +587,4 @@ It should not answer:
 - how hardware pacing should work
 - what health warnings should be emitted
 
-If this boundary holds, later phases can safely split `RuntimeHost` without just recreating the same coupling under a different class name.
+If this boundary holds, later phases can continue without recreating the old coupling under a different class name.

docs/subsystems/VideoBackend.md

@@ -572,11 +572,11 @@ The most important migration is:
 
 ### Previous Runtime Status Updates
 
-Frame pacing and signal status setters currently called from the bridge should ultimately be routed through:
+Frame pacing and signal status setters that were historically called from the bridge should route through:
 
 - `VideoBackend -> HealthTelemetry`
 
-rather than:
+rather than the old pattern:
 
 - callback/bridge -> `RuntimeHost`