ActivityOps

Inspiration

A store manager opens up at 7 a.m. and works through a checklist — walk the entrance, check the alarm panel, count the float. Today that's a paper sheet or a tick in a spreadsheet. Nobody can later prove that a check happened when it was meant to, what failed, whether it was rechecked, or who decided the site was ready.

I realised that the Ring camera already at the door could be the missing witness — not as a judge of what was seen, but as a timestamped record that someone looked. What it does

ActivityOps turns opening/closing checklists into accountable records:

1. A verification run lists required checks. For a Ring-backed check, a time window opens and PASS is locked until Ring Event History shows a live-view session inside it.
2. The operator decides PASS or FAIL. A FAIL opens an incident. A recheck is a new, immutable attempt — the original failure is never overwritten.
3. Readiness is computed deterministically from checks, incidents, and evidence — with a plain-language explanation of what's blocking it.
4. An AI copilot (Strands Agents SDK) writes handover notes using 10 read-only tools. It can read everything but change nothing.
5. A printable audit report goes to head office or an inspector.

The UI never says "person detected", "motion detected", "site clear" or "site safe" — a test fails the build if any of those phrases appear. The camera is a witness. The person stays accountable. How I built it

• Backend: Node.js 24, Fastify, SQLite (WAL mode) with node:sqlite — no ORM, no external database. Immutability is enforced by database triggers: no code path can update or delete an attested attempt.
• Frontend: React + Vite + Tailwind CSS. Works on desktop and a 390px phone.
• Ring integration: Built against the live Ring Partner API — device discovery, status, and Event History. Client-side filtering is authoritative because the Playground ignores the event_types filter (documented in the friction log). Evidence matching checks device, event type, time window, and a UNIQUE constraint so one session can never count twice.
• AI copilot: Strands Agents SDK with 10 read-only tools, a step limit, a timeout, and an output guard. The same agent code works against Amazon Bedrock, Google Gemini, and local models (Ollama) — one environment variable switches between them.
• Security: httpOnly session cookie, CSRF protection, rate limiting, strict CSP, non-root container with read-only root filesystem. Six security guards are mutation-tested: disabling any one makes the suite fail.
• Testing: 273 automated tests covering the domain engine, Ring adapter, API routes, security guards, and AI output guards.

Challenges I faced

• Bedrock quota: Our new Free-plan AWS account has a 0.0 daily token quota on every Bedrock model. Every invocation is refused. The Strands agent is built and tested, but the recorded demo runs on Google Gemini instead — clearly labelled. One setting switches it back when quota opens.
• Ring Playground limitations: The Playground ignores the event_types filter, the single device was offline for the first five days, and pagination couldn't be tested with real data. Each of these is documented with evidence and a workaround.
• Timing measurement: We got one live session indexed in about 10 seconds. One sample isn't a distribution, so the post-window wait (60s) and clock-skew allowance (30s) are conservative defaults — documented as unmeasured.
• Port conflict: Port 8080 was taken by a Windows service, discovered during the first dev session. A small thing, but the kind of friction that costs time in a hackathon.

What I learned

• Treat a camera API as a timestamped witness, not an oracle. The moment you say "detected" or "clear", you're making a claim the data doesn't support.
• Immutability by database trigger is simpler and more reliable than application-level guards.
• Build the Bedrock path and the fallback path at the same time. When one is blocked, the other proves the agent works.
• Record every integration finding, decision, and mistake as it happens — not afterwards. The project has five running logs, and they saved hours of re-investigation.

What's next

1. Ring webhooks for instant evidence (today the app polls every 15s)
2. Role separation— operator and approver as separate sign-ins
3. Multi-site dashboard for area managers
4. Amazon Bedrock in production, then AgentCore hosting
5. Embedded live view (WHEP) inside the check card

Built With

• agents
• amazon
• api
• bedrock
• css
• docker
• fastify
• gemini
• google
• html
• javascript
• node.js
• partner
• react
• ring
• sdk
• sqlite
• strands
• tailwind
• typescript
• vite
• vitest
• zod