WITNESS

WITNESS: Evidence and Integrity for Ring Events

Inspiration

Connected devices can produce observations that are difficult to interpret when information is missing, delayed, duplicated, or inconsistent. A device disappearing from an observation is not necessarily the same as a device being offline, and an unsuccessful request does not automatically mean something has changed on the device.

We built WITNESS around a simple question: How can a connected-device integration explain what it actually knows, show the evidence behind its conclusions, and avoid claiming more than the evidence supports?

The goal was to explore a more trustworthy approach to device monitoring. Instead of treating every missing observation as a definitive state change, WITNESS evaluates observations over time, preserves supporting evidence, and communicates uncertainty explicitly.

What We Built

WITNESS is an evidence-oriented integration for Ring. It connects to the Ring Partner API through authenticated, read-only requests and provides a framework for evaluating device observations and detecting inconsistencies in recorded evidence.

The project focuses on four capabilities:

Evidence-based observation: Records observations and evaluates them over time rather than relying on a single missing response.
Explicit uncertainty: Distinguishes observed facts from interpretations, incomplete information, and unverified assumptions.
Tamper detection: Uses a hash-linked evidence ledger to help identify modifications to recorded evidence.
Scenario testing: Exercises difficult event-processing cases, including device disappearance, configuration and encryption transitions, duplicate deliveries, and late or out-of-order observations.

These capabilities are designed to make the integration's behavior easier to inspect and its limitations easier to understand.

How We Built It

We developed WITNESS as a software project with separate components for integration, observation processing, evidence storage, and demonstration.

The Ring integration uses authenticated API requests to retrieve available device information and related configuration or event-history data. The observation-processing logic evaluates incoming information, while the evidence ledger preserves records that support later inspection and integrity checks.

We also built automated tests and controlled scenarios to examine cases that are difficult to reproduce consistently against a live service. These scenarios help us test how the system responds to missing observations, duplicate events, changes in configuration, and events that arrive out of order.

A key design decision was to keep live integration evidence separate from simulation results. The demonstration identifies which operations contact the Ring Playground and which scenarios use scripted inputs. This distinction helps viewers evaluate the implementation without confusing a simulated result with a real device event.

Live verification: We successfully authenticated with the Ring Playground API and retrieved device information, including one synthetic Playground device. Configuration retrieval and event-history retrieval were also verified during integration testing. The Playground returned no events during the reported event-history check.

Simulation coverage: Device disappearance, configuration and encryption transitions, duplicate delivery, and late or out-of-order event arrival were exercised through explicitly labelled simulations. These scenarios demonstrate tested behavior; they are not claims of observed live Ring events.

Challenges We Faced

Separating Missing Data from Actual State Changes

One of the central challenges was avoiding assumptions based on incomplete information. A failed request, an empty response, and a device missing from an observation can have different explanations.

We addressed this by designing around evidence and uncertainty rather than treating every absence as a definitive event. This makes the system's conclusions more cautious and easier to investigate.

Working with Limited Live Playground Data

The Ring Playground provided a real integration environment, but the available dataset was limited to a synthetic device and no returned events during the verified event-history check. This made it impossible to demonstrate every event-processing scenario using live Ring-generated events.

We therefore combined genuine, authenticated, read-only integration footage with clearly labelled simulations. This allowed us to demonstrate both real API connectivity and the system's behavior under additional test conditions without misrepresenting either.

Preserving Evidence Integrity

An evidence ledger is useful only if its integrity properties are explained accurately. Hash linking can help reveal changes to recorded entries, but it does not make a database immutable or guarantee detection of every possible attack.

We treated this limitation as an engineering consideration rather than making absolute security claims. WITNESS demonstrates tamper detection while acknowledging that a complete ledger rewrite may not be detectable by local checks alone.

Testing Difficult Event Sequences

Duplicate deliveries and out-of-order observations can complicate event processing. Similarly, changes in configuration or encryption status require careful interpretation rather than assumptions based on a single observation.

We used automated tests and scripted scenarios to exercise these cases repeatedly. This provided a controlled way to evaluate behavior even when equivalent live Playground events were unavailable.

What We Learned

Building WITNESS reinforced several important lessons:

Evidence is more valuable than unsupported certainty. Systems should communicate what they observed and what remains unknown.
Integration success and feature completeness are different things. Successfully calling an API does not prove that every downstream scenario has been validated against live data.
Simulations are valuable when labelled honestly. They allow repeatable testing of edge cases without pretending those cases occurred in production.
Integrity guarantees need clear boundaries. A tamper-evident ledger is not the same as immutable storage.
Negative results are still evidence. An empty event-history response describes what the API returned during that check; it does not establish that no event could ever occur.
Reliable engineering includes testing failure conditions. Database safety, request failures, duplicate inputs, and incomplete observations deserve as much attention as the successful path.

Perhaps the most important lesson was that a trustworthy system must make its limitations visible. We would rather report a verified capability with a clear boundary than claim a broader capability that we cannot substantiate.

What's Next

Further work could include testing against a wider range of authorized Ring Playground scenarios, strengthening evidence retention and recovery, and adding independent verification mechanisms for the ledger. Additional live testing would also help validate how the system behaves when real event sequences become available.

These are future validation and development opportunities, not capabilities we claim are already complete.

Conclusion

WITNESS explores a practical principle for connected-device software: observe carefully, preserve evidence, and communicate uncertainty honestly.

By combining a real Ring API integration, an evidence-oriented design, automated testing, and clearly separated simulations, the project demonstrates an approach to making device observations more transparent and accountable.

Built for the Amazon Developer Hackathon 2026 — Ring track.

Source code: https://github.com/itzebe/WITNESS