# CON-137 — The consent record must capture the number it authorises

> The consent record must store the specific telephone number the consumer authorised messages to be sent to.

- **Rule ID:** CON-137
- **Layer:** Consent flow (`CONSENT_FLOW`)
- **Checks:** `consent artifact phone field`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Supply evidence only you hold
- **Required by:** FCC, SIP.US
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/consent-flow/con-137/

## Why this rule exists

The federal definition of written consent turns on the number the signatory authorised, so a record proving somebody consented without recording which number they consented for cannot be matched to the message that was sent. It is the failure that surfaces late and badly: the brand has thousands of consent records and cannot tie any of them to the number in the complaint.

## How to fix it

Store the number on the consent record itself, in the form it was given, next to the timestamp and the disclosure version. Done when you can take any number from your sending list and produce the record that authorised it.

## Example of a compliant value

```text
Each consent record stores: phone number, timestamp, collection surface, disclosure version shown, and the session or agent identity.
```

## Common mistakes

- Storing consent against a customer account rather than a number breaks the moment somebody changes their number, and the old number stays on the sending list with a record that no longer describes it.

## Notes

Judged from what the flow and the artifact say about the record, since the record itself is the brand's own system. OPS-205 states the same field requirement on the retained record.