Cleared to Call

Use this skill when an agent is about to place an outbound call to a consumer about money: a past-due balance, a payment reminder, a collection follow-up, or any account-servicing call where the recipient did not initiate the contact.

cleared-to-call supplies offline advisory helpers, not a dialer or a legal compliance certification. They read supplied records, evaluate a declared policy, and print results. They do not place or end calls, write suppression entries, or create or verify an audit chain. The integration requirements below describe work a host must implement; they are not shipped runtime features. An ALLOW result is not proof that a call is lawful or authorized.

The rules are data, not prose. They live in assets/policy.json and are explained in references/policy.md.

When To Use

Use this skill for:

• outbound collection, payment-reminder, or past-due account calls
• any batch of consumer accounts where each row must be checked before dialing
• workflows that must honor "stop calling me" during the call, not after it
• workflows collecting evidence for a human compliance assessment
• workflows explaining why the declared policy blocked a record

When Not To Use

Do not use this skill to:

• place calls outside the United States, or under any rule set other than US federal TCPA, FDCPA, and Regulation F - the policy is single-jurisdiction and a different region needs a different policy file, not a workaround
• decide anything for inbound calls the consumer initiated
• override, soften, or "just this once" bypass a block reason
• guess a missing timezone, consent record, or phone number
• give the recipient financial, legal, credit, or settlement advice
• negotiate, threaten, or discuss consequences of non-payment

If the caller wants a block overridden, the answer is to fix the underlying record, not the gate. A missing timezone is fixed by getting the timezone, not by assuming one.

Required Inputs

Each account must carry all of these. None of them may be inferred:

• account_id
• display_name
• phone_e164 - E.164, for example +15550101234
• timezone - IANA zone name, for example America/New_York
• amount_due and currency
• consent_on_file - true or false
• consent_timestamp - required when consent_on_file is true

Check a batch before evaluating any of it:

node scripts/validate-input.mjs --file accounts.json

A row that fails validation is reported and skipped. It is never dialed.

Never derive timezone from the phone number, the area code, the operator's locale, the server clock, or the country code. Rule 1 is a statement about the recipient's local time, so a guessed timezone is a guessed legal position. If the timezone is missing or unknown, the account is blocked.

Try It

The skill ships a fictional batch that hits every branch. Nothing dials:

node scripts/validate-input.mjs --file assets/example-accounts.json
node scripts/evaluate-account.mjs \
  --file assets/example-accounts.json --account-id A-1002 \
  --suppression assets/example-suppression.jsonl --now 2026-08-28T13:30:00Z
node scripts/check-revocation.mjs --utterance "stop calling me"

At that instant A-1001 is clear, A-1002 is outside its local call window, A-1003 has no consent, and A-1004 is suppressed.

The Pre-Dial Gate

The host must run these four checks before dialing. Passing them is necessary for this sample policy, not sufficient authorization for a real call.

Rule	Requirement	Block reason
R1 call_window	Local time at the recipient is inside 08:00-21:00	OUTSIDE_CALL_WINDOW
R2 consent_on_file	Prior express consent is recorded, with a timestamp	NO_CONSENT
R3 not_suppressed	The number is not on the opt-out or DNC list	ON_SUPPRESSION_LIST
R4 disclosure_ready	The rendered script carries every required disclosure element	MISSING_DISCLOSURE

Run the gate on one account:

node scripts/evaluate-account.mjs \
  --file accounts.json \
  --account-id A-1001 \
  --suppression suppression.jsonl

Exit code 0 is ALLOW, 2 is BLOCK, 1 is unusable input. The printed JSON holds every rule result, not only the failing one, so an audit reader can see the whole evaluation.

When several rules fail, the reported block_reason is the first failure in policy order. All four are still evaluated and printed for the host to retain.

Read references/policy.md for what each rule means, which authority it comes from, and the property it is meant to enforce.

The In-Call Revocation Handler

Rule 5 cannot be decided before dialing. A host integration has two duties; only the literal transcript checker is included here:

1. The call task tells the agent to stop the moment the recipient revokes: acknowledge once, end the call, do not ask why, do not offer alternatives.
2. After the call, run the transcript checker, then have the host persist any required suppression entry and record the outcome.

The checker prints a required action; it does not carry it out. If the agent talks past an opt-out, the host must still persist suppression and record opt_out. A post-call check cannot retrospectively stop a running call.

node scripts/check-revocation.mjs --utterance "stop calling me"
node scripts/check-revocation.mjs --transcript transcript.json

Exit code 3 means the number must be suppressed. Only recipient turns count: the agent saying "if you would like us to stop calling" is a required disclosure, not an opt-out.

Once the host persists suppression and supplies the updated list, R3 blocks the number on later evaluations. The host must retain the opt-out unless the consumer asks for it to be reversed.

How CALL-E Is Invoked

This skill does not place calls. Once an account is cleared, hand it to the existing CALL-E route - the CALL-E CLI, MCP plan_call / run_call / get_call_run, or whatever route the current client already uses:

gate -> ALLOW -> plan_call -> inspect plan -> run_call -> get_call_run -> transcript -> revocation re-check

Requirements on the call task handed to CALL-E:

• the opening disclosure must be included verbatim and must be spoken first
• the task must instruct the agent to end the call on any revocation
• the task must restrict the agent to payment logistics
• the task must ask for one outcome from promise_to_pay, dispute, refusal, no_answer, opt_out
• the destination must be exactly the cleared account's number

Inspect the plan before running it. If the plan targets a different number than the cleared account, do not run it. Providers often echo the destination masked, for example ...9724: compare its last four digits with the cleared number. A plan that names no destination at all cannot be checked, and an unchecked plan is not a verified one - do not run it unless the operator explicitly accepts that. Match symbol masks only; the call script itself says "account ending 1001", and reading that as a destination would refuse every call.

Structured Result

Suggested host outcome shape, not an output implemented by the bundled helpers:

{
  "account_id": "A-1001",
  "call_placed": true,
  "block_reason": null,
  "disclosure_given": true,
  "outcome": "promise_to_pay",
  "promise_date": "2026-09-05",
  "opt_out": false,
  "audit_ref": "aud_0af29e7f"
}

outcome is one of promise_to_pay, dispute, refusal, no_answer, opt_out, not_called. A blocked account is always not_called with call_placed: false and a non-null block_reason.

The host must derive disclosure_given from what was actually said, not merely from the script. This package does not implement that post-call verification.

Audit Record

Optional host design: retain decisions in a hash-linked JSONL log. This package does not append entries or verify a chain. A hash chain alone is not proof of legal compliance or protection against rewriting the entire log.

Such an entry can hold the timestamp, the account id, the masked phone number, the decision, the block reason, every rule result, the outcome, the policy id and version, and prev_hash plus hash.

The host must mask phone numbers in audit output, for example +1******1234.

Dry Run

All bundled helpers are offline: they read input and print advisory results. There is no live adapter, simulated dialer, suppression writer, or audit-chain writer. Host integrations must provide and validate those features separately.

Never place a real call to test the helpers. Offline checks exercise the declared sample policy, not the legality of a real calling program.

Place a real call only when the operator has explicitly asked for one, on a number they are authorized to call.

Safety Rules

Read references/safety.md for the full contract. Always:

• treat a phone call as a real-world side effect with legal consequences
• refuse rather than guess when a required field is missing or ambiguous
• mask phone numbers in every summary, log, and user-facing message
• never expose API keys, tokens, callback URLs, or confirmation tokens
• keep the call to payment logistics only, never advice or pressure
• honor an opt-out immediately and permanently
• never place a call for an account the gate blocked
• never edit or rewrite an audit entry

Output Format

After a host-managed batch, report only actions the host actually performed:

• how many accounts were cleared, blocked, and opted out
• each blocked account with its block reason
• each cleared account with its outcome and masked number
• any opt-out, distinguishing suppression required from confirmed persistence
• any implemented audit verification result, or state that it is not implemented

If the gate blocked everything, say so plainly and give the reasons. A run that places no calls because no account was clearable is a successful run, not a failure.

See references/examples.md for worked batches, including the refusal cases.