# OPS-055 — Revoke-all across categories has a deadline

> A suppression architecture that cannot revoke across every message category for a sender must be flagged before the federal revoke-all rule takes effect on 31 January 2027.

- **Rule ID:** OPS-055
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `suppression list data model`
- **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** Human check — only someone holding the document can settle it
- **Fix type:** Wait on an external system or a required interval
- **Required by:** FCC
- **Applies:** Applies to every 10DLC registration.
- **In force from:** 2027-01-31
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-055/

## Why this rule exists

The rule is scheduled rather than hypothetical, and the work it implies is architectural: a brand whose consent and suppression are modelled per programme cannot become category-wide with a configuration change. Naming it now is what makes it a planned migration rather than a discovery made in the month it applies.

## How to fix it

Check now whether one revocation can suppress every category a sender operates, and if it cannot, schedule the change against the January 2027 date. Done when a single revocation demonstrably clears every programme the brand runs.

## Check this yourself

**Is suppression on your platform keyed per sender or per programme — and if per programme, is the migration scheduled against 31 January 2027?**

1. Answer the one architectural question: can a single revocation clear every category this sender operates?
2. If it cannot, schedule the change now. A per-programme consent model does not become category-wide with a configuration change.

*What wrong looks like:* The rule is scheduled rather than hypothetical, and it is discovered in the month it applies — when the work it implies is architectural rather than a setting.

## Notes

A future obligation about a system we cannot inspect, carried at LOW until it takes effect and BLOCKING after. What the user has to do is answer one question about their own platform — is suppression keyed per sender or per programme — and start the migration if the answer is the second.