BOUNDARY

Inspiration

Home-service visits create a basic information asymmetry: a technician may recommend an action, while the homeowner may have little ability to verify why that action is justified.

BOUNDARY was built around a simple principle: proof is not permission.

The goal is to make consequential home-service decisions explicit, evidence-bound, human-authorized, and auditable.

What it does

BOUNDARY turns a service visit into a structured decision chain:

observation → claim → evidence → authorization → expected outcome → observed result → record

It separates what was observed from what was claimed, and evidence from permission.

Before an action is authorized, BOUNDARY records the supporting evidence and freezes an observable success criterion. After the work, it compares the observed result with that expectation and preserves the complete decision trail.

Ring provides an external evidence source in this workflow. BOUNDARY retrieves Ring Event History through the Ring API and preserves the event semantics exactly as returned by the platform.

During the final Playground test, Ring returned the session as on_demand, not motion. BOUNDARY retained on_demand rather than upgrading the evidence into a stronger claim.

How we built it

BOUNDARY combines:

• a deterministic Python policy core
• persistent SQLite records
• an MCP server using Streamable HTTP
• a browser-based interface
• a live Ring API / Event History integration

The Ring path supplies evidence to the same decision workflow used by the rest of BOUNDARY.

A Ring event can support a decision, but it never becomes authorization by itself. Consequential actions remain explicitly human-controlled.

Challenges we ran into

The hardest problem was preserving evidentiary precision across the full workflow.

During Ring Playground testing, the simulated interaction appeared motion-like, but Event History returned the session as on_demand. Treating it as motion would have claimed more than the API actually established.

BOUNDARY therefore preserves the returned value exactly.

Repeated Ring Playground testing also exposed friction around temporary authentication tokens and token regeneration, which we documented separately in our submission feedback.

Accomplishments that we're proud of

We built a complete working chain rather than a standalone demo screen:

claim → evidence → owner authorization → predicted result → actual result → auditable record

We also integrated the live Ring developer path without silently strengthening the evidence returned by the API.

Most importantly, BOUNDARY keeps evidence and authority separate: having evidence that something happened does not automatically grant permission to act.

What we learned

The most important lesson was that trustworthy automation requires more than recording events.

Claims, evidence, authorization, predicted outcomes, and actual outcomes need to remain distinct objects.

That separation makes the system easier to audit, easier to explain to a homeowner, and harder to misuse through implicit assumptions.

What's next for BOUNDARY

The next step is to extend BOUNDARY to additional home-service workflows and additional evidence sources while preserving the same core rule:

claims, evidence, authorization, predicted outcomes, and actual outcomes remain separately recorded and auditable.

Built With

• html
• javascript
• mcp
• python
• ring-api
• ring-developers-playground
• ring-event-history
• sqlite
• streamable-http