OpenWay — Accessibility Assurance for Ring

OpenWay helps teams detect blocked accessible entrances, coordinate staff responses, and verify restoration with fresh evidence and nine deterministic safety checks. Detection isn't proof of recovery.

Comment

Inspiration

Accessibility should not end when a building installs a wheelchair ramp, an automatic door, or an accessible entrance. Those facilities must remain usable throughout the day.

Imagine someone using a wheelchair arriving at a shopping center, hospital, office, or restaurant, only to discover that delivery boxes have been placed across the accessible entrance. The building may be designed for accessibility, but a temporary obstruction has made that entrance unusable.

Traditional security cameras can detect motion and record footage, but they do not necessarily determine whether an entrance is accessible. Facilities management systems can track maintenance tasks, but they often treat an employee clicking "Completed" as sufficient evidence that a problem has been resolved.

What if we could detect an interruption, coordinate corrective action, and independently verify restoration before declaring the entrance accessible again?

That question inspired OpenWay — Accessibility Assurance for Ring.

We wanted to explore how Amazon Ring's connected-camera infrastructure, AWS cloud services, and deterministic software verification could work together to support a more accountable approach to physical accessibility.

Our central engineering principle became:

Detection ≠ Resolution ≠ Verification.

A problem being detected does not mean it has been resolved. A task being completed does not mean restoration has been independently verified.

OpenWay was built around that distinction.

What it does

OpenWay is an accessibility assurance platform designed to help facilities teams manage temporary physical barriers affecting accessible entrances.

It combines a deterministic restoration-verification engine, an interactive operator workbench, AWS infrastructure, and independently verified integration with the official Amazon Ring Developer Playground.

1. Detect accessibility interruptions

OpenWay demonstrates how visual observations can identify obstructions such as delivery parcels blocking a wheelchair ramp or objects preventing access through an entrance.

In the current public demonstration, these accessibility observations are generated by a deterministic simulator. This makes the scenarios reproducible without requiring physical hardware or exposing real visitor footage.

When an interruption is identified, the entrance transitions into an actionable state.

2. Coordinate staff remediation

The system creates remediation tasks associated with the affected venue and entrance.

Facilities staff can inspect the interruption, perform corrective work, and report completion using the OpenWay Assurance Workbench.

Each step is recorded alongside the relevant operational state and evidence history.

3. Refuse premature restoration

When staff report an obstruction as removed, OpenWay does not automatically declare the entrance accessible.

Instead, the entrance transitions to RECHECKING.

This prevents an employee's self-report from being treated as independent proof that a physical condition has changed.

4. Require fresh evidence

OpenWay requires new evidence captured after remediation is completed.

Its temporal verification logic enforces:

capturedAt >= completedAt

Evidence collected before corrective action cannot be reused to prove successful restoration.

5. Enforce a nine-point restoration gatekeeper

A deterministic TypeScript policy engine evaluates nine verification conditions:

  1. The entrance is in the appropriate RECHECKING state.
  2. The remediation task is marked COMPLETED.
  3. The evidence capture time is not earlier than task completion.
  4. The evidence matches the correct venue and entrance.
  5. Camera device and component bindings match the expected source.
  6. The evidence satisfies freshness requirements.
  7. Required accessibility conditions are explicitly satisfied.
  8. No contradictory observations exist within the verification window.
  9. Evidence provenance is valid and accurately represented.

Only when the required conditions pass can OpenWay authorize the VERIFIED_RESTORED state.

6. Fail closed when evidence is uncertain

If required evidence is unavailable, stale, contradictory, or insufficient, OpenWay refuses to report successful restoration.

Instead, it transitions to UNKNOWN.

This behavior prevents missing information from becoming an unsupported success claim.

7. Integrate with the official Ring Developer Playground

Beyond the simulated accessibility workflow, OpenWay has successfully demonstrated authenticated integration with the official Amazon Ring Partner API.

Our existing application code verified:

  • Ring device discovery.
  • Device status.
  • Device capabilities.
  • Device event history.
  • WebRTC/WHEP live-video streaming.
  • Secure streaming-session termination.

The final demonstration includes actual video frames delivered through the official Ring Developer Playground and decoded by OpenWay.

Technical distinction: The official Ring Playground video is simulated footage provided by Ring. OpenWay's accessibility-restoration scenarios use separate deterministic simulated observations. We do not claim that official Ring footage has already completed an end-to-end physical-ramp verification workflow.

How we built it

We designed OpenWay as an evidence-driven application with clear boundaries between camera integration, interpretation, deterministic decisions, and cloud infrastructure.

Amazon Ring API Integration

The integration layer uses a server-side TypeScript RingClient and RingPlaygroundProvider to communicate with the official Ring Partner API at https://api.amazonvision.com.

Using authenticated Ring Developer Playground access, we successfully exercised the official API for device discovery, status, capabilities, and event history.

The implementation processes Ring's JSON:API responses and normalizes device data into OpenWay's internal models.

Verified WebRTC/WHEP Live Video

We implemented Ring's WebRTC HTTP Egress Protocol (WHEP) integration to establish authenticated live-view sessions.

During Phase R3 verification, OpenWay successfully:

  • Created an official Ring WHEP session with HTTP 201 Created.
  • Negotiated an SDP offer and answer.
  • Established an active WebRTC peer connection.
  • Decoded more than 470 actual Ring-delivered video frames.
  • Played video at 1280 × 720 and approximately 30 FPS.
  • Preserved the original Ring watermark.
  • Terminated the upstream streaming session successfully with HTTP 200 OK.

The revised hackathon video demonstrates this verified integration.

Ring credentials are handled server-side. Production WHEP and clip endpoints are disabled by default to prevent unauthorized use of temporary Playground access.

Deterministic Domain and Policy Engine

We implemented the core accessibility assurance logic in TypeScript.

The system manages six states:

AVAILABLE → INTERRUPTED → ACTION_REQUIRED → RECHECKING → VERIFIED_RESTORED / UNKNOWN

A nine-point restoration gatekeeper evaluates evidence independently of the visual observation provider.

AI-generated observations or staff completion reports cannot directly authorize restoration.

The application includes evidence freshness checks, temporal ordering, camera identity binding, contradiction handling, and explicit provenance separation.

AWS Cloud Infrastructure

OpenWay is deployed using AWS Amplify Hosting with Next.js 14, React, and TypeScript.

We use:

  • Amazon DynamoDB: Durable entrance state, remediation tasks, evidence records, and audit history, with conditional writes and transaction-based integrity controls.
  • AWS Amplify Hosting: Production application hosting and deployment automation.
  • AWS Secrets Manager: Secure management of integration configuration and sensitive credentials.
  • AWS IAM: Scoped permissions for application services.
  • Amazon CloudWatch: Operational logging and diagnostics.
  • Amazon Polly Neural: Indian-English demonstration narration using the Kajal voice.
  • Amazon Bedrock Nova Lite: An implemented vision-analysis integration using the Converse API.

Live Bedrock inference remains restricted by an account-level invocation error in the tested environment. The public accessibility demonstration therefore uses an explicitly labelled simulated vision provider rather than implying that live model inference succeeded.

Interactive Assurance Workbench

We created a responsive, accessibility-oriented operator console that brings together:

  • Entrance status and interruption information.
  • Staff remediation tasks.
  • Evidence and provenance information.
  • The nine-point gatekeeper audit report.
  • Chronological event history.
  • Controlled demonstration scenarios.
  • Fail-closed UNKNOWN behavior.

Judges can run the public demonstration without creating an account or supplying Ring or AWS credentials.

Testing and Validation

The final release passed 316 automated tests across 38 test files.

The tests cover deterministic gatekeeper behavior, temporal consistency, stale evidence, tenant isolation, Ring API contracts, WebRTC security boundaries, DynamoDB concurrency, and adversarial failure conditions.

TypeScript type checking, ESLint, and the production build also passed.

Challenges we ran into

1. Moving beyond mocked Ring API integration

Our initial Ring integration implemented the required API contracts but lacked successful authenticated runtime evidence.

We overcame this by using the official Ring Developer Playground with OpenWay's existing server-side integration code.

We verified real API responses for device discovery, status, capabilities, and event history, then progressed to successful WebRTC/WHEP live-video playback.

This was one of our most important technical milestones.

2. Ring media API validation and streaming

Official snapshot download requests returned HTTP 403 errors, including responses identifying missing timestamp fields and invalid request structures.

Rather than misrepresenting that result as successful image retrieval, we documented the limitation and investigated Ring's independent WHEP streaming pathway.

The WHEP integration succeeded and enabled authenticated Ring Playground video playback.

Snapshot retrieval remains unverified.

3. Preventing false restoration

One of our hardest architectural challenges was ensuring that staff-reported completion could not directly authorize restoration.

We built a deterministic gatekeeper requiring new evidence, correct identity bindings, satisfied accessibility requirements, and the absence of contradictions.

This separation between operational action and independently verified outcome became OpenWay's defining architectural feature.

4. Stale cloud state and concurrency

Rapid workflow transitions occasionally exposed stale DynamoDB read results.

We improved consistency using strongly consistent reads on relevant paths, conditional state updates, and monotonic client-side state handling.

These safeguards help prevent older information from overriding newer operational states.

5. Separating official and simulated evidence

Working with Ring's official Playground introduced an important provenance challenge.

Official Ring API responses and WebRTC playback are genuine integration results, but the Playground video scenes are simulated by Ring. Our accessible-ramp obstruction scenarios are separately simulated by OpenWay.

We explicitly distinguish OFFICIAL_RING_PLAYGROUND from SIMULATED_LOCAL to avoid overstating what has been verified.

6. Bedrock model-access restrictions

Although we implemented the Amazon Bedrock Nova Lite adapter, live inference encountered an account-level invocation restriction.

We retained deterministic fallback behavior and documented the limitation instead of displaying simulated analysis as a successful Bedrock response.

7. Protecting live streaming in production

The WHEP testing implementation required server-side session management and secure teardown.

Before production release, we added fail-closed restrictions to ensure that public users could not anonymously initiate Ring streaming sessions using developer credentials.

Accomplishments that we're proud of

Verified official Ring integration

OpenWay successfully communicated with the real Ring Developer Playground API using its own server-side integration code.

Device discovery, status, capabilities, and event-history requests returned HTTP 200.

Genuine Ring live-video interoperability

We established an authenticated WHEP session, decoded more than 470 Ring-provided video frames at 1280 × 720, preserved the native watermark, and successfully terminated the session.

This result is included in the final hackathon demonstration.

A deterministic nine-point restoration gatekeeper

We built a policy engine that distinguishes task completion from verified physical restoration.

It requires appropriate state, fresh evidence, identity consistency, explicit requirement satisfaction, and valid provenance before allowing restoration.

Fail-closed UNKNOWN behavior

OpenWay demonstrates that uncertain evidence does not have to produce an optimistic result.

The system refuses to declare success when required verification conditions are missing or contradictory.

A functional AWS-hosted application

We deployed a working Assurance Workbench with durable persistence, operational workflows, audit information, and repeatable demonstration scenarios.

316 passing automated tests

Our final validated test suite passed all 316 tests across 38 files, alongside type checking, linting, and production-build verification.

Secure and transparent integration boundaries

We documented verified Ring API behavior separately from simulated accessibility testing, secured developer credentials, and disabled production WHEP endpoints by default.

Public open-source release

We published OpenWay under the MIT License with architecture documentation, a judge evaluation guide, setup instructions, reproducible tests, developer friction logs, and Ring integration verification evidence.

What we learned

1. Accessibility assurance requires more than detection.

Identifying an obstruction is useful, but detecting a problem and verifying that it has been resolved are separate engineering responsibilities.

2. Deterministic verification matters when false success is costly.

AI can help interpret observations, but final operational decisions should follow explicit, testable rules rather than model confidence alone.

3. Time and provenance are essential evidence properties.

An apparently clear entrance image is not sufficient if it was captured before the obstruction was removed or came from an unrelated camera.

4. Successful authentication, successful media playback, and verified physical outcomes are different milestones.

Our Ring integration journey made this particularly clear. We progressed from API contract tests to official authenticated requests and finally working WHEP video, while keeping the remaining end-to-end visual-analysis limitation explicit.

5. Safe failure is a product feature.

A system that acknowledges UNKNOWN can be more trustworthy than one that always produces a confident answer.

6. Developer tooling benefits from reproducible evidence.

Sanitized HTTP results, protocol-level verification, automated tests, audit trails, and honest failure reporting make complex integrations easier to review and reproduce.

What's next for OpenWay

1. End-to-end Ring visual evidence integration

Connect authorized Ring camera imagery directly into OpenWay's accessibility-analysis pipeline and validate the complete observation-to-restoration workflow using genuine camera data.

2. Production Ring account linking

Complete the applicable Ring Partner onboarding and authorization requirements to support customer-owned Ring devices.

3. Live Amazon Bedrock inference

Enable and test the Nova Lite vision-analysis pathway with representative physical-accessibility imagery.

Measure detection accuracy, missed obstructions, false positives, and false-restoration behavior rather than relying solely on model confidence.

4. Controlled real-world pilots

Work with facilities operators to evaluate accessible entrances under realistic conditions, including changing lighting, camera occlusions, delayed observations, and incomplete remediation.

5. Proactive staff notifications

Extend the existing remediation workflow with operational notifications and escalation mechanisms for facilities personnel.

6. Broader accessibility coverage

Explore camera-observable disruptions involving accessible doorways, entrance pathways, building approaches, and similar facilities.

7. Open accessibility interoperability

Investigate how verified entrance-state information could complement existing accessibility mapping and navigation systems.

Our long-term goal is to help organizations move from merely providing accessibility infrastructure toward actively maintaining and verifying its usability.

OpenWay — Detection ≠ Resolution ≠ Verification.

Because identifying a problem is not the same as proving it has been fixed.

Built With

  • accessibility-technology
  • aes-256-gcm
  • ai-agents
  • amazon-bedrock
  • amazon-cloudwatch
  • amazon-dynamodb
  • automated
  • aws-amplify
  • aws-iam
  • aws-sdk
  • aws-secrets-manager
  • computer-vision
  • deterministic-state-machine
  • hmac-sha256
  • next.js
  • node.js
  • react
  • rest-api
  • ring-api
  • ring-oauth
  • ring-webhooks
  • tailwind-css
  • typescript
Share this project:

Updates

Submission history