Phase 1 of 6
Scoping & Edge-Only Constraints
Define the site typology, threat model, detection latency budget, power envelope, and sovereignty posture before a single camera is specified.
0/9
Phase Progress
Required Recommended Optional Open-Source Proprietary Trinidy
Site Typology & Threat Model
Identify tower / site classes in scope
Why This Matters
Site class dictates camera mount height, expected subjects, lighting infrastructure, and power envelope — a rooftop urban macro and an off-grid solar monopole have almost no shared assumptions. Rural lattice sites dominate copper and battery theft losses in the US, while urban small cells fail more often on vandalism and tamper. Scoping to the wrong mix produces a model that works everywhere on paper and nowhere in production.
Note prompts — click to add
+ Have we stratified our loss history by site class to prioritize deployment?+ Which site classes share enough visual similarity to justify a common model, and which need dedicated training?+ Do we have at least 30 days of baseline footage per site class before model tuning begins?Confirm which physical site types the CV monitoring program must cover.
Select all that apply
Define the threat inventory
Why This Matters
Detection quality is a per-class problem — the model that catches fence breaches at 98% recall may be blind to in-progress copper theft inside a cabinet. Copper theft alone costs US telecom operators roughly $1B annually per industry reports, and climb-detection has distinct safety-regulatory implications under OSHA 29 CFR 1926 Subpart M. A comprehensive threat inventory anchors the labeling schema, the evaluation set, and the escalation playbook downstream.
Note prompts — click to add
+ What percentage of our last 12 months of physical losses fall into each event class?+ Which threat classes have formal incident-response SLAs with the NOC or law enforcement?+ Are any threat classes safety-critical (climb, weapon, fire) and therefore priority-one at the edge?Select every physical event class the model must detect and distinguish.
Select all that apply
Set detection-to-alert latency budget
Why This Matters
Every second between a detected climb and an escalated alert directly raises the probability of a successful theft or a human injury. Cloud-routed analytics introduce a latency floor set by backhaul RTT and cloud queue depth, which is fundamentally incompatible with a sub-second safety-critical class. Latency tiering by threat class is almost always the right architecture — climb and weapon detection deserve a tighter budget than cabinet tamper.
Note prompts — click to add
+ Does our current cloud or hybrid stack meet the sub-3-second tier reliably, or only under ideal conditions?+ What is our measured p99 detection latency today, and what is the distribution of the tail?+ Do we have a documented graceful-degradation behavior when detection latency breaches SLA?Select the end-to-end latency SLA from camera frame to confirmed alert.
Single choice
Trinidy — Cloud CV round-trip adds 300–1500ms on a good link and becomes unbounded under backhaul degradation — exactly when physical risk spikes. Trinidy runs detection and classification locally on-node, keeping p99 detection latency flat in the 1–5 second window whether the backhaul is up, down, or degraded.
Set the power / thermal envelope per site
Why This Matters
Edge CV is a power problem before it is an accuracy problem. Sustained inference on 4–8 camera streams can draw 40–150W depending on model and accelerator — and on a battery-backed solar site that headroom is not available without sacrificing uptime on the radio load. Specifying the envelope up front drives every downstream decision from accelerator selection (Jetson class) to how many streams per node are realistic.
Note prompts — click to add
+ Have we measured sustained (not peak) power draw of the proposed stack at full camera load?+ What happens to inference when the site drops to battery — do we gracefully reduce frame rate or go dark?+ Does thermal behavior at 45C+ ambient match vendor spec, or have we seen throttling in field trials?Select the sustained edge-compute power budget the monitoring stack must fit inside.
Single choice
Camera count and coverage per site
Why This Matters
Per-site camera count is the first-order driver of edge-compute sizing — a 2-camera small cell and an 8-camera compound need different accelerator SKUs even with the same model. Typical macro towers converge on 2–4 cameras covering perimeter, tower base, cabinet, and access gate. Overspecifying camera count wastes power and capex; underspecifying leaves blind spots on the highest-loss sites.
Note prompts — click to add
+ Does our camera count match the threat surface at each site class, or was it inherited from a prior design?+ Where are cameras missing on our highest-loss sites — base of tower, cabinet face, ingress?+ Are we sizing edge compute for current camera count or for a realistic 24-month expansion?Select the per-site camera count the edge node must support simultaneously.
Single choice
Define sovereignty and off-site data posture
Why This Matters
Tower site video reveals equipment inventory, cable routing, access patterns, and authorized personnel — precisely the intelligence a sophisticated thief or threat actor needs. Continuous cloud streaming both creates that exposure and costs roughly $300–$800 per site per year in backhaul, which at 10,000+ sites is a material OpEx line. Defining the egress envelope before architecture selection locks the correct trust boundary in place.
Note prompts — click to add
+ Do our current contracts with camera-VMS vendors permit cloud-side storage we do not want?+ Which confirmed-event clip retention policy matches our legal-hold and dispute timelines?+ Is there a national-security or export-control overlay on any of our tower footprint?Specify what, if anything, may leave the site under normal operation.
Select all that apply
Trinidy — Trinidy processes raw video on-node and emits only metadata, confirmed-event clips, or model embeddings upstream. No continuous RTSP to cloud, no bulk frame egress — sovereignty and bandwidth collapse into the same architectural win.
Privacy scoping — biometric and worker-monitoring exposure
Why This Matters
Running face recognition or gait-based identification on tower-site video puts the program inside EU AI Act Annex III as a high-risk system and inside Illinois BIPA with per-capture statutory damages — a very different compliance posture than object and event detection. The cleanest architectural move is to design the model to classify events and objects, not to identify individuals, and to document that scoping choice. BIPA and CUBI have both produced material settlements against employers running biometric systems on workers without written consent.
Note prompts — click to add
+ Are we performing any identification (face, gait, re-identification), or only event and object classification?+ If any identification is in scope, do we have a DPIA / FRIA for the AI Act Annex III pathway?+ Have union and works-council stakeholders reviewed the system where applicable?Select every privacy regime that touches the proposed CV stack.
Select all that apply
Regulatory overlays — OSHA, FCC, ASIS
Why This Matters
Climb detection at an unauthorized hour overlaps OSHA 1926 Subpart M — if a worker is detected climbing without fall-protection indication, that is both a security event and a safety event, and the escalation path is different. FCC 47 CFR Part 17 mandates obstruction-light monitoring on many towers, and CV can be an inexpensive secondary monitor for lighting failures that also have FCC Part 4 reporting consequences. Mapping to ASIS and SIA performance standards keeps the deployment defensible against insurers and in post-incident review.
Note prompts — click to add
+ Have we aligned our climb-detection escalation path with OSHA authorized-climber records?+ Does our CV stack also detect obstruction-light failures, and is that wired into FCC Part 17 compliance?+ Are we benchmarking our false-alarm performance against SIA perimeter standards?Identify safety and physical-security standards the program must align with.
Select all that apply
Confirm deployment topology
Select the deployment pattern the inference stack will follow.
Single choice