Phantom Vision VMS / Ghost Protocol

Appearance

About this article ​

  • Audience: Operators and integrators who need a mental model for fleet mesh, playbooks, and on-demand stack cost
  • Goal: After reading, you understand how Hermes ties shadows together, which playbooks self-heal common failures, and why the Phantom stack defaults to idle
  • Type: Concept

Summary ​

Hermes is the edge fleet mesh that lets shadows discover peers, exchange signed agent-to-agent queries, and share a common device bus. The Phantom proxy orchestrates playbooks against that mesh. Keeping the host stack down when you are not doing VMS work avoids broker traffic, proxy pulls, and readiness loops that would otherwise run continuously.

Hermes mesh (mental model) ​

Each shadow runs a Hermes sidecar on UDP with mTLS or HMAC-backed peer trust. After bake and activation, devices advertise a non-null fingerprint and join a shared bus so site-role-a and site-role-b remain visible to each other and to the proxy.

The proxy resolves Phantom agents and forwards approved remediation steps. A fleet controller can observe mesh health in read-only mode before any execute-safe action runs. Cross-shadow queries flow through /a2a/query on the proxy, which injects precomputed detection context where policy allows.

Healthy mesh signals include active peer discovery, consistent bus membership, and MQTT telemetry near the expected contract rate when the stack is up.

Playbooks and self-heal ​

Playbooks live under cost-sentinel/phantom-agents/playbooks/ as YAML sections the proxy can execute after operator approval. They group signals, diagnostic steps, and UI actions into repeatable flows.

Playbook familyPurpose
Fleet onboardingProvision shadows, register labels (site-role-a / site-role-b), validate fleet manifest
h265_stallDetect encoder stall streaks; prune if needed; restart app; re-validate recording
disk_criticalRespond to storage CRITICAL; prune recordings; confirm free space before soak resume
Connection / federationRestore proxy, MQTT, or peer links after network blips
Setup wizardWire stack, registry, and readiness modules for first-time host setup

Self-heal paths prefer allowlisted steps: provision shadow, validate fleet, call MCP tools through the proxy, and re-run readiness. The orchestrator and readiness agent can invoke Hermes validation hooks during batch soaks without bypassing execute-safe gates.

Cost control and on-demand VMS ​

Phantom Vision is designed for on-demand operation:

  • Stack down (default): No MQTT subscriber, no proxy fleet timers, no background H.265 pulls. Host ports :8788 and :1883 stay idle.
  • Stack up (active VMS): Proxy, broker, and optional UI serve registry, /fleet/mqtt/latest, playback-ready, readiness, and playbook execution.

Long retention and frequent incident pulls increase edge storage churn; pruning and external storage policies reduce soak risk without keeping the host stack running 24/7. Video understanding and cloud annotation modules add API usage only when you explicitly include them in readiness or batch scenarios—the proxy remains the central escalation surface so edge images do not embed cloud keys.

Batch reproduction for mesh validation typically runs through the shadow orchestrator with --hermes and --prune-first after npm run stack:up. Detailed rates, soak percentages, and harness tables stay in operator-controlled artifacts—not on the public site.

How this ties to automation ​

  • Readiness agent: Interleaved 5-minute modules exercise device_identity_fp, hermes_mesh, MCP health, and federation when --hermes-validate is set.
  • Orchestrator: Batch scenarios such as recovery_after_stall and normal_short can enable Hermes hooks alongside visual and TAP collection.
  • Proxy routes: /fleet/readiness, /fleet/readiness/remediate, and /fleet/health are the operator-facing surfaces for mesh-aware status.

Next steps ​

Operator depth ​

Live fleet state and harness evidence live in private operator handoff (not published) (private).