A compliance review should prove three separate facts before a large calling programme begins: each person can be called, each opt-out stops future calls, and each call outcome reflects what happened on the line. A delivered webhook proves that a system sent data; it does not prove that a person answered, understood the agent, or completed the intended conversation.
In 1999, NASA engineers were receiving data from the Mars Climate Orbiter as it approached Mars. The spacecraft still entered the atmosphere on the wrong trajectory and was lost. The investigation, led by Arthur Stephenson, found that one team had supplied impulse data in pound-force seconds while another expected newton seconds.
The interfaces worked well enough to pass information between teams. The information was interpreted under incompatible assumptions.
NASA’s Mars Climate Orbiter Mishap Investigation Board Phase I Report documents the failure. Its lesson applies directly to voice calling: a successful handoff between systems cannot establish that the real-world event occurred as intended. You need an independent record of what each event means.
Trace permission before tracing calls
Start with the contact record, before the dial request.
For every person in the proposed audience, the reviewer should be able to identify the source of consent, the scope of that consent, when it was recorded, and whether it still applies to the planned call. A general marketing permission may not answer whether a specific automated voice call is appropriate. The evidence must match the channel and purpose being reviewed.
This becomes especially important in bilingual calling. A caller may grant, question, or withdraw permission in Twi after the conversation begins in English. The audit trail must preserve that change as part of the same interaction. The language switch cannot become a gap where consent loses its meaning.
The review should also test the negative path. What happens when consent is absent, disputed, withdrawn, or too ambiguous to rely on? The expected result is simple: the contact stays out of the callable audience until the record supports a call.
Asenda Talk includes consent, opt-out, and audit-trail controls for every call. Reviewers should still evaluate the programme’s configured rules, source data, and intended use. Product controls cannot repair consent evidence that was never collected.
Prove that an opt-out changes the next decision
An opt-out is useful only when it changes what the system does next.
The review should begin with a controlled test contact. Place a call, express a clear request to stop future calls, then verify the resulting record and attempt to place another call through the same route the programme will use. The second attempt should be blocked before money is spent or a provider receives the request.
Repeat the test in each supported conversational path. For a Twi and English programme, that includes an opt-out spoken in Twi, one spoken in English, and one made after switching languages. Inspect the transcript or stored evidence, the normalized opt-out state, the timestamp, and the suppression decision.
The language model’s interpretation alone should not be the final record. A reviewer needs enough evidence to determine what the caller said, how the platform classified it, and which later action that classification prevented. What Must a Call Review Prove After a Caller Says “Stop Calling”? examines that chain in more detail.
Separate webhook delivery from call truth
A telephony webhook describes an event reported by a provider or runtime. Its arrival confirms delivery of that event payload. The payload may indicate that a call was queued, initiated, ringing, connected, completed, rejected, unanswered, or failed, depending on the provider and integration.
Those states must not collapse into one green “complete” label.
Before launch, define a call-state model that answers concrete questions:
- Did the dial request leave the platform?
- Did the provider accept it?
- Did a human answer, or did the call reach voicemail or another machine?
- Did the assistant begin the intended conversation?
- Did the caller opt out?
- What terminal outcome was recorded?
- Which event authorizes billing?
Then test delayed events, duplicates, missing events, and events received out of order. The final record should remain deterministic. A late “completed” webhook must not overwrite an earlier opt-out or turn an unanswered attempt into a human conversation.
Asenda Talk has a telephony lifecycle webhook pipeline with call-truth tracking and metered per-minute billing behind an operator-controlled real-money gate. Outbound calling remains early-access functionality, and the live telephony-provider decision has not yet been made. The gate should stay closed until the chosen provider’s event meanings, retry behaviour, terminal states, and billing boundaries have been tested against the audit model.
For a concrete example of why a completion label needs examination, see What Really Happened When the Bilingual Call Was Marked Complete?.
End the review with evidence, not a dashboard colour
The approval packet should contain the callable audience criteria, sampled consent records, tested opt-out paths, webhook fixtures, expected state transitions, billing decisions, and unresolved exceptions. It should also name who can open the real-money gate and what evidence that person must inspect first.
Run one final reconciliation across three layers: provider events, the platform’s call record, and the conversation evidence. Differences should remain visible for review. They should never be silently converted into a successful outcome.
The Mars Climate Orbiter investigation did not stop at confirming that data had crossed an interface. It examined the units, assumptions, and physical result behind that exchange. Apply the same discipline before the first large calling list is released: prove what the records mean, then allow the calls to begin.
Comments
No comments yet.