# OPS-256 — A recurring programme should expire consent that has gone quiet

> A recurring programme should describe expiring an opt-in after a long period of subscriber inactivity, with one final notification permitted.

- **Rule ID:** OPS-256
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow`
- **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review.
- **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:** CTIA, AWS
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-256/

## Why this rule exists

A subscriber list that only grows eventually consists mostly of numbers that have changed hands, and every one of those is an unconsented message waiting to be sent. Expiry is the cheap version of the reassigned-number problem: it removes the numbers nobody has heard from, which is the same population, without a database lookup. Brands resist it because it shrinks a number they report on.

## How to fix it

State an inactivity window after which an opt-in expires — eighteen months is the published figure — and describe the single final message that may be sent before removal. Done when the flow says what happens to a subscriber who never engages.

## Example of a compliant value

```text
Subscribers with no engagement for 18 months receive one final notice and are then removed from the programme.
```

## Notes

Registration-side twin: the expiry job runs long after approval. What we judge is whether the programme has a policy for it, which is the part a reviewer can also see.