NightWatch

Inspiration

Most home security alerts are good at telling you that something happened, but not necessarily whether it matters.

A single motion event at 3 PM is very different from three motion events at the front entrance at 3 AM while everyone in the household is asleep. We wanted NightWatch to understand that difference.

The idea behind NightWatch was to build a home-safety system that doesn't simply react to individual Ring events, but evaluates them in context: time, frequency, intervals between events, household state, location patterns, and deviation from a household baseline.

We were also interested in exploring how an event-driven home-safety system could interact with an AI assistant. Instead of simply producing an alert, NightWatch can provide an explanation when asked “Why did you wake me?” — grounded in the actual events and reasoning that triggered the alert.

What it does

NightWatch receives Ring-style motion events and evaluates them against household context and a configured baseline.

It considers:

Time of day Event frequency Time between events Household state Location patterns Deviation from the household baseline

A deterministic context engine then classifies activity as normal, unusual, or high priority and produces an explainable escalation decision.

NightWatch exposes this information through a self-hosted MCP server with four core tools:

get_recent_events get_home_context assess_activity get_alert_explanation

For the current hackathon implementation, the Alexa+ experience is simulated locally. The simulation uses the actual NightWatch MCP/domain layer rather than hard-coded responses.

This allows a user to interact with NightWatch conversationally:

“Why did you wake me?”

NightWatch retrieves the current event evidence and explains why the activity was considered unusual.

The system deliberately reports unusual activity rather than claiming to identify a burglary, crime, or emergency.

How we built it

We built NightWatch incrementally, starting with a credential-free Ring event simulator and a deterministic context engine.

The current stack includes:

React + TypeScript for the dashboard Node.js backend with tRPC SQLite for persistent event and alert data MCP TypeScript SDK with Streamable HTTP Automated tests and an MCP HTTP smoke client

The architecture is roughly:

Ring / Simulator ↓ Event Ingestion ↓ SQLite Event Store ↓ Deterministic Context Engine ↓ Escalation Decision ↓ NightWatch MCP Server ↓ Simulated Alexa+ Experience ↓ User

The context engine remains deterministic and is responsible for the actual escalation decision. The conversational layer is responsible for retrieving and explaining that decision rather than independently making a safety-critical judgment.

We also built the MCP interface around the existing NightWatch domain layer, so the MCP tools don't duplicate the application's core logic.

Challenges we ran into

One of our biggest challenges was figuring out where AI should and should not be used.

It would have been easy to let an LLM simply look at an event and decide that something was dangerous. Instead, we wanted the system's escalation behavior to remain predictable and explainable.

That led us to separate the system into two responsibilities:

Deterministic logic decides. AI can explain.

Another challenge was integrating with the Alexa+ ecosystem without assuming that undocumented APIs existed. We investigated the current Alexa+ MCP architecture and found that live integration requires additional Amazon-side onboarding, remote HTTPS infrastructure, authentication, and developer access that aren't currently available to our prototype.

Rather than pretending to have physical Alexa control, we built a clearly labeled simulated Alexa+ experience powered by the real NightWatch MCP layer.

We also had to make the MCP boundary reliable enough to test independently, including initialization, tool discovery, structured outputs, HTTP transport, and a dedicated smoke client.

Accomplishments that we're proud of

We're particularly proud that NightWatch evolved from a simple motion-alert concept into a system with a clear separation between event data, contextual reasoning, escalation, and conversational interaction.

We're proud of:

Building a working end-to-end NightWatch prototype Implementing persistent SQLite-backed event storage Building a deterministic, explainable context engine Exposing NightWatch through a real MCP server Implementing structured MCP tool outputs Building an MCP client and HTTP smoke test Creating a simulated Alexa+ interaction layer backed by real NightWatch data Making the “Why did you wake me?” interaction dynamically retrieve actual evidence Keeping safety-critical escalation deterministic instead of delegating it entirely to an LLM Being explicit about the boundaries between implemented, simulated, and unavailable functionality

Most importantly, we built the project incrementally and tested each major layer rather than treating the entire system as one black box.

What we learned

We learned that building an AI-enabled system isn't just about adding an AI model.

The architecture around the model matters just as much.

We learned how to design an MCP interface around an existing application, how to expose structured tools over Streamable HTTP, and how to build tests around an agent-facing interface.

We also learned the importance of grounded explanations. When a system makes a decision that affects a user, being able to explain why is much more useful than simply producing a confidence score.

Finally, we learned to distinguish between what a platform technically supports, what is publicly available to developers, and what we can responsibly claim in a prototype.

What's next for NightWatch

The next stage is to expand NightWatch's connection to the Amazon ecosystem.

We're planning to explore:

AWS-based infrastructure and AI services A more capable agentic reasoning layer Further Ring integration A production-oriented authenticated MCP deployment Live Alexa+ integration if the required developer access becomes available More adaptive household baselines Additional contextual signals and event types

The long-term goal is for NightWatch to become a context-aware household safety layer that can connect events across devices, understand what is unusual for a particular household, and communicate important situations to people in a way that is both useful and explainable.