The AMD log is your defense exhibit

A call center manager once told me detection logging was "a debugging feature we turn on when something breaks." That belief is how TCPA plaintiffs win. When a litigator claims a live human answered and got dead air, or a regulator asks you to demonstrate your abandonment rate for a campaign over 30 days, the per-call detection log is either your defense exhibit or the absence of one. There is no third option.

I have spent years on the AMD side of outbound calling, and the pattern is consistent: shops that log every detection verdict with full context settle cheaply or win. Shops that kept CDRs and vibes settle. The log is not diagnostics. It is evidence, and evidence has requirements that debug output does not.

The myth: logs are for engineers

The mental model most dialer operators carry is that AMD output is operational telemetry. You look at it when answer rates look wrong, then you forget it. Under that model, retention is a cost, verbosity is noise, and the log line is whatever the dialer happened to print.

Flip the perspective to the moment it matters. A complaint lands. Caller X says your campaign called them on a specific date, they answered, and heard silence before disconnect. Their attorney knows exactly what silence-then-disconnect sounds like to a court: an abandoned call under the FTC's Telemarketing Sales Rule. The rule at 16 CFR 310.4(b)(4) caps abandonment at 3% of answered calls per campaign, measured over a rolling 30-day period, and requires that no call be abandoned before thedialer holds the line. You can read the text yourself: FTC TSR, 16 CFR 310.4.

Now the question put to you, formally: what happened on that call? Not what usually happens. That call. At that timestamp. If your answer is "our AMD is 99% accurate," you have no evidence, because accuracy is a population statistic and disputes are about individual events. If your answer is a log record showing the call was answered by a machine per a detection verdict rendered in 125ms, with the cause code and a reference to the retained audio, the complaint usually stops being a lawsuit and becomes a nuisance.

That is the whole difference. Populations do not litigate. Individual calls do.

What a defensible per-call detection log must contain

A log line that cannot survive being handed to opposing counsel, an auditor, or a carrier desk is not a compliance log. Here is what each record has to carry, and why the field exists.

Timestamp, precise and monotonic

Date and time of the detection event, at sub-second resolution, in an unambiguous timezone, from a clock you can show is synchronized. The verdict's latency belongs here too: when after answer the decision was made. A verdict rendered at 125ms into the call supports a very different narrative than one rendered after five seconds of listening. Latency also proves you were not sitting on the line manufacturing abandonment.

The verdict, in the classifier's own vocabulary

HUMAN, MACHINE, NOTSURE, and whatever intermediate categories your system emits. Log the machine's actual output, not a downstream summary. If the classifier said NOTSURE and your dialer policy treated NOTSURE as machine, both facts need to be in the record, because that policy decision is exactly what a plaintiff's expert will go looking for.

The cause

Asterisk gets this right structurally, which is why app_amd output maps cleanly to evidence. AMDSTATUS carries HUMAN, MACHINE or NOTSURE, and AMDCAUSE carries which threshold fired and the duration that triggered it: initial silence, greeting length, total analysis time. So when you log AMDSTATUS=NOTSURE with a cause of INITIALSILENCE-2560, a reviewer can reconstruct the decision instead of taking your word for it. The default thresholds in amd.conf (initial_silence 2500ms, greeting 1500ms, after_greeting_silence 800ms, total_analysis_time 5000ms) are documented at Asterisk app_amd documentation, which means anyone auditing your log can independently verify what your numbers meant. That auditability is the property to preserve regardless of whose AMD you run.

An audio reference

A pointer to the retained answer-side recording, keyed by unique ID. The log says what was decided; the audio proves what was actually there. If you keep no audio, every disputed call is your word against the complainant's, and juries do not average that out. Recording review with classification closes the loop: sampled recordings, reviewed against verdicts, give you a measured accuracy figure you can state under oath instead of a vendor's marketing number.

Campaign and list context

Campaign ID, list ID, the phone number dialed, the carrier where identifiable. Abandonment is measured per campaign over 30 days, so your log has to be sliceable by campaign and date range or you cannot compute the regulated number from your own records. And when a honeypot number planted by a litigator shows up across your lists, per-call records with list context are how you document the pattern.

What happens after the verdict

Whether an agent was connected, when, or why not. The abandonment definition turns on agent connection within the two-second window after a live human answers. A detection log without the connect-or-abandon outcome is half an exhibit.

The table: dispute scenarios and the field that answers them

Dispute scenario	The log field that answers it
"A human answered and heard silence"	Verdict + latency + cause: e.g. MACHINE at 125ms, greeting threshold, not an unanswered-then-abandoned call
"Your campaign abandons more than 3% of calls"	Per-campaign, 30-day slice of verdicts with connect/abandon outcomes; compute the rate directly from records
"You called me repeatedly after I answered"	Timestamps + dialed number across the full retention window; verdict on each prior call
"Nobody was there when I picked up, your bot hung up"	Verdict + agent-connect event timing; shows detection decision and routing, not a dead line
"That number was on the Do-Not-Call list"	List context + campaign ID; documents which list contributed the number and when
"Your 'machine' classifications are just wrong"	Audio reference + sampled recording review results; measured accuracy vs claimed accuracy
"You knew your detector was failing and kept dialing"	Verdict-distribution trends over time + retraining/review records; shows measurement, not blindness

Read the last row twice. The discovery question in TCPA litigation is increasingly not just "what happened" but "what did you know." A shop with per-call logs, periodic accuracy audits, and records of acting on them has a negligence defense. A shop with none has a negligence problem it cannot dispute.

Computing the 3% number from your own records

The abandonment cap is where the log stops being defensive and becomes operational. The TSR formula is unforgiving in a specific way: abandonment rate is calculated per campaign, as abandoned calls over answered calls, across a rolling 30-day window. Not per dialer, not per client account. Per campaign. If your records cannot slice by campaign, you cannot know your regulated number; you can only discover it during discovery.

To compute it from a detection log you need, on every call: campaign ID, answer timestamp, detection verdict, and the connect-or-abandon outcome. The numerator is live humans answered with no agent inside the two-second window. The denominator is all answered calls, including machines. That distinction matters and logs get it wrong constantly: the denominator includes every answered call, not every connected call, so a dialer that only logs agent-connected calls silently shrinks its denominator and inflates its rate, or worse, hides it.

The per-campaign cut also exposes a failure mode I see weekly: one campaign with bad list data or a hostile answer side pushes the whole account over 3% while aggregate dashboards show a comfortable 1.8%. The regulator or plaintiff will slice per campaign, because the rule says per campaign. Slice your own log the way they will, monthly, before they do.

The honeypot angle

Litigation economics have produced a specialized answer-side actor: the honeypot number. Plaintiffs' firms and blacklist operators plant numbers on lead lists, answer every call, and log everything, building a record of your dialer's behavior call after call. These numbers are machines in the statistical sense, they never convert, and their entire purpose is to be misdialed.

A per-call detection log cuts both ways here. On one hand, if your dialer repeatedly connects a honeypot to abandoned silence, the plaintiff's log of your behavior is better than yours, which is the worst position in the room. On the other hand, honeypot detection is a solvable problem: numbers that answer at implausible rates across lists, hold patterns, never disposition as contacts. We built honeypot detection and reporting into the platform because the first time you see a planted number is ideally in your own report, not in an exhibit list. Your per-call log, sliced by dialed number, is the dataset that makes that visible. Without it, you are dialing into a trap with the lights off.

What to do when your own log is against you

Half the shops reading this already know their record-keeping would not survive contact with a subpoena. A word on the honest path, because the dishonest path is how small disputes become federal cases.

If you find, on measuring, that your human-drop rate or your abandonment slice is bad, the record of finding it and fixing it is itself protective. Regulators distinguish operators who measure and correct from operators who fly blind; so do courts, and so do state AGs deciding whether to escalate. The sequence that hurts is the one where you never measured, the plaintiff's expert does measure, and your internal emails show you knew the dialer was dropping humans and kept the list running.

So: audit first, before anyone asks. Fix what the audit finds, document the fix with dates. Keep the audit. The audit is not an admission you can be punished for having done; the absence of any audit is the fact that gets argued against you.

A note on the machine side of the log

Machine detections get logged lazily because they feel harmless, and that laziness costs money in a place nobody expects: carrier disputes and false answer supervision. When a carrier signals answered on a call where no party existed, your AMD hears an announcement and renders a verdict on audio that was never a subscriber. Logged per carrier, those verdicts accumulate into a FAS pattern: one carrier's answer-side audio classifying as machine at 5x the rate of its peers. That is the signature of false answer supervision, and a per-carrier FAS breakdown is how you take it to the carrier with counts and timestamps instead of a vibe. Same log, different dispute, still evidence.

Logs you deleted are indistinguishable from logs you never kept, and courts have drawn adverse inferences from missing records that a reasonable business process would have retained. The practical requirements:

Retain beyond the limitations horizon

TCPA claims can reach back years depending on jurisdiction and tolling arguments. The record-keeping obligations the FTC and FCC have pushed under the TSR point the same direction: if the dialing decision is regulated, the record of the dialing decision is the artifact. Decide retention with counsel, not with your disk quota. We treat the detection log as a compliance artifact first: our audit trail covers TCPA record-keeping, is HIPAA-ready for health-adjacent call centers, and on Scale plans supports GDPR-format exports, because a log that cannot be produced in the format a regulator asks for is a log you cannot use.

Keep it queryable

A tarball of flat files is not a defense posture; it is a promise to spend six figures on forensic consultants when the subpoena arrives. The log needs to be queryable by phone number, by campaign, by date range, and exportable on demand. When we built queryable per-call detection log export into amdy.io, the driver was not debugging convenience. It was "produce every call to this number in the last 18 months, this afternoon."

Protect it

Evidence that can be edited after the fact is weak evidence. Append-only records, access logs on the log system itself, and documented retention policy. The other side's expert will ask how they can know the record is contemporaneous. Have an answer.

AMDSTATUS and AMDCAUSE as evidence, concretely

It is worth walking one call through the lifecycle, because the mapping from dialer fields to evidence is simpler than people fear.

A call answers. Asterisk's app_amd runs and sets AMDSTATUS=MACHINE, AMDCAUSE=LONGGREETING-1720. Your dialer policy disconnects the leg and leaves a message or drops the call. Six months later the called party's attorney sends a demand letter claiming a human was abandoned.

Your production, from the log: the call record with the timestamp and timezone, the AMDSTATUS=MACHINE verdict, the AMDCAUSE showing the greeting measured 1720ms against a 1500ms threshold, the 125ms-class detection latency if you run a fast classifier, the audio reference for the retained answer-side recording, and the recording review results for that sample period showing measured machine-detection accuracy. Opposing counsel can listen to the audio and hear the voicemail greeting themselves. The dispute collapses from "what did your box do to my client" to "here is the voicemail your client's carrier played."

Now run the same dispute with no log. Your position is that your vendor publishes 99% accuracy. Their position is a sworn statement from a plaintiff who says they answered. That is a coin flip with your company's money, repeated for every call in the class period.

Wire the habit in before you need it

If you run ViciDial or Asterisk and you are not currently capturing AMDSTATUS and AMDCAUSE per call into durable storage, that is the first fix, and it is cheap. The second is sampling verdicts against agent dispositions and recordings so your accuracy claim is yours, measured, current. We documented the methodology for both: How to test AMD accuracy for the general procedure and Measure AMD accuracy in ViciDial: the audit for the ViciDial walk-through. If you want the compliance framing tied to the abandonment cap, read AMD and the TCPA 3% abandonment rule, and for which detection metrics belong on the wall, Outbound AMD metrics to track.

Detection accuracy is the number that keeps you dialing. The log is the thing that keeps you out of the deposition. Fund both.

A detection log nobody can query is a debug feature. A detection log with timestamps, verdicts, causes, latency, audio references and retention is a defense. Same data, different shape. Which one you hold is decided years before anyone sues you.

One question I keep asking peers in the industry and never get a clean answer to: when your AMD vendor retrains their model, does the verdict in your historical log mean the same thing it meant the day it was logged? If a MACHINE verdict from 2024 was produced by a different classifier than a MACHINE verdict from last week, your audit trail has a silent semantic break in it, and nobody has written the retention rule for that yet. The operators who figure out how to log model versions alongside verdicts will have the only fully defensible records in the room.