About this article

• Audience: Operators and integrators evaluating whether a shadow deployment is fleet-ready
• Goal: Understand readiness tiers, gate themes, and what evidence to collect before promotion
• Type: Concept

Summary

Ghost Protocol grades production readiness across four tiers: continuous H.265 recording, on-device precomp authority, fleet services stability, and standards compliance. Public docs describe the gate model; live percentages, verifier logs, and promote decisions stay in operator-controlled repositories.

Prerequisites

• First operator tasks completed on a lab shadow
• Soak automation guide for reproducible batches
• Phantom proxy at https://<phantom-proxy>:8788

Readiness tiers

Tier	Theme	What "ready" means
T1 — H.265 recording	Independent 4K evidence stream	Recent justified chunks without prolonged stall; keyframe cadence passes ffprobe checks
T2 — Precomp authority	RF-DETR on-device detection	Stable ~10 Hz dets telemetry; person class available for alert pipelines
T3 — Fleet services	MCP, Hermes, proxy integration	Health endpoints respond; mesh registration and playback-ready paths work
T4 — Platform surfaces	OTA, manifests, WinUpdate poll	Recording manifests publish; upgrade channels report success/failure cleanly

Promotion requires passing soak gates on a canary shadow before fleet-wide rollout. Tier weights and bump rules are strict: do not advance T1 scores without verified fresh chunks plus harness pass at the configured threshold.

Gate categories

Automated grading checks these areas during soaks:

• Encoder health — Chunk growth, sidecar validity, playback wall-clock alignment
• Thermal governor — Die temperature within warning and critical thresholds; inference throttles before encode failure
• Storage — eMMC free space above WARNING; prune policy engaged before CRITICAL
• MQTT contract — Retained status, telemetry rate, detection schema keys present
• Visual harness — Optional playback-ready and person-alert path verification through the proxy

Site roles (site-role-a, site-role-b) are graded independently; cross-site aggregation happens at the proxy /fleet/health surface.

Evidence collection

Operators collect readiness evidence through:

1. Shadow orchestrator soak batches with TAP traces
2. soak_gate.sh or equivalent gate scripts against MQTT and storage probes
3. H.265 verification scripts with expected FPS and keyframe policy
4. Mass-transit safety scenario harness runs (nine cases, precomp-first latency targets)

Artifacts land in [operator-artifacts] — not in public documentation.

Known remainders (themes)

These themes appear in private grading until closed on hardware:

• Canary recovery — First verified >1M H.265 chunk after container recovery on site-role-a
• Secondary physical cycle — Controlled power cycle and eMMC health confirmation on site-role-b
• Harness uplift — Live MCP harness at or above the superiority baseline before T1 percentage bumps
• 24/7 sustain — Scheduler-backed kickers, thermal mitigation, and zero-gap monitoring between soak waves

Exact commands, session IDs, and current percentages are maintained only in operator handoff.

Standards alignment

Readiness grading references OWASP IoT ISVS hardening, NIST zero-trust patterns for outbound-only control plane, and project requirements for thermal and imaging guardrails. Mass-transit safety scenarios provide the operational acceptance lens for person-detection workflows.

Next steps

• Grading overview — what soak grading measures
• Release status — current release train
• Recovery runbook — when gates fail mid-soak

Operator depth

Live tier percentages, verifier PASS logs, scheduler rosters, and promote decisions live in private operator handoff (not published).