TwinOps Control Plane

Digital twins are often demos or notebooks. Production teams need drift detection, reconciliation, ownership, telemetry persistence, and a path to replay incidents — not a one-off visualization that collapses when someone updates a mesh or a kit version.

A GitOps control plane composes OpenUSD scenes, detects drift against desired state, reconciles through Kubernetes operators, persists history, streams kit telemetry, and supports incident replay. Desired twin state lives in Git; runtime state is observed and reconciled like any other platform product.

Industrial and platform teams share ownership boundaries: who can change composition, what drift is actionable, how telemetry is retained, and how an incident is replayed without rebuilding the scene by hand.

Treating twins as platform products adds operator and GitOps complexity. The benefit is reviewable state, recoverable failures, and demonstrable E2E behavior instead of fragile demos.

Useful signals include composition history, drift events, reconcile outcomes, kit telemetry streams, and replay records that reconstruct what the twin saw during an incident window.

PLM REST reliability: ETag / If-None-Match polling, exponential backoff with jitter on 5xx and timeouts, 409 conflicts surfaced as a PlmConflict condition, and idempotent resync — after an outage the next successful poll increments resyncCount exactly once. PLM fetches go through an SSRF guard (operator host allowlist, private-IP blocking on DNS and redirects, 1 MiB response cap). MQTT ingest drops out-of-order and duplicate messages, marks stale sensors STALE / UNKNOWN and quarantines clock-skewed messages without advancing the sequence. All Operator kind jobs, including PLM poll E2E and MQTT smoke, green in CI run 38133823218.