# OPS-236 — An IVR opt-in must log the prompt, the keypress, the time and the call

> Every consent record must carry the prompt version played, the digit or spoken answer captured, the timestamp and the call identifier.

- **Rule ID:** OPS-236
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow + privacy policy`
- **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 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 IVR.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-236/

## Why this rule exists

An IVR consent leaves no human witness on either side, so the log is the entire record — and unlike a live agent, an IVR can be misconfigured to accept any keypress as agreement and will do it identically to everyone who calls. All four fields are needed together: the prompt says what was asked, the captured input says what was answered, and the call identifier is what ties the pair to a person.

## How to fix it

Log all four values on every IVR consent: the prompt version played, the DTMF digit or recognised phrase captured, the timestamp, and the call identifier. Done when one log line lets you replay what was asked and what was pressed.

## Example of a compliant value

```text
IVR opt-ins log: prompt_version=ivr-optin-v4, captured_input=DTMF 1, captured_at=2026-03-04T14:22:11Z, call_id=UCID-88213004.
```

## Notes

Registration-side twin of a runtime log. We judge the description of the log, never the log. The four elements are one record judged in one pass rather than four rules, because they fail together: a log missing any one of them cannot reconstruct a single consent.