Predictika · Outbound Consent Check

Before an AI agent sends a marketing message, the consent is checked

Orchid Retail, a fictional retailer, lets AI agents and campaign tools send email, text messages, automated calls and push notifications to customers in the United States, the United Kingdom, the EU and Canada. Before a send, the call goes to Predictika’s Outbound Consent Check. It checks the channel and region, whether the recipient is a consumer or a business, the consent on record and its age, opt-outs, the recipient’s local hour, how many messages went out this week, whether the sender is identified and an unsubscribe is present, and any approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Orchid Retail is fictional. The scenarios are illustrative. The rules are a simplified model informed by CAN-SPAM, the TCPA, ePrivacy and GDPR, PECR and CASL; they have not been reviewed by a lawyer and the legal citations were not checked against the primary text in this build.

Scope: one proposed marketing or service message on one channel to one recipient, judged against consent, opt-out, sending-hour and frequency rules in the US, UK, EU and CanadaSee everything this validator covers

This validator decides one thing: whether one proposed message to one recipient on one channel may go ahead, given the consent on record and the facts of the send. It is not a legal opinion or a list-hygiene tool.

  • Channels and regions — email, text message, automated call and push notification; United States, United Kingdom, EU and Canada.
  • Rules — opt-out honored, unsubscribe and sender identification, written consent for US texts, allowed sending hours, consent valid for the channel and region, implied consent windows, published addresses, push opt-in, weekly frequency cap, EU business-email and Canadian do-not-call approvals, and consent that is too old.

Within these channels and rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not read message content, check do-not-call registries, cover other countries or states, or decide whether a recipient is really a consumer or a business; those are taken as stated facts or left out.

What the validator sees: facts about the send and the consent, never the recipient or the messageRead more

The validator takes facts as inputs: the channel, the recipient region and type, marketing or service message, the consent on record and its age in days, opt-out status, the local hour at the recipient, messages already sent in the last 7 days, whether the sender is identified and an unsubscribe is present, and the approval on record. These come from the campaign and consent systems at the moment of the call. The validator never sees an address, a phone number or the content.

Two honest limits. The validator judges the facts it is given: if the consent record is wrong, the answer follows it. And a send that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the sending workflow makes the call.

The AI agentProposes a send, says why it is fine, then calls the validator before sending anything.
Predictika validatorReads the channel, region, consent and send facts, applies the rules, then returns one verdict.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where messaging platforms and consent tools get it wrong

Click to expand

General statements about messaging platforms and consent tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

What the validator caughtTypical toolPredictika
The kind and age of consent behind each recipientCannot do it
A messaging platform sends to whatever list it is given. It has no field for whether consent was written, implied or expired, and no way to apply different rules by channel and region.
Every rule is checked on every call and the verdict lists each finding.
Sending only in the recipient allowed hoursOnly if someone is vigilant
Many tools schedule in the sender time zone. A check against the recipient local hour works only when someone writes it and calls it on every send.
Every rule is checked on every call and the verdict lists each finding.
Different rules for the US, UK, EU and Canada in one decisionOnly with workarounds
A tool can hold one rule set per region if someone builds and maintains them. It does not return one answer with every reason across regions and channels.
Every rule is checked on every call and the verdict lists each finding.
Marketing email with no unsubscribeOnly with workarounds
A campaign tool can add the footer automatically. It does not report that a particular send lacks one, or tie that to the channel and region.
Every rule is checked on every call and the verdict lists each finding.
Text without the written consent US law requiresCannot do it
A messaging platform can send to any number on a list. It has no field for the kind of consent behind each number, so it cannot tell written consent from a past purchase.
Every rule is checked on every call and the verdict lists each finding.
Sent outside the allowed hoursOnly if someone is vigilant
Messaging tools often schedule in the sender time zone. A check against the recipient hour works only if someone writes it and calls it on each send.
Every rule is checked on every call and the verdict lists each finding.
Implied consent has run outOnly if someone is vigilant
A mailing list tool keeps addresses. It rarely keeps the date and kind of consent per address, so expiry depends on someone checking by hand.
Every rule is checked on every call and the verdict lists each finding.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

1This marketing email has no working way to unsubscribe (CAN-SPAM 15 USC 7704(a)(3), PECR reg 23, CASL s6(2)(c)).
2The recipient has opted out of marketing by email. The opt-out must be honored (CAN-SPAM 15 USC 7704(a)(4), PECR reg 22, CASL s11).
3This marketing email does not identify the sender with a valid contact address (CAN-SPAM 15 USC 7704(a)(5), PECR reg 23, CASL s6(2)(a)).
4A US text message needs prior express written consent for marketing, or prior express consent for a service message. The consent on record is implied_purchase (TCPA 47 USC 227; 47 CFR 64.1200(a)).
5Marketing by text message at 22:00 local time is outside the allowed hours of 8:00 to 21:00 (47 CFR 64.1200(c)(1) for the US; company policy elsewhere).
6Marketing push notifications need the recipient to have opted in. The consent on record is implied_purchase.
7A published email address gives implied consent only for business messages to a person in their business role (CASL s10(9)). This recipient is a consumer.
8The implied consent on record (implied_inquiry) is 200 days old and the allowed window is 180 days (CASL s10(10); company policy for the EU and UK).
9No valid consent for marketing by email to a consumer recipient in United Kingdom. The consent on record is no_consent (ePrivacy Art 13, PECR reg 19 and 22, CASL s6 and s10).
10This would be message 5 to this recipient in 7 days by email, above the cap of 4 (company policy).
11Marketing email to a business recipient in the EU depends on each member state rule for corporate subscribers (ePrivacy Art 13(5)). Legal must confirm the country.
12Marketing calls to Canada must also be checked against the National Do Not Call List and the telemarketing rules, which this validator does not model. Compliance must confirm.
13The consent on record is 1400 days old, over the 1095 day refresh limit (company policy). A person must confirm it is still valid.

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Unsubscribe: Email with no unsubscribe link

The agent's request. I'm sending the spring promotion email to one US customer. The sender is identified, but I left out the unsubscribe link.

Verdict: Blocked.

  • Marketing email with no unsubscribe. This marketing email has no working way to unsubscribe (CAN-SPAM 15 USC 7704(a)(3), PECR reg 23, CASL s6(2)(c)).

2. Unsubscribe: The unsubscribe link added

The agent's request. I'm sending the same spring promotion email to the US customer, now with the unsubscribe link added.

Verdict: Allowed.

3. Texting: Marketing text to a customer who never agreed

The agent's request. I'm texting a promotion to a customer who bought 40 days ago. They never signed up for texts.

Verdict: Blocked.

  • Text without the written consent US law requires. A US text message needs prior express written consent for marketing, or prior express consent for a service message. The consent on record is implied_purchase (TCPA 47 USC 227; 47 CFR 64.1200(a)).

4. Texting: Written text consent on file

The agent's request. I'm sending the promotion text to a customer who gave written consent to marketing texts 40 days ago.

Verdict: Allowed.

5. Sending hours: Written consent, but sent at 22:00

The agent's request. I'm sending the promotion text to the customer with written consent. It is scheduled for 22:00 at their end.

Verdict: Blocked.

  • Sent outside the allowed hours. Marketing by text message at 22:00 local time is outside the allowed hours of 8:00 to 21:00 (47 CFR 64.1200(c)(1) for the US; company policy elsewhere).

6. Sending hours: The same text rescheduled to 9:00

The agent's request. I'm sending the same promotion text to the customer, rescheduled to 9:00 at their end.

Verdict: Allowed.

7. Implied consent: Canadian customer who inquired 200 days ago

The agent's request. I'm emailing a promotion to a customer in Canada who sent us an inquiry 200 days ago.

Verdict: Blocked.

  • Implied consent has run out. The implied consent on record (implied_inquiry) is 200 days old and the allowed window is 180 days (CASL s10(10); company policy for the EU and UK).

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. Orchid Retail, a fictional retailer, lets AI agents and campaign tools send email, text messages, automated calls and push notifications to customers in the United States. Before a send, the call goes to Predictika’s Outbound Consent Check. It checks the channel and region, whether the recipient is a consumer or a business, the consent on record and its age, opt-outs, the recipient’s local hour, how many messages went out this week, whether the sender is identified and an unsubscribe is present, and any approval on record. Then it returns one verdict: allow, needs approval, or block.
  2. I will start with the first request by the agent.
  3. The agent says. I'm sending the spring promotion email to one US customer. The sender is identified, but I left out the unsubscribe link.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with one finding, all in one answer. This marketing email has no working way to unsubscribe (CAN-SPAM 15 USC 7704(a)(3), PECR reg 23, CASL s6(2)(c)).
  6. The validator returned one blocking finding in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
  7. What this shows: for marketing email with no unsubscribe, a tool can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the unsubscribe link to present.
  10. It calls the validator again.
  11. This time the validator clears it.
  12. The earlier finding is cleared.
  13. One problem caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.