# OPS-199 — Consent records must capture all seven required fields

> The programme must retain a consent record holding the number, timestamp, medium, a capture of the consent experience, the campaign, an IP or call identifier, and the consenting party.

- **Rule ID:** OPS-199
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow + privacy policy`
- **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:** AI judgement over the submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** CTIA, FCC, TCR
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-199/

## Why this rule exists

CTIA enumerates these seven fields specifically, and the reason is evidentiary: when a complaint arrives eighteen months later, "opted in: true" proves nothing about what the consumer actually agreed to. The capture-of-experience field is the one almost everybody omits, and it is the one that matters most — it is the only record of the wording shown at the moment of consent.

## How to fix it

Store all seven fields per opt-in, and version the disclosure text so you can reproduce exactly what a given consumer saw. Describe this in the message flow — a reviewer treats an undescribed record-keeping practice as an absent one.

## Example of a compliant value

```text
For each opt-in we store: phone number, UTC timestamp, acquisition medium, the versioned disclosure text shown, the campaign, the originating IP (or call ID for phone consent), and the account or session identity that consented.
```

## Common mistakes

- Storing a boolean flag with a date is the most common shortfall — it cannot answer "what did they agree to?".