# MSG-SAMPLES-USECASE — Sample messages must match the declared use case

> The content of the samples must be consistent with the campaign use case selected.

- **Rule ID:** MSG-SAMPLES-USECASE
- **Layer:** Message content (`MESSAGE_CONTENT`)
- **Checks:** `campaign.sample[] + campaign.usecase`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** TCR, Twilio, Bandwidth, AWS, Sinch
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/message-content/msg-samples-usecase/

## Why this rule exists

The use case determines the consent standard, the throughput a carrier grants, and the filtering applied to your traffic. A campaign registered as ACCOUNT_NOTIFICATION that sends promotions is receiving treatment it did not qualify for, so the mismatch is a registration integrity problem rather than a labelling error.

## How to fix it

Either change the use case to match what you actually send, or replace the off-pattern samples. If you genuinely send both promotional and transactional content, select MIXED and show both — but note that MIXED requires promotional-grade consent.

## Example of a compliant value

```text
For ACCOUNT_NOTIFICATION: "Acme Coffee: your payment of $24.50 was received. View receipt: https://acmecoffee.com/r/4471 Reply STOP to opt out."
```

## Common mistakes

- A single promotional sample inside an otherwise transactional set is enough to trigger this — Bandwidth codes it separately as 8200.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen1) | `30893` | yes |
| Bandwidth | `8200` | yes |