Platform
How Parkspot.ai works.
We run computer vision on public city cameras. The output is block-face-level data on occupancy, turnover, violations, revenue, and policy outcomes. This page is the technical architecture for anyone writing an RFP or doing an integration evaluation.
Utilization
74%
+2.1%
Revenue (QTD)
$4.2M
+12%
Violations (30d)
8,412
-4%
Turnover
2.4/hr
+0.1
CO2 avoided
1.8t/day
+6%
The stack
Computer vision → data platform → three product surfaces.
1. Perception layer
Real-time CV inference on government-operated camera streams. We do not store camera video — detection events and block-face state are the only persisted output.
2. Data platform
Block-face state, turnover, violations, and forecasts are stored in a time-series store with confidence intervals. Backfills when new integrations come online.
3. Product surfaces
Cities dashboard, Fleet dispatch, Drivers app — all read the same underlying block-face timeline via a shared API.
Curb detection
Computer vision on cameras your city already runs.
Real-time inference on government-operated camera streams produces block-face state: vehicle presence, occupancy transitions (arrivals and departures), dwell time, vehicle class (passenger / commercial / livery), and events that correlate with violations — hydrant blocking, double-park, bus-stop obstruction.
What we detect
Block-face occupancy, turnover events, vehicle class, dwell time, and stop-event classification.
What we never store
Raw video frames, license plates, faces. Detection events are the only persisted output; frames are discarded after inference.
Accuracy, target
>92% during business hours on NYC study areas. Published per block-face and updated as new ground truth accumulates.
Data sources
Official data, not proprietary scrapes.
We run on government-issued and open federal data — the same sources a technical RFP reviewer can audit. No data-broker dependencies, no gray-area scraping. Specific datasets, refresh cadence, and coverage strategy ship with the technical due-diligence pack.
Live camera feeds
Government traffic camera feeds run by city and state transportation departments.
Regulations & metering
Sign inventory, meter rates, loading-zone designations, and alternate-side schedules from city agencies.
Enforcement & complaints
Historical citation data, resident complaint feeds, and sanitation suspension calendars.
Disruption overlays
Construction permits, special events, film shoots, crash data, and weather — anything that changes demand on a given block.
Multi-modal context
Transit real-time feeds, bike-share availability, and land-use zoning to contextualize parking demand.
Demographic & emissions baselines
Federal census, equity overlays, and emissions factors used for policy-impact and grant modeling.
Forecasting & confidence
We share what we know, and what we don't.
Tilde notation for estimates
Forecasts are prefixed with ~ (e.g., ~3 spots open). Measured values are integers. This distinction is non-negotiable — it's how we stay honest with cities and drivers.
AI forecasts with confidence bands
Every forward-looking metric ships with a confidence band. Cities see them in exports; drivers see them as a confidence score on the recommendation.
Per-block error rates
We track accuracy per monitored block-face (target: >92% during business hours in NYC study areas) and share the numbers with each deploying city.
Ground-truth sampling
We plan to validate detection accuracy through scheduled field sampling per block-face. 311 complaint data serves as a secondary signal layer — we expect top-decile complaint blocks to show meaningfully higher violation density, and we'll share the ratio once our own data is statistically sufficient.
Operations dashboard
One workspace for everyone running the curb.
A block-face map of the city with nine toggleable layers — occupancy, turnover, violations, revenue density, 311 complaints, cameras, loading zones, bike lanes, sweep schedule. A live block inspector (camera feed, 30-day turnover, meter yield, next-2-hour forecast). KPI strip across the bottom. Time scrubber from live through year-over-year. Alerts surface when a block's pattern breaks.
Daily driver for city operations, parking authorities, and enforcement dispatch.
Policy simulator
Model the change before you ship it.
Scenario-driven what-if modeling. Pick a policy change — meter-rate shift, parking-hours change, loading-zone relocation, parking-to-bike-lane conversion — and the simulator returns projected impact on revenue, utilization, spillover to adjacent blocks, CO₂, and equity distribution. Confidence bands, not point estimates.
Scenarios export as PDF for council decks and as the data packs required for FHWA, FTA, EPA, and USDOT grant applications. Scenarios can be re-run after implementation to compare modeled versus actual.
API
REST + streaming API for custom integrations.
Fleet teams, mobility apps, and city IT will read block-face state, turnover, and ticket-risk signals through a rate-limited REST + streaming API. Developer documentation publishes with the first integration partner.
Integrations
Built for the stack your city already runs.
Parkspot reads from and writes to the systems cities already use — meter payment, enforcement hardware, GIS, 311, sanitation, and sign-management platforms. No rip-and-replace.
Want a deeper architecture briefing?
We'll walk through data sources, error rates, and integration paths with your engineering team.