The normalized playback model acts as an anti-corruption layer between the music service and its visual consumers. Source-specific field names and optional data are resolved once, producing a stable internal state with an authoritative revision, track identity, playback state, cue, timestamps, and whatever musical metadata is safely available. Downstream mappers begin from that model instead of raw JSON.

Normalization also creates a meaningful boundary for change detection. The coordinator fingerprints the state it actually understands, so irrelevant differences in an upstream response do not trigger another round of visual updates. Repeated states are suppressed, but the most recent state is periodically replayed after a configurable freshness interval so downstream systems do not become stale simply because the music remained unchanged.

The two consumers speak related but distinct languages. Visualizer Stream receives a track-oriented representation plus recommendation and diagnostics context. DungeonOPC receives a stricter now-playing contract centered on revision, time, track, playback state, tempo, palette, and visual guidance. This mapping strategy lets either downstream evolve without forcing the source service to adopt its presentation model.

Observability follows the same separation. Liveness answers whether the coordinator process is running. Dependency health records whether MixMan and each configured downstream are reachable. Delivery state tracks attempts, successes, failures, recovery, last status, and the most recent payload fingerprint. Keeping those signals distinct turns “the visuals stopped changing” from a vague complaint into a traceable question about polling, normalization, deduplication, or delivery.