# POL-232 — Every opt-in surface on the site must appear in the terms

> Every opt-in surface found by crawling the site must be represented in the list of opt-in methods in the SMS terms.

- **Rule ID:** POL-232
- **Layer:** Policy pages (`POLICY_PAGE`)
- **Checks:** `crawled opt-in surfaces vs SMS terms opt-in list`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Fix the privacy policy or SMS terms
- **Required by:** Twilio
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-232/

## Why this rule exists

This is the same question as POL-181 asked from the other side, and it catches the case the declared flow cannot: a sign-up form somebody built for a campaign months ago, still live, feeding the same programme. A subscriber who joined through it reads terms that do not describe how they got there.

## How to fix it

Inventory every form on the site that collects a mobile number for messaging, then either list it in the terms or take it down. Done when the terms describe every live route into the programme.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen2) | `30909` | yes |

## Notes

Decided from the crawl rather than the declared flow, which is why it is separate from POL-181 — the two disagree independently, and this is the one that finds the surface nobody remembered.