What we measure, and how we know

Every live phone line is probed by an automated canary that grades itself honestly: a line that sat idle for a full day is graded FAIL, not skipped. We would rather show a red square than pretend a quiet day was a good one. We also count our own tool failures and publish the count — a system that never reports a failure is a system that is not looking.

source: D1 event_ledger — canary_run + voice_call + tool_failure classes · grading: idle day = FAIL · live counters render when the aggregation feed is attached; until then, honest “measuring”.

Calls answered, appointments booked, and forms captured — counted from the event ledger over a rolling 30-day window. These are aggregate totals only: no company name, no caller, no per-client breakdown ever appears here. And we hold each counter back until it clears a floor — a number too small to mean anything reads “measuring,” because a tiny count paraded as a milestone would argue against us, not for us.

source: D1 event_ledger — voice_call · booking_created · form_capture classes, trailing 30d · a counter renders only once it clears its display floor · the metric is the receipt: each number ships with its event class and window.

The honest way to know whether an AER agent actually helped is to hold a portion of leads back untouched and compare. That is a holdout: for a client cohort, some contacts are worked by the agent and a matched set is held, and we report the difference — worked versus held — only after a full measurement window closes. We never model the lift, back-fill it, or show a projection.

source: holdout measurement engine — per-cohort worked/held delta · published only on window completion · zero synthetic numbers.

Some numbers cannot be measured honestly, so we do not publish them — even when a competitor would. Keeping this list public is the point.

• No invented callback stat. The one speed claim we make is a measured bound, not a flattering average: missed call to your phone ringing in under 8 seconds — machine-verified (Jul 2026). We do not quote a tighter figure, because the honest bound is what we can stand behind.
• No results-in-N-days promise. What we will commit to is delivery: live in 7 business days from your onboarding form, and a 90-day performance guarantee in the contract. Outcome timelines depend on your market, so we do not put a number on them.
• No counts below a floor. A small tally is not a milestone. Until a metric clears its display floor it reads “measuring” here rather than borrowing weight it has not earned.
• No caller data, recordings, or transcripts. Call recordings and transcripts never appear on this surface, by design — this page shows aggregates and self-checks only.

source: CLAIMS-CANONICAL — the single quotable source for every external Vectrion claim · corrections to public claims are logged and reflected here.

We put Vectrion through 2,000+ calls before we'd let it answer yours.

Here is exactly what that number is, labeled: n=2,014 synthetic certification calls across two banked ledgers — 1,011 test dials through the live production recovery path (missed-call ingest → dispatch → callback) between July 5 and July 10, 2026 (UTC), plus 1,003 direct dispatch-timing calls to controlled parked numbers between July 11 and July 13. The second study measures dispatch and answer timing, not the full recovery path. Together they certify the machine before launch. They are certification traffic, not client traffic, and we will never count them as client calls. For the same reason we disclose the other side of the ledger: as of the date below, our systems have handled 4 real inbound forwarded calls — that number is too small to mean anything yet, and we publish it anyway. A public client-traffic count returns only after the first 100 real inbound calls, ledger-backed.

ledgers: Cloudflare D1 database vectrion-portal, table missed_calls · query: SELECT COUNT(*) AS n FROM missed_calls WHERE source != 'twilio_forward' → 1,011 (synthetic recovery-path certification dials) · local timing-study-v2 calls.jsonl → 1,003 successful synthetic dispatch-timing calls · combined certification n=2,014 · SELECT COUNT(*) AS n FROM missed_calls WHERE source = 'twilio_forward' → 4 (real inbound) · as-of 2026-07-13 · registered as C-002 (certification class) in the Vectrion stat registry.