GDPR alignment

Art. 5 — principles of processing

Data minimisation is enforced via the auto_truncate field — long prompts get older messages dropped before the model sees them, with the receipt surfaced in the response. Storage limitation is enforced by the retention policy engine, which cryptographically deletes ciphertext at expiry.

Art. 6 — lawful basis

The deployer policy declares the lawful basis on a per-purpose basis. The user_consent_id field on the request links to your stored consent record so the basis is provable per-request.

Art. 15 — right of access

The GET /api/v1/data-lineage/export/:dataSubjectId endpoint produces a complete export packet for one data subject (filtering on tenantId AND end_user_id) and includes the tenant's processor list per Art. 15(1)(c). See Lineage & liability.

Art. 17 — right to erasure

Erasure is performed on the dashboard's data-lineage tools or via direct DB-level redaction of conversation rows tagged with the subject's end_user_id. The retention scheduler also performs proactive erasure at the end of each tenant's retention window.

Art. 22 — automated decisions

Article 22 right to object to a solely-automated decision is satisfied via the appeal flow at /api/v1/appeals. Every high-risk response carries appeal instructions in the user_notice envelope so the data subject can act on it.

Art. 28 — sub-processors

The public sub-processor registry is exposed at GET /api/v1/sub-processors with no auth required (Article 28 transparency). It carries an ETag derived from the SHA-256 of the live list and a Cache-Control: public, max-age=300 so callers can poll cheaply.

Owners can add, edit, or soft-delete sub-processors at any time via POST, PATCH /:id, or DELETE /:id on the same path (gated to the OWNER role). Every mutation immediately fires the sub_processor.changed webhook so customer integrations subscribed to that event get advance notice — closing the GDPR Article 28 obligation that processors notify controllers when sub-processors change.

# Read (public, no auth)
curl https://api.meridianblue.ai/api/v1/sub-processors

# Add a new sub-processor (owner only)
curl -X POST https://api.meridianblue.ai/api/v1/sub-processors \
  -H "Authorization: Bearer $MB_DASHBOARD_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PineconeDB",
    "purpose": "Vector store hosting (semantic-cache embeddings)",
    "location": "United States",
    "data_categories": ["embeddings"],
    "dpa_signed": true,
    "sccs_required": true,
    "sortOrder": 10
  }'

The list is DB-backed (the SubProcessor Mongo collection). Operators bootstrap it from the static seed shipped with the server via npm run seed:sub-processors (or the equivalent POST /api/v1/test/run/seed-sub-processors when running in a managed environment).

Art. 30 — records of processing

Every chat-completion request becomes a Conversation row with the categories of data, the recipients (the upstream provider), the retention class, and (when supplied) the lawful basis link. That table is the Article 30 register — exportable per-tenant.