SMS Consent & Disclosure Exhibit

Program Summary

What this number is used for

Opt-in Workflow

How consent is obtained

There is no web form, keyword, or checkout path into this program. Consent is verbal and is obtained one recipient at a time, in the course of an official interaction:

1. An officer taking a statement asks the person for a mobile number and reads the disclosure script at Exhibit A aloud, in person or by phone. The script names Jurat as the sender, states that message frequency varies, states that message and data rates may apply, and gives both STOP and HELP.
2. If the person agrees, the officer enters the number on the Statement Request screen and checks the consent box shown at Exhibit B. The screen carries the same disclosure in writing. The number cannot be submitted without that box — the API rejects a phone-bearing request without confirmed consent, so this is a server-side rule, not a UI convention.
3. Submitting the request writes the consent event to an immutable audit record (Exhibit D) and sends exactly one message — the one at Exhibit C.
4. Replying STOP ends all messages to that number. STOP and HELP are processed upstream by the carrier; Jurat does not send a confirmation of its own, deliberately, so that a person who has just opted out is not messaged again.

Exhibit A

The opt-in — verbal disclosure script

This is the opt-in itself: the words the recipient hears before any number is collected. It is the same string the officer reads from in Exhibit B below — one constant, rendered in both places, so the script in the field and the script on file cannot differ.

Consent is recorded only after this is read. A recipient who declines simply has no phone number entered, and the request goes out by email instead.

Exhibit B

Officer-facing consent capture

Rendered directly beneath the phone number field on the officer's Statement Request screen whenever a phone number is entered. The send button stays disabled until the box is checked — enforced again server-side, so the API itself rejects a phone-bearing request with no confirmed consent. Try the checkbox below; it's the real component.

The card only appears when a phone number is present — an email-only request never shows it. Both the checkbox label and the disclosure sentence are shown exactly as rendered.

Exhibit C

Sample outbound message

Not a mock-up and not paraphrased — the bubble below is rendered by buildAffiantRequestSms(), the same function the notification layer calls to send the real thing. The sender name, the opt-out suffix, the link shape and the character count are all produced here exactly as they are produced in production; only the case number and the link token are stand-ins.

Jurat is the registered sender on this number; ECSO is the requesting agency's configured abbreviation, named in the message as the agency that requested the statement. The link and case number are unique per request — the token is 21 characters in every message, so the length above is the real one, not a shortened illustration.

Exhibit D

Consent audit record

Every request created with a phone number writes an immutable, append-only audit event at the moment of creation — a permanent record that consent was confirmed before any SMS could be sent.

The phone number itself is never stored in the log in full — only the last four digits, so the record proves consent without becoming a second copy of the contact detail.