Inspiration
Smart-home routines are designed to make everyday life easier, but convenience should not come at the cost of safety. A routine might contain a sensitive action, target a device the user has excluded, or attempt an operation that the device does not support.
We wanted to explore a simple question: What if a smart-home routine could be checked against the user's intentions before it executes?
That question inspired Routine Intent Guard, a prototype that puts safety checks between a proposed routine and its simulated execution.
What it does
Routine Intent Guard is a smart-home routine safety prototype that evaluates proposed actions and assigns one of three outcomes:
- VALID: The routine passes the configured safety checks.
- NEEDS_APPROVAL: The routine contains sensitive actions that require explicit user approval.
- BLOCKED: The routine contains unsupported actions or attempts to use an explicitly excluded device.
The application demonstrates these outcomes through three scenarios:
- Good Night: A routine that passes validation.
- Courier Delivery: A routine that flags sensitive actions, including unlocking the front door, opening the garage door, and disarming the perimeter alarm.
- Hazardous Energy Saver: A routine that is blocked because it includes an unsupported operation and targets an excluded device.
Users can inspect and edit proposed actions, review validation explanations, and observe simulated execution and activity logging.
How we built it
We built the frontend using React, TypeScript, Vite, Tailwind CSS, and Lucide icons. The backend uses Python, FastAPI, and Pydantic.
The frontend sends structured routine proposals to the backend through an API. The backend evaluates the proposed actions against the configured rules and returns a validation result with explanations. The frontend uses that result to present the appropriate state and control the simulated execution flow.
We designed the prototype around three distinct outcomes—VALID, NEEDS_APPROVAL, and BLOCKED—so that passing validation, requesting authorization, and preventing unsafe actions are not treated as the same thing.
The project explores a safety concept relevant to the Alexa+ smart-home experience. The current implementation is a standalone prototype; it does not have a live Alexa+ integration or control physical smart-home devices.
Challenges we ran into
One challenge was keeping the action shown in the interface consistent with the structured action evaluated by the backend. Editing a device's state could change the underlying operation, so we needed to ensure that the displayed description remained consistent with the action being validated.
We also worked on preventing duplicate activity-log entries, requiring explicit approval for routines marked NEEDS_APPROVAL, and preventing repeated simulated execution of the same routine.
These challenges showed us that a safety-focused application needs more than a successful API response. Its interface, validation rules, authorization flow, and activity log must work together consistently.
Accomplishments that we're proud of
- Built a full-stack prototype connecting a React and TypeScript frontend to a Python FastAPI backend.
- Demonstrated three clear validation outcomes for different smart-home routine scenarios.
- Added explanations that help users understand why an action is accepted, requires approval, or is blocked.
- Created an action-editing flow so proposed actions can be reviewed and checked again.
- Worked on approval safeguards, execution-state handling, and reliable activity logging.
- Tested the backend and frontend build during development.
Our biggest accomplishment is turning a broad safety idea into a working prototype that demonstrates how routine validation can be separated from execution.
What we learned
We learned how to integrate a frontend with a backend API, validate structured data, model different safety outcomes, and handle state consistently across an application.
We also learned that authorization and validation solve different problems: an action can pass basic checks yet still require user approval, while an unsupported or explicitly excluded action should not be allowed through the normal execution flow.
Most importantly, we learned to test edge cases instead of focusing only on the successful path, and to be clear about the difference between a simulated prototype and a real smart-home integration.
What's next for Routine Intent Guard
Our next steps are to strengthen scenario testing, improve the clarity of validation explanations, and refine the demonstration experience.
Future development could explore integration with Alexa+ or compatible smart-home APIs, a more persistent audit history, configurable household permissions, and workflow automation for routing validation outcomes. These are future possibilities, not features claimed as implemented in the current prototype.
Our long-term vision is to explore how smart-home routines can remain convenient while respecting user intent, device capabilities, and explicit safety boundaries.
Built With
- css
- fastapi
- python
- react
- tailwind
- typescript
- vite
