Purpose & consent
Meridian Blue accepts a free-form purpose field and a user_consent_id reference on every chat-completion request. They become first-class entries in the conversation log and the audit trail, and high-risk patterns can require them before serving the request.
purpose
A free-form string describing why the request is being made ("customer_support", "loan_underwriting", "radiology_assist", etc.). The value is stored on the conversation log row and visible in the dashboard and audit-log feed.
The risk classifier matches purpose against high-risk-purpose patterns. A purpose like loan_underwriting will flip the request's risk tier to high even if the prompt itself looks neutral, because the use case lands inside Annex III.
user_consent_id
An opaque reference to a stored GDPR consent record on your side (a UUID, your own DB id, etc.). Meridian Blue does not store or verify the consent record — it stores the reference, so when a regulator asks "where's the consent?" you can join your consent ledger to the audit log by this ID.
When the deployer policy demands it (regulated-industry templates do), high-risk requests without a user_consent_id are rejected with 400 missing_consent.
end_user_id
A pseudonymous identifier for the natural person whose data is being processed. Used to:
- Drive per-end-user data-lineage exports (GDPR Article 15) via
GET /api/v1/data-lineage/export/:dataSubjectId. - Link conversation rows so a Right-to-Erasure request can find every artefact tied to one person.
Pseudonymise on your side first — Meridian Blue does not need (and does not want) the raw email or any Article 9 identifier in this field.
Enforcement
Today, all three fields are accepted but only enforced when the deployer policy template is one of the regulated-industry presets (eu_bank, healthcare, etc.). Generic policies log them but don't gate on their presence. Make the gating explicit in your tenant's deployer policy when you want Meridian Blue to refuse high-risk traffic that omits them.
Right to erasure
The end_user_id field is the join key for GDPR Article 17 erasure: query the conversation log for every row tagged with the subject ID, then delete or redact via your dashboard's data-lineage tools.