Verity Verification Core
Use this skill in the gap between a CALL-E call finishing and your agent acting on it.
CALL-E reports task_completed: true; this skill decides whether that is safe to act
on. It re-reads transcript_turns with a deterministic grammar, checks the parsed
value against what your action would actually write, requires a strict in-transcript
confirmation, and folds in a fresh check of the resource you are about to change. Any
missing field, any open ambiguity, any thrown error resolves to BLOCK, never ALLOW.
task_completed == true is necessary, never sufficient.
It does not place calls, hold slots, or write calendars. It turns one call snapshot
into ALLOW / BLOCK + a reason_code + a repair_target to confirm elsewhere.
When to use
- After a CALL-E
confirm, reschedule, or book call whose result will trigger a
real-world write (a calendar entry, a CRM update, a fulfillment step).
- When you need to tell "the caller agreed to 3:30" apart from "CALL-E's summary says
3:00", "the call reached voicemail", or "a time was mentioned but never confirmed".
- When a caught failure should govern future calls: the skill can turn a blocked
transcript into a PII-safe pattern for your own learned-pattern store.
When not to use
- To place or schedule the call. That is your CALL-E integration's job — see
references/calle-handoff.md.
- As a source of the booking value. The value always comes from the deterministic
grammar over the transcript, never from a model and never from CALL-E's summary.
- For medical, legal, financial-advice, or emergency call content. See
references/safety.md.
Workflow
- Preview. Run
scripts/preview_gate.py with your
intent + the value the task will write. It prints the call plan (task text,
result_schema, a deterministic idempotency key, a masked recipient) and the
exact E1–E7 checklist the gate will apply. No call is placed.
- Get explicit user intent for that specific recipient and value before any call
is placed. Read
references/safety.md.
- Place the call through your own CALL-E integration with the previewed plan.
- Re-fetch, don't trust the webhook. CALL-E does not sign webhooks; fetch
GET /v1/calls/{id} server-side and reconcile that snapshot.
- Reconcile. Run
scripts/reconcile_call.py with
the call snapshot + the same intent/value. It prints ALLOW / BLOCK, the
reason_code, and on BLOCK the repair_target to quote on a second channel
(e.g. an SMS "reply YES to confirm 3:30"). Voicemail, self-correction, ambiguity,
and an unconfirmed value are all reported as BLOCK, never as a verified result.
- Act only on
ALLOW. On BLOCK, open the second channel with repair_target,
or route to a human. Never let a BLOCK fall through to the write.
Quick start (no network, no CALL-E account)
cd skills/verity-verification-core
python scripts/preview_gate.py --input assets/experience-b.input.json
python scripts/reconcile_call.py --call assets/experience-b.call.json --input assets/experience-b.input.json
python scripts/self_test.py # runs A / B / D, asserts each expected verdict
The bundled scripts use only the Python standard library and never open a socket.
The reference implementation with full timezone handling is the TypeScript app at
apps/typescript/verity-verification-core/ (npm install && npm run demo).
What the gate checks (E1–E7)
|
Requirement |
| E1 |
task_completed == true and confidence is not low — necessary, never sufficient. |
| E2 |
The transcript resolves to exactly one datetime after self-correction. |
| E3 |
That parsed value exactly equals what the action would write (date + time + tz). |
| E4 |
A bot turn restated the full value and the caller affirmed it (a bare "yes" after a partial restatement does not count). |
| E5 |
No open ambiguity flag (self_correction_unresolved, multi_time_mention_unresolved, relative_date_ambiguity, no_explicit_confirmation, claim_parse_mismatch). |
| E6 |
A fresh re-check shows the resource is still yours and not expired. |
| E7 |
No learned failure pattern demands a second channel or a hard block. |
All seven must hold together for ALLOW. Full walkthroughs of the three headline
cases are in references/examples.md.
1---2name: verity-verification-core3description: Gate a CALL-E phone task's task_completed claim behind an independent transcript read-back before any real-world action. Use after a confirm, reschedule, or book call to decide ALLOW or BLOCK, catch a mid-sentence self-correction, a voicemail, or a value the caller never actually confirmed, and get the exact value to re-confirm on a second channel. Deterministic, no network, fail-closed.4license: MIT5---67# Verity Verification Core89Use this skill in the gap between a CALL-E call finishing and your agent acting on it.10CALL-E reports `task_completed: true`; this skill decides whether that is *safe to act11on*. It re-reads `transcript_turns` with a deterministic grammar, checks the parsed12value against what your action would actually write, requires a strict in-transcript13confirmation, and folds in a fresh check of the resource you are about to change. Any14missing field, any open ambiguity, any thrown error resolves to **BLOCK**, never ALLOW.15`task_completed == true` is necessary, never sufficient.1617It does not place calls, hold slots, or write calendars. It turns one call snapshot18into `ALLOW` / `BLOCK` + a `reason_code` + a `repair_target` to confirm elsewhere.1920## When to use2122- After a CALL-E `confirm`, `reschedule`, or `book` call whose result will trigger a23 real-world write (a calendar entry, a CRM update, a fulfillment step).24- When you need to tell "the caller agreed to 3:30" apart from "CALL-E's summary says25 3:00", "the call reached voicemail", or "a time was mentioned but never confirmed".26- When a caught failure should govern *future* calls: the skill can turn a blocked27 transcript into a PII-safe pattern for your own learned-pattern store.2829## When not to use3031- To place or schedule the call. That is your CALL-E integration's job — see32 [`references/calle-handoff.md`](references/calle-handoff.md).33- As a source of the booking value. The value always comes from the deterministic34 grammar over the transcript, never from a model and never from CALL-E's summary.35- For medical, legal, financial-advice, or emergency call content. See36 [`references/safety.md`](references/safety.md).3738## Workflow39401. **Preview.** Run [`scripts/preview_gate.py`](scripts/preview_gate.py) with your41 intent + the value the task will write. It prints the call plan (task text,42 `result_schema`, a deterministic idempotency key, a masked recipient) and the43 exact E1–E7 checklist the gate will apply. No call is placed.442. **Get explicit user intent** for that specific recipient and value before any call45 is placed. Read [`references/safety.md`](references/safety.md).463. **Place the call** through your own CALL-E integration with the previewed plan.474. **Re-fetch, don't trust the webhook.** CALL-E does not sign webhooks; fetch48 `GET /v1/calls/{id}` server-side and reconcile that snapshot.495. **Reconcile.** Run [`scripts/reconcile_call.py`](scripts/reconcile_call.py) with50 the call snapshot + the same intent/value. It prints `ALLOW` / `BLOCK`, the51 `reason_code`, and on BLOCK the `repair_target` to quote on a second channel52 (e.g. an SMS "reply YES to confirm 3:30"). Voicemail, self-correction, ambiguity,53 and an unconfirmed value are all reported as BLOCK, never as a verified result.546. **Act only on `ALLOW`.** On `BLOCK`, open the second channel with `repair_target`,55 or route to a human. Never let a `BLOCK` fall through to the write.5657## Quick start (no network, no CALL-E account)5859```bash60cd skills/verity-verification-core6162python scripts/preview_gate.py --input assets/experience-b.input.json63python scripts/reconcile_call.py --call assets/experience-b.call.json --input assets/experience-b.input.json64python scripts/self_test.py # runs A / B / D, asserts each expected verdict65```6667The bundled scripts use only the Python standard library and never open a socket.68The reference implementation with full timezone handling is the TypeScript app at69`apps/typescript/verity-verification-core/` (`npm install && npm run demo`).7071## What the gate checks (E1–E7)7273| | Requirement |74|---|---|75| E1 | `task_completed == true` and confidence is not `low` — necessary, never sufficient. |76| E2 | The transcript resolves to **exactly one** datetime after self-correction. |77| E3 | That parsed value **exactly equals** what the action would write (date + time + tz). |78| E4 | A bot turn restated the full value **and** the caller affirmed it (a bare "yes" after a partial restatement does not count). |79| E5 | No open ambiguity flag (`self_correction_unresolved`, `multi_time_mention_unresolved`, `relative_date_ambiguity`, `no_explicit_confirmation`, `claim_parse_mismatch`). |80| E6 | A **fresh** re-check shows the resource is still yours and not expired. |81| E7 | No learned failure pattern demands a second channel or a hard block. |8283All seven must hold together for `ALLOW`. Full walkthroughs of the three headline84cases are in [`references/examples.md`](references/examples.md).