# BRD-222 — Editing the brand expires a completed vet

> A completed vet expires when the brand information behind it changes.

- **Rule ID:** BRD-222
- **Layer:** Brand (`BRAND`)
- **Checks:** `the brand diff vs the vet state`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** Deterministic (settled in code from the submitted values)
- **Fix type:** Wait on an external system or a required interval
- **Required by:** TCR
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-222/

## Why this rule exists

The vet certifies the brand as it stood, so an edit invalidates it in the same way a change of address invalidates an identity document — and the expiry is silent. Throughput drops back to the unvetted tier and the first anyone knows is a queue building on a send that used to clear.

## How to fix it

Batch brand edits and make them before ordering the vet, not after. Where an edit is unavoidable on a vetted brand, budget for re-ordering the vet and expect the cooldown in BRD-221 to apply to it.

## Check this yourself

**Is this brand edit worth losing the completed vet that is pinned to the current record?**

1. Check whether a completed vet is attached before making the edit.
2. Batch edits and make them before ordering the vet, not after.
3. Where the edit is unavoidable, budget for re-ordering the vet and expect the three-month cooldown to apply.

*What wrong looks like:* The expiry is silent. Throughput drops to the unvetted tier and the first anyone knows is a queue building on a send that used to clear.

## Notes

The expiry happens at the registry when the change lands. What the user has to do is treat a completed vet as pinned to the current brand record: check whether an edit is worth losing it before making it, because getting it back costs the fee again and the time again.