Phase 1 of 6
Scoping & Municipal-Data-Residency Constraints
Fix the municipal applications, jurisdictional data boundary, FedRAMP/StateRAMP posture, and streetside siting constraints before architecture lands on a pole.
0/10
Phase Progress
Required Recommended Optional Open-Source Proprietary Trinidy
Municipal Application Surface
Identify municipal AI workloads in scope for tower hosting
Why This Matters
Smart city workloads vary by an order of magnitude in latency, privacy sensitivity, and regulatory posture — a gunshot-detection feed is a CJIS-adjacent public-safety workload, while air-quality time-series is open-data by default. The NIST SP 1900-series Smart City framework treats each of these as a distinct "application domain" precisely because the governance controls do not transfer. The most common procurement mistake is bundling them into one contract with a single data-handling clause and then discovering that public-safety video carries restrictions the traffic workload never needed.
Note prompts — click to add
+ Which of these workloads are funded in the current capital plan vs. grant-dependent?+ Have we separated public-safety-video controls from traffic and environmental controls in the MSA?+ Who on the city side is the single accountable owner per workload — CIO, police, DPW, or sustainability?
Required
Confirm which city applications the shared streetside inference fabric will host in year one.
Select all that apply
Intelligent traffic signal optimization (intersection CV)
Public safety video analytics (person / vehicle / weapon detection)
Gunshot / acoustic event detection
Pedestrian and bicycle counting
Air quality and environmental sensing (PM2.5 / NO2 / noise)
Parking occupancy and curb management
Transit priority and bus-lane enforcement
Flood, stormwater and inflow/infiltration monitoring
required
✓ saved
Establish per-workload inference latency SLA
Why This Matters
The FHWA 2024 Connected Infrastructure Framework and related U.S. DOT guidance set hard latency expectations for the safety-critical layer — miss them and the workload either falls back to a human review loop or is non-compliant with the reference architecture city grant funders expect. Once the pole is in the street, latency is set by physics (backhaul distance, codec, queue depth); it is not a parameter you can improve later with a software release. Specify per-workload SLAs up front so the tower host does not overbuild for environmental sensors or underbuild for public-safety video.
Note prompts — click to add
+ Do the city and carrier agree on a measurement methodology (p50 / p95 / p99, camera-to-decision) for each SLA?+ What is our contractual remedy when the SLA is breached — credits, termination right, or mere reporting?+ Have we pressure-tested the SLA at a city-scale event (parade, game day, severe weather)?
Required
Select the end-to-end latency budget each workload class must hold at the tower edge.
Single choice
< 50ms (real-time public safety video, signal phase decisions)
< 250ms (pedestrian / vehicle counting, transit priority)
< 1s (parking, curb, acoustic event classification)
1–30s (environmental sensing, batch video review)
Tiered per workload (mixed SLA)
requirededgetrinidy
TrinidyCloud-routed inference adds 40–200ms of WAN round-trip before the first frame is decoded — enough to miss the U.S. DOT Connected Infrastructure Framework 50ms public-safety target on its own. Trinidy runs CV and time-series inference on-tower with sub-frame latency.
✓ saved
Map municipal data residency and jurisdictional boundary
Why This Matters
Data residency for municipal workloads is almost always a statutory question, not a contractual preference — and the penalty for getting it wrong is grant clawback under programs like the IIJA smart-city provisions rather than a negotiated credit. CJIS Security Policy in particular treats a criminal-justice video feed as in-scope the moment it is retained, transmitted, or processed on infrastructure an outside vendor controls, and that control test is what forces on-jurisdiction processing. A vendor "data stays in-region" SLA does not satisfy a residency statute that asks where the processor is sited.
Note prompts — click to add
+ Has city legal signed off on the residency boundary at the hardware-site level, not the cloud-region level?+ Does our procurement contract reference the specific state statute or ordinance being satisfied?+ What happens to data in transit between the tower and the city operations center — is that path also in-jurisdiction?
Required
Document which categories of municipal data must remain within city, county, or state jurisdiction.
Select all that apply
State data residency statute (30+ US states have one)
Municipal charter or ordinance restricting data export
Public safety video — CJIS Security Policy jurisdiction
Open data portal — state public records / sunshine act
CCPA / CPRA applies to resident PII captured in public spaces
EU AI Act Annex III (if EU-sited city)
Cross-border transfer explicitly prohibited in procurement
No formal residency requirement identified
requiredtrinidy
TrinidyOn-tower inference with NEXUS OS keeps raw video, sensor telemetry, and model outputs inside the city jurisdiction by architecture — the residency clause is satisfied by where the silicon sits, not by a vendor attestation.
✓ saved
Confirm FedRAMP Moderate / High and StateRAMP posture
Why This Matters
FedRAMP Moderate is the de facto baseline for any municipal workload carrying federal grant funds, and StateRAMP has been adopted by a growing set of state procurement offices as the equivalent at state level. Once a workload is tagged FedRAMP-in-scope, the tower-hosting environment must either inherit authorization from an already-authorized cloud service provider or independently achieve it — there is no informal third option. The common failure is a carrier bidding municipal AI hosting on infrastructure that has never been through a 3PAO assessment and discovering mid-procurement that the entire stack is unauthorized.
Note prompts — click to add
+ Which authorization baseline does our tower-hosting stack currently inherit, and from which CSP?+ Do we have a 3PAO engaged or planned, and what is the gap-assessment status?+ Has the city validated that our authorization scope covers the specific streetside deployment, not just a central data center?
Required
Identify the authorization baseline the hosting environment must inherit or achieve.
Single choice
FedRAMP Moderate authorization required (federal-grant-funded workload)
FedRAMP High (public safety / CJIS-adjacent)
StateRAMP authorization required by state procurement
City-level authorization only — no RAMP inheritance
Mixed — per-workload authorization baseline
required
✓ saved
Map CJIS Security Policy applicability
Why This Matters
CJIS Security Policy applies from the point of creation or receipt of criminal-justice information, and it reaches every vendor, contractor, and device in the processing path. The 2023 revision tightened advanced-authentication requirements and vendor-access controls, and any streetside AI hosting contract that touches a CJIS feed inherits those controls whether or not the RFP mentions CJIS by name. Treating CJIS as a downstream concern — bolt it on after the architecture is chosen — is how vendors get disqualified in the final contract review.
Note prompts — click to add
+ Has the city CJIS Systems Officer been engaged on the hosting architecture?+ Do our personnel screening, training, and incident response controls meet the CJIS baseline for all staff with tower access?+ Is the tower physical-access model compatible with CJIS physically-secure-location requirements?
Required
Identify which workloads touch criminal-justice information and will therefore inherit CJIS controls.
Select all that apply
Public safety video with retention that may become evidentiary
License plate reader (ALPR) feeds
Gunshot / acoustic detection tied to CAD dispatch
Facial analytics (where locally permitted)
Integration to RMS / CAD / NCIC queries
None — no CJI crosses the inference plane
required
✓ saved
Section 508 / WCAG accessibility scope
Why This Matters
Section 508 applies to all federally-funded ICT procurement and most state and municipal procurements mirror it through local accessibility statutes; WCAG 2.1 AA is the practical conformance target. AI-generated outputs — a natural-language 311 response, a traffic-dashboard visualization — are procurement deliverables under 508 just like any other UI, and the Section 508 refresh harmonized the standard with WCAG. Cities have increasingly unwound contracts that delivered inaccessible dashboards, regardless of model quality.
Note prompts — click to add
+ Which of our AI outputs render in a citizen-facing surface, and has each been tested against WCAG 2.1 AA?+ Do we have an accessibility conformance report (ACR / VPAT) for every deliverable in the statement of work?+ Who on the team owns accessibility sign-off, and are they resourced before go-live?
Required
Confirm the citizen-facing outputs that must meet Section 508 and WCAG 2.1 AA.
Select all that apply
Public dashboards and open-data portals
Transit rider information displays
Parking and curb availability apps
311 / service-request AI responses
Internal operator consoles (where staff have disability accommodations)
No citizen-facing surface — purely back-office inference
required
✓ saved
EU AI Act Annex III applicability (EU deployments)
Why This Matters
The EU AI Act places several municipal AI use cases squarely in Annex III high-risk, which triggers conformity assessment, registration in the EU AI database, and ongoing post-market monitoring obligations. Real-time remote biometric identification in publicly accessible spaces is separately restricted under Article 5 and cannot be designed-in on the assumption that a derogation will be granted. For US cities the Act is formally out of scope, but software supply-chain vendors subject to it often flow down requirements that end up in the municipal stack anyway.
Note prompts — click to add
+ Has legal confirmed which Annex III categories apply to the workload set?+ Do we have the technical documentation, logging, and human oversight artefacts the Act requires?+ If a vendor in our stack is EU-regulated, do their flow-downs conflict with city-side rules?
Recommended
For EU-sited cities, confirm whether workloads fall under Annex III high-risk public-service categories.
Select all that apply
Access to essential public services (utilities, benefits triage)
Law enforcement — biometric identification in public spaces
Migration, asylum and border control interactions
Critical infrastructure management (traffic, water, energy)
Workforce decisions affecting municipal employees
Not applicable — non-EU deployment
recommended
✓ saved
FCC Section 6409 / small-cell siting constraints
Why This Matters
Adding an AI compute module to an existing streetside small cell is an "eligible facilities request" under Section 6409(a) in many cases, which starts a 60-day federal shot clock on local review. Misreading which framework applies is the fastest way to lose a municipal contract: if the carrier asserts Section 6409 and the city disputes it, the whole hosting program can stall in administrative litigation. The regulatory path also determines whether NEPA or NHPA review attaches, and that in turn determines the actual time-to-first-kilowatt at the site.
Note prompts — click to add
+ Which sites in scope are collocations on existing structures vs. new builds, and which framework governs each?+ Has the city attorney agreed on the regulatory classification in writing?+ What are our historic / environmental review obligations, and who is tracking the shot clocks?
Required
Confirm the siting authority and timelines the tower host is operating under.
Select all that apply
FCC Section 6409(a) — eligible facilities request (60-day shot clock)
FCC small cell order — 60/90-day shot clocks on new small cells
Local ROW agreement / pole-attachment license
State small-cell preemption statute
Historic or environmental review (NHPA / NEPA) required
No special siting framework applies
required
✓ saved
Confirm spectrum and RAN context for backhaul
Why This Matters
3GPP Release 18 establishes the 5G-Advanced baseline and Release 19 introduces AI/ML-native features in the air interface that change how model updates and inference hints can ride on the control plane. O-RAN splits change who integrates the radio stack with the edge AI fabric, and CBRS Part 96 SAS coordination imposes its own operational cadence on any site using the 3.5 GHz band. Locking an AI hosting architecture to a specific 3GPP release without a clear upgrade story creates a stranded-asset risk when the city asks for features introduced two releases later.
Note prompts — click to add
+ Which 3GPP release does our current deployment target, and what is the upgrade commitment to the city?+ Are we O-RAN compliant at the sites in scope, or locked to a single-vendor RAN?+ If CBRS is in use, who holds SAS responsibilities and how does that interact with municipal priority access?
Required
Identify which radio standards and spectrum bands the backhaul and integrated RAN are operating under.
Select all that apply
3GPP Release 17 (5G features — RedCap, NTN early)
3GPP Release 18 (5G-Advanced baseline)
3GPP Release 19 (5G-Advanced, AI/ML native air interface)
O-RAN Alliance split-7.2 open fronthaul
CBRS Part 96 (3.5 GHz shared spectrum)
Licensed mid-band / mmWave carrier spectrum
Fiber or mmWave fixed backhaul only (no integrated RAN)
required
✓ saved
Specify tower-edge deployment topology
Required
Select the physical deployment target for the municipal inference fabric.
Single choice
Streetside small-cell pole (integrated RAN + AI compute)
Macro tower base station with municipal compute tenant
City-owned light pole with carrier compute attachment
Municipal operations center data hall (centralized)
Hybrid: pole inference + city data hall orchestration
requirededge
✓ saved