Attestation Changes What Answers Your Calls

Everyone treats STIR/SHAKEN as a deliverability problem. It isn't. It is an answer-behavior problem, and answer behavior is the input to your answering machine detection engine. Get attestation wrong and you have not just lost impressions. You have silently changed the composition of every answered call your AMD has to classify, and your accuracy numbers will move for reasons that have nothing to do with your model.

I want to walk the full chain, because most writing about STIR/SHAKEN stops at the part where calls get labeled. The part that matters to a dialer operator starts after the label.

What Attestation Actually Is

STIR/SHAKEN is the FCC-mandated framework for signing and verifying caller ID on the US PSTN. The signing part happens at the originating carrier, which attaches a cryptographically signed token to the call. That token carries an attestation level, and the level is a claim about how much the originating carrier knows about the call's identity. There are exactly three, and the definitions are worth memorizing because everything downstream follows from them. The FCC's own STIR/SHAKEN overview is the reference, but the operative version for an outbound operator is below.

Level A: Full Attestation

The carrier knows the caller, knows the telephone number, and can verify that this specific customer is authorized to use this specific number. The call is signed at the highest confidence. This is what you get when your numbers are properly documented on the trunk that originates them.

Level B: Partial Attestation

The carrier knows the customer but cannot fully verify that the customer is authorized to use the number being presented. This happens with number portability gaps, resold trunk arrangements, and numbers added to a campaign faster than the carrier's records update.

Level C: Gateway Attestation

The carrier can only attest that the call entered its network at a specific gateway. It makes no claim about who the caller is or whether the number is legitimate. This is the signature you get when a call has traversed multiple carriers with poor handoff documentation, and it is common with some international origination paths.

The Part Everyone Misses: Attestation Changes Human Behavior

Here is the chain, step by step, because this is where the industry loses the thread.

A call signed at C, or unsigned, does not arrive at the phone looking the same as a call signed at A. Analytics engines and carrier screening apps consume the verification result and adjust what the subscriber sees and hears. The call may render as "Spam Likely." It may be silenced to voicemail by default. It may trigger a screening prompt before the phone ever rings normally.

And each of those outcomes changes who, or what, ends up on the audio path after answer supervision.

The Three Answer Populations

Think about your answered calls as three populations, not one.

First, the call rings through normally and a human answers. That is the population your AMD was designed for, and the population every legacy AMD tuning guide from the 2000s assumes.

Second, the call is intercepted before the human. iOS Call Screening, Google Call Screen, and carrier screening products answer the call with a system prompt, ask the caller to state their business, and transcribe the response for the subscriber to review. We built a third classification for this at AMDY, which we call CALLGUARD, because forcing these calls into a binary HUMAN/MACHINE decision produces garbage either way. If you want the full treatment of that problem, I wrote about spam-likely labels and caller ID reputation separately, and it is the single most under-modeled variable in 2026 outbound.

Third, the call never rings at all, and voicemail or the screening system's fallback handles it. You get an answer supervision event, audio starts flowing, and your AMD has to make a call on what is now a machine path that behaves differently than the voicemail greeting your engine was trained on.

Attestation shifts the mix between these three populations. Not at the margin. Substantively.

The Table: Attestation to AMD Traffic Mix

Here is the mapping I use when I explain this to operators. The behavioral columns describe directionally what changes, based on how screening systems treat verified versus unverified calls. I am deliberately not inventing percentages: the actual shift depends on your destination mix, and the right move is to measure it on your own traffic, which I will describe below.

Attestation	What the carrier asserts	How answer behavior shifts	Effect on your AMD traffic mix
A	Full identity and number authorization verified	Most calls ring through; screening apps intercept a smaller share	Mix closest to classic HUMAN/MACHINE; your trained priors hold
B	Customer known, number authorization unverified	More "Spam Likely" rendering; more subscribers let unrecognized calls go to voicemail	Human answers skew toward the most motivated recipients; voicemail share rises; screening prompts rise
C or unsigned	Gateway entry only, no identity claim	Highest rate of carrier silencing, spam labeling, and screening interception	Screening-prompt and synthetic-voicemail paths dominate the marginal call; binary AMD misfires grow

Notice what that last column says. As attestation degrades, the marginal answered call is progressively less likely to be a plain human answer and more likely to be a machine-adjacent or screening path. Your AMD is not getting worse. Its input distribution is shifting under it.

Why Legacy AMD Breaks Under a Shifted Mix

Stock Asterisk AMD, the app_amd module most ViciDial and FreeSWITCH-adjacent stacks still run, is a silence-pattern detector. Its defaults tell the story: total_analysis_time of 5000ms, initial_silence of 2500ms, greeting of 1500ms, after_greeting_silence of 800ms, min_word_length of 100ms, between_words_silence of 50ms, maximum_number_of_words of 3, and a silence_threshold of 256. It counts words and gaps, then returns HUMAN, MACHINE, or NOTSURE. Those thresholds encode an assumption about what an answer sounds like: a short greeting from a person, or a longer scripted greeting from a voicemail box.

A screening prompt violates the assumption. It answers fast, asks a question, then waits. The pause after the prompt can exceed after_greeting_silence while a live human is literally reading the transcript on their screen. Stock AMD calls that MACHINE and the dialer drops a call the subscriber was actively evaluating. Or the prompt's speech pattern trips the word count and the engine routes a robot to your agent.

Our measured claim, and I flag it as ours: default Asterisk AMD drops an estimated 10-20% of live humans. That number comes from our own traffic analysis, not from a standards body. And that estimate was formed on traffic mixes closer to attestation A. As attestation degrades and the screening share of answers grows, the silence heuristics have fewer and fewer calls they were designed for. If you want the vocabulary straight, our AMD terms glossary covers the rest.

FAS Piles On

There is a second-order effect. False answer supervision, where the carrier signals answered before anyone picked up, corrupts the timing baseline your AMD uses. Attestation problems and FAS correlate in practice, because both concentrate on the same sloppy origination paths. We cover the mechanics in how carrier false answers corrupt AMD. The short version: an early answer signal starts your silence clocks too soon, the classifier fires before the audio even begins, and the error lands in your logs looking like an AMD bug when it is an upstream identity problem.

Measure the Mix on Your Own Traffic

I promised no invented benchmarks, so here is what to actually measure. Pull your last 30 days of answered-call dispositions and compute four shares: clean human answer, voicemail, screening prompt, and other. Then segment by the attestation status your terminating analytics report, or if you cannot get that, by origination trunk, which is a decent proxy since attestation is determined at origination.

The comparison you want is the ratio of screening-prompt share between your best-attested traffic and your worst. When we look at traffic across our platform, the pattern is consistent enough that we treat screening share as an input variable, not noise. But your number is your number. Compute it before you blame your detection layer for a connect-rate decline, because the two causes require opposite fixes.

The Fix Order

If your attestation is bad, no AMD upgrade fixes it. The order matters and getting it backwards wastes money.

1. Fix identity first

Every number you dial from must be verifiably yours on the trunk that originates the call. Number inventory, porting records, and trunk documentation all have to agree. This is boring work. It is also the only thing that moves attestation, because attestation is the originating carrier's claim, not yours. You cannot self-attest.

2. Then fix reputation

Attestation is not the only reputation input. Labels from analytics vendors and complaint rates matter independently. We walk that pipeline, including how ghost calls poison it, in the outbound spam-flag pipeline. The quick test for where you stand is in our piece on caller ID reputation scoring.

3. Then fix detection

Only after identity and reputation are stable does it make sense to evaluate AMD on the traffic you actually have. At that point you want an engine that handles three states rather than two. Ours returns a verdict starting at one-eighth of a second, 125ms, at 99% accuracy, and classifies screening interception separately so your dialer can treat it as what it is: a subscriber who has not decided yet, not a machine. That third state is the difference between a wasted dial and a recovered conversation in 2026 traffic, and it is why we describe 2026 as the year binary AMD stopped being adequate in the state of AMD in 2026.

A Worked Example of the Drift

Let me make the drift concrete with a hypothetical, clearly labeled as one. Suppose your campaign currently answers out as 60% clean human, 30% voicemail, and 10% screening prompt on well-attested traffic. Your AMD was tuned, formally or by accumulated config folklore, against roughly that mix.

Now suppose a trunk change drops your attestation to B on half the traffic. Screening share on that half rises, voicemail share rises as more subscribers let unrecognized calls ring out, and clean human share falls. Nothing about your dialer changed. Nothing about your list changed. But two things happen to your operation.

First, your connect rate falls, because fewer humans pick up personally. Managers read that as a list problem or a script problem and start fixing the wrong thing.

Second, the accuracy of your AMD falls, because the classifier is now seeing an answer mix it was never tuned for. If it is a silence-based engine, the screening prompts are structurally indistinguishable from a hesitant human or an unusual voicemail greeting, so errors cluster exactly on the calls your operation most wanted to salvage: the ones where a real person is on the other end of a screening prompt, deciding whether to take your call.

That second effect is the quiet one. It never shows up in a dashboard as "attestation degraded." It shows up as NOTSURE rates creeping up, as agents reporting more weird answers, as voicemail drops firing on humans. I have sat in more than one postmortem where the team spent weeks retuning AMD thresholds against a problem that was entirely upstream.

Where B and C Come From in Practice

Nobody chooses bad attestation. It arrives through operational shortcuts, and knowing the patterns helps you catch them before your stats drift.

Number porting is the classic. You port a block of numbers to a new carrier but the origination records lag, and for some window you are signing at B or not at all. Every dial in that window is degraded.

Reseller and aggregator trunk arrangements are the other big source. If your calls originate through a chain where the entity that signed the call is not the entity that owns the number relationship, full attestation is structurally unavailable. This is permanent, not a window, and it is worth knowing before you sign the trunk contract rather than after.

International origination into the US is the C factory. Multiple carrier handoffs, thin documentation, and the signing carrier knowing nothing about the original caller. If your cost optimization moved origination overseas, part of the savings is coming back out as screening interception and degraded AMD input.

Compliance Is on the Same Chain

One more connection operators miss. The FTC's Telemarketing Sales Rule caps call abandonment at 3% per campaign, measured over 30 days, per 16 CFR 310.4(b)(4). A misclassified human who gets dropped is an abandoned call. As attestation degrades and screening prompts grow, a binary AMD converts more of those prompts into drops, and your abandonment rate climbs for a reason that never appears in your dialer's AMD report. We map that mechanism in AMD and the TCPA 3% rule. If your compliance dashboard only counts dialer-level abandons, it is undercounting.

A Concrete Audit You Can Run This Week

If you want to know whether attestation drift is already hurting you, run this sequence. It takes an afternoon.

First, segment your answered-call dispositions by origination trunk over the last 30 days. You are looking for differences in voicemail share and unclassified or weird-answer share across trunks. A trunk whose voicemail share is materially higher than its peers, with a comparable list and campaign mix, is suspect.

Second, pull your NOTSURE and misclassification counts per trunk. On stock Asterisk AMD, NOTSURE is logged in the channel variables after the AMD() application runs, so the data exists even if nobody looks at it. Rising NOTSURE on one trunk with a flat list mix is the fingerprint of a shifting answer population.

Third, check your number registration state. Every number in service should be documented with the originating carrier and registered with the major analytics engines. Gaps there are both a reputation problem and, sooner or later, an attestation problem.

Fourth, ask your carrier directly what attestation level they are signing your calls at, per trunk, and what they need from you to sign at A. Some will not tell you. That answer is itself information.

What you are looking for is correlation between the weak trunk and the degraded answer mix. If it is there, you have found a cause, and the fix is paperwork and provisioning, not another AMD tuning pass. If it is not there, your AMD layer genuinely is the next place to look, and at least you will be tuning against a stable input distribution instead of chasing a moving one.

What We Did About It

For our part, we stopped treating attestation as someone else's problem. The detection engine classifies CALLGUARD states, so a screening-intercepted call is never forced into a human-or-machine decision made for a different era. Integration is a one-line change on ViciDial and Asterisk-family stacks, a WebSocket API for everything else, and the features page has the current list. Pricing is flat per detection with unlimited servers on every plan, from the free Sandbox tier's 50K monthly detections to Scale and Partner volumes on the pricing page, because the number of servers you originate from should not be a pricing lever when the problem is per-call.

The Takeaway

Attestation is not a marketing deliverability score. It is an upstream control on the distribution of answer types your detection engine sees, and every point of degradation shows up in your AMD stats disguised as an accuracy problem. Fix identity, then reputation, then detection, in that order, and measure your own screening share before you conclude anything about your engine.

The question I would put to other operators running their own numbers: what screening-prompt share are you seeing on A-attested versus C-attested traffic, and did your AMD vendor tell you it was coming?