About this article

• Audience: Operators and integrators evaluating or deploying Shadow 1 and Shadow 2
• Goal: After reading, you understand device roles, public hardware requirements, and how they fit the VMS data path
• Type: Reference

Summary

Shadow devices are Ghost Protocol’s edge cameras. They run sovereign Ghost Protocol firmware, produce on-device RF-DETR detections, and record justified ~60-second H.265 evidence chunks. The fleet uses role labels (Shadow 1 / Shadow 2) in public docs — not physical site names.

Product video

Loading stream…

Fleet roles

Role label	Device id (docs)	Typical use
Shadow 1	site-role-a / shadow1	Canary node — first validation gate, primary deploy path
Shadow 2	site-role-b / shadow2	Secondary node — mesh peer, extended storage / precision workloads

Use role labels in scripts, proxy queries, and operator runbooks. Physical placement names stay in private handoff.

Hardware baseline (public)

Attribute	Requirement
Platform	Ghost Protocol Shadow edge platform (industrial SoC-class vision node)
Imaging	High-res primary stream + independent RF-DETR inference stream
Encode	4K-class H.265 evidence path; action modes may downscale for tracking
AI	On-device RF-DETR precomp remains authoritative
Software	Ghost Protocol edge runtime and vision pipelines
Enclosure	Outdoor / transit-ready packaging for fleet deployments

Pipeline detail: Edge AI / RF-DETR architecture and Production readiness (where published).

Connectivity (LAN preferred)

Priority	Path	Notes
Preferred	LAN over PoE+ (IEEE 802.3at) on the industrial Ethernet port	Power + data for production fleets
Supported	WLAN via M8 connector + Wi‑Fi adapter	Failover or sites without hardline

M8 also supports I/O relay control and CANbus vehicle telemetry. Full doctrine, port diagram, and plugin map: Shadow connectivity & M8 accessories.

Power, thermal, and storage

• Power — PoE+ required for peak encode + inference; plain PoE or constrained budgets force degraded inference and throttled encode. Size budget for accessories too.
• Thermal — Firmware degrades inference before dropping video; critical die temps suspend AI while keeping RTSP/MQTT where configured.
• Storage — Rolling justified chunks on device; prune policies protect flash wear. Shadow 2 may use USB-C extended storage — see USB extended storage.

What each Shadow produces

1. Live detections — RF-DETR precomp metrics and events (authoritative on the edge)
2. Justified recordings — ~60 s H.265 chunks with sidecar metadata and rolling manifest
3. Telemetry — health, thermal, mesh/peer status over MQTT to the central proxy
4. Peer mesh — Hermes peer discovery for cross-shadow status (proxy aggregates fleet view)

Playback and cloud escalation are owned by Phantom Vision VMS, not by cloud API keys on the camera.

Requirements checklist (deploy readiness)

Gate	Expectation
Identity	Device role label and registry entry visible at the proxy
Health	Mesh / MQTT telemetry updating
Recording	Justified chunks with valid sidecars; wall-clock timing matches events
Thermal	Die temp within operating guardrails under load
Storage	Free space and prune policy healthy

Operator procedures: Quickstart, Deploy, Prune & storage.

Relationship to Phantom Vision VMS

Shadow 1 / Shadow 2
  → MQTT telemetry + justified chunks
  → Phantom Vision VMS (proxy @ :8788)
  → optional cloud understanding on justified clips only

See: Phantom Vision VMS.

Next steps

• Shadow connectivity & M8 accessories — PoE+ · WLAN · relay · CAN
• Phantom Vision VMS — central product brief
• Product promo videos — full film pack
• Architecture overview — tiers and dataflow
• Recording contract — justified chunk fields
• Model card / RF-DETR — detection authority

Operator depth

Live device serials and private fleet evidence live in operator handoff (not published).