Answering Machine Detection Is a Guess: A 16-Scenario Test for Voice AI Calls

The decision in one minute

Do not treat an answering-machine-detection (AMD) label as ground truth. Treat it as a time-sensitive, fallible observation that may influence a call route. Before buying or enabling AMD, decide what a wrong decision costs, which events are distinguishable in the provider’s event model, how long the caller waits, and what happens when the classifier says “unknown.” Then test those decisions on recordings and live, consented traffic that represent your own destinations, languages, carrier mix, scripts and voicemail habits.

The practical rule is simple: route only when the expected cost of acting on a classification is lower than the cost of waiting, transferring, or ending the call. If the confidence or event is ambiguous, keep the interaction recoverable. A voicemail greeting is not always a machine, a human answer is not always a person ready to speak, and a “machine” result does not establish permission to leave a message. Keep authorization, disclosure and suppression checks outside the classifier.

If your implementation is part of a wider call-center change, the Vocalis implementation guide is a useful context for planning the workflow and ownership around the model. The protocol below narrows the question to one component: can this AMD configuration make a safe and useful route decision under the conditions you actually encounter?

This article provides a reproducible acceptance protocol, a 16-case scenario matrix, a small executable JavaScript evaluator and a route-state model. It does not claim that one provider, classifier, language or configuration is universally best. The proposed fixtures are a test design, not a measured benchmark. Do not report them as accuracy statistics.

What is being classified?

AMD usually runs after a telephony leg is answered. It attempts to infer whether the audio belongs to a person, a voicemail system, a fax or another category. That sounds like one decision, but an implementation actually involves several distinct observations: the carrier reports answer; audio begins or remains silent; the classifier may return a category; and the application decides whether to speak, wait, transfer, leave a message or stop. Those stages have different owners and failure modes.

The call-control question is often not “Is this a machine?” but “What action is safe now?” A fast answer can be useful if an outbound agent otherwise wastes a connection on a known greeting. Yet an aggressive decision can discard the first word of a person’s response, cut off a screening prompt, or transfer a voicemail greeting to an agent. Waiting longer may improve classification while increasing abandoned calls, caller confusion, and cost. A classifier event is therefore an input to a policy, not the policy itself.

Provider documentation illustrates why the distinction matters. Twilio describes synchronous and asynchronous AMD and exposes different outcomes and configuration choices; its documentation also warns that machine detection can be wrong and discusses tuning tradeoffs. Read the current event definitions and parameter semantics for the exact API and version you will deploy: Twilio AMD documentation. In asynchronous mode, application audio can begin before the detection result, which changes the practical risk compared with blocking for a result. The same label can therefore produce different caller experiences in different architectures.

Exotel documents its own categories and a detection interval, and its product material reports an accuracy range. Treat those as vendor-specific claims with their stated scope, not as a comparable independent benchmark: Exotel AMD documentation. A result from one vendor, route, country or evaluation set cannot establish how another provider behaves. Telnyx likewise has provider-specific AMD documentation and voice pricing. Confirm current commercial terms, destinations and event behavior directly in the contract and documentation before cost modeling: Telnyx AMD and Telnyx voice pricing.

Why the word “accuracy” is not enough

Suppose a provider says a system is 90% accurate. Without the denominator, class balance, language, destination, observation window, threshold, treatment of unknown results, and definition of a correct answer, that number cannot tell an operator whether the system is safe for a particular route. Accuracy can be high while the costly error is concentrated in a smaller group. If machine calls dominate a sample, a classifier that labels almost everything machine may appear accurate while failing the human answers that matter most.

Separate at least four quantities. A false-machine decision labels a live person as a machine; it may delay or suppress a conversation. A false-human decision labels voicemail as a person; it may send a greeting to an agent or trigger the wrong script. An unknown or timeout is not necessarily a mistake if policy routes it safely, but it consumes time and may add cost. A correct label can still be operationally poor if it arrives after the useful decision window. Report each class separately and report latency alongside the confusion matrix.

The denominator should be independently adjudicated audio segments or calls, not simply the provider’s own event labels. Freeze the intended definition before reviewing results. For example, “human” can mean a natural person is audibly present, not that the person has consented, is the intended recipient, or is ready for an automated conversation. Define “voicemail” as a recording system greeting, while treating carrier screening prompts and personal assistant interception as separate categories. If reviewers disagree, preserve disagreement and mark the sample uncertain rather than forcing an artificial truth label.

Historical sources provide useful cautions but should not be mixed into a modern vendor leaderboard. Ofcom’s 2015 report records industry participants’ self-estimates about AMD performance; the cited material describes a small self-reported sample, not a controlled laboratory test. Its value here is methodological: the word “accuracy” can conceal how estimates were formed. See Ofcom’s report annex, and retain its date, self-report basis and sample limitations whenever discussing it.

A research preprint published in October 2026 evaluates audio-embedding and gradient-boosting approaches across datasets and languages. It describes the OpenAMD corpus with 233 human and 300 machine recordings across seven languages, and reports that model comparisons vary by dataset. The authors’ work is a preprint, not peer reviewed, and its experimental corpus is not a guarantee about a commercial provider or your traffic. Its useful lesson is that transfer across datasets, languages and recording conditions must be tested rather than assumed: Altwlkany and Paric, arXiv:2610.26100.

Evidence ledger: fact, inference, recommendation

Sourced facts. Provider APIs define their own event names, timing and detection modes. Those definitions are not interchangeable. The Twilio and Exotel documentation above describe their respective implementations; use the API version and product configuration actually under consideration. The cited October 2026 preprint compares models across datasets and languages and identifies dataset dependence; it is an early research result, not an operational service-level commitment. Ofcom’s annex describes self-reported estimates from its historical context. CNIL’s guidance treats automated commercial prospecting with prerecorded messages as a regulated context requiring prior, specific and informed consent under the conditions it describes. These sources answer different questions and should remain separate.

Inference. Because detection timing, event semantics and input distribution vary, the same nominal category can have different operational consequences across implementations. A test should therefore connect raw events and timestamps to actual route actions. This is a system-design inference from provider-specific interfaces and the cost of irreversible decisions; it is not a claim that any named provider is inaccurate.

Recommendation. Maintain an explicit “unknown” route, preserve a human-recoverable path, and measure errors by outcome and subgroup. Choose thresholds and delays through a documented cost model using your own adjudicated sample. Do not let an AMD output grant permission to call, disclose less, or leave a message. Those controls have separate legal and policy owners.

The consulting sources cited here inform the organizational boundary, not AMD performance. BCG’s AI capabilities overview, PwC’s AI insights, EY’s AI hub, and Bain’s commercial-excellence X-ray are not controlled evaluations of answering-machine detectors. They are included only as recognized consulting context for the broader points that AI deployment involves process, ownership and commercial workflow design. They cannot support a claim about any provider’s classification accuracy, latency or legal compliance. The operational recommendation remains to validate AMD on an independent, locally relevant sample.

Build the acceptance sample before running the test

Create two linked datasets. The first is a replay set of audio snippets with labels assigned by at least two trained reviewers who do not see the model result. The second is a call-event set containing the timestamps and application actions for consented, authorized live tests. Do not use customer recordings unless the organization has established an appropriate lawful basis, notice, retention schedule, access controls and review process. For synthetic examples, identify them as synthetic; do not combine them with live results when reporting observed production performance.

For each replay item, record a stable sample ID, source type, language, destination country, carrier or route where permitted, codec, signal level, duration, adjudicated class, reviewer agreement, and exclusion reason. Avoid storing names, phone numbers or message content when a coded feature is sufficient. If the source is a live call, keep the identity mapping in a restricted system separate from the evaluation file. Set a deletion date before collection. A convenience sample is useful for finding obvious errors but cannot represent the full population. State that limitation.

Partition data by call or speaker, not by tiny audio fragments from the same call. Otherwise, the same greeting or voice characteristics can appear in both tuning and evaluation sets, making the result look stronger than it is. Keep a held-out set for the final decision. Write down the configuration and threshold before testing it. If you tune the model after inspecting the held-out outcomes, that set is no longer an independent test set; create another holdout or label the work exploratory.

Include prevalence scenarios. The natural share of human and machine answers can change by campaign, hour, country or list source. A single aggregate measure hides that shift. Report confusion counts and class-conditional measures, then recompute expected operational cost under plausible prevalence values. If a service produces few samples for an important language or destination, do not infer performance from a majority-language sample. Mark the area unvalidated and use a conservative route.

The 16-scenario acceptance matrix

This matrix is an original test design, not a measured dataset. Its sample size is 16 designed scenarios. It includes no actual caller recordings, no provider output and no statistical estimate. The date is 29 October 2026. Its purpose is to ensure the test plan covers distinct decision hazards before an organization gathers its own appropriately authorized sample. Each scenario should be exercised with multiple independent recordings in a real evaluation; the sixteen rows are categories, not a claim of sufficient statistical power.

ID	Scenario	Expected truth label	Hazard to inspect	Safe application behavior
S01	Person says “hello” immediately	Human	First syllable clipped by wait	Preserve audio and greet promptly
S02	Person answers, then pauses	Human	Silence mistaken for machine	Do not discard; keep short recovery window
S03	Person speaks in a supported non-default language	Human	Language-specific bias	Use validated language route or human fallback
S04	Person answers through speakerphone	Human	Echo and room noise	Avoid hard termination on one label
S05	Person says a short screening prompt	Human/screening	Screening confused with voicemail	Wait for policy-safe response or route to agent
S06	Carrier plays an “identify yourself” assistant	Screening	Automated prompt resembles greeting	Do not assume permission to leave message
S07	Personal assistant answers and requests a name	Assistant-mediated	Person versus recording ambiguity	Use an approved neutral response or stop
S08	Voicemail greeting begins after silence	Voicemail	Detection arrives late	Follow pre-authorized message policy only
S09	Voicemail greeting begins without a tone yet	Voicemail	Message-end mode waits too long	Enforce bounded timeout and recoverable state
S10	Voicemail with a short custom greeting	Voicemail	Short human-like audio	Avoid transferring blindly to live agent
S11	Voicemail with a long personal greeting	Voicemail	Long greeting crosses timeout	Treat timeout as unknown, not human
S12	Fax or modem tone	Fax/other	Misroute to speech workflow	Stop or use explicitly designed route
S13	Background speech behind greeting	Mixed/ambiguous	Multiple speakers	Mark uncertain and avoid irreversible action
S14	High packet loss or clipped first audio	Uncertain	Model sees damaged input	Fail to safe route; log quality indicators
S15	No audible audio after answer	Silence/unknown	Dead air mistaken for voicemail	Bounded retry or end with reason code
S16	Provider webhook delayed or duplicated	Event-system fault	Duplicate transfer or double greeting	Idempotency key and single terminal action

Run the matrix against each configuration that could change behavior: provider, synchronous or asynchronous mode, threshold, greeting length, route, language or relevant destination. If you change any of these, treat it as a new configuration and rerun the affected cases. Keep the raw provider event, its timestamp, the independent label, the action taken, and the eventual outcome. That event ledger is what allows a team to distinguish model behavior from webhook handling or a poor routing policy.

A small executable evaluator

The following Node.js script accepts JSON Lines records. Each line must have truth and predicted, with values human, machine, other, or unknown. It prints the confusion matrix, per-class recall, precision, and unknown rate. It makes no assumptions about the representativeness of the input. It deliberately does not produce a single headline accuracy figure because that can hide the operationally important class errors.

Example input (amd-results.jsonl):

{"truth":"human","predicted":"machine"}
{"truth":"machine","predicted":"machine"}
{"truth":"human","predicted":"human"}
{"truth":"other","predicted":"unknown"}

Save as amd-metrics.js:

const fs = require('node:fs');
const allowed = new Set(['human', 'machine', 'other', 'unknown']);
const labels = ['human', 'machine', 'other'];
const matrix = Object.fromEntries(labels.map(t => [t, Object.fromEntries([...labels, 'unknown'].map(p => [p, 0]))]));
let total = 0;
for (const [index, line] of fs.readFileSync(process.argv[2] || 'amd-results.jsonl', 'utf8').split(/\r?\n/).entries()) {
  if (!line.trim()) continue;
  let row;
  try { row = JSON.parse(line); } catch { throw new Error(`Line ${index + 1}: invalid JSON`); }
  if (!allowed.has(row.truth) || !allowed.has(row.predicted)) throw new Error(`Line ${index + 1}: invalid label`);
  if (!labels.includes(row.truth)) continue; // unknown truth is excluded from scored denominators
  matrix[row.truth][row.predicted] += 1;
  total += 1;
}
const sum = values => Object.values(values).reduce((a, b) => a + b, 0);
const report = {};
for (const truth of labels) {
  const row = matrix[truth];
  const actual = sum(row);
  const correct = row[truth];
  const predicted = labels.reduce((n, label) => n + matrix[label][truth], 0);
  report[truth] = {
    support: actual,
    recall: actual ? correct / actual : null,
    precision: predicted ? correct / predicted : null,
    errors: Object.fromEntries([...labels, 'unknown'].filter(p => p !== truth && row[p]).map(p => [p, row[p]])),
  };
}
const unknown = labels.reduce((n, truth) => n + matrix[truth].unknown, 0);
console.log(JSON.stringify({ totalScored: total, unknownRate: total ? unknown / total : null, matrix, byClass: report }, null, 2));

Run it with node amd-metrics.js amd-results.jsonl. Review the support beside every rate. A class with two samples cannot support a stable conclusion; the script exposes the denominator so it cannot disappear behind a rounded percentage. If reviewer truth is uncertain, do not pass it as a forced truth label. Exclude it from scored metrics while retaining its count and reason in the study notes. The unknown predicted value remains in the denominator because the application still had to handle that outcome.

The evaluator’s precision uses all scored truth classes in the predicted-class denominator. The report is a descriptive summary, not a significance test, confidence interval, or causal estimate. Add confidence intervals only with a method appropriate to the sampling process; a small convenience sample may not justify them. If there are repeated calls per speaker or destination, account for that dependence rather than treating all rows as independent.

From classifier event to route: make states explicit

flowchart TD
  A[Call answered by network] --> B{Consent, suppression and policy checks passed?}
  B -- No --> X[End or safe service-specific route]
  B -- Yes --> C[Collect bounded audio and provider events]
  C --> D{Valid AMD event before deadline?}
  D -- No --> U[Unknown or timeout]
  D -- Yes --> E{Event class}
  E -- Human --> H[Preserve audio; begin approved disclosure and conversation]
  E -- Machine --> M{Pre-authorized message allowed?}
  M -- No --> X
  M -- Yes --> V[Wait for provider-specific message point; play approved content]
  E -- Fax/other --> X
  U --> R{Recoverable route available?}
  R -- Yes --> H
  R -- No --> X
  H --> Z[Record one terminal outcome with event and policy IDs]
  V --> Z
  X --> Z

The flow separates eligibility from classification. The first gate checks whether this call is permitted and whether the intended action is allowed. AMD cannot satisfy that gate. The second stage collects events, but it must have a deadline. A delayed or missing callback must not leave a call consuming resources indefinitely. The terminal outcome must be idempotent: a duplicate webhook should not trigger a second transfer, disclosure or message. Persist a call-leg identifier, provider event identifier, policy version, configuration identifier and terminal state transition.

For a live-person route, keep the first audio buffered or otherwise available until the classifier decision has been reconciled. If a synchronous API blocks audio, test caller delay and timeout behavior. If asynchronous AMD permits speech to begin while detection continues, test what happens when the result arrives after the conversation has started. Do not let a late “machine” event interrupt a person already engaging with the assistant. The safest policy may be to ignore stale classifications after a conversation state transition.

For a voicemail route, distinguish “machine detected” from “message point detected.” Some provider modes attempt to identify the end of a greeting or a tone; others return a broad machine result. A message should play only if the product’s policy explicitly allows it for that context and jurisdiction. If a provider does not expose a reliable message point for your configuration, do not improvise from silence or a guessed delay. Use an approved alternative such as a human follow-up or no message.

The cost model: compare actions, not labels

For each possible action, estimate the cost of its outcomes using your own business and customer measures. Let C_hm be the cost of routing a human answer as machine, C_mh the cost of routing a machine as human, C_wait(t) the cost of waiting t seconds, and C_unknown(a) the cost of sending an uncertain result to action a. These costs may include abandoned conversations, agent time, customer harm, regulatory exposure, telephony charges and follow-up workload. They are organization-specific; do not copy another operator’s values.

The decision should minimize expected cost under an explicit prevalence assumption. For a route action a, compute the expected cost from the class-conditional outcomes, then compare it with the cost of waiting or choosing a conservative fallback. A threshold is not “best” in isolation. It is best only relative to a defined loss function, a measured distribution and acceptable constraints. If a severe outcome has low frequency but high impact, an average-cost objective may still be too permissive. Use hard constraints for prohibited actions and separate those from optimization.

Run a sensitivity table across low, central and high human-answer prevalence rather than treating the current campaign mix as permanent. For each row, show false-machine, false-human, unknown, time-to-decision, route cost and the proposed policy. A new campaign, carrier mix, language or screening feature can change prevalence. If the policy changes materially across plausible scenarios, the correct decision may be to collect more data, set a stricter threshold or route a segment to human review.

Do not compare vendor pricing as if it were total cost. The per-minute, per-detection or add-on fees are only one line. Include extra connection time, retransmission, delayed agent availability, quality assurance, handling of exceptions, and the cost of failed customer interactions. Confirm live price, destination and tax terms at procurement time. Provider pages change, and the documentation links above do not replace a quote for your route.

A ten-step acceptance exercise

1. Write the action contract. Specify which event can trigger each action. State explicitly that AMD does not establish consent, identity or legal permission. Assign an owner for consent, suppression, retention and message approval.
2. Freeze the configuration. Record provider, product, API version, mode, threshold, timeout, destination route, codec, webhook endpoint and application build. Hash the configuration snapshot so that later results can be tied to the exact setup.
3. Define adjudication. Give reviewers a short rubric for human, voicemail, screening, assistant-mediated, fax/other, silence and uncertain. Blind them to provider output. Decide how disagreement is retained.
4. Select representative strata. Sample by language, destination, carrier, time, script and known screening behavior. Document how each stratum was selected and the population it can represent. Do not claim representativeness for a convenience set.
5. Set exclusions before scoring. Examples include corrupt files, missing event correlation, prohibited collection, or reviewer disagreement. Log counts and reasons. Never silently remove a bad provider result as “not a real sample.”
6. Replay the held-out set. Run identical files through each configuration. Keep the input and output immutable. If a service is nondeterministic, repeat a subset and report variation rather than selecting the best run.
7. Exercise live event delivery. In a controlled, authorized environment, test delayed, duplicated, out-of-order and missing webhooks. Confirm that one call has at most one terminal action and no late event can reverse a completed conversation.
8. Measure the caller experience. Capture time to first useful audio, time to route, dead-air duration, agent handoff delay, hang-up and retry. Use consented or synthetic test calls and disclose the sample and exclusions.
9. Run safety cases. Test no-consent, suppression, wrong recipient, screening prompt, language mismatch, stale event, timeout, message-not-authorized and retention-expired cases. These should be enforced in application logic regardless of classifier quality.
10. Sign off by segment. Approve only the language, route, destination and script combinations with adequate evidence. Record residual risk, rollback threshold, owner and review date. Unvalidated segments remain on a conservative route.

The sign-off should include more than a pass/fail label. Preserve an evidence bundle with the protocol version, sample selection, label rubric, adjudication counts, configuration hash, raw event export, evaluator output, errors, limitations and decision owner. If the provider changes its model without a version identifier, ask how the organization can detect material change. If that is not available, schedule recurring sampling and monitor behavior drift; do not assume a historical evaluation remains valid forever.

What real users reveal that synthetic tests miss

User reports are useful for discovering edge cases, but they are not a performance study. A published Associated Press technology tip about iPhone call screening described a caller who believed a screening prompt was voicemail and hung up. That anecdote suggests a failure mode worth testing: a live person or screening assistant can sound machine-like and change the greeting sequence. It does not establish how often the behavior occurs, nor does it estimate AMD accuracy. Use it to add a scenario, not to assign a rate: AP technology report.

For operational discovery, collect support tickets and agent feedback using structured reason codes: “caller heard silence,” “prompt cut off,” “voicemail transferred,” “agent spoke over greeting,” “unknown waited too long,” “screening not handled,” and “duplicate action.” Ask reviewers to attach a call ID and configuration version, not a personal transcript. A weekly review can identify new scenarios, but avoid converting ticket counts into rates unless the denominator and reporting propensity are known. People are more likely to report some failures than others.

When a real failure arrives, keep the original event timeline. Reconstruct network answer, first audio, classifier result, webhook receipt, route transition and user-visible output. If the audio stream is needed, access it through an authorized, audited workflow and delete it on schedule. A screenshot of a dashboard or a model label is not enough to diagnose a race condition. The event sequence often reveals that the model was not the cause: the policy may have played too early, ignored a late result, or processed a duplicate callback.

Legal and disclosure boundaries are separate gates

AMD output does not make an outbound call lawful. For France, CNIL’s guidance on automated commercial prospecting using prerecorded telephone messages describes a prior, specific and informed consent requirement in the covered context. The separate Service-Public consumer guidance is useful for the related solicitation rules. Scope depends on what is being done, who is contacted, the relationship and the communication method; do not extend a marketing-specific rule to every requested service callback. Confirm the current legal basis with counsel or the responsible privacy and compliance owners before launch: CNIL guidance and Service-Public telephone solicitation rules.

AI disclosure is another distinct question. The European Commission’s Article 50 FAQ describes the transparency obligation for systems directly interacting with people and explains the conditions and exception in the AI Act text. The application depends on whether the system is an AI system, whether the interaction is genuine and two-way, whether the AI communicates directly, and whether the person is a natural person; the FAQ also notes the “obvious” interaction exception. Its application date for Article 50(1) is 2 August 2026 according to that FAQ. Teams should read the current official text and assess the facts of their exact interaction rather than treating “voice bot” as a complete legal analysis: European Commission AI Act transparency FAQ.

The recommendation is to design disclosure and permission checks as independent gates before any campaign. Store the policy decision and version, but do not store more personal data than needed. An AMD event must not waive a required introduction, convert a prohibited contact into a permitted one, or trigger a prerecorded message just because the endpoint appears to be voicemail. The policy should fail closed if consent state is missing, stale or not tied to the intended purpose.

Failure modes and their controls

False-machine on a live answer. The user hears dead air, loses the first syllable, or is disconnected. Preserve the start of audio, bound the wait, allow a retry or human fallback, and track this separately by language and route.

False-human on a greeting. An agent or assistant may speak into a recording, or a workflow may start a human conversation with voicemail. Test both short and long greetings and ensure the route can recover without duplicating messages.

Screening prompt mistaken for voicemail. A device or intermediary may ask the caller to identify themselves. Use a neutral approved response only if policy allows it; otherwise end or route to a human. Do not assume the device’s prompt means the recipient consented.

Late result interrupts a live conversation. In asynchronous mode a classification may arrive after the assistant begins speaking. Make state transitions monotonic: once a valid human conversation has started, stale AMD should not transfer or terminate the leg.

Webhook duplication. Retries may deliver an event more than once. Use an idempotency key and ensure terminal actions are single-shot. Record duplicates for reliability analysis without replaying the action.

Unbounded unknown. A missing callback can keep a call open. Set an explicit deadline, emit a timeout reason and route conservatively. Measure timeout frequency and duration.

Wrong truth labels. Reviewers may call an assistant “machine” when the policy must handle it differently. Preserve more granular labels and uncertainty. Revise the rubric if disagreement clusters around a category.

Sample leakage. Similar segments from one greeting appear in both tuning and holdout sets. Split by call or speaker, freeze the holdout and report any tuning on evaluation data.

Prevalence shift. A new country, time of day or campaign source changes answer types. Monitor class distribution and route outcomes. Re-evaluate before expanding to an untested segment.

Policy drift after a product change. A new disclosure, script, model, carrier or timeout can alter the outcome even if the classifier is unchanged. Version the policy and rerun impacted tests.

The decision table for a buyer or engineering lead

Situation	Evidence needed	Decision
Provider reports only aggregate accuracy	Class denominators, language, routes, unknowns and latency are absent	Do not approve based on the headline; request breakdowns and test locally
One route has strong human recall but slow results	Caller delay, false-machine cost and holdout evidence	Compare bounded wait with conservative fallback using your loss model
Machine detection is useful but message-point timing is unclear	Event semantics, greeting and tone cases, exact mode	Do not auto-play until message timing and authorization are independently approved
New language has few adjudicated cases	Per-language support and uncertainty	Keep on human or conservative route; gather authorized evidence
Webhooks can arrive late or twice	Event ordering and idempotency test	Fix state handling before model tuning
Marketing permission is uncertain	Consent records, purpose, jurisdiction and legal review	Do not call or leave a message based on AMD
AI disclosure applicability is uncertain	Interaction facts and current official text	Escalate to compliance; keep disclosure independent of the classifier
No route can safely handle unknown	Product policy and recovery design	Do not launch AMD-triggered automation until an unknown route exists

If the vendor cannot provide a meaningful test harness, event semantics or an explanation of how thresholds and timeouts affect the route, that is itself procurement evidence. It does not prove the product is poor, but it limits your ability to validate it. A vendor demonstration is not a substitute for a held-out sample from your intended traffic. Ask for logs and reproducibility, not only a polished dashboard.

Method note, sample size and limits

The original asset in this article is a 16-scenario acceptance matrix plus an executable evaluator and route-state design. The matrix was authored on 29 October 2026 by enumerating failure cases implied by provider event distinctions, current research limitations, public user-reported screening confusion and the separate permission/disclosure gates. Its design sample is 16 scenarios. No production call, provider classifier, statistical measurement or user study was run for this article. The evaluator example uses four illustrative JSONL rows only; those rows are toy data, not observed results. The article reports no original accuracy percentages or rate estimates.

Source selection was targeted to primary provider documentation for product behavior, government guidance for regulatory scope, a dated regulator report for historical method context, a preprint for current research methods, and one public technology anecdote for scenario discovery. Excluded from the claims are unsupported comparative vendor rankings, uncited market statistics, broad legal conclusions, and any claim that AMD identifies consent, a specific person or intent. Search results and vendor claims are not treated as independent experiments. The source set is small and English-heavy; the relevant legal guidance is jurisdiction-specific. It should guide test design, not replace legal advice or a local validation study.

Operational checklist

• [ ] Exact provider, API version, detection mode, threshold and timeout recorded.
• [ ] “Human,” “machine,” “screening,” “other,” “unknown,” and truth uncertainty defined before scoring.
• [ ] Reviewers blinded to model output; disagreement retained and measured.
• [ ] Samples split by call or speaker; held-out set frozen before evaluation.
• [ ] Language, destination, carrier, script, codec, noise and time strata documented.
• [ ] Exclusions and reasons reported; no inconvenient provider output silently removed.
• [ ] Confusion counts, class precision/recall, unknown rate and latency reported together.
• [ ] Expected operational costs recalculated under plausible prevalence scenarios.
• [ ] Late, missing, duplicated and out-of-order callbacks tested; terminal transitions idempotent.
• [ ] Human audio preserved; unknown and timeout routes recover safely.
• [ ] Voicemail playback requires an independently approved policy and message point.
• [ ] Consent, suppression, identity, purpose and AI disclosure are handled outside AMD.
• [ ] Data collection, access, retention, deletion and audit responsibilities approved.
• [ ] Sign-off limited to validated language, destination, route and script combinations.
• [ ] Monitoring owner, rollback criteria and reassessment date assigned.

Closing decision

AMD is useful when it shortens a clearly defined workflow without converting uncertainty into an irreversible caller-facing action. It is a bad fit when the project expects one generic “human or machine” flag to solve permission, disclosure, voicemail timing, identity and route policy at once. Start with a conservative event policy, measure the failure modes your team cares about, and expand only after the evidence covers the segment you intend to serve.

The acceptance question is not whether a provider can classify a clean demo call. It is whether your complete system can handle the first syllable, the long greeting, the screening prompt, the late webhook, the unknown language and the no-consent state without losing control. The matrix and evaluator make those checks repeatable. The final choice remains local: use measured outcomes, disclose uncertainty, and keep every high-impact action governed by an explicit policy.