> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The US SMS Regulatory Model: Three Rule Books, One Control Plane

> One concept page that explains how TCPA, CTIA, and carrier A2P rules intersect for a US SMS tenant, and how Orbit divides the labour: what the platform enforces, what you configure, and where the single federal guard sits.

# The US SMS Regulatory Model: Three Rule Books, One Control Plane

Every US SMS you send is read against three rule books at once: a
federal statute, an industry self-regulation code, and the carriers'
own application-to-person (A2P) enforcement. The deep pages in this
docs group cover each control on its own surface. This page is the
concept that ties them together: read it once to answer three
questions, then dive into the owning deep page for any row you need
to configure.

1. **What does Orbit enforce?** The gates you switch on, the keyword
   floor, the suppression entries that exist, and one platform-owned
   federal guard.
2. **What do I configure?** Everything else: consent posture, opt-out
   lists, quiet hours, lane tags, and the scrubs you opt into.
3. **Where does the federal guard sit?** On the voice dialing window
   only. SMS has no platform-side equivalent; on SMS the statute is
   your obligation and Orbit gives you the controls to honour it.

<Warning>
  This page describes Orbit's platform controls. It is **not legal
  advice.** Which rules apply to your traffic depends on what you send
  and to whom, and every control named here is tenant-owned except the
  single federal guard in [Section 7](#7-the-single-global-guard-everything-else-is-yours).
  Confirm your posture with qualified counsel.
</Warning>

***

## 1. The three regulators, one control plane

| Rule book | What it is | What it cares about | The Orbit surfaces that answer it | Read it here |
| - | - | - | - | - |
| **TCPA** (47 U.S.C. § 227) | Federal statute | What is *illegal*: texts without prior express consent, telemarketing outside permitted hours. Priced per violation, $500 to $1,500 each | Consent ledger, consent preflight, quiet-hours gates, suppression | [TCPA posture guide](/compliance/tcpa-posture-guide), [TCPA consent record defense](/compliance/tcpa-consent-record-defense) |
| **CTIA Messaging Principles** | Carrier self-regulation | The operational mechanics: A2P vs P2P lanes, SHAFT content categories, opt-in disclosures, STOP/HELP/START handling, sender identification | Policy scanner, opt-out rules page, short-code preflight, 10DLC use-case validation | [CTIA Messaging Principles as an ordered schema](/concepts/ctia-messaging-principles) |
| **Carrier A2P rules** (TCR/10DLC, short-code vetting, filtering) | The enforcement layer | Registration, vetting, throughput, and content filtering. This is the layer that actually throttles, blocks, or fines a program | Brand and campaign registration, campaign status, carrier rejection read-outs | [10DLC concept](/concepts/10dlc-concept), [10DLC baseline posture](/guides/10dlc-marketing-baseline) |

The three intersect in a fixed order. TCPA sets the legal floor and is
silent on *how* you wire the controls. CTIA translates that floor into
the operational checklist a carrier audit or TCR re-vet actually runs:
a program can be TCPA-compliant on paper and still fail the audit
because the opt-in disclosures, the keyword set, or the SHAFT posture
do not match the Principles. The carriers then enforce the result
operationally, through registration, vetting, and filtering, whether or
not anyone ever files a lawsuit.

Orbit divides the labour the same way. The platform carries the
configuration and the ledger, enforces exactly what you set, and feeds
you the carrier-side read-outs. The decisions (which posture to run,
which lanes to tag, which lists to import) stay yours. The one
exception is the federal voice guard in
[Section 7](#7-the-single-global-guard-everything-else-is-yours).

***

## 2. The opt-in sum-of-parts

Five pieces make up the opt-in side, and each already has its own
page. This section is how they connect.

* **The consent ledger** is the record everything else reads: one
  receipt per `(contact, channel)`, written at a recorded opt-in
  moment, carrying the channel and message type it covers and its
  expiry. [Consent Management](/compliance/consent-management) owns the
  API; [Consent and suppression model](/concepts/consent-and-suppression-model)
  owns the data model.
* **The double-opt-in handshake** is how a claimed opt-in becomes a
  provable one: the confirmation turn that upgrades a sign-up into a
  receipt a carrier audit will accept. See
  [Double opt-in](/compliance/double-opt-in) and
  [SMS double opt-in enforcement](/guides/sms-double-opt-in-enforcement).
* **`consent_required`** is the org-wide gate. It ships **off**; a new
  tenant's sends are not consent-preflighted until you enable it.
  Enabled, any gated-channel send to a contact without an active,
  unexpired opt-in for that channel and message type is refused. See
  [Compliance gate error codes](/compliance/compliance-gate-error-codes-faq)
  for the refusal contract.
* **`consent_default_policy`** decides what a *missing* ledger row
  means for CDP destination fanouts and subscription gates. The
  default `permit_on_missing` is fail-open; `deny_on_missing` flips it
  fail-closed. Universal legal gates (revoked consent, erasure) apply
  regardless of the setting. See
  [Consent posture: the unknown-consent policies](/compliance/consent-default-policy).
* **`unknown_marketing_policy`** decides what happens to *marketing*
  addressed to a contact whose consent state is `unknown`. The default
  `refuse` is fail-closed toward marketing: an unknown-consent contact
  receives no marketing. Loosening to `allow_with_logging` is an
  owner-only write that demands a written justification and a lawful
  basis, both recorded in the audit log. See
  [Consent posture](/compliance/consent-default-policy).

The division of labour: the ledger stores receipts, the handshake
writes them with confidence, and the three knobs decide the edges of
the table, namely the org-wide enforcement level, the absent row, and
the unknown state. Set the knobs deliberately; their defaults are a
deliberate pair, fail-open on fanout so a missing row never stalls
operational traffic, fail-closed on marketing so an unknown state
never widens into promotional sends.

***

## 3. The opt-out sum-of-parts

The opt-out side is four pieces, ordered by where they act.

* **Opt-out keyword rules.** The platform seeds the carrier-mandated
  floor (the STOP family, HELP, START) and your rules page can only
  widen it: aliases for the languages you send in, branded re-subscribe
  words. A deleted tenant rule never narrows the floor, so the audited
  posture is always "platform floor plus your additions." See
  [SMS opt-out and opt-in rules](/guides/opt-out-rules) and the
  [opt-out keyword alias table](/compliance/opt-out-keyword-alias-table).
* **Opt-out suppression lists.** Every entry point (a STOP reply, the
  Consent API, the preference center, a CSV bulk import) writes the
  same list, and the send-time gate reads it **fail-closed**: a
  suppressed address is dropped before dispatch, no matter how it
  arrived. Scopes decide breadth: phone rows default to scope `all`,
  which gates voice and dialer traffic too. See
  [Opt-Out and Suppression Lists](/compliance/opt-out-suppression).
* **DNC scrub.** Opt-in (`dnc_sync_enabled` ships off, and queries
  return `403 DNC_SYNC_NOT_ENABLED` until you enable it). Once on,
  `/compliance/dnc/check` and the suppression feed back your dialing
  and sending decisions. Plan around the documented caveat: until a
  federal snapshot is synced, a number only on the FTC list reads back
  clear. See [DNC Scrubbing](/compliance/dnc-scrub).
* **RND check.** Also opt-in, and refused with `409` until the FCC
  reassigned-numbers feed is connected; until then every verdict
  degrades to `no_data` and no safe harbor is claimed. See
  [RND scrubbing](/compliance/rnd-scrub) and
  [Reassigned Numbers Database](/concepts/reassigned-numbers-database).

Keywords write suppression; suppression gates every send; DNC and RND
inform the decision before the send goes out. Together they make
revocation honoured on every channel and provable in the ledger, which
is exactly what a TCPA revocation defense asks for.

***

## 4. The quiet-hours envelope

Three layers, each inside the last.

1. **Tenant channel settings.** The per-channel org gate
   (`settings → quiet_hours.<channel>.enabled`) ships **off** on every
   channel: a new tenant's sends are not held. Enable a channel and the
   platform window 08:00 to 21:00 recipient-local applies immediately,
   or set your own `start_hour` / `end_hour`. The campaign fallback
   window covers drip and journey sends that carry no window of their
   own. See
   [Quiet hours configuration](/guides/quiet-hours-configuration) and
   [TCPA quiet hours and windows](/guides/tcpa-quiet-hours-and-windows).
2. **The policy scanner's lane gate.** The pre-send policy scan emits
   a `tcpa_quiet_hours` finding for a US recipient outside the window.
   In the default `warn` mode it records and sends; in `strict` mode it
   hard-blocks, and only for the **marketing** lane. Transactional
   sends stay a non-blocking warning even in strict mode, because the
   statute restricts telemarketing, not operational traffic. A
   timezone the platform cannot resolve fails open on SMS. See
   [Pre-Send Policy Scanner](/compliance/policy-scanner) and test a
   recipient before a rollout with
   [quiet-hours preview](/compliance/quiet-hours-preview).
3. **The sole federal guard.** Campaign and dialer **voice** to US
   recipients is hard-blocked outside 8 AM to 9 PM recipient-local,
   fails closed when a recipient timezone is unresolvable, and accepts
   no tenant toggle; stricter state overlays (Florida's Sunday ban,
   Mississippi's 7:30 PM close, the Oklahoma, Louisiana, Alabama, and
   West Virginia mini-TCPA windows) intersect on a
   most-restrictive-wins rule. This is the platform's single global
   hard guard, and it is a voice guard: SMS has no platform-side
   equivalent, which is why the two tenant layers above exist. See
   [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard) and
   [Federal vs state vs tenant voice gates](/concepts/federal-vs-state-vs-tenant-voice-gates).

The envelope reads as a contract: outside the federal voice guard,
*when* you may send is your configuration, and the defaults are open
so you tighten from an open posture rather than loosen from a
restrictive one.

***

## 5. Lane resolution, and why silence resolves as marketing

Every send runs on one of two lanes, and two different surfaces ask
the question.

**Throughput and routing** resolve the lane from your send metadata:
an explicit `traffic_lane` value always wins; a campaign or journey
origin defaults to `marketing`; a direct API send with no tag runs
`transactional`. See
[Message priority and traffic lanes](/concepts/message-priority-traffic-lanes).

**Compliance classification** resolves silence the other way, as
marketing, and for a deliberate reason: an exemption from a
telemarketing rule must be *asserted and provable*, never assumed.
Three surfaces apply that rule:

* The strict-mode quiet-hours gate treats an untagged send as
  marketing, so a campaign caller that forgets the tag gets the
  stricter treatment, not a free pass. Tag it `transactional` to claim
  the exemption.
* The federal voice guard records an absent lane as marketing,
  because the window governs marketing traffic; silence bears the
  stricter rule. See
  [Voice traffic lane resolution](/compliance/voice-traffic-lane-resolution).
* The carriers reclassify on content: the moment a "transactional"
  send carries promotional copy, the carrier and content-moderation
  layers read it as marketing regardless of your tag. See the
  [order-dispatch workflow](/guides/order-dispatch-notifications-workflow)
  for the three rules that keep the class clean.

The practical rule: the lane you mean is the lane you tag, and the
content you send must match the lane you claim. Ambiguity is resolved
against you on purpose, because on the compliance surface the cost of
a wrong guess is a statutory violation, not a misqueued message.

***

## 6. The compliance health score as the read-out

Everything above writes into one feedback loop. The compliance health
score (`GET /compliance/health`, plus the per-sender and per-campaign
list endpoints) blends consent coverage, opt-out velocity, STOP-reply
rate, and carrier rejections into a 0 to 100 score per organization,
sender, and campaign, with a ranked `warnings` array of fixes. It
never blocks a send; it tells you which sender is about to be
throttled before the carrier throttles it.

That is the loop the three rule books close through Orbit: a carrier
filter scores your content, a recipient texts STOP, a consent row
expires, and each of those moves the score before it becomes a
rejection or a complaint. Read the score and the warnings before and
after every posture change, and pair it with quiet-hours preview when
you change a window. See
[Compliance Health Scores](/compliance/compliance-health) and
[the SMS complaint feedback loop](/concepts/sms-complaint-feedback-loop).

***

## 7. The single global guard; everything else is yours

One asymmetry defines the whole model. The federal TCPA voice
dialing window is **platform-owned**: no tenant toggle, no opt-out,
fail-closed on an unresolvable timezone, because the $500 to $1,500
per-call statutory penalty is not yours to waive and therefore not
yours to configure. It is the only hard guard Orbit operates globally.

Every other control on this page is tenant-owned and ships open: the
consent gate off, the consent policies at their documented defaults,
the suppression list empty, the keyword floor at the carrier minimum
waiting for your aliases, quiet hours off per channel, DNC and RND
off, the policy scanner in `warn`. The platform enforces what you
set, keeps the auditable ledger of what you did, and never mandates a
posture for you.

That is the answer to the three opening questions. Orbit enforces
your configuration plus one federal guard. You configure everything
else, from an open default. And the federal guard sits on the voice
dialing window only; on SMS the statute is your obligation and the
controls on this page are how you honour it. For the toggle-level map
of the same model, read
[Your Tenant Compliance Posture](/compliance/posture-overview); for
the ownership principle in full,
[Compliance tenant-owned model](/concepts/compliance-tenant-owned-model);
for the operator questions behind both,
[Compliance Posture FAQ](/compliance/posture-faq).

***

## See also

* [CTIA Messaging Principles as an ordered schema](/concepts/ctia-messaging-principles)
* [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard)
* [Consent and suppression model](/concepts/consent-and-suppression-model)
* [Opt-Out and Suppression Lists](/compliance/opt-out-suppression)
* [Pre-Send Policy Scanner](/compliance/policy-scanner)
* [Send Gates](/compliance/send-gates)
* [10DLC concept](/concepts/10dlc-concept)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.