​

Suppression vs Consent Precedence Model

​

1. Why Inbound vs Outbound Consent Differ

• Inbound requests (STOP family) assert an immediate, unconditional right to halt contact. When a recipient texts a recognized opt-out keyword (STOP, UNSUBSCRIBE, CANCEL, QUIT, or localized synonyms documented in the Opt-Out Keyword Alias Table), Orbit writes an inbound suppression entry with scope all. This suppression acts as an absolute block. It ignores any previously active consent records, bypasses marketing preference profiles, and prevents further standard outbound dispatches to that identifier.
• Outbound dispatches require multi-layered evaluation before transmission. An outbound message or voice call does not simply query a single boolean flag. Instead, the dispatch pipeline evaluates:
  1. Suppression check: Is the recipient identifier present on the tenant suppression list for the target channel or under scope all? If suppressed, the send is dropped immediately.
  2. Consent check: If the tenant enforces affirmative consent (via consent_required), does an active, unexpired opted_in grant exist for this specific channel and message type?
  3. Timing and regulatory windows: Is the message within permitted local hours according to tenant quiet-hours rules and statutory windows?
  4. Destination and sender rules: Does the destination country or route enforce registration preflight checks (e.g., 10DLC campaign profiles, alphanumeric Sender ID registrations, or DLT templates)?

​

2. Interaction Matrix: Suppression Scope vs Consent Scopes

​

3. Worked Scenario: The STOP → START → Transactional Lifecycle

[Day 1] Customer opts in via web checkout 
        └── Recorded: consent_state='opted_in', consent_type='marketing', channel='sms'

[Day 10] Customer receives promotional SMS and replies 'STOP'
        ├── Trigger: Canonical opt-out alias match
        ├── Action 1: consent_records updated with consent_state='opted_out', source='inbound_keyword'
        └── Action 2: suppression_list entry created with scope='all' for the E.164 phone number
        └── Result: Number is completely fenced. Marketing and standard sends are BLOCKED.

[Day 12] Customer logs in and texts 'START' to re-subscribe
        ├── Trigger: Canonical opt-in alias match
        ├── Action 1: suppression_list entry for the number is removed
        └── Action 2: New consent_records row appended: consent_state='opted_in', source='inbound_keyword'
        └── Result: Number is unsuppressed.

[Day 13] Tenant dispatches a Transactional Send (Order Confirmation / OTP)
        └── Evaluation:
            1. Suppression check: Negative (cleared by START).
            2. Consent check: Message categorized as 'transactional'.
               Under 'exempt_transactional: true', transactional messages rely on contractual basis
               and do not require active marketing consent.
            3. Quiet-hours check: Evaluated against tenant rules.
            └── Outcome: Dispatched successfully.

​

Key Behavioral Rules in This Scenario

1. STOP writes scope all: When the recipient sent STOP, Orbit stamped suppression across all channels for that phone number (SMS, WhatsApp, voice). Even if the user only intended to stop promotional SMS, the platform adheres to TCPA revocation parity: a phone-level stop fences the device.
2. START unblocks suppression: The inbound START keyword clears the active suppression row written by the previous opt-out and appends a fresh opted_in audit record. Historical revocation records are never deleted; a new grant is appended.
3. Transactional gating: Does marketing consent gate transactional messages? No. When exempt_transactional is enabled (the default setting in Orbit preflight), transactional messages rely on contractual necessity or legitimate interest rather than marketing consent. However, if the recipient remained in active STOP suppression, even transactional sends would be blocked by the transport firewall until unsuppressed.

​

4. Role Mapping: Consent-First Architecture vs Inbound Suppression

+---------------------------------------------------------------------------------------+
|                                    OUTBOUND PIPELINE                                  |
|                                                                                       |
|   +-----------------------+      +-----------------------+      +-----------------+   |
|   | 1. Suppression Fence  | ---> |   2. Consent Gate     | ---> | 3. Dispatch     |   |
|   | (Defensive Drop)      |      | (Affirmative Opt-In)  |      | (Quiet Hours &  |   |
|   | Check: suppression    |      | Check: consent_record |      | Country Gates)  |   |
|   +-----------------------+      +-----------------------+      +-----------------+   |
|              ^                              ^                                         |
+--------------|------------------------------|-----------------------------------------+
               |                              |
+--------------|------------+   +-------------|-----------------------------------------+
|    INBOUND SUPPRESSION    |   |           CONSENT-FIRST ARCHITECTURE                  |
|                           |   |                                                       |
| • Handles STOP / CANCEL   |   | • Handles web signup forms & double opt-in handshakes |
| • Writes scope='all'      |   | • Scoped to specific channels and purposes           |
| • Immediate drop filter   |   | • Tracks legal basis (GDPR Art 6, TCPA, DPDP)        |
| • Zero marketing leeway   |   | • Evaluates validity_until expiration windows         |
+---------------------------+   +-------------------------------------------------------+

​

Inbound Suppression (Defensive Layer)

• Purpose: Defensive compliance enforcement protecting recipients from unwanted contact after revocation.
• Trigger Mechanism: Inbound keyword replies (STOP, END, QUIT), manual CSV bulk suppression imports, or API revocations (opt_in: false).
• Enforcement Behavior: Acts as a hard firewall at the entry point of the send service. If an identifier matches an active suppression row for the given channel or all, the pipeline drops the request before queuing or billing.
• Scope: Default all across all messaging and voice capabilities linked to that phone number.

​

Consent-First Architecture (Affirmative Layer)

• Purpose: Lifecycle tracking of affirmative permissions granted by data subjects for specific communication categories (e.g., promotional newsletters, product alerts, automated agent outreach).
• Trigger Mechanism: Web forms, double opt-in confirmation handshakes (POST /compliance/consent/double-opt-in), paper agreements, or signed digital receipts.
• Enforcement Behavior: Evaluated downstream from the suppression check. Verifies whether an active, non-expired grant exists under consent_records before permitting marketing traffic.
• Scope: Granular per channel (sms, whatsapp, email, voice) and per purpose (marketing, transactional).

​

Related Guides

• Opt-Out Keyword Alias Table — Seeded multi-lingual STOP and START keyword vocabularies and scope propagation rules.
• Consent Management & Receipts — Recording affirmative grants, revocation flows, expiry windows, and signed DPDP receipts.
• Opt-Out & Suppression Lists — Bulk suppression import workflows, deduplication rules, and ledger exports.
• Send Gates & Quiet Hours — Pre-flight timing windows, BAA requirements, and carrier pre-flight linters.