Physical security and manned guarding · Case study
US security services company: An AI-assisted body-camera operations platform for security patrols
AI video analysis platform case study: body-camera footage turned into searchable incidents, Vertex AI reviews and client-ready PDF reports for a US security operator.

- Client
- A US-based guarding company whose officers patrol client sites wearing body cameras.
- Team
- 3 engineers across backend, video pipeline and front end, plus 1 QA engineer
- Timeline
- First commit January 2025, most recent December 2025
- Services
- AI and data, Web development, Cloud and DevOps, Enterprise software
- 159
- Features across 22 modules
- 1,855
- Automated test cases in the worker service
- 15
- Background jobs including 3 scheduled
- 9
- Documented field endpoints for cameras and the guard app
In short
A US guarding company needed body-camera footage to become evidence without a person stitching the steps together. We built a multi-tenant SaaS platform and field API where uploaded segments are stitched, analysed by Google Vertex AI for severity and detections, and turned into PDF reports on demand. Delivered over 2025 across three repositories with 22 modules, 159 features and 1,855 automated tests in the media worker.
Where they started.
- A guarding company can only bill for, and defend, what it can prove, but raw footage is not evidence a client will read
- Finding the moment that mattered, grading its severity and writing it up by hand does not scale past a few sites
- Footage arrives in segments at unpredictable times and processing needs FFmpeg and a headless browser, which cannot run inside web requests
- Shifts cross midnight and sites sit in different timezones, so a report labelled Tuesday must mean the client's Tuesday
The approach.
- Three repositories sharing one database schema as a git submodule: a Next.js web app and field API, a Trigger.dev worker service, and the Prisma schema
- An S3 event router that classifies each upload and fans out to specialist jobs for video stitching, audio extraction, frame and sprite-map generation and transcription, each with idempotency keys and retry policies
- Google Vertex AI review of every incident returning proposed severity, detections, scene conditions, key phrases and recommended actions, stored beside the guard's record and never overwriting it
- A report builder producing single-incident, multi-incident, analysis and shift PDFs with a configurable day-start hour and email delivery
- Live dashboards with in-progress patrols, GPS positions on a map and the latest frame from each camera
- Device fleet management with AWS IoT provisioning, certificate rotation, SIM and data-plan inventory and tenant migration with a dry run
What shipped.
- Operations dashboard, incident management with a six-level severity scale and live subscriptions
- AI incident analysis with raw model output retained next to every normalised field for traceability
- Patrol and session views with HLS playback, sprite-map scrubbing and checkpoint galleries
- Transcription and subtitles with WebVTT timelines
- Clients, sites, geofenced areas of interest with synthesised voice guidance
- Guard directory, gamification with daily tasks and leaderboards
- Authentication with passkeys, two-factor, magic links and tenant switching
- Field REST API published as an OpenAPI 3.0 specification, plus deployment and device-migration runbooks
How the engagement ran.
Context
Body cameras produce hours of footage per shift. For a guarding company that footage is only valuable if someone finds the moment that mattered, describes it, grades how serious it was and puts it in a report the client will accept. Done by hand, that does not scale past a handful of sites, and it makes every incident report only as good as an officer's memory at the end of a long night.
The operator wanted the whole chain to run without a person stitching the steps together: camera in the field, footage in the cloud, incident on a screen, report in a client's inbox. Development ran from January to December 2025 across three repositories with 2,561 commits.
What we built
- An ops overview for duty supervisors with live patrol feeds, critical-incident surfacing and GPS positions on a site map
- Incident management with cursor-paginated lists, a six-level severity scale, manual creation from a GPS position or a single frame, and remote capture dispatched to a camera as an AWS IoT job
- AI incident analysis on Vertex AI: severity with confidence, person, vehicle and object detections, scene, weather and lighting, speech segments and key phrases, risk factors, recommended actions and quality assessment
- A media pipeline that combines segments, extracts audio and frames, builds sprite maps, packages archives and generates speech, with idempotency keys on every job
- Reporting with four report types, selectable screenshots and checkpoints, duplicate detection, server-rendered previews and emailed PDFs
- Clients, sites with geocoding and timezone detection, geofenced areas with synthesised entry and exit messages, guards with performance stats and gamification
- Device fleet, SIM and plan management, users and permissions scoped to tenant, client or site, and audit logs for application, authentication, device and email events
Architecture and stack
| Layer | Technology | Why |
|---|---|---|
| Frontend | Next.js 15 App Router, React 19, TypeScript strict, Tailwind 4, MUI X, TanStack Query and Table, hls.js | Dashboards with data grids, maps and video playback |
| API | tRPC 11 with schema-generated CRUD routers plus 136 hand-written procedures, Better Auth | Boring code is generated; the interesting code stays small enough to review |
| Data | PostgreSQL, Prisma 6, ZenStack access policies, 50 models, 67 enumerations, soft delete | Access rules are declared next to the models they protect |
| Background | Trigger.dev v4 with 15 jobs, FFmpeg, headless Chromium | Slow, CPU-heavy work runs outside web requests and reports progress to the dashboard |
| Infrastructure | Docker multi-stage builds, AWS ECR and ECS Fargate, GitHub Actions, Infisical secrets | Tag-driven deploys to staging and production with pinned-image rollback |
| Integrations | AWS S3 and IoT Core, Google Vertex AI, Cloud Storage, Text-to-Speech, Maps and Places, Resend, Datadog, Axiom, OpenTelemetry, Sentry | Managed AI, mapping, messaging and observability instead of custom builds |
Splitting the web app from a separate worker service was the most consequential decision. Uploads land in S3, S3 emits events, and one router job classifies each object and fans out to the right specialist job. Each job validates its own payload, carries an idempotency key so a retry never duplicates work, and reports progress to the database, where the dashboard picks it up through live subscriptions. Both applications consume the same schema repository as a submodule, so a field added to the incident model is visible to the dashboard and the workers in the same commit.
How we worked
Tests were concentrated where a silent failure would lose a client's evidence: the worker service carries 1,855 test cases across 111 files covering S3 event parsing, FFmpeg safety, download resilience, disk-space handling and error categorisation, with Playwright configured for end-to-end runs against the web app. CI gates every pull request with type checking, linting on changed files, a dependency audit that fails on critical vulnerabilities, workflow linting and a check that the schema submodule matches what the app expects.
Security lives in the code, not only in policy: all inputs validated with Zod, tenant scoping on data access, no raw SQL for ordinary queries, secrets injected at runtime, security headers and request-size limits at the edge, and log redaction so sensitive fields never reach the logging provider. Deployment, local testing, monitoring, IAM migration and device-migration runbooks were written for the next developer.
Scale and complexity
| Measure | Figure |
|---|---|
| Modules / features | 22 / 159 |
| Data models / enumerations | 50 / 67 |
| Hand-written API procedures / generated routers | 136 / 45 |
| Field endpoints (OpenAPI 3.0) | 9 |
| Background jobs | 15, including 3 scheduled |
| Report types | 4 |
| Worker test cases / files | 1,855 / 111 |
| Live environments / CI workflows | 2 / 6 |
What this means for your project
If your product turns raw media or documents into records people act on, the same shape works: a thin web app, a worker service for everything slow, one shared schema, and AI reviews stored next to human decisions rather than in place of them. Evaluation, guardrails and traceability are part of the build, not a later phase.
Innovation Insight builds AI features like this from $12k to $60k for a scoped feature, or as a dedicated team for a full platform. Discovery gives you a written scope first.
What changed.
- An hour of patrol footage becomes reviewable in seconds through stitched video, frames and sprite maps
- Every incident receives a structured AI review with provider, model, prompt and temperature recorded for reproducibility
- Two live environments on AWS ECS Fargate driven by six CI/CD workflows with tag-driven, reversible deploys
- A 50-model data domain with 67 enumerations defined once and shared by the web app and the workers
Questions about this project.
Can you build AI video analysis into our product?
Yes. The pattern here, media processed by background workers and analysed by a foundation model with strict schema validation, applies to any product that turns video, audio or documents into structured records.
How do you stop AI output from being trusted blindly?
Model responses are validated against strict schemas, the raw text is stored beside every normalised value, and the AI's proposed grade stays distinguishable from the one a human assigns.
Do you handle hardware and device fleets?
In this project we provisioned body cameras into AWS IoT with per-device certificates, tracked SIM cards and data plans, and dispatched remote commands as device jobs. Fleet operations became part of the product rather than a spreadsheet.