# POL-233 — The document dates must not predate the last change to the programme

> The last-updated dates on the privacy policy and the terms must be no older than the last material change to the messaging programme.

- **Rule ID:** POL-233
- **Layer:** Policy pages (`POLICY_PAGE`)
- **Checks:** `privacy policy + terms dates vs the last programme change`
- **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 privacy policy or SMS terms
- **Required by:** CTIA
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-233/

## Why this rule exists

A programme that gained a message category last month, documented by terms dated two years ago, is telling subscribers about a programme that no longer exists — and CTIA asks for up-to-date information rather than merely dated information. The dates are the cheapest way for a reviewer to spot it, which makes a stale date an invitation to read the rest more carefully.

## How to fix it

Update both documents whenever the programme changes materially — a new message category, a new opt-in surface, a changed frequency — and set the date by hand when you do. Done when both dates are at least as recent as the last change.

## Example of a compliant value

```text
Programme gained cart reminders in June 2026; both documents now read "Last updated: 1 July 2026".
```

## Notes

Authored as a judgement rather than as a predicate on purpose. Comparing a published date against a change that happened "N days ago" needs a clock, and a rule whose verdict changes with the calendar cannot be pinned by a fixture — the corpus would drift silently. The judge is given the campaign fields, which carry how long ago the programme last changed where the caller knows it. Whether a date is present at all is POL-141.