Consent is a system, not a checkbox

Evidence, withdrawals and delivery decisions across channels.

Research checked October 16, 2026 · Publication and proposed design only

A design and research section, not a live consent service. Nothing here enrolls a recipient, sends a message or implements a compliance system. The goal is to make permission evidence, withdrawal and delivery decisions reviewable.

Start with three separate questions

1. May this sender contact this recipient for this purpose? Evaluate applicable law, the actual message and technology, permission evidence and current withdrawals.
2. Will this provider and route permit it? Check carrier registration, provider policy, sender identity and technical suppression.
3. Can we prove our system respected both? Keep decision evidence and test queued work, retries, migration and races.

Passing one gate does not pass the others. TCR registration is not subscriber consent. An OS push grant is not an all-purpose marketing basis. Permission to receive an image does not grant publication rights. A provider's accepted response is not delivery or permission.

Read the section

• 1. Channels, law and effective dates — SMS/MMS, AI and human voice, CAN-SPAM, push, recording and media; US baseline and pending FCC changes.
• 2. TCR and provider practices — Twilio, SignalWire and Telnyx acquisition rules, native suppression boundaries, APIs, callbacks and unresolved capabilities.
• 3. A proposed Rails consent ledger — evidence, sender/purpose scopes, enqueue/dispatch decisions, STOP races, privacy and failure tests.

What the labels mean

Law / regulation

A source-backed legal baseline with jurisdiction and effective-date limits, requiring program-specific review.

Provider policy / documented behavior

Contract, onboarding or API requirements. They can be stricter than law and differ by product or route.

Engineering recommendation

Our proposed control, not an assertion that every field or design choice is legally mandated.

Verified here

Research and publication checks only. No account-level configuration, delivery behavior or deployed consent engine was verified.

A practical consent record

Represent the actual legal sender and brand, tenant/rooftop, recipient ownership context, destination, channel, purpose, disclosure version, affirmative action, evidence source and time. Keep marketing and service purposes explicit. Record withdrawal and later narrow re-enrollment as new events. Do not overwrite the history with a single subscribed flag.

Give people clear optional choices and an accessible way to change them. Marketing SMS, requested service updates, email, voice and push are distinct decisions. Recording/transcription and media rights need separate review. An existing customer list, purchased lead or broad “contact me” field is not sufficient evidence for every use.

Implementation priorities and acceptance gates

1. Inventory and policy review. List every automated/manual sender, represented business, channel, provider, purpose and jurisdiction. Success: no unowned sending route; uncertain legal or source evidence is held for review.
2. Evidence and suppression. Import restrictions first; keep historical grants unverified until supported. Success: all routes consult one authoritative decision, with correct brand/channel/purpose scope and tenant isolation.
3. Dispatch protection. Add durable outbox intentions, fresh authorization, attempt reconciliation and authenticated callbacks. Success: STOP before the defined dispatch boundary prevents submission; in-flight uncertainty is visible and later attempts stop.
4. Failure testing and rollout. Test races, duplicate/reordered callbacks, stale caches, reassignment and provider timeouts. Success: independently reviewed fixtures, synthetic-data tests, kill switch and rollback that preserve withdrawals before any canary.
5. Operations and maintenance. Review law/policy dates and provider changes, suppression lag, failed callbacks, unknown attempts and retention. Success: an assigned owner, auditable decisions and explicit unresolved gaps. No recurring review job is installed by this article.

Scope and honest limits

Research date: October 16, 2026. The legal guide is a US federal starting point, not a state-by-state or international survey. A dated FCC change needs effective-date verification before activating new permissions. Provider documentation is not a test of an enabled account. This section does not promise “bulletproof” compliance or replace legal review.

Ruby already requires provider adapters, tenant-scoped message history, signature-checked webhooks and independent review. This proposal builds on services, identity, testing and Rails synchronization; it does not claim those recommendations constitute a deployed consent engine.