# OPS-223 — The retention clock starts at the last message, not the opt-in

> The retention period must be measured from the last message sent in reliance on the consent, not from the date the consent was collected.

- **Rule ID:** OPS-223
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow + privacy policy`
- **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:** FCC, PossibleNOW
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-223/

## Why this rule exists

A limitation period runs from the act complained of, which is a message, not a signup. Anchoring at collection shortens every window by the life of the subscription: a consumer who opted in five years ago and was messaged last month has a record that a collection-anchored policy deleted years before the message that will be complained about. It is a one-line difference in a retention policy and almost nobody writes it deliberately.

## How to fix it

Write the anchor into the retention sentence: measure from the last message sent in reliance on that consent, and re-arm the clock on every send. Done when a long-standing subscriber's record survives as long after their most recent message as a new subscriber's does after their first.

## Example of a compliant value

```text
Consent records are retained for five years from the last message sent in reliance on that consent.
```