Skip to main content

Trust-tier governor: enforce carrier-assigned 10DLC throughput at send time

Your brand’s TCR vetting score unlocks a carrier-assigned throughput ceiling: an AT&T per-campaign throughput class in messages per minute (MPM), and a T-Mobile per-brand Brand Daily Cap in message parts per rolling 24 hours. Orbit derives both ceilings and displays them on the brand throughput endpoint. Until the trust-tier governor, nothing enforced them: a campaign paced generically could out-run its AT&T MPM class or blow past the T-Mobile daily cap, the exact behaviour that triggers carrier filtering and number-reputation damage. The trust-tier governor is an opt-in, tenant-owned control on the campaign. Set trust_tier_governor in campaign.variables and the batch send loop enforces the carrier-assigned ceilings while the run is live.
Everything on this page is tenant-owned and defaults off. Campaigns without the trust_tier_governor variable see zero behaviour change. The governor paces and defers your existing sends; it is not a new platform compliance gate.

The gap it closes

Before the governor, the ceilings the brand throughput endpoint resolved were display-only:
  • AT&T assigns each campaign a throughput class (MPM) off your brand trust score. Sending faster than the class grants is what gets a campaign flagged for carrier-side filtering.
  • T-Mobile assigns each brand a rolling 24-hour Brand Daily Cap in message parts. Blowing past the cap is the reputation-damaging behaviour, and it is a per-brand cap, shared across every campaign and API send the brand runs, not per campaign.
A campaign that resolved those ceilings from the endpoint but paced only on a plain throttle_rate had nothing between it and the cap. The governor is the missing send-time enforcement.

Turn it on

Add a trust_tier_governor block to campaign.variables (the same variables object adaptive_pacing and ramp_up live in):
Deriving from the trust score keeps a single source of truth: the governor reads the ceilings through the same resolution the /10dlc/brands/:id/throughput endpoint uses, so what the governor enforces is what the endpoint shows. Per-field overrides only ever lower a ceiling; use them to protect a warming number, never to claim more than the tier grants.
The daily cap is per-brand. If you omit daily_baseline and the brand’s other traffic has already consumed 40% of the T-Mobile cap, this campaign treats the full cap as available and can still push the brand over it. Seed the baseline from the brand’s current consumption at launch; when the run is paused and resumed across a day boundary, the governor treats the current rolling-24h consumption, not the stale launch value.

What the governor does during a run

On every batch, the governor reads the resolved ceilings plus current consumption and issues a send decision:
  1. Hard rate ceiling (AT&T MPM). The MPM class becomes a messages-per-second ceiling. When the campaign’s ramp-adjusted effective rate exceeds the ceiling, the governor computes a pace factor in (0, 1] the send loop folds into the same inter-batch delay and token-bucket machinery adaptive pacing uses. The loop slows to the carrier ceiling instead of running generic pacing.
  2. Daily-cap consumption (T-Mobile). The governor tallies daily_baseline + parts sent this run against the daily cap and reports the remaining headroom and a consumption band (ok / warning / critical / exceeded) matching the bands the brand throughput endpoint reports.
  3. Cap verdict. When the next batch would cross the daily cap (sent today + batch size > daily cap), the loop defers the batch and auto-pauses the campaign rather than oversending. The campaign transitions to paused and the remaining recipients roll to the next rolling-24h window. Under-sending by at most one batch is the safe direction for a carrier cap.
The governor is deliberately conservative on the cap: it defers before a batch that would cross the limit, not after. Over-sending is what filters the number.

When not to use the governor

The governor is not right for every campaign. Skip it when:
  • Low daily residue. If the brand routinely sits within a few hundred parts of its T-Mobile cap (because your other campaigns and API traffic consume most of it), a governor-enabled campaign will auto-pause almost immediately on launch, and relaunching it every day adds more operational burden than protection. In that posture the right move is to re-vet the brand for a higher tier (see 10DLC rejections and re-vet), then enable the governor once the headroom exists.
  • Degraded-mode exposure. If your possible values for trust_score / entity_type resolve to a very low ceiling (an unwarmed brand, a sole-proprietor entity), a high-volume campaign clamped to that ceiling runs for days. Re-vet or fix the brand registration rather than letting the governor mask the real problem by slowing the campaign into a degraded mode.

Ordering with the other pacing controls

The governor is one of four controls that can shape a campaign’s send rate. They apply in a fixed order, and each narrows what the previous one left:
  1. throttle_rate — the campaign’s nominal send rate (messages per second) you set. This is the open-loop baseline: with no other control, the loop sends at this rate.
  2. ramp_up — a linear, time-based ramp on throttle_rate: the delay starts higher and eases to the nominal rate over the ramp window. It still knows nothing about the carriers.
  3. Trust-tier governor — a hard ceiling, not a rate. It clamps whatever rate the first two produced down to the AT&T MPM class, and auto-pauses when the T-Mobile cap would be crossed. It never speeds a campaign up.
  4. adaptive_pacing — closed-loop DLR feedback. Periodically re-reads this campaign’s per-network delivery outcomes and folds a traffic-weighted pace factor in to slow the blast on networks that are spam-blocking or rejecting, degrading open (factor 1.0) on any feedback gap.
At each batch the governor and adaptive pacing multiply together and clamp the rate that throttle_rate + ramp_up produced. The effective send rate is the lowest of what those four controls allow, never higher. The governor is the only one that can also stop the campaign: the daily-cap verdict defers and auto-pauses where the others only slow.

Operational notes

  • Single source of truth. Deriving from trust_score reads the same resolver the /10dlc/brands/:id/throughput endpoint uses, so the send loop and the display endpoint never disagree about the ceilings. Pin a lower ceiling only with the mpm / daily_cap overrides.
  • Resume-safe. The per-brand cap tail is re-computed from daily_baseline + parts sent this run each batch, so pausing and resuming a campaign re-checks the current consumption rather than inheriting a stale pre-pause tally.
  • Auditable. The governor logs the resolved ceilings and the cap verdict when it auto-pauses, and the pause reason names the exact cap and consumed count. A paused campaign is explainable, not silent.

  • 10DLC marketing baseline: the everyday US SMS posture this enforcement plugs into; the checklist names “keep throughput ahead of volume” and the governor is the send-side close of that.
  • Messaging best practices: number warm-up, throughput tiers, and the delivery-rate posture around campaigns.
  • Channel rate overrides: tenant-owned per-channel rate overrides; the governor is the carrier-assigned counterpart to those operator-set overrides.
  • 10DLC rejections and re-vet: read the throughput classes, re-vet the brand when volume approaches the tier.
  • Campaign end-to-end: the full campaign variables surface the governor block lives in.