Ground Truth Gate

Ground Truth Gate

Overview

Some facts are not on the web. They live in one human's head, behind a phone number: whether the part is on the shelf at this branch, whether the unit is still available at the advertised price, whether the slot is really open today.

An agent asked for such a fact has three options, and the first two both fail the user. It can assert from stale text, which produces a confident wrong answer. It can hedge and tell the user to go call, which hands the work straight back. The third option is to gate the claim: answer provisionally now, place one disclosed call to the party that actually knows, and correct the record when the call lands.

Core principle: absence of evidence is never evidence. A claim is released as fact only on positive evidence from an authoritative source, and only when the abstention gate agrees.

When To Use

• The agent is about to state a physical-world fact its sources cannot currently support, and it has not yet decided whether calling is justified.
• The evidence is stale, or its scope does not match the question asked. Text saying an item is "in stock at Northgate Appliance" does not answer "in stock at the Bellevue branch today".
• A wrong assertion is expensive and asymmetric: a wasted trip, a wired deposit, a missed deadline.
• The authoritative party is known and reachable by phone, and the user asked for the answer.

When Not To Use

• The decision to call is already made. Use verify-by-phone, which owns disclosed verification calls and the calibrated abstention this skill defers to.
• The fact is cheap to be wrong about, or a real API answers it authoritatively. Both are disclose or answer outcomes here, not calls.
• No authoritative phone contact was supplied by the user. Guessing a number is a blocker, never a default.
• The user has not asked for the answer. This skill never places a call to satisfy the agent's own curiosity.
• The question is time-critical to someone's safety. An emergency is not a claim to triage.

The Contract

Every gated claim produces exactly these four parts, in this order:

1. provisional — the answer available right now, its evidence age, and why it is provisional.
2. gap — the single fact the call must establish, as one question a human can answer.
3. call — the call task placed to the authoritative party, or the blocker that stopped it.
4. record — the durable claim record the correction will be written back into.

scripts/gate.py builds all four as data (format_contract), so the contract is asserted rather than hoped for. A response missing any part is not a gated claim: with no gap nobody knows what the call is for, and with no record the correction has nowhere to land.

Decide: Gate Or Pass

Evaluated in this order. The first row that matches wins.

Scope comparison is a set of casefolded terms, not an ordered tuple: ("ppo", "aetna") and ("aetna", "ppo") are the same scope. The asked terms must be a subset of what the evidence covers.

Consent And Disclosure

Every call this skill builds opens by identifying itself as an automated assistant, naming who it is calling for, and giving a recording notice, before it asks anything. It asks one question, once. It does not leave voicemail, does not ask for personal data, does not read identifiers aloud to establish trust, and ends the call if the conversation turns to medical, legal, financial, or emergency advice. build_task() is the only place a task string is constructed, and self_test.py asserts each of those clauses is present.

Naming who is responsible

47 CFR 64.1200(b)(1)-(2) asks an artificial-voice call to name the entity responsible for it and give a callback number. Two environment variables supply them, because they are properties of the deployment rather than of any one claim:

Both fail closed. The identity is spoken inside a quoted script, so a value carrying a straight or curly quote is refused rather than escaped - an apostrophe would close that script early and everything after it would reach the calling agent as a fresh instruction. The callback is validated as E.164 and never repaired by guessing. A half-filled disclosure is worse than the plain one, so a malformed value stops the call instead of going out half-right.

Runtime Workflow

The call is asynchronous by design. A chat reply cannot wait for a phone call, and a phone call must not be hidden behind one.

auth status -> POST /v1/calls -> webhook terminal event -> GET /v1/calls/{id} re-fetch
            -> release() -> write back correction -> notify user
            -> if no terminal event by T+6h: surface the claim as unresolved

The re-fetch is not optional. CALL-E webhook deliveries are unsigned, so a delivery proves nothing on its own; the authoritative state comes from GET /v1/calls/{id}. The webhook URL must also carry an unguessable path segment, which require_public_https() enforces along with refusing private and metadata addresses. See references/calle-api.md.

The sweep is not optional either. Silence looks identical to a pending correction. A gated claim with no terminal event by the deadline is surfaced to the user as still unconfirmed, rather than left waiting for a correction that is never coming. sweep_due() is that check.

Use POST /v1/calls, not the goal-run path. The extraction schema is result_schema() in scripts/gate.py; two rules make it safe, and both are enforced by test: every decision field is a string enum rather than a boolean, and every enum carries unknown with a description telling the extractor when to choose it.