Preflight

See the failing branch before asking the carrier to dial. Preflight checks Vonage call flows, holds uncertainty, and records the decision separately from placement.

Comment

Inspiration

A voice flow can look correct at its greeting and still lose an important step when someone does not press a key. I built Preflight for developers who need to see that failing branch before asking the carrier to dial, rather than discovering it only after a call has started.

The reference application deliberately contains a timeout defect. It is a test application, not a customer deployment or a claim that we discovered misconduct. The goal is a checkable developer loop: inspect the path, correct the flow, and try again.

Lens

Real-World Use: helping Vonage developers inspect a failing callback path and its evidence before trying the corrected flow.

What it does

Preflight sits between a Vonage voice application and the call-control objects its server returns. Outbound requests go through a create-call gateway. A failing structural check blocks forwarding; an inconclusive result holds under strict policy. Passing requests go to Vonage, and the platform response establishes whether placement was accepted.

Signed answer and branch callbacks check the flow after placement. These are different boundaries: changing webhook URLs alone cannot prevent dialing. The cockpit shows decisions, witness paths, observed flow coverage, held requests and an evidence log. A named human release can permit uncertainty without pretending the underlying monitor became true.

How we built it

The TypeScript engine parses Vonage NCCOs and evaluates three-valued temporal monitors: true, false or inconclusive. Five default properties check calling-hours facts, identification structure, an opt-out or human-connection path, and caller-ID presence. They cite selected federal and Georgia provisions, but encode narrower structural checks, not the law itself. No language model decides whether a flow passes.

Fastify handles the gateway and signed callbacks. PostgreSQL stores decisions, call context, release reservations and the hash-linked ledger. The browser checker runs the engine locally. Vonage Voice API supplies call creation and callbacks; the Client SDK and Users API support the browser softphone. Carrier-report reconciliation requires successful gateway-placement provenance for an outbound match, rather than treating an answer-time observation as proof of authorization.

What the demonstration proves

In the September 8 gateway recording, the defective flow received HTTP 409 with a P3 witness. Across a 60.183-second observation window, the stored signed-webhook count stayed at 193. The corrected-flow request then received HTTP 201 and a call UUID, with matching signed events and passing ledger decisions. This is evidence for that controlled run between account-owned numbers, not a guarantee about every call or proof that a personal phone stayed silent.

The physical iPhone footage is separate, silent visual evidence of an SDK call. Audible product speech comes from a separately labelled browser call. The iPhone notification is a real test push, not proof of automatic held-call delivery while closed. Android is a labelled browser-emulator still, not a physical-device test.

Challenges and lessons

The answer callback arrives too late to provide pre-dial enforcement, which required a separate gateway. Another challenge was ordering: an answer can arrive before the create-call response. Release correlation and replay protection must preserve that legitimate call without transferring approval to an already answered UUID. We also learned to separate placement receipts from subsequent decisions, and internal hash consistency from independently anchored history.

Try it and next steps

The public site includes a browser checker, with no account needed for that surface. The published CLI, [email protected], checks objects, replays the corpus and verifies ledger hashes. A recorded clean-directory check reproduced all 48 corpus labels and verified a 115-entry ledger snapshot.

Next I would expand real-flow coverage and validate more device paths. Current coverage is limited to observed branches and declarations. The checker cannot establish consent, exemptions, truthful speech or actual suppression handling. Optional Verify was not physically tested for this demonstration, and no Identity Insights result is claimed as its evidence. Preflight is a structural debugging tool, not legal advice or a compliance guarantee.

Links and verification

Verify the public evidence log without credentials:

npx -y [email protected] verify-ledger https://preflight-api-rc34.onrender.com

The cockpit and push subscription controls require a dashboard token; the public checker and summary do not.

Built With

Share this project:

Updates

Submission history