# OPS-235 — A spoken consent record must pin the script version that was read

> Every consent record must carry the version and effective date of the consent script read to the consumer.

- **Rule ID:** OPS-235
- **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:** FTC, CTIA, practice
- **Applies:** Applies when consent was collected by live verbal, IVR and point of sale.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-235/

## Why this rule exists

Scripts get improved, and every improvement makes the previous wording unprovable unless the record says which one was in force. This is the verbal twin of the capture-of-experience field, and it is the difference between "our script says X" — which a regulator reads as what you say today — and "this consumer heard version 3, effective 12 January". Brands miss it because the script lives in a document nobody versions.

## How to fix it

Version the consent script, give each version an effective date, and store the version identifier on every consent taken while it was live. Done when you can pick any past consent and reproduce the exact words that consumer heard.

## Example of a compliant value

```text
Verbal opt-ins store script_version: 2026-03-a (effective 2026-03-01) with the agent ID and call UCID.
```

## Common mistakes

- Attaching the current script to the registration proves what is read today. It is silent about the consents already taken, which are the ones a complaint will be about.

## Notes

Registration-side twin: we judge whether the programme describes storing the field, never whether the stored record exists.