SEQSEAL — A checklist that can see

Every box is checked. Release is still locked. SEQSEAL uses Ring evidence to verify the real-world sequence and unlocks Release only when the protocol holds.

Comment

Inspiration

A receiving checklist records that each step happened, not in what order. At a loading dock, Arrival → Storage → Staging means the goods were put away before they went through staging, and every box on the checklist is still ticked. Cameras already watch these docks. We wanted the checklist to use what they observe: a checklist that can see, and that lets the workflow proceed only when the physical sequence is right.

What it does

SEQSEAL turns Ring events into evidence and verifies a physical workflow against a declared protocol.

  • The checklist. Two deliveries go through the same five steps: Arrival, Staging, Storage, Departure, Clear. Delivery A did them in order, and Release delivery unlocks. Delivery B stored the goods before staging them: every box is checked, but Release stays locked with Wrong order (ORDER-02).
  • Ring as the eyes. Each step is bound to a Ring event: its event id, its Ring request id and its start time. In the demo, the footage is simulated by the Ring Developer Playground. Because the Playground does not classify the footage, the operator binds each newly captured Ring event to its simulation (Vehicle, Package, Motion) and dock zone. The operator never chooses the verdict or the action: the sequence verification and RELEASE or HOLD are computed automatically from the captured Ring event timestamps.
  • A deterministic verdict. The expected process is a PWPS protocol (IDP-01): required steps, order rules such as ORDER-02 (Staging before Storage) and time windows. The Sequence Integrity Engine returns SEALED, DEVIATED, INCOMPLETE or UNCERTAIN. No model decides.
  • A separate action. A versioned action policy maps the verdict to an action: SEALED → RELEASE, DEVIATED → HOLD, INCOMPLETE → WAIT, UNCERTAIN → REVIEW. The Operational Gate then moves the receiving workflow and emits WorkflowReleased or WorkflowHeld.
  • A receipt. Every final decision produces a SeqSeal Receipt: protocol, policy, evidence set and decision, each with its hash, plus an explanation chain built without any model. Replay verification runs it again and finds the same verdict and the same action.
  • AI proposes, never releases. When metadata is not enough, an interpreter may propose evidence. Ambiguous evidence goes to REVIEW; a supervisor confirms the evidence, never the outcome, and the engine re-evaluates.

How we built it

  • TypeScript monorepo with pnpm, zod contracts at every boundary, and Vitest.
  • PWPS 0.1, our open-source Physical Workflow Protocol Specification: JSON Schema, validator, canonical hash, compiler, reference evaluator, CLI and conformance suite.
  • Ring integration. A Ring API client (devices, device event history), Playground captures that carry their provenance, and a guided command that runs a whole delivery live: it says which simulation to click, waits for the Ring history event and sends it to SEQSEAL. Ring webhook verification (HMAC-SHA256 over the raw body) and JSON:API parsing are implemented and tested.
  • One event-driven pipeline, two runtimes. The same code runs in-process for local demos and on AWS: API Gateway, 13 Lambda functions behind EventBridge and SQS, DynamoDB, S3, Secrets Manager, KMS and CloudWatch, deployed with Terraform (172 resources). The functions that decide carry an explicit deny on Amazon Bedrock.
  • A Next.js console that runs on either backend.
  • Checks. 203 tests, including one that reads the Terraform and replays every flow against the IAM grants, and one that delivers events in parallel as AWS does; a 32-scenario benchmark with a release gate.

Challenges we ran into

  • Ring sees, but does not classify, Playground footage. Playground history events are on_demand with empty cv_detections. We never claim that Ring detected a vehicle: the operator declares each step's source and zone, and the evidence drawer says so.
  • No API to pick the simulation. Each step needs a click in the Playground. Our guided command only accepts a Ring event that started after its instruction, which prevents duplicate and early captures.
  • Short tokens and slow history calls. Playground tokens last about 30 minutes, and some history calls took 10 s or more. The capture tool reads the token's expiry and keeps polling.
  • At-least-once delivery on AWS. The first deployment gave the right verdicts, but four receipts for two deliveries: parallel finalizations each produced a final decision. A finalization lease (a DynamoDB conditional write) and a rule that an unchanged outcome is not an amendment fixed it, and a test now delivers events in parallel.
  • Honest provenance. Live, replayed and test data must never be confused. Every screen labels its source: Ring Developer Playground, Ring-derived replay or Test fixture.

Accomplishments that we're proud of

  • Same events, different order, different action, live. On October 21, both deliveries ran live through the Ring Developer Playground and were processed on AWS: A was released, and B was held because Storage came 49 s before Staging. That is the run in the video.
  • On our defined benchmark of 32 constructed scenarios: 0/21 false RELEASE, 0/21 false SEALED, 32/32 receipts replayed to the same verdict and action, and 100/100 runs of A released and of B held.
  • AI cannot release, by construction. Its output schema has no verdict or action field, and IAM denies Bedrock to the functions that decide.
  • PWPS stands on its own as an open-source specification with a conformance suite.

What we learned

  • Presence is not process: the order and timing of the steps is the signal that matters.
  • At-least-once delivery makes "one outcome per delivery" a design property, and only tests that deliver in parallel prove it.
  • Keeping AI on the evidence side, and decisions deterministic and replayable, makes a system easier to trust and to audit.

What's next for SEQSEAL

  • Production Ring webhooks through a registered Ring app: the endpoint and the signature check are ready.
  • Several deliveries at the same dock at once (today: one active delivery per lane).
  • A measured run of Bedrock evidence interpretation for ambiguous footage.
  • More PWPS protocols beyond inbound receiving, such as equipment hand-offs, returns and caretaking routines.

Built With

Share this project:

Updates

Submission history