Skip to main content

​
Voice Guard Sentinel: the Observability Contract

The federal TCPA voice-window guard answers a compliance question — may this dial proceed — but it also has to answer an operational one: is the guard actually wired at the dial gate? A gate that exists in code but was never reached in production fails the second question silently. The voice-guard sentinel closes that gap: every gate runs through a deliberately instrumented wrapper that emits one Sentry breadcrumb per invocation, so the wiring question reduces to a count. This page documents that contract — where the sentinel wraps, what the breadcrumb carries, how to chart it, and how to alert on its absence.

​
1. The four dial gates the sentinel wraps

Every outbound voice send path evaluates the federal window through the sentinel wrapper, never through the raw guard directly:
  • API voice compliance guard — ad-hoc dashboard and softphone dials created through the voice API (the app-layer gate is separately instrumented; the sentinel covers the shared decision module).
  • Campaign dialer pace — predictive, progressive, and preview campaign dials in the dialer worker.
  • Callback dispatch — virtual-hold and scheduled callbacks in the dispatch worker.
  • Voice-gateway pre-dial — the final hop before carrier egress, and the only gate that throws on a blocked evaluation.
Bypass-by-direct-import is banned by a static-analysis rule shipped with the platform’s guardrail suite (g-no-direct-voice-guard): any new send path that imports the raw guard module instead of the sentinel wrapper fails the check in review, so all four gates keep emitting their breadcrumb and any fifth gate joins the same contract. Check the send gates page for where the federal guard sits inside the full chain of send-time controls.

​
2. What the breadcrumb emits

Each invocation emits one Sentry breadcrumb under the category compliance.tcpa.federal-window, fired before the guard evaluates — so even a thrown block at the gateway pre-dial gate is preceded by its breadcrumb. Allowed and blocked evaluations both emit, which is what makes the count a wiring proxy rather than an error proxy. The breadcrumb data carries: Chart it by category, not by message text — the enforce and no-throw variants label their messages differently, and the category is the join across all four gates. Blocked evaluations additionally write a structured service log with the recipient masked; the breadcrumb is the wiring signal, the log is the decision record.

​
3. Alerting on zero breadcrumbs

Because the breadcrumb fires on every invocation, a gate that is genuinely reached produces a continuous stream. The detection rule the sentinel is designed for: if the breadcrumb count for a gate stays at zero for more than 30 days on a send path you know is dialing, the wire-up never took — escalate it as a platform defect with the send path and tenant context. Thirty days is the margin that survives campaign pauses, seasonal quiet periods, and low-volume tenants; below it, a zero count is ambiguous between “no traffic” and “no wiring.” To set the alert, aggregate the breadcrumb count grouped by gate (by service environment, or by send path where you can distinguish them) and alarm when any group reads zero across the 30-day window while that path’s dial volume is non-zero. Gate preconditions still apply — the dialer-pace and callback-dispatch gates only evaluate +1 NANP recipients, so a marketing-free or non-US-only tenant can legitimately show zero there; scope the alert to the paths and recipient classes that should dial. The breadcrumb troubleshooting page walks the same triage with worked Sentry queries.

​
4. Failure mode: gate in code, sentinels missing

The sentinel exists for one specific failure shape: the guard is wired into the send path’s code, the semgrep rule passes, and production calls still enforce the federal window correctly — but the breadcrumb never emits, so observability cannot confirm any of that. In that shape the dials are still enforced; only the verification fails. The 30-day zero-breadcrumb alert is what keeps that drift from living undetected: the guard’s correctness is provable from the breadcrumb stream, and a silent sentinel is itself the defect, caught by the count rather than by an incident.

​
5. What the sentinel verifies — and what stays yours

The sentinel verifies Orbit’s own guard wiring — that the platform’s federal-window check runs at the dial gate on every outbound voice path. It does not classify your traffic. The marketing/transactional lane attribution the guard reads, the consent posture behind each contact, and every other compliance control remain your choice and your configuration, exactly as the consent default policy frames the boundary. The federal window is the one platform-level floor; the sentinel is how you watch that floor hold.

​
See also