Live content has to keep matching the registration

The requirementstatement

Traffic must continue to match the registered use case and the registered samples, not merely have matched them at approval.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: live traffic against the registered use case and samples
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: Post-submissionUNDETECTABLE_PRE_SUBMISSION; The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass: Wait on someone elseTERMINAL_EXTERNAL; Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities: TCRT-MobileTwilioTelnyxVonage
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

The samples are a promise about the programme, and programmes drift: a transactional campaign starts carrying a seasonal offer, an account-notification campaign adds a survey. Nobody re-reads the registration when writing a new template, so the drift is gradual and nothing flags it until the traffic no longer resembles what was approved.

How to fix itremediation

Review live templates against the registered samples on a schedule, and register a new campaign — or change the use case — before sending a category the registration does not describe. Done when every template in production would be recognised by somebody reading the registration.

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

Would somebody reading your registration recognise every template now in production?

1Put the live templates next to the registered samples and read them together, on a schedule.
2Register a new campaign — or change the use case — before sending a category the registration does not describe.
3Nobody re-reads the registration when writing a new template, so the drift is gradual and nothing flags it.

What wrong looks like: A transactional campaign starts carrying a seasonal offer; an account-notification campaign adds a survey. The samples were a promise about the programme, and the traffic no longer resembles what was approved.

Notesnotes

Absorbs MSG-279, the same duty from the message-content side. Requires the live templates. What the user has to own is the review: the approval-side rules — MSG-141 and OPS-USECASE-SCOPE — check what was submitted, and neither of them sees what was added afterwards.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-026The universal opt-out keyword set must be declaredBlockingBLOCKING OPS-027Opt-out keyword handling must be declared, not assumedBlockingBLOCKING OPS-029A revocation must survive punctuation, case and surrounding wordsBlockingBLOCKING OPS-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-033STOP must never come back as an errorBlockingBLOCKING OPS-037On a shared address, STOP must stop everythingBlockingBLOCKING

All operational rules

OPS-149 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.