> ## 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.

# Sender identity classification model

> How Orbit classifies each sender identity you use — long code, toll-free, short code, or alphanumeric sender ID — what the classification changes on the compliance-evaluated send path (quiet hours, RND, opt-out posture), and how to read the type from the Messaging Compliance Health panel.

# Sender identity classification model

A tenant's sender pool usually mixes several kinds of `from` identity —
geographic long codes, NANP toll-free numbers, numeric short codes, and
alphanumeric A2P sender IDs (`"Devotel"`, `"INFO"`). The sender-identity
classifier resolves each of those to its true identity type so every
compliance surface can label the sender under the right class instead of
lumping every row under "Number". This page is the model for that link:
how the classification flows, which send-time gates apply differently
per class, how you read the verdict in the dashboard, where it meets the
messaging services console, and the constraints of the classification.

## 1. The classification flow

The classifier is a pure mapping: **sender number → line-type
classification → sender-identity type output**. The
[line-type and reachability model](/concepts/line-type-and-reachability)
owns the layer that decides the structural shape; the sender-identity
resolver layers its per-class rules on top to emit exactly one of five
outputs.

| Identity shape                                | Classifier output | What decides it                                                                                          |
| --------------------------------------------- | ----------------- | -------------------------------------------------------------------------------------------------------- |
| Branded A2P sender ID (`"Devotel"`, `"INFO"`) | `alphanumeric`    | a non-numeric alphabetic string (blended letters and digits also classify as alphanumeric)               |
| Numeric short code, 3–8 digits, no `+` prefix | `short_code`      | digit-only identifiers outside the meaningful E.164 range                                                |
| NANP `+1` 800/833/844/855/866/877/888 number  | `toll_free`       | an explicit toll-free prefix check that beats the geographic long-code branch                            |
| Any other complete E.164 number               | `long_code`       | a valid geographic E.164 that is not NANP toll-free                                                      |
| Fully invalid or unmatched input              | `unknown`         | the resolver's fail-safe never throws — a muted "Unknown" chip renders instead of a wrong classification |

The display layer flattens each verdict to a label — the badge component
keys on these five ids.

<Note>
  A NANP toll-free number beats the plain E.164 long-code branch:
  `+1` numbers carrying the 800/833/844/855/866/877/888 prefixes resolve
  to `toll_free`, not `long_code`. The ordering matters — toll-free
  senders carry their own Toll-Free Verification registration path, so
  labelled surfaces must distinguish them from geographic long codes.
</Note>

## 2. Per-classification guidance — which gates apply differently

The classification does not itself change the gate chain; it makes the
gate chain readable per class and selects which registration and
gate-wiring guidance applies. Every per-sender gate remains
tenant-owned (except the sole platform-global federal TCPA dialing
window) — where a gate's posture differs by sender class, the class
badge makes that visible.

* **`alphanumeric`** — mandatory in EU / MENA / APAC A2P markets. US and
  Canada corridors reject alphanumeric MT, so a per-country pool map
  must keep numeric-only pools for `+1` recipients. Registration posture
  varies per country (`none` / `recommended` / `required`) — read it in
  [Country Compliance Requirements](/compliance/country-requirements),
  and register where required via
  [Sender-ID Registration](/compliance/sender-id-registration).
* **`long_code`** — passes the alphanumeric classes above but still hits
  the per-country sender-type rules; on US corridors the 10DLC
  registration path applies instead of alphanumeric or Toll-Free
  Verification. Quiet-hours and RND safe-harbor gates resolve on the
  recipient line, not the sender class — the sender class only shapes
  which sender-identity rules apply, not the recipient-time gates.
* **`toll_free`** — carries its own Toll-Free Verification registration
  path rather than 10DLC. Unverified toll-free senders hit their own
  gating before a send dispatches, which the classifier's distinct
  `toll_free` label on the compliance panel is what makes visible.
* **`short_code`** — gated by short-code-specific preflight; see
  [Short-code preflight](/compliance/shortcode-preflight) for the
  checklist. Their quiet-hours and opt-out posture differs from 10DLC
  numbers by corridor, not by the classifier itself.
* **`unknown`** — read as an inventory anomaly, not a hunt-the-shape
  signal. Re-check the sender value — a malformed or unmatched sender
  string never classifies on send either, so verify the stored value
  rather than assuming a wrong type was applied.

For the quiet-hours, RND, and opt-out gates matched per surface, see
[Send Gates](/compliance/send-gates) — the identity resolver only makes
those gate decisions readable per sender class; ownership and wiring
stay with the tenant.

## 3. How you read the classification

The Messaging Compliance Health panel's per-sender table renders each
sender under its classified type label — "Long code", "Toll-free",
"Short code", "Alphanumeric sender ID" — rather than a bare "Number"
column. The resolver computes the class on render from the message's
`from` identity; label rendering lives in the component, and the
classifier itself returns the raw id the chip keys on.

Without this layer every row in the per-sender table would claim "Number"
for an alphanumeric or short-code sender identity, or carry a wrong
claim when the stored string is invalid (`unknown`) rather than classify
it as a telephone number.

## 4. Interaction with messaging services and pools

The classifier resolves on the **sender identity value** — it does not
know or care which construct owns the sender. An inline `from`, a pool
member, or a messaging service's resolved sender all pass through the
same classification function. For which construct wins on a given send,
see the [sender construct decision model](/concepts/sender-identity-decision-model);
for how services bundle defaults, see
[Messaging services](/concepts/messaging-services-model). The
classification surfaced on the compliance panel is the same verdict
regardless of construct — it carries no service-specific advisory.

## 5. Constraints

* **The classification is static per sender value, not per send.** A
  given `from` string always resolves to the same five-output id; the
  resolver holds no state between calls.
* **The classifier labels; the gates decide.** Sender-type resolution
  tells the surfaces what a sender *is*. The send gate chain (quiet
  hours, DNC, RND, country sender-type rules) evaluates recipient-time
  and corridor posture separately — see
  [Send Gates](/compliance/send-gates).
* **Fail-safe over assertive.** `unknown` never throws; the badge
  renders muted rather than assert a wrong class on an invalid stored
  value.
* **Pool-type and sender-type are separate classifications.** A pool's
  purpose (`inbound_did_route` vs `a2p_sender` vs `mixed`) is derived
  from its membership and documented on
  [Sender resolution](/concepts/sender-resolution); the identity
  classifier classifies each member's type independently. Both feeds
  reclaim per-sender compliance panels.
* **Class movements are rare and manual.** An invalid value stays
  `unknown`; a sender you re-register as toll-free verified changes
  nothing in the classification layer — verification state lives
  elsewhere, the type does not change.

## Related references

* [Line type and reachability classification model](/concepts/line-type-and-reachability) —
  the three classification surfaces and where sender-identity resolution
  sits beside them.
* [Send Gates](/compliance/send-gates) — the quiet-hours, DNC, RND, and
  country-rules evaluations the classification labels per sender.
* [Country Compliance Requirements](/compliance/country-requirements) —
  per-country sender-type rules and registration posture.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
  alphanumeric registration flow.
* [Messaging services](/concepts/messaging-services-model) — the service
  entity and its sender defaults.
* [Sender construct decision model](/concepts/sender-identity-decision-model) —
  which construct owns the sender the classifier labels.