Two consent mechanisms, two records, kept separate.
Halton Meter Cloud writes two distinct consent records, and they do not
share a code path. The first is checkout consent: a legal record taken
on the /subscribe page before a subscription starts. The second is
prompt-content viewing consent: an audit record written every time one
member views another member's stored prompt body. This page documents the
mechanism of each. The verbatim legal language is regulated copy and is
stubbed below pending counsel.
1. Checkout consent at subscribe time
When a user subscribes on the dashboard /subscribe page, the page renders
two ConsentGate tickboxes. Both must be ticked before Clerk's checkout
drawer opens. On confirmation the dashboard calls POST /v1/consent/checkout,
which persists one checkout_consent_records row. This row is the evidence
that consent was given for that plan, at that price period, against that exact
wording.
The persisted columns are:
| Column | What it holds |
|---|---|
user_id | The subscribing user. |
plan | The plan being purchased (for example Solo or Team). |
period | The billing period (monthly or annual). |
wording_hash | SHA-256 of the verbatim user-facing consent strings, versioned in the dashboard consent-gate.tsx. |
ip | The request IP. |
user_agent | The client user agent, truncated to 512 characters. |
timestamp | When consent was recorded. |
The wording_hash is the integrity link: because it is a SHA-256 of the
exact strings shown to the user, the stored row proves which version of the
copy the user agreed to. If the wording changes, the hash changes, and old
consents stay tied to the old text.
The two tickboxes cover (1) agreement to the Terms, Privacy, and Refund policy, and (2) an express request for immediate performance plus acknowledgement that the 14-day cooling-off right is lost on delivery, citing UK CCR 2013 reg. 37. The second tickbox is what evidences the cooling-off waiver if a charge is later disputed.
The exact strings are regulated legal copy. Their text is not reproduced here.
2. Prompt-content viewing consent
A stored prompt body is sensitive. Reading another member's body is gated, and every read that does happen is logged.
Who can read a body
A trace body is fetched at GET /v1/traces/{request_id}/body. The body is
readable only by the user who made the original request, or by a workspace
or organisation admin. Any other caller gets an opaque 403. The 403 never
reveals whether a body exists, so a non-authorised member cannot probe for
the presence of a teammate's data. This is a plain role check on the read path.
The append-only view ledger
When an authorised member views a teammate's prompt body through the
dashboard, that view is recorded by POST /v1/audit/prompt-views. The ledger
is append-only. Each row holds:
| Field | What it holds |
|---|---|
workspace_id | The workspace the view happened in. |
request_id | The trace whose body was viewed. |
viewer_user_id | Who viewed it. |
subject_user_id | Whose body was viewed. |
consent_grant_id | Optional reference to a consent grant, if one applies. |
reason | Free-text reason for the view (1 to 2000 characters). |
viewed_at | When the view happened. |
client_ip | The viewer's request IP. |
user_agent | The viewer's client user agent. |
Writing a view row is gated at the Team tier and above. Reading the ledger
back at GET /v1/workspaces/{ws}/audit/prompt-views is gated at Business+
and above. So a Team workspace records its views, and a Business+ workspace
can review them.
The privacy and employee-monitoring wording around teammate prompt visibility is regulated copy. It is not reproduced here.
See also
- Intake of request bodies: when bodies are stored and the workspace opt-in gate
- Cloud security: auth, encryption, and data handling
- Sync and retention: what syncs and the retention windows
- Workspaces: members, roles, and admin access