Replay demo · no live calls

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.

Hard invariant: no calendar write can be triggered by an unverified 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.

Shared single-instance demo. Concurrent visitors use the same seeded calendar, so click Reset if state looks off.
Evidence gate

The check every claim runs

  1. CALL-E's claim is usable. task_completed === true, and CALL-E's own confidence is not self-rated low. Necessary — never sufficient on its own.
  2. The transcript points to exactly one time. Read independently, after resolving any self-correction, it yields a single date + time.
  3. That time matches what would be written. Exact match on date, time and timezone — no rounding.
  4. 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.
  5. No open ambiguity. No unresolved self-correction, no competing times, no vague relative date, no missing confirmation, no claim-vs-transcript mismatch.
  6. The slot is still ours. A deterministic re-check taken seconds before the write shows the slot held by this hold and not expired.
  7. 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.

Replay

Run a scenario

A → expect ALLOW (allow_clean)  ·  B → BLOCK (self_correction)  ·  C → BLOCK (fixture_force_sms)

Open the live dashboard →
Guarantees

What Verity never does

FAQ

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.