Verity
Gate a phone agent's task_completed claim before it acts.
Businesses running AI calling agents for scheduling need proof an outcome is correct,
not a claim that a call completed. Verity is a control plane that sits between CALL-E's
task_completed: true and the calendar write: it re-reads the transcript
independently, re-checks the slot deterministically, and — when the evidence is
ambiguous — asks for a second-channel SMS confirmation before anything is booked.
It is not a booking bot.
task_completed claim alone.
Every button below drives a recorded call through the real pipeline. No live calls —
this deployment runs VERITY_MODE=replay with no CALLE_API_KEY set.
The check every claim runs
- CALL-E's claim is usable.
task_completed === true, and CALL-E's own confidence is not self-ratedlow. Necessary — never sufficient on its own. - The transcript points to exactly one time. Read independently, after resolving any self-correction, it yields a single date + time.
- That time matches what would be written. Exact match on date, time and timezone — no rounding.
- Someone actually said yes to it. A caller turn affirming the value immediately after the agent restated the full date and time. A bare “yes” anywhere else does not count.
- No open ambiguity. No unresolved self-correction, no competing times, no vague relative date, no missing confirmation, no claim-vs-transcript mismatch.
- The slot is still ours. A deterministic re-check taken seconds before the write shows the slot held by this hold and not expired.
- No learned failure shape applies. No previously captured regression fixture says this transcript pattern needs an SMS or a hard stop.
All seven must hold to ALLOW. The first that fails, top to bottom, decides how the claim is blocked and repaired.
ReplayRun a scenario
A → expect ALLOW (allow_clean) ·
B → BLOCK (self_correction) ·
C → BLOCK (fixture_force_sms)
What Verity never does
- Commit from the claim alone.
task_completed: trueis one of seven conditions; it cannot satisfy the gate without the independently parsed value, the exact match, and an explicit caller confirmation. - Let an exception become a booking. Any thrown error, malformed input, or unavailable dependency in the verification path returns BLOCK. There is no code path from a failure to a calendar write.
- Write a value nobody confirmed. A committed value always traces to a caller
confirmation, a deterministic backend check, an inbound SMS
YES, or a recorded operator action. - Silently overwrite CALL-E's result. When the transcript disagrees with the claim, the repair SMS quotes the transcript's value, and both values are logged.
- Trust the webhook body. It re-fetches
GET /v1/calls/{id}server-side and gates on that snapshot, never on the delivered payload. - Learn a value from a model. A regression fixture's ground truth may come only from
a caller confirmation, a deterministic check, or an operator — never from
task_completed, confidence, or any LLM output. - Keep transcript text or audio. Audio is never stored; fixtures and audit rows hold turn indexes and field names, not quoted speech.
Questions judges ask
Does this place real phone calls?
No. This deployment runs VERITY_MODE=replay with no CALLE_API_KEY
set, so the live transport is never constructed. Each run replays a recorded synthetic
transcript through the same pipeline the live path uses.
Why does CALL-E's own task_completed: true get blocked?
It is evidence E1 — necessary, never sufficient. An ALLOW also needs an independently parsed value (E2), an exact match to what would be written (E3), an explicit caller confirmation that followed the agent restating the full date and time (E4), no open ambiguity (E5), and a fresh slot re-check (E6).
What happens if the SMS reply never comes?
The confirmation times out, nothing is committed, and the verification goes to
needs_human with the slot left held for an operator. It never auto-commits
on silence.
Is the gate deterministic?
Yes. decide() is a pure function with no I/O — same input, same
output, so every run here is replayable. Its whole body is wrapped so any thrown error
returns BLOCK.
Does an LLM ever choose the booking value?
No. The value written always comes from a deterministic date grammar. An LLM may only classify whether a turn is affirmative or tag a self-correction cue — it never supplies the date or time.
What is “ghost booking prevented”?
A run where CALL-E claimed task_completed: true but the independent parse
disagreed with the value that would have been written
(claim_parse_mismatch) — a wrong calendar entry stopped before it
happened. It is the headline metric on the dashboard.
It's a shared demo — will other visitors affect my run?
Possibly. One instance, one seeded calendar, so concurrent runs can collide on a slot. Use Reset to put it back to a known state.