Compliance
A message leaves only after policy allows it
Eligibility, suppression and sending identity are decided before delivery. A gate that cannot decide blocks the send, so a failure is never read as permission.
- 1Use case
- 2Contact and channel eligibility
- 3Suppression
- 4Sender and provider
- 5Allow or block
Any gate that cannot decide blocks the send. A failure is never treated as permission.
Channels
What is open today
This is the current state of the product, not a roadmap.
| Channel | Status | What that means |
|---|---|---|
| Open for approved use cases | A message may be sent only for a use case we have approved, and only after the gates above allow it. | |
| SMS | Closed | No SMS is sent. The capability exists in the product but is not enabled, and SMS is not a blanket cold-outreach channel even when it is opened for an approved use case. |
| Voice | Closed | No calls are placed. There is no dialer and no voice delivery. |
Opt-out
How stopping works
An opt-out is recorded against the contact and the purpose, not against a single message. Once recorded, it is checked before every later attempt, and a suppressed contact cannot be re-added by importing the same list again.
Every message carries a working way to stop. A request to stop is honoured for the purpose it names, and an unsubscribe link never requires an account to use.
Data
Where the data comes from and what is kept
Audience attributes and signals carry their source and the time they were observed. Public registry data is attributed to the registry it came from; a change that cannot be attributed is not used to justify a message.
A contact record holds what was sent, when, by whom it was released, and the reply or accepted result it produced. That record is what an auditor reads.
Jurisdiction and consent detail
Permission is evaluated per contact, per channel and per purpose. Where a jurisdiction requires a stricter basis than the use case claims, the stricter rule decides. Where the basis cannot be established, the send is blocked rather than attempted.
Consent changes are recorded with their reason and the actor who made them, so a later reviewer can see not only the current state but how it was reached.
Sender and provider detail
Sending identity is configured per approved use case: the sending domain, the from-address and the provider. A change of sending identity is an administrative act and is recorded as one.
A provider failure is not a reason to fall back to an unapproved sender. If the approved path is unavailable, the message waits.