Inspiration
Smart-home routines are easy to understand one at a time. A welcome routine can turn on the porch light while an away routine keeps the home secure. Trouble begins when both respond to the same visit and issue commands in an order the homeowner never intended. We built DOMINO so someone can see that chain unfold, understand the outcome, and try a repair while keeping the welcome they wanted.
What it does
In the local demo, a familiar visitor rings while the modeled resident is away. DOMINO shows how the sensor event, rule conditions, and competing lock commands lead to an unsafe result. The user can ask for the cause through a simulated Alexa+ conversation or inspect the detailed home view. DOMINO proposes bounded rule changes and replays the same visit, so the user can compare the lock, porch light, and camera before and after. The visit and its policies can be saved as a portable case.
How we built it
We built the investigation around a deterministic event engine in Node.js. Its trace drives the home display, causal explanation, and repair search, so each view refers to the same modeled events. The search tries defined guard, delay, and disable edits, then checks candidate repairs against modeled cases and behavior the homeowner wants to retain. Clock probes reveal timing cases where a promising change fails. A local Streamable HTTP MCP server provides tools for loading, explaining, proposing, replaying, and comparing a case. The simulated Alexa+ client uses those tools through a phrase router. A pinned AmazonAppDev Ring sample generator supplies reproducible local input.
Challenges we ran into
The hardest part was making a repair mean more than an empty conflict list. A timing change can remove a command collision while still allowing an unlock during away mode. Disabling the welcome light and camera can also stop the collision while spoiling the desired experience. We check the final device state and useful behaviors alongside the conflict. Source loading needed care too. An earlier path could analyze before the requested sample arrived, and missing browser modules once kept the investigation from opening. Those experiences pushed us to bind explanations and replays to the source actually accepted.
Accomplishments
DOMINO carries one local case from input through rule execution, explanation, a proposed policy edit, and replay. The user can see why the lock changed and whether the light and camera still behave as intended. The investigation is available through a detailed browser view and a simulated conversational client backed by the local MCP server. A separate first-person home presentation is a candidate interface that connects to a running DOMINO backend. We are still reconciling it with the final source package before including it in the submitted experience.
What we learned
Home automation needs explanations that connect an event to a device state the homeowner can recognize. A conflict count alone cannot show whether the home is safer. Replaying a specific visit makes a proposed change easier to judge, and a saved case lets us return to the evidence. These replays and timing probes describe the modeled inputs checked and give us a clear basis for adding more situations.
What's next
We want to bring the first-person home view and detailed investigation into one selected release, with the same case moving between them. Showing original and repaired states together would make the difference clear at a glance. We can then broaden event schedules and the homeowner's stated goals before exploring authenticated provider connections and deliberate, reversible device actions.
Built With
- css
- html
- javascript
- model-context-protocol
- node.js
- streamable-http

Log in or sign up for Devpost to join the conversation.