My condo flooded twice in seven months. In my test, Ring's camera saw the water and recorded nothing, so I built the app that makes it record.

Two floods, and two phone videos

My condo flooded on December 5, 2025, from a badly sloped drain pipe and a toilet leak. I rebuilt. On June 20, 2026, one week after the repairs finished, the city sewer backed up into more than 60 units, and in mine water also came in through the foundation, gaps beside the electrical panel and a basement window. The mitigation company's report said heavy rain, and floated my backyard shed as the cause. The only reason that didn't stick was two phone videos I took while it was happening, because I happened to be home. Whether that water was sewer backup or clean rainwater decided which coverage limit applied. Next time I won't be home.

Ring already knows. It just doesn't record.

A Ring Flood & Freeze sensor tells your phone there is water. What it does not do is make a camera record it. I tested that with my real devices: my sensor in a bowl, my Indoor Cam pointed at it, water poured in slowly. The Ring app alerted at 8:35 PM. Its own event history shows nothing after 8:27, and still nothing at 8:38. Slowly rising water does not trip motion detection, so the one camera that saw it kept nothing. That is the gap Watermark fills: when the sensor fires, it opens a live session on the camera that already sees the room, which forces it to record, and keeps pulling frames with Ring's own time until the sensor reads dry.

Ring's frames, with Ring's time

Every frame in a pack comes from a Ring Partner API live session, downloaded with Ring's own X-Media-Timestamp burned in, and any frame further than Ring's documented 10 s tolerance from the request is flagged. Measured on Ring's Developer Playground through the real API, the first frame arrived 6.85 s after the sensor event, median of 10 runs, range 6.6 to 11.2 s. The camera in those runs is the Playground's doorbell, which is why the demo frames show a bird feeder in the snow rather than a basement. Webhooks are written to disk before anything else, because Ring keeps no history for sensor events, and a reconcile loop polls status so a missed webhook can neither start nor end a capture silently.

Amazon Rekognition labels what is in each captioned frame, and the flooring question in the pack cites the floor material it names. I tested it on my own June flood footage first: it labels a film of water on hardwood exactly as it labels the dry floor. So in Watermark it can add "water visible" but never "no water", and the sensor stays the record of wetness. I designed prose captions for Amazon Bedrock and the code is still in place, but Bedrock is blocked on my account in every region I tried.

The pack, against my adjuster's questions

What comes out is one evidence pack a homeowner can print or send: the timeline, the frames, device health, and an integrity section that lists every gap it could not verify. Then it maps itself against the 7 questions my adjuster actually asked on my June claim. On one of the 10 runs (first frame in 6.9 s), it answers 2: when the water started and how long it stood, and where it was, which is the footage that would have settled sewer backup against rainwater. It partly answers 2 more, flooring and contents, where the frames show what was there but the homeowner adds the rest. The other 3 are about the house and the policy, and are mine to answer.

It refuses to name a cause

Cause is what the mitigation report got wrong, so Watermark never states one. The pack's "What this record cannot vouch for" section comes before the claim map: frame labels describe what is visible and are not measurements, the sensor event in these runs is simulated, events learned by polling rather than by webhook are marked, and camera offline windows are reported as gaps. A script, check_claims.py, fails the build if a number in the docs disagrees with the committed runs.

ringwire, and a pull request to Amazon's sample

For the Open Source challenge I split the Ring client out of Watermark and published it as ringwire, a typed Python client for the Ring Partner API built around the Early Access sensor scope: sensor status with flood, freeze, contact and tamper state, the sensor webhooks with HMAC verification, chime playback, WHEP live sessions, the two-step media downloads and the account-linking nonce. It encodes three traps in Ring's sensor docs so callers cannot fall into them: the never-reported 1970 epoch becomes None, tamper reads "detected" rather than "faulted", and the reporting state is never treated as liveness. I also opened a pull request to Amazon's ring-api-helloworld adding sensor_status.py, the sample's first script that reads a sensor. Every one of the 10 measured runs went through ringwire.

What is not claimed

The timing is graded by Ring's own timestamps and the ablation by the Ring app's own history, not by my code, but the scope is narrow. The 10 measured runs used a simulated sensor event and the Playground's doorbell, not a flooded basement; the bowl test used my real sensor and camera, but it was a controlled test, labelled as one, with water poured in slowly. The claim map is scored against one claim's questions, mine. The printed rover that would carry the camera to a room no fixed camera covers has its code and its AWS IoT Core dispatch in the repo (a flood event reached it through IoT Core and it reported on station 7.7 s after the sensor, with the drive simulated), but it has not driven on a real floor, so it is not in the demo. Chime playback works through the API but the Playground has no chime, so the demo does not show it. And Watermark never says what caused the water; that stays with the adjuster.