Attest

What Attest does

When a household and a worker disagree about a home visit, the coordinator has to work through doorbell activity, check-in times and separate accounts of what happened. Attest puts those sources in one record so each person can see and respond to the same information.

The worker can acknowledge or dispute the record. The household has its own view, and the coordinator can add a conclusion. Later statements and corrections are added to the history without replacing earlier ones. A signed export lets someone check the record outside Attest.

The workflow

1. Collect Ring events and snapshots alongside the scheduled visit, check-in and polling coverage.
2. Read the worker's account, the household's account and the recorded events side by side.
3. Record the coordinator's conclusion while keeping the original accounts and later corrections.
4. Export the case pack and verify it in a browser or with Python. Compare exports to see what was added, changed or removed. Media can be withheld while its signed digests stay in the pack.

Doorbell activity alone cannot establish who was present. The signature checks whether the exported record is intact; the people reviewing the case still have to decide what happened.

The video and public demo

The 1:53 video shows genuine browser screenshots from the local integrated-v2 version, using one simulated visit. The worker and household forms were submitted in the browser; the coordinator's conclusion and export were prepared through the API. Its clean pack verifies successfully. Changing observed_span_minutes from 0 to 70 makes verification fail and the comparison identifies that field. This version is still local.

Open the public demo, verify the clean pack, then try the altered pack. Compare them to see the changed field: observed_span_minutes goes from 65.25 to 135.25.

That public demo is the earlier a7d23b0 release, with a different sample case. Its product screens use simulated visit data; pack verification runs in the browser. The release CI results below apply to a7d23b0.

How it works

• Python, FastAPI and SQLite handle ingestion, visit records and review history. A durable inbox handles duplicate and delayed events. Polling coverage records when the system was watching, so a quiet period can be distinguished from a gap in observation.
• The Ring client supports event history, snapshots, device discovery and signed webhooks. Token refresh and retry handling are implemented. The client limits response sizes and avoids forwarding credentials to media redirect destinations.
• Ed25519 signatures, payload hashes and chained receipts protect the exports. A chained mutation journal records store changes, and separately retained checkpoints provide a reference outside the deployment.
• The AWS integration code includes KMS signing-key wrapping, S3 checkpoint publishing and a Lambda pack verifier. The Lambda verifier runs separately from the code included in a case pack.
• Bedrock summary generation and a Strands agent for weekly triage are implemented. The captured workflow used template output and made no external provider calls. Fresh model inference still needs verification.

What was tested

• The emulator-backed pipeline was exercised from ingestion through visit matching, snapshots, signed receipts, review history and offline verification.
• The 15 September Ring Playground run read the user and devices, retrieved event history and a real 68 KB snapshot, and produced a signed receipt from the polling path. The separate signed report from 30 September records five passing probes and three failures.
• Release CI passed on Ubuntu and Windows with Python 3.11 and 3.14: 815 Attest tests passed on Ubuntu, with 7 skipped; 821 passed on Windows, with 1 skipped. Each job also passed 58 companion tests.
• All nine published browser test cases returned the expected results. The browser verifier is also tested against Python-signed receipts.
• The attack demo covers 23 cases: 22 were caught and rolled back; one is a documented detection limit. A duplicate-delivery test reduced ten copies of a signed delivery to one visit and one event.

ring-sandbox

ring-sandbox is the companion open-source project. It provides a typed Ring client, a FastAPI emulator and pytest fixtures so the ingestion and review workflow can be tested without a live device. Its scenarios include normal visits, short visits, no-shows and device outages. It also includes recorded Playground fixtures, webhook signing checks and a recording command. It is MIT-licensed and tested on Windows and Linux with Python 3.11 and 3.14.

Current limits

• Production OAuth refresh has not been verified against the real token endpoint. The implemented refresh and retry path has been tested with the emulator.
• Delivery from the real Ring webhook service has not been verified. The real-service ingestion evidence uses event-history polling. Fresh hardware and WHEP testing also remain unverified.
• The public whole-site check can report success for an invalid manifest and show a previous pack's filename. Its green summary is therefore not a reliable verification result. The current hosted manifest's signature and all 541 artifact hashes were checked separately. The fix is still local, so use the independent signature check.

The repository's FRICTIONLOG.md records the integration problems, workarounds and requested API changes, including token expiry, media redirects and local webhook testing.

Built With

• amazon-bedrock
• boto3
• ed25519
• fastapi
• httpx
• jinja
• pytest
• python
• ring-partner-api
• ring-sandbox
• sqlite