# OPS-141 — One approved number is controlled by one party

> Sub-aggregation is prohibited: no more than one party may control the content sent from, or the numbers receiving on, a single approved number.

- **Rule ID:** OPS-141
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `number to content-provider mapping`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Hard stop — not remediable, resubmission will not help
- **Required by:** T-Mobile, AT&T, Verizon, CTIA, Bird, Vonage
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-141/

## Why this rule exists

The registration says who is behind a number, and sub-aggregation makes that untrue — the consumer receives messages from an entity that was never vetted, and a complaint traces back to a brand that did not send it. It also breaks the one-opt-in-per-message-sender rule underneath, because consent given to one party is being used by another. Agencies and franchise groups arrive here honestly, by provisioning centrally and letting each client send.

## How to fix it

Register a separate brand and campaign for each party whose content goes out, and give each its own numbers. Where a shared arrangement is genuinely needed, get it approved and keep the sender register OPS-142 describes rather than operating it informally.

## Notes

Absorbs OPS-266 and MSG-140, which state the same prohibition from the shared-number and message-content sides. Partly visible in what a submission describes and not settleable from it — the arrangement lives in an operating model rather than in a field. What the user has to establish is who can send from each number today, and register a separate brand per party where the answer is more than one. OPS-367 is the ISV form of the same requirement.