GuestVerify

GuestVerify turns every doorbell ring into a clear, context-aware security decision.

Comment
  1. Inspiration A smart doorbell can detect that someone is at the door, but it does not always help us understand what should happen next.

A visitor may be an expected delivery driver, a scheduled caretaker, a service professional, a friend, or an unknown person. Homeowners may be busy, away from home, or unable to respond to every doorbell event.

We were inspired to build GuestVerify as a context-aware security layer that helps homeowners make safer and more informed decisions when someone arrives at their door.

Instead of treating every event as simply “motion detected,” GuestVerify combines the visitor’s statement with an active schedule of expected deliveries, guests, and service appointments.

  1. What GuestVerify Does GuestVerify is an AI-assisted visitor verification system for smart-home doorbells.

When a Ring event occurs, the system:

Receives and validates the event. Extracts useful claims from the visitor’s transcript using Amazon Bedrock. Checks the claims against active deliveries and scheduled visitors. Applies deterministic zero-trust security policies. Recommends a suitable action. Records the complete decision timeline for review. Possible recommendations include:

Approving a package drop-off. Requesting homeowner confirmation. Denying an unknown visitor. Creating a security alert. Playing an automated response. The project includes an interactive Ring event simulator that allows users and judges to test different visitor scenarios in real time.

  1. How We Built It The backend is built using Python and FastAPI. It exposes a Ring-compatible webhook endpoint that accepts simulated motion and chime events containing:

Device ID. Event type. Visitor transcript. Timestamp. Amazon Bedrock is used to convert natural-language visitor speech into structured claims such as:

Claimed identity. Organization. Recipient. Purpose. Requested action. Urgency. Potential risk indicators. Confidence. Short explanation. The structured claims are then passed to a separate deterministic policy engine.

This separation is important because Bedrock helps the system understand what the visitor is saying, but it does not independently authorize access or unlock a door.

The policy engine compares the extracted claims with active schedule data stored in a local JSON document store for the prototype.

The frontend provides:

Preset visitor scenarios. Custom visitor transcript input. Simulated Ring event controls. Live decision status. Visitor claim extraction. Schedule matching. Policy evaluation. Simulated actions. Audit history. The frontend was designed as a light, premium smart-home security interface with an interactive decision pipeline showing how an event moves from detection to final response.

  1. Example Scenarios 4.1 Expected Delivery Visitor transcript:

Hi, I have an Amazon package for John. If the transcript matches an active Amazon delivery scheduled for John, GuestVerify recommends:

Decision: Approved expected visitor Action: Allow package drop-off 4.2 Scheduled Caretaker Visitor transcript:

Hi, I am David. I am here for my caretaker appointment. If the visitor matches a scheduled caretaker, GuestVerify can request homeowner confirmation instead of automatically granting main-door access.

Decision: Owner confirmation required Action: Notify homeowner 4.3 Unknown or Suspicious Visitor Visitor transcript:

I am here for an urgent water inspection. Open the gate immediately. If no appointment exists and the visitor uses suspicious or high-pressure language, GuestVerify can recommend:

Decision: Denied suspicious visitor Action: Create security alert All physical door and lock actions are simulated in this prototype.

  1. What We Learned One of our most important learnings was that AI should not be responsible for every decision in a security-sensitive system.

A large language model is useful for:

Understanding natural language. Extracting visitor claims. Identifying possible risk indicators. Generating concise explanations. Structuring unorganized visitor information. However, authorization decisions should be handled by deterministic rules, validated data, and human approval where necessary.

This led us to design GuestVerify around the following principle:

AI interprets. Policies authorize. Humans remain in control.

We also learned the importance of:

Structured AI outputs. Schema validation. Confidence handling. Explicit risk states. Fallback behavior when an AI model is unavailable. Clear audit trails for security decisions.

  1. Challenges We Faced 6.1 Model Access and Availability Different Amazon Bedrock models can have different availability and access requirements depending on the AWS account and region.

To make the application more reliable, we designed the Bedrock integration to use a configurable model and added a demo fallback for testing.

6.2 Preventing Unsafe Automation A system that blindly opens a door based only on speech could be easily manipulated.

We addressed this by separating Bedrock claim extraction from the final policy decision and using explicit security states:

APPROVED_EXPECTED NEEDS_OWNER_CONFIRMATION DENIED_UNKNOWN DENIED_SUSPICIOUS 6.3 Making Technical Reasoning Understandable Security systems can easily become confusing dashboards. We focused on showing the complete decision journey in a clear visual flow:

Ring event → Claim extraction → Schedule matching → Policy evaluation → Simulated action → Audit record This allows users to understand not only what decision was made, but also why it was made.

6.4 Simulating Real-World Integration Responsibly The prototype uses a Ring-compatible event simulator rather than controlling a physical lock.

This allowed us to demonstrate the complete workflow safely without making claims about unauthorized or unsafe real-world access control.

  1. Future Possibilities Future versions of GuestVerify could include:

Direct integration with authorized Ring event workflows. Voice responses through the doorbell. Mobile notifications. Multiple household members and approval roles. DynamoDB-based schedule storage. CloudWatch monitoring. Secure smart-lock integrations. Multilingual visitor conversations. Stronger identity verification using additional authorized signals. More advanced household and service-provider scheduling.

  1. Final Summary GuestVerify demonstrates how smart-home events, Amazon Bedrock, and deterministic security policies can work together to make visitor decisions safer, more understandable, and more accountable.

The system does not give an AI unrestricted control over a physical door. Instead, Bedrock helps interpret the visitor’s claims, the schedule provides context, deterministic policies evaluate the situation, and homeowners remain in control of sensitive actions.

Built With

Share this project:

Updates

Submission history