Resolved after two independent captures, and labelled honestly: verified on Ring API emulator captures, not genuine Ring evidence
Obstruction observed: estimated 65 cm clear vs the household's 91 cm need. Incident opens. (Ring API emulator, not Ring footage)
Real test run: Ring v1.1 webhook, evidence-origin isolation, emulator end-to-end, retry and recovery tests all passing.
Full backend suite: 136 passed, 1 skipped (real-photo set not yet available). Output copied verbatim from the run.
Signed Ring v1.1-format webhooks → WHEP/WebRTC capture → analysis. Each event shows an explicit outcome and its linked observation.

ClearWay AccessGraph — Prove the Way Is Clear

Beyond package detection. Beyond smart alerts. Beyond assumed resolution.

ClearWay is an accessibility-aware spatial intelligence and Proof-of-Clearance system that transforms camera observations into personalized geometric decisions, authorized human intervention, and independently checked outcomes.

Our core idea: A camera can tell you a package arrived. ClearWay asks whether you can still leave your home—and refuses to call the problem solved without fresh evidence.

Inspiration

What if a ₹500 parcel could become a barrier to someone's independence?

Imagine a person using a wheelchair or walker. Their doorbell detects a delivery. A parcel is sitting outside the entrance, and the camera successfully sends a notification.

The camera worked. But the accessibility problem remained invisible.

The notification cannot tell whether that parcel blocks the particular route the resident depends on. And even if a family member comes to move it, the system has no reliable way of establishing whether the correction actually restored sufficient clearance.

That exposed three gaps we wanted to solve:

1. The personalization gap: Traditional event detection identifies what is in a scene, not what the scene means for a specific resident's mobility needs.

2. The action gap: A notification doesn't coordinate an accountable, authorized response.

3. The verification gap: Someone attempting a fix doesn't prove the physical problem was resolved.

We set out to explore a different category of connected-camera application: an accessibility intelligence layer that connects observation, consequence, intervention and verification.

Our guiding question became:

What if the next generation of smart cameras didn't just detect events—but helped people understand their impact and verify the outcome?

That is how ClearWay AccessGraph began.

What it does

Seven interconnected engineering innovations. One closed-loop system.

ClearWay is not a generic package detector with an LLM attached. It is a functioning spatial-analysis and incident-verification prototype that links actual geometric computation with event processing, human authorization and auditable evidence.

Innovation 01 — AccessGraph: The Personalized Spatial Twin

One camera image. Different households. Different accessibility decisions.

Residents configure the geometry that matters to them:

Their essential entrance route
Their preferred parcel-delivery zone
Floor-reference points and measured coordinates
A household-specific minimum clearance requirement

For example, consider an observed clearance of 65 cm.

For a household configured with a lower clearance requirement, the estimated passage may be adequate. For a resident requiring 91 cm, the same estimated width triggers a potential-obstruction assessment.

The scene hasn't changed. The resident's requirements have. Therefore, the decision changes.

This is AccessGraph's central innovation: context-aware spatial reasoning instead of one-size-fits-all object detection.

Innovation 02 — Ground-Contact Vision: From 2D Pixels to Estimated Physical Clearance

Bounding-box overlap is not the same as a blocked path.

ClearWay implements a calibrated computer-vision pipeline using:

OpenCV homography → ground-contact estimation → vertical-edge filtering → Shapely polygon geometry → clearance estimation.

Four measured floor-reference points allow image coordinates to be projected onto a ground plane.

Instead of assuming every pixel occupied by an object represents floor obstruction, ClearWay estimates the object's ground-contact edge. It uses geometry derived from the floor homography to help identify elevated vertical edges that could otherwise create false obstruction estimates.

The system then constructs an estimated footprint, intersects it with the resident's marked route and evaluates the remaining clearance.

It also uses ORB feature matching and RANSAC to detect potentially invalid camera calibration after displacement.

If ground contact or calibration is unreliable, the result can be UNABLE TO VERIFY rather than a fabricated centimeter measurement.

This is interpretable geometric computer vision, not an opaque model pretending a single camera has perfect depth perception.

Innovation 03 — Uncertainty Intelligence: 160 Ways to Challenge Every Decision

We didn't want ClearWay to simply calculate a number. We wanted it to challenge its own conclusion.

A small change in segmentation, unseen object depth or floor calibration can alter estimated clearance.

So ClearWay runs 160 perturbation-based remeasurements to test the sensitivity of its spatial decisions.

It checks whether plausible geometric changes support the same conclusion or produce conflicting outcomes.

The result is reported as Perturbation Agreement, not a calibrated probability of physical safety.

When evidence is insufficient, ClearWay explicitly responds with:

REVIEW REQUIRED or UNABLE TO VERIFY.

Unexplained image changes, poor visual quality, unreliable ground contact, missing reference detail and invalid calibration prevent unjustified all-clear decisions.

Our design principle: The most trustworthy answer is sometimes an honest refusal to guess.

Innovation 04 — Counterfactual Clearance Planner

Most detectors tell you what is wrong. ClearWay computes what might improve it.

The Counterfactual Planner explores alternative object placements using the configured route, delivery zone and clearance requirement.

It can visualize:

CURRENT POSITION → PROPOSED RELOCATION → NEWLY OBSERVED POSITION

The planner prefers possible placements that reduce route overlap while respecting the designated delivery region.

Crucially, the proposed position is treated as a simulation, not evidence that anyone has physically moved the object.

ClearWay never confuses a recommendation with an accomplished intervention.

Innovation 05 — Human-in-the-Loop Authorization

The system can identify a possible problem, but a person controls the response.

ClearWay prepares an assistance request and requires an authenticated household approver before the request can be authorized.

It implements distinct household and approving-member credentials, authorization checks, and an auditable history of decisions.

The current prototype uses a clearly labeled simulated local helper inbox rather than claiming live SMS or email dispatch.

No automatic door unlocking. No facial recognition. No unapproved physical intervention.

AI proposes. People authorize. Evidence determines the outcome.

Innovation 06 — Proof-of-Clearance: Our Signature Breakthrough

An attempted correction is not a verified correction.

This is the most important part of ClearWay.

In our working demonstration, an obstacle reduces estimated passage width to 65 cm, below the configured 91 cm requirement.

ClearWay opens an incident and prepares an approved assistance workflow.

First correction: 65 cm → 79 cm.

The object has moved. The situation has improved.

But 79 cm is still below 91 cm.

A conventional notification workflow might consider the intervention complete.

ClearWay refuses.

PARTIALLY RESOLVED. INCIDENT REMAINS OPEN.

Following another correction, newly captured evidence indicates that the marked route is no longer visibly obstructed.

Still, one clear-looking frame isn't automatically enough.

For live-style verification, ClearWay requires two independent clear observations from separate capture sessions, subject to chronology, quality, calibration and provenance requirements.

Only compatible, trustworthy evidence can support automatic incident closure.

This transforms the product from event detection into a closed-loop outcome-verification system.

Innovation 07 — EvidenceGraph: Every Decision Has a Verifiable History

Why did the system open this incident? Why did it refuse the first correction? What evidence supported the final result?

ClearWay's EvidenceGraph connects observations, spatial calculations, approval decisions, incident transitions and verification outcomes.

A per-household SHA-256 hash-chained, append-only ledger preserves an inspectable history.

The interactive "Why this decision?" interface exposes the measurement and evidence associated with each important state transition.

ClearWay also enforces distinct evidence origins:

Genuine Ring
Ring API emulator
Synthetic render
Independent test footage
Recorded replay

Replay or emulator footage cannot automatically close an incident established using genuine Ring evidence.

Duplicate images, stale observations, calibration changes and incompatible origins are handled explicitly.

A different image hash is not proof of a new physical event. A later timestamp is not proof of trustworthy evidence.

This is our interpretation of explainable, provenance-aware physical-world intelligence.

How we built it

A full-stack system spanning computer vision, geometry, real-time protocols, reliable event processing and interactive visualization.

We built ClearWay as an integrated engineering system rather than disconnected demonstration screens.

Stage 1 — Ring-compatible event ingestion

Our Python Ring adapter implements the publicly documented integration patterns:

OAuth token-refresh workflow
Device discovery and capability inspection
Signed v1.1-format motion webhooks
Device identification through data.attributes.source
Server-side WHEP/WebRTC streaming using aiortc
SDP offer/answer handling and video-frame decoding
Snapshot support and explicit streaming-session deletion

Webhook payloads are persisted and processed using an idempotent workflow with retry handling, processing leases and startup recovery.

Stage 2 — Computer-vision processing

The backend uses OpenCV, NumPy and Shapely for calibrated change detection, shadow suppression, footprint estimation and geometric clearance analysis.

The engine examines object contact with the estimated ground plane, not only image-space bounding boxes.

Stage 3 — Uncertainty and counterfactual evaluation

The pipeline performs 160 geometric perturbations, applies conservative classification gates and evaluates alternative placements through polygon-based reasoning.

Stage 4 — Evidence-aware incident orchestration

A deterministic state machine distinguishes obstruction assessment, authorized assistance, partial improvement, uncertain rechecks, verified observations and manual overrides.

SQLite stores observations, spatial configurations, incident history, authorization decisions and evidence-ledger records.

Stage 5 — Interactive control center

We built a React and TypeScript interface using Vite, Tailwind CSS, Konva and TanStack Query.

The application includes:

Household-specific Spatial Twin
Interactive route calibration
Annotated camera evidence
Counterfactual Planner
Incident dashboard
Ring integration interface
Approval workflow
Proof Ledger
Live server-sent updates

Stage 6 — Reproducible engineering

The project includes Docker Compose environments, an automated test suite, synthetic evaluation scenarios, security regressions and a local Ring API emulator.

Our v2.3.1 release report documents 136 passing automated tests and one skipped real-photo evaluation test.

That includes documented tests for webhook parsing, WebRTC emulator integration, token refresh, provenance isolation, approval security, incident recovery and evidence integrity.

The Ring-compatible integration has been exercised end to end against our own custom Ring API emulator. We have not yet completed a genuine Ring Developer Playground session.

The key engineering achievement: Real incoming test events drive real frame processing, geometry calculations, authorization and state transitions—not pre-scripted result screens.

Challenges we ran into

Challenge 1 — Reproducing Ring Integration Without Genuine Playground Access

Our development environment lacked credentials and network access for a genuine Ring Developer Playground session.

Instead of presenting mocked UI interactions as real Ring calls, we implemented a Ring API emulator capable of exercising documented OAuth behavior, device discovery, signed webhook delivery, WebRTC streaming and session cleanup.

This allowed us to test the complete application workflow using real HTTP and WebRTC connections to our own emulator.

We kept every emulator-produced observation explicitly labeled RING_API_EMULATOR.

This proves our local integration flow, while leaving genuine Ring interoperability as an acknowledged validation milestone.

Challenge 2 — Our Emulator Initially Repeated a Real API Parsing Bug

This was one of our most important engineering lessons.

An early version of the webhook parser read the source-device identifier from the wrong field.

The local emulator repeated that assumption.

The tests passed because the implementation and its simulator were wrong in exactly the same way.

During an independent audit, this incompatibility was discovered.

We corrected the parser to recognize the documented v1.1 payload structure, corrected the emulator, and added signed HTTP-to-observation regression tests.

We learned that a working mock isn't sufficient; an integration test must be checked against the external system's contract.

Challenge 3 — Estimating Real-World Geometry From a Single Camera

A doorbell doesn't provide a perfect three-dimensional reconstruction.

Object height can be confused with ground contact. Shadows can resemble obstacles. Cropped objects hide part of their true footprint. Camera movement can invalidate calibration.

We addressed these challenges through homography, vertical-edge analysis, visual-quality checks, camera-displacement detection and bounded uncertainty.

Where the evidence remains unreliable, we deliberately preserve a review state.

Challenge 4 — Making Evidence Trustworthy Across Its Entire Lifecycle

A photo upload should not acquire Ring authority simply because a caller supplies a Ring-like source label.

A simulated observation should not silently resolve a genuine Ring incident.

A successful authorization should not be interpreted as proof that the helper completed the physical task.

These issues led us to enforce separate provenance categories, authenticated approvals, capture-session independence, event chronology and explicit manual-override semantics.

We turned the incident engine into an evidence-integrity system rather than a notification-status tracker.

Accomplishments that we're proud of

We built more than an accessibility dashboard—we built an inspectable observation-to-outcome workflow.

01 — Personalized Spatial Reasoning

Identical camera frames can produce different assessments according to household-specific route geometry and clearance requirements.

02 — Perspective-Aware Footprint Estimation

ClearWay uses floor-plane calibration, ground-contact reasoning and geometric intersection—not naive bounding-box overlap.

03 — 160 Perturbation-Based Checks

Every spatial judgment can be challenged through controlled geometric variations, with explicit uncertainty and abstention behavior.

04 — Counterfactual Intervention Planning

The application visualizes candidate relocations while ensuring suggestions are never treated as actual physical changes.

05 — Independently Rechecked Outcomes

Our demonstration captures the crucial difference between an improvement and a resolution:

65 cm → 79 cm → new clear observations.

The case stays open when the first correction is insufficient.

06 — Provenance-Enforced EvidenceGraph

Hash-linked evidence, source-origin controls, chronology checks and clear explanations make incident decisions inspectable.

07 — Protocol-Level Engineering

We implemented the Ring-compatible OAuth, webhook and WHEP/WebRTC pathways, with a local emulator for end-to-end testing.

08 — Regression-Hardened Release

Our v2.3.1 release documentation records 136 passing automated tests, following multiple rounds of security, integration and evidence-integrity auditing.

09 — Quantified Synthetic Evaluation

Across 300 configuration-level analyses of 100 synthetic porch scenes, our packaged evaluation reports:

97.5% obstruction precision on evaluated non-borderline synthetic cases
100% recall on the same eligible synthetic evaluation subset
Zero false-clear decisions in that evaluated subset
6.05 cm mean absolute clearance-width error
25.91 cm 95th-percentile absolute width error
Approximately 793 ms median CPU analysis latency

These are controlled synthetic results, not accuracy claims for real Ring footage. The large upper-tail width error is precisely why ClearWay must treat borderline geometry conservatively.

What makes us proudest is that ClearWay does not pretend the first apparently successful action was enough. It waits for evidence that supports the outcome.

What we learned

The hardest part of physical-world intelligence is not seeing something. It is deciding what the observation actually justifies.

We learned five fundamental lessons.

Detection is not understanding. A package's meaning depends on the resident's route, accessibility requirement and spatial context.

A measurement is not a guarantee. Perspective, hidden geometry and uncertain segmentation can make centimeter-level estimates unreliable.

A recommendation is not an action. A counterfactual placement is useful planning information, but not evidence that anything moved.

An action is not a verified outcome. An approved assistance request and a partially improved walkway do not justify closing an incident.

An image is not trusted merely because it is new. Evidence origin, capture method, chronology, calibration and independence matter.

We also learned that simulator fidelity can be as important as application correctness: a convincing local integration test can still conceal a misunderstanding of an external API.

That changed our product philosophy.

Trustworthy systems shouldn't merely explain why they made a decision. They must explain what evidence would change that decision—and when they cannot verify an answer at all.

What's next for ClearWay AccessGraph: Prove the Way Is Clear

Our next milestone is to take the verified local workflow into genuine platform and real-world evaluation.

1. Genuine Ring Developer Playground acceptance

Connect authorized Ring devices, receive actual video through the documented WHEP interface, validate the real event stream and demonstrate complete session cleanup.

2. Real-world vision benchmarking

Evaluate properly sourced real entrance photographs under shadows, occlusion, camera shifts, varied parcel geometry and different lighting. Measure real false-clear and review rates separately from synthetic benchmarks.

3. Stronger spatial perception

Investigate pluggable instance segmentation, improved metric calibration and multi-camera fusion to reduce uncertainty caused by hidden object geometry.

4. Consent-based real assistance channels

Extend the existing authorization workflow to actual messaging integrations and caregiver coordination, with explicit consent.

5. Broader accessibility use cases

Explore shared residential entrances, apartment access routes and other personalized environmental-accessibility scenarios.

Our longer-term vision isn't another camera notification product.

It is an evidence-aware layer for connected environments—one that understands how observations affect people, supports authorized intervention and verifies whether the visible problem was addressed.

Current validation disclosure: ClearWay's end-to-end Ring-compatible pipeline has been tested against our own labeled Ring API emulator, not the genuine Ring Developer Playground. The reported computer-vision benchmarks use synthetic scenes. ClearWay is not a certified accessibility measurement or physical-safety system.

Source code: https://github.com/navyaa14/clearway-accessgraph