# CMP-101 — A QR opt-in must supply the QR code image itself

> A QR-code opt-in must include the QR image in the registration evidence.

- **Rule ID:** CMP-101
- **Layer:** Campaign (`CAMPAIGN`)
- **Checks:** `opt-in evidence (OptInImageURLs)`
- **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:** Deterministic (settled in code from the submitted values)
- **Fix type:** Supply evidence only you hold
- **Required by:** Twilio
- **Applies:** Applies when consent was collected by QR code.
- **Canonical URL:** https://ekas.io/rules/10dlc/campaign/cmp-101/

## Why this rule exists

The QR code is the only part of a QR flow a reviewer can independently verify: they scan it and see where it actually goes, which is the one thing the description cannot establish. A code that resolves somewhere other than the stated destination is the specific defect this evidence exists to catch, and it is invisible in every other field.

## How to fix it

Attach the QR image exactly as it appears on the printed piece — the same code, not a regenerated one pointing at the same URL — and scan it yourself from a printout before submitting. Done when scanning the attached image lands on the opt-in destination the flow describes.

## Common mistakes

- Regenerating a "clean" QR for the submission defeats the check: the reviewer is verifying the code that is actually in the wild, and a code that has since been re-pointed will scan differently from the one on your poster.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio | `30896` | yes |

## Notes

The presence half is settled here; whether the scanned destination is a compliant opt-in surface is CON-QR-DEST and CMP-103, which read the destination rather than the file. Split because they fail differently and are fixed by different people — one by attaching a file, the other by rebuilding a landing page.