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?
Required
Confirm which physical site types the CV monitoring program must cover.
Select all that apply
Macro towers (rooftop / greenfield)
Monopole / lattice towers (rural)
Small cell / street-level (urban)
Distributed antenna systems (DAS venues)
Cable head-ends / POPs
Solar / hybrid-powered off-grid sites
Microwave / backhaul hops
Co-located tenant vaults and ground shelters
required
✓ saved
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?
Required
Select every physical event class the model must detect and distinguish.
Select all that apply
Perimeter intrusion / fence breach
Unauthorized climb on tower structure
Copper / feeder-line theft in progress
Battery / generator theft
Cabinet tamper / door-open events
Vandalism / graffiti / deliberate damage
Arson / fire / smoke at site
Weapon brandishing or assault on authorized crew
required
✓ saved
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?
Required
Select the end-to-end latency SLA from camera frame to confirmed alert.
Single choice
< 1 second (active-threat / climb detection)
1 – 3 seconds (perimeter / intrusion)
3 – 5 seconds (tamper / anomaly classes)
5 – 15 seconds (deferred verification tier)
Tiered per threat class (mixed SLA)
requirededgetrinidy
TrinidyCloud 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.
✓ saved
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?
Required
Select the sustained edge-compute power budget the monitoring stack must fit inside.
Single choice
< 25W (solar / off-grid constrained)
25 – 50W (hybrid / battery-backed rural)
50 – 100W (standard macro site)
100 – 250W (urban / mains-powered)
> 250W (data-center-adjacent / shelter)
requirededge
✓ saved
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?
Required
Select the per-site camera count the edge node must support simultaneously.
Single choice
1 – 2 cameras (small cell / POP)
2 – 4 cameras (typical macro tower)
4 – 8 cameras (compound / multi-tenant)
> 8 cameras (large shelter / head-end)
Variable by site class
requirededge
✓ saved
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?
Required
Specify what, if anything, may leave the site under normal operation.
Select all that apply
Raw video must never leave the site
Short confirmed-event clips may egress for review
Detection metadata / bounding boxes only
Model embeddings for aggregated retraining
Continuous cloud streaming is acceptable
Strict geographic / national-border residency applies
requirededgetrinidy
TrinidyTrinidy 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.
✓ saved
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?
Required
Select every privacy regime that touches the proposed CV stack.
Select all that apply
EU GDPR (Art. 9 special-category biometrics)
EU AI Act Annex III — remote biometric identification (high-risk)
US CCPA / CPRA (California)
Illinois BIPA
Texas CUBI
Other state biometric / video consent statutes
Works-council / union worker-monitoring constraints
No biometric identification in scope — object / event only
required
✓ saved
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?
Required
Identify safety and physical-security standards the program must align with.
Select all that apply
OSHA 29 CFR 1910 (general industry — shelters / head-ends)
OSHA 29 CFR 1926 (construction — tower climb safety)
FCC 47 CFR Part 17 (tower marking and lighting)
ASIS International Physical Security Standard
SIA (Security Industry Association) performance standards
FCC Part 4 outage reporting thresholds
Local AHJ / fire-marshal requirements
required
✓ saved
Confirm deployment topology
Required
Select the deployment pattern the inference stack will follow.
Single choice
On-site edge node per tower (fully distributed)
Cluster of sites to regional aggregation point
Camera-integrated (smart camera only)
Hybrid — edge pre-filter plus cloud deep review
Cloud-only (current state, to migrate)
requirededge
✓ saved