​

Voice Traffic-Lane and Voice-Classification FAQ

The voice guard runbook documents the federal dialing-window gate end to end, and the blocked-call troubleshooting page walks a call that is already on the floor. Support volume around the guard is not “why was this call denied” — it is the questions upstream of the denial: which lane your call resolved, why a destination lookup failed, what ran before the guard saw your call, and where the verdict landed afterward. This page answers those four.

​

1. When is my call marketing vs transactional?

The lane-resolution question. Every outbound voice dispatch — API dial, softphone click-to-call, campaign, dialer, callback, Flow Builder make _call — resolves to a lane of marketing or transactional before the federal window is evaluated. transactional dials 24/7; marketing is governed by the recipient-local 8 AM–9 PM window the moment recovery is time-based. The federal window answers time; the lane answers whether time applies. The resolution rules, in precedence order:

1. Artificial or prerecorded voice → marketing. Any of these on the call metadata resolves marketing no matter what else is there: a TTS payload (tts_text, tts_body, message_body), a routed agent (voice_agent_id), a cloned-voice model (voice_cloned_model_id, agent_id), or an explicit voice_content_type of "synthetic" or "cloned". The statute names precisely this — the TCPA federal window restricts “artificial or prerecorded voice” — so this step is evaluated before anything else.
2. An explicit claim you made — "traffic_lane": "marketing" on the request metadata → marketing.
3. Campaign / journey / dialer / broadcast origin → marketing. Any of these metadata keys resolves marketing: campaign_id, journey_campaign_id, dialer_campaign_id, broadcast_id, flow_execution_id. A Flow Builder make_call node dials on an event, a schedule, or a webhook with no operator on the line, so flow-origin traffic is governed by default.
4. Unattended origination → marketing. amd_requested (answering- machine detection) or dynamic_variables (per-recipient substitution) on the metadata: a dial nobody is attending is an outbound blast, not a hand-placed one.
5. Otherwise → transactional. A direct API dial or a softphone click-to-call with none of the above resolves transactional and dials 24/7.

The one-way ratchet. Only traffic_lane: "marketing" is honored. An explicit traffic_lane: "transactional" claim is ignored and the inference above runs — a caller can make its own call more governed, never less. Your metadata blob travels unauthenticated from your request body through the dispatch path, and honoring a transactional claim off it would type around the federal gate. If a server-side dispatcher (verified origin) needs a transactional lane, the platform stamps it on a trusted internal field — never the caller-supplied metadata bag. How to claim marketing. When you genuinely want your call governed — a dialer you run socially but not legally, a campaign where the metadata shaped by the dispatcher did not yet hit the origin keys — pass "traffic_lane": "marketing" in the request metadata bag and Orbit enforces the window. This is the only way a voice caller can opt a call into governance; the messaging traffic_lane override (see Message priority traffic lanes) uses the same name there, but voice rejects the reverse direction on purpose.

​

2. Why did the +1 recipient lookup fail and how do I fix it?

The blocked-call troubleshooting page walks a call that evaluated the guard and lost — this is the lookup question: your call returned with no federal verdict at all because the recipient could not be resolved. The lookup sits before the gate: recipient E.164 → area-code → IANA timezone (for +1), or country-code prefix for non-+1. When none of that resolves, the voice guard fails closed by design and returns the dial timezone_unresolved, not a warning. The split is described on Number timezone and state resolution; the voice-specific handling is what this section answers. Fix: pass an explicit recipientTimezone hint. The lookup chain runs an explicit-per-request hint first, then the area-code inventory, then the prefix fallback. If your recipient’s actual timezone is known — you hold it against your contact’s verified address, or your CRM passes it forward — set recipientTimezone on the call and the guard honors it verbatim. That is the only resolution path the platform cannot infer and you must; an area code says where the number was assigned, not where the subscriber now lives. Common resolutions, in order of how often each is the answer:

• Toll-free or non-geographic +1 (800, 888, N11 codes). These carry no geographic signal and are deliberately unmapped — the dial returns timezone_unresolved until you pass recipientTimezone.
• New or overlay US area codes. When NANPA assigns a fresh NPA, the platform’s area-code inventory resolves it within a release cycle, but until then the area code is unmapped and the dial fails closed. Same fix — pass the hint.
• Canadian recipients. Canada is in the +1 inventory but it is not a US jurisdiction; the country resolves and the state reads null. The federal window does not apply — the guard allows immediately.
• Non-NANP (+44, +33, …). The guard skips the US federal wire entirely (non_us_recipient), and tenant quiet-hours or state overlays may still apply downstream. The lookup failure is not on the federal rail; it is on whatever tenant policy layer follows.

If the hint is not available and the recipient and you are both in coverage, the failure is an inventory update — the code is new and mapping lands with the next cycle — not a posture the guard needs from you. Field-specific support for a missing inventory entry is the platform’s own ticket, not yours.

​

3. What runs BEFORE the guard?

The dispatcher stamps metadata before the guard ever reads it, and the order matters: every voice dispatch assigns the class the classifier names and the lane the guard recovers, in this fixed sequence, at the dispatch-entry point (the API POST /voice/calls/place route or the voice-gateway /api/v1/outbound-call handler, whichever ingress your caller reaches):

1. Ingress metadata bag assembled. Your request body and any server-side dispatch hints (e.g. an agent_id the route folds into the bag) compose the metadata the classifier and resolver read.
2. Voice-content class stamped. The classifier resolves the voice_content_type from the metadata in precedence order: explicit voice_content_type (verbatim) → voice_cloned_model_id → voice_agent_id (campaigns canonical key) → agent_id (fallback) → tts_text / tts_body → message_body → otherwise human. The class is stamped on the audit row and forwarded downstream with the verdict.
3. Lane resolved. The traffic-lane resolver sees the same metadata and the classifier’s voice-content class as its artificialVoice signal. The verdict chain above (step 1–5) returns marketing or transactional.
4. Voice-compliance gates, then the federal window. The lane and class settle first, and then the voice-compliance gates run in sequence: DNC-suppression, STOP-suppression, FCC 24-17 written- consent gate, then the federal TCPA window check on marketing traffic only. A blocked call never loops back to the window math; each gate is short-circuited and returns its own reason.

The read-yourverdict consequence: a dial recorded as human + transactional skips the federal window entirely; the same metadata bag carrying a TTS payload resolves synthetic and the window is checked. The class is stamped before the window check runs — the guard does not infer speech type mid-gate.

​

4. Where do I read the decision ledger?

Every voice dispatch evaluation — allowed or blocked — lands in your tenant’s audit chain with the same shape: resolved lane, resolved local hour, the reason the gate returned, and the resolved voice_content_type. Read it back with the audit export route (filter on event_type = 'voice_dial_guard_decision') or the dashboard compliance ledger (Compliance → Audit ledger, the voice scope). Blocks report with the recipient number masked. Roll those events up over a reporting window and you get a posture history — the SOC 2 evidence-binder convention described on Audit ledger posture rollup — with federal-only, federal+state, and federal+state+tenant bands set per period so a reviewer can attest what gate was active when. Only the lane and posture bands appear there; the full reason enum a blocked call returned is on the runbook and the federal window check.

​

See also

• Voice guard — the federal gate’s wire-up and decision chain.
• TCPA window blocked calls — post-block recovery runbook.
• Quiet hours FAQ — the org gate, campaign fallback, and preview layering.
• Number timezone and state resolution — the lookup chain section 2 derives.
• Compliance posture FAQ — the broader operator index.
• Message priority traffic lanes — the messaging-side lane override.