GDPR — Article 15 access + Article 17 cascade

Crewship stores agent-authored content (peer cards, memory snapshots, inbox items) that may include personal data about end users. EU operators have an obligation under GDPR Article 15 (Right of Access) and Article 17 (Right to be Forgotten) to produce that data on request and to delete it on demand. This page is the operator playbook for both flows. It covers the two admin endpoints, the audit table that records every action, the idempotency contract, and the parts of the cascade that intentionally remain manual for the operator’s judgement.

Two endpoints, one audit table

Action	Endpoint	RBAC	Records to `gdpr_actions`
Export (Article 15)	`GET /api/v1/admin/users/{userId}/data`	`manage` (ADMIN+)	`action='export'`, no reason required
Delete cascade (Article 17)	`DELETE /api/v1/admin/users/{userId}/data`	`manage` (ADMIN+)	`action='delete'`, reason required (non-empty after trim)

The gdpr_actions audit table is the canonical record of every Article 15 / 17 attempt — successful or failed — keyed by (workspace_id, data_subject_id) for fast SAR query lookup. Each invocation creates a new row even when repeated against the same subject, so the audit trail captures the full history of how the workspace handled that subject.

Article 15 — exporting a subject’s data

A data subject contacts the operator (typically via support email or a privacy portal) requesting a copy of all personal data held about them. The operator finds the subject’s user_id in the workspace identity store, then:

curl -X GET \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data" \
  > sar-export-$USER_ID-$(date +%Y%m%d).json

The response is a single JSON bundle containing every row from the four tables that carry data_subject_id (the three data tables below plus gdpr_actions, the audit history — see “What’s in the export” for the boundary):

{
  "subject_user_id": "usr_…",
  "exported_at": "2026-05-21T18:42:11Z",
  "scope": {
    "peer_cards": 23,
    "memory_versions": 117,
    "inbox_items": 4,
    "inbox_item_reads": 9,
    "user_models": 1,
    "user_model_provenance": 3,
    "gdpr_actions": 2
  },
  "peer_cards": [ {...}, {...} ],
  "memory_versions": [ {...}, {...} ],
  "inbox_items": [ {...}, {...} ],
  "inbox_item_reads": [ { "inbox_item_id": "ibx_…", "title": "…", "kind": "escalation", "read_at": "…" } ],
  "user_models": [ {...} ],
  "user_model_provenance": [ {...}, {...}, {...} ],
  "gdpr_actions": [ {...}, {...} ]
}

The handler returns 500 Internal Server Error on ANY query failure — even if a partial bundle was assembled from successful queries — to prevent an incomplete export from being handed to the subject as if it were authoritative. The audit row is still written with status='failed' so the attempt is recorded; the operator retries after investigating the underlying failure. The export is the canonical artefact the operator hands the subject. The format is JSON because it’s machine-readable for downstream redaction tooling; the operator is responsible for translating it into whatever the subject requested (PDF, CSV, etc.) if a specific format was named.

What’s in the export

The export covers tables that carry a data_subject_id foreign key, plus the subject’s own read markers and the audit history itself:

peer_cards — agent-authored peer cards mentioning the subject
memory_versions — versioned memory blobs the agent wrote about the subject
inbox_items — inbox rows whose payload references the subject (e.g. persona-suggestion proposals about the subject)
inbox_item_reads — the subject’s own per-item read markers (“I read inbox item X at time Y”), the one table here keyed on user_id rather than data_subject_id. The items themselves may be anyone’s — a role-targeted escalation the subject happened to open — so each entry carries the item’s title and kind beside its id, and the list is scoped to this workspace’s items
user_models — the operator model: the subject’s role, ownership and stated working constraints. Exported with its body, not just the index row — it is the one surface here holding facts the subject stated about themselves, so a row count would not answer the access request
user_model_provenance — the evidence behind each of those facts (#1693): the subject’s own quoted words, the message they were found in, and when each was recorded, newest first. Every row, not only the newest per field — the history of what was recorded is part of what is held about them
gdpr_actions — the audit history itself (always included)

What’s NOT in the export

Content the operator may also need to surface manually:

lessons.md entries that mention the subject by user_slug — agents append to a per-crew lessons file with free-form text; the cascade logs a warning naming the subject when its slug is found in any lessons.md but does not modify the file. Operators are responsible for redacting if the lesson text contains personal data. See Memory tiers.
Chat conversation history — the chats table is workspace-scoped not subject-scoped; if the subject’s user_id is user_id on a chat row, the operator filters those rows separately. Covered by Chat sessions.
Audit logs from internal/journal — operator-facing operations the subject performed are tracked in the journal; the operator queries by actor_user_id rather than data_subject_id because the journal is for what the operator did, not what was done to a subject.

Article 17 — cascade delete

A data subject requests deletion of all personal data (“right to be forgotten”). The operator runs:

curl -X DELETE \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  -H "Content-Type: application/json" \
  -d '{"reason": "GDPR SAR ticket #1234 from data-subject"}' \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data"

reason is REQUIRED. The handler rejects an empty or whitespace-only reason with 400 Bad Request, and the underlying gdpr_actions CHECK constraint rejects the same at the DB layer (defense-in-depth — even a future admin SQL bypass that skips the handler can’t land an unjustified delete row). Whitespace-only reasons like " " or "\n" are also rejected because they’re functionally blank for audit purposes.

The contract: unnamed in this workspace

The erasure is workspace-scoped, and the promise it makes is precise:

Of the tables the cascade enumerates below, no row belonging to this workspace still names the subject once the cascade completes.

It does not delete the users row, and it does not touch another workspace’s rows. The same person in a second workspace is a second SAR ticket answered by a second call with that workspace’s id; page_grants a subject issued in workspace B survive an erasure run against workspace A, by design.

Read “of the tables below” literally — it is not yet “every table”. Four kinds of row deliberately keep naming the subject after a successful cascade, and only the first is an accountability record:

journal_entries, audit_logs and gdpr_actions — permanent by design, listed in the table below.
workspace_members — the subject stays a member of the workspace. Erasure and removal are separate operations (crewship workspace member remove); an erasure that also evicted would be doing something the operator did not ask for.
chats and lessons.md — flagged as operator-handled in the table below, and still manual.
Columns still awaiting a product decision, listed under “What stays excluded” below: an issue’s owner, the subject’s recorded peer-card consent and its audit trail, a memory proposal’s decider and an agent’s config-change history. The sweep in internal/api/admin_gdpr_pages_identity_test.go walks the live schema, so this list is what it reports, not what someone remembered to write down.

Everything else the sweep found — some forty columns across credentials, notification channels, routines, issues, backups and the subject’s own saved views and preferences — is reached since #2308, with one receipt key per table.

Two consequences an operator should expect on the receipt:

Anonymised is not deleted. Where a row is history worth keeping — a page version, say — the erasure clears the subject’s name from it and leaves the row. It is reported under an …_anonymised key and is not counted in rows_deleted, because nothing was deleted.
Revoked is deleted. Where a row is a live capability the subject issued — a grant, a public link, a webhook token, a standing routine approval, a workspace invitation — the erasure removes it. The capability stops working immediately, and the row is counted in rows_deleted. Its accountability trail is the gdpr_actions row this cascade writes, not the capability row itself.
Removed is the subject’s own. A saved view, a notification preference, a delivery addressed to them, their personal notification channel: rows that are not attribution on somebody else’s record but the subject’s own data. Deleted, counted in rows_deleted, reported under …_removed.
Re-attributed is the one exception. A credential the subject created keeps working for every agent bound to it — deleting it would take a secret the workspace still relies on — but its created_by cannot be blank. The admin running the erasure becomes its custodian (the oldest other OWNER if the admin is erasing themself), the credential’s own audit timeline gets a REATTRIBUTED event naming the custodian and the action id, and the count is reported as credentials_reattributed. If nobody can take custody, the whole #2308 step refuses and the response is 207 with the reason.

What the cascade touches

Layer	Scope	Behaviour
`peer_cards` (DB)	rows WHERE `data_subject_id = $USER_ID`	Hard delete
`peer_cards` (disk files)	`peers/{user_slug}.md` and its `.lock` sentinel in each agent’s `.memory/`	Best-effort — `outputBasePath` must be configured + filesystem writable. Failures logged but do not block DB delete.
`memory_versions` (DB)	rows WHERE `data_subject_id = $USER_ID`	Hard delete
`memory_versions` (blob store)	content-addressed blobs deduplicated across the workspace	NOT auto-deleted in v107 — rows go but blobs left for cross-tenant dedup safety; tracked as PR-F16 for a separate orphan-GC sweep
`inbox_items` (DB)	rows WHERE `data_subject_id = $USER_ID`	Hard delete
`inbox_item_reads` (DB)	rows WHERE `user_id = $USER_ID`, on items in this workspace	Hard delete (A7, per-user read state). This is the subject’s activity — their record of having read items that may belong to anyone — not items about them. Markers on items the row above deleted are already gone by `ON DELETE CASCADE`; this catches the rest. Counted in `rows_deleted`, reported as `inbox_item_reads`. Read markers in a different workspace are a separate SAR ticket.
`user_models` (DB)	row WHERE `user_id = $USER_ID` in this workspace	Hard delete — UNLESS the on-disk delete below failed for that model, in which case the row is left in place (see the disk-file row)
`user_models` (disk file)	`/crew/shared/.memory/users/{user_slug}.md` and its `.lock` sentinel, in EVERY crew directory found under `outputBasePath` — not just the subject’s current most-active crew. The index row only ever names the CURRENT crew, and an operator’s most-active crew changes over time, so a delete keyed on that one row would leave every earlier copy an unreachable orphan.	`outputBasePath` must be configured. A directory that fails to delete is NOT masked: the cascade reports a partial failure (`207 Multi-Status`) instead of `202`, and the `user_models` row for that model is left in place — deleting it would make the surviving copy unfindable by any retry, since this cascade (and the self-service delete) locates a model by looking up that same row.
`approvals_queue` (DB)	rows WHERE `requested_by = $USER_ID` OR `decided_by = $USER_ID`	Hard delete (#2233). No `data_subject_id` column exists on this table, so it is matched on the two columns that ARE user-attributable instead — `requested_by` (a user id for an interactively-triggered approval gate, an agent id for an autonomously-triggered one) and `decided_by` (always a user id; only a human decides). Its own accountability trail (who decided what, when) survives regardless in `journal_entries`, which is excluded below.
`pages` (DB)	rows WHERE `owner_user_id = $USER_ID` in this workspace	Transferred, never deleted (#1944, Pages §7.1 rule 1b (`docs/specs/pages.md`)). Each page is handed to a crew before anything else in the cascade runs; if a page cannot be resolved to a crew the entire erasure is refused with `409 Conflict` and nothing is changed. Reported as `pages_transferred`.
`page_versions` (DB)	rows WHERE `author_user_id = $USER_ID`, on pages in this workspace	Anonymised (#1976) — `author_user_id` set to `NULL`, the version row kept. A version is history: rollback still works and the save is still in the list, it simply no longer names a person. Reported as `page_versions_anonymised` and not counted in `rows_deleted`.
`page_grants` (DB)	rows on pages in this workspace WHERE `granted_by_user_id = $USER_ID`, or the grant’s subject is that user (`subject_type='user'`)	Removed (#1976). A grant is authority, not a record: `docs/specs/pages.md` §7.1b rule 1 is that only a human issues one and that it narrows with its issuer, and `granted_by_user_id` is `NOT NULL … ON DELETE CASCADE` precisely so a grant delegated by nobody cannot exist. Grants naming the subject go with them for the same reason the contract above gives. Reported as `page_grants_removed`.
`page_public_tokens` (DB)	rows WHERE `created_by_user_id = $USER_ID`, on pages in this workspace	Revoked by removal (#1976). Every `/p/{token}` link the subject published stops resolving at once. The ordinary revoke path marks `revoked_at` and keeps the row, but a kept row still carries `created_by_user_id NOT NULL` — i.e. still names the subject — which an erasure may not leave behind. Reported as `page_public_tokens_revoked`.
`page_webhooks` (DB)	rows WHERE `created_by_user_id = $USER_ID`, on panels of pages in this workspace	Revoked by removal (#1976). Any cron, Zapier step or gateway holding one of the subject’s inbound tokens gets `404` on its next push. Same reasoning as public tokens. Reported as `page_webhooks_revoked`.
`user_model_provenance` (DB)	rows WHERE `user_id = $USER_ID` in this workspace	Hard delete (#1693). The evidence behind the operator model — the subject’s own quoted words, one row per fact per sync, kept beside the model file so `crewship privacy user-model list --provenance` can say where each entry came from. Erased by the identity step unconditionally: unlike `user_models` there is no disk copy whose failure would have to keep the row findable. Reported as `user_model_provenance_removed`. The same rows go on the self-service delete, the per-field forget and the opt-out purge.
`saved_views`, `user_notification_prefs`, `notification_deliveries`, `notification_channels` (`scope='user'`), `onboarding_proposals`	rows WHERE `user_id` / `owner_user_id` / `created_by` `= $USER_ID` in this workspace	Removed (#2308). The subject’s own records — a personal channel carries their own address, an onboarding proposal is the draft the Guide wrote in their session. Reported as `saved_views_removed`, `user_notification_prefs_removed`, `notification_deliveries_removed`, `notification_channels_removed`, `onboarding_proposals_removed`.
`waitpoint_trust_grants`	rows WHERE `granted_by_user_id = $USER_ID`	Revoked by removal (#2308). A standing approval on a routine gate is `page_grants`’ twin — a human delegating authority, with a `NOT NULL` issuer. The gate starts asking again; each live grant that went is journalled as `approval.trust_revoked` exactly as the ordinary revoke path does it. Grants the subject merely withdrew stay, with `revoked_by_user_id` cleared. Reported as `trust_grants_revoked` and `trust_grants_anonymised`.
`workspace_invitations`	rows WHERE `invited_by = $USER_ID`	Revoked by removal (#2308). A pending invitation is a live capability to join the workspace in the subject’s name; `invited_by` is `NOT NULL`. Reported as `workspace_invitations_revoked`.
`credentials`	rows WHERE `created_by`, `created_by_actor_id` or `approved_by_user_id` `= $USER_ID`	Re-attributed (#2308) — see the bullet above. `created_by` goes to the custodian, the two nullable columns are cleared, the credential and every binding on it keep working. Reported as `credentials_reattributed`.
`credential_bindings`, `credential_rotations`	rows WHERE `created_by` / `rotated_by` `= $USER_ID`, on credentials in this workspace	Anonymised (#2308). A binding is what makes the credential reach an agent; removing it would revoke the credential by the back door. Reported as `credential_bindings_anonymised`, `credential_rotations_anonymised`.
`notification_channels` (`scope='workspace'`), `notification_channel_agents`, `hooks_config`, `automations`, `recurring_issues`, `composio_settings`	rows WHERE `created_by` / `owner_user_id` / `granted_by` / `default_user_id` `= $USER_ID`	Anonymised (#2308). Workspace configuration the subject happened to set up. Every one of these columns is nullable with no foreign key — the schema’s own statement that the row is valid without its creator — so the team’s Slack channel, hooks and cron issues keep running and stop naming a person. (`composio_settings.default_user_id` is a Composio-side identity and is cleared only when it literally equals the subject’s id.) Reported as `<table>_anonymised`.
`agents`, `crews`, `pipelines`, `pipeline_versions`, `pipeline_runs`, `pending_runs`, `pipeline_waitpoints`, `agent_runs_archive`, `missions` (`created_by_user_id` only), `mission_proposals`, `mission_tasks`, `mission_comments`, `mission_code_links`, `checkpoints`, `backup_catalog`, `backup_restore_origins`, `eval_runs`, `workspace_files`, `attachments`, `escalations`, `gate_reward_history`, `keeper_governance_settings`	the attribution column(s) `= $USER_ID`, in this workspace	Anonymised (#2308). History worth keeping without the name: who created the agent, ran the routine, approved the task, uploaded the file. `pipeline_versions.author_id` and `mission_comments.author_id` are `NOT NULL` beside an `author_type`; for `author_type='user'` the id becomes empty and the row keeps saying a human wrote it. Clearing `keeper_governance_settings.security_contact_user_id` leaves the workspace with no security contact — Keeper findings become visible to every admin instead of one, and the server logs a warning so you appoint a new one. Reported as `<table>_anonymised`.
`memory_versions` (`written_by`), `inbox_items` (`target_user_id`, `read_by_user_id`, `resolved_by_user_id`)	rows in this workspace that survive the `data_subject_id` delete above	Anonymised (#2308). Both tables were already in the cascade, matched on `data_subject_id` only; the other columns on the same rows are now cleared. An inbox item whose addressee was erased becomes untargeted, i.e. visible to everyone who can see the inbox. Reported as `memory_versions_anonymised`, `inbox_items_anonymised`.
`keeper_requests`	All rows	Excluded — these record sidecar decisions and don’t carry user-attributable content beyond the agent_id
`journal_entries`, `audit_logs`, `gdpr_actions`	rows naming the subject as actor or subject	Excluded — deliberately, and permanently. These are append-only accountability records, and they are how a regulator verifies that the erasure happened at all: you log what you did about a person, and you keep that log after the person’s data is gone. A SAR does not erase the SAR. This is the one place where the “unnamed in this workspace” contract above does not hold, and it is stated in the threat model as well.
`lessons.md` content scan	Per-crew lessons files	Manual — the handler logs a warning naming the subject when it finds the user_slug in any lessons.md; operator decides whether to edit the file by hand
`chats`	All rows owned by subject	NOT auto-deleted — operator runs a separate query if the data subject was also a Crewship user; see Chat sessions

What stays excluded

The sweep still reports these after a successful cascade. Each is a decision not yet taken, not an oversight, and the test rig deliberately does not seed them so a green sweep cannot be mistaken for coverage:

Column	Why it is still named
`missions.owner_user_id`	An issue with no owner may be a state the app cannot render. It needs the transfer-or-refuse treatment `pages.owner_user_id` got (#1944), not a blind `NULL`.
`chats`, `chat_participants`, `chat_read_cursors`, `captain_chats`, `conversation_messages`, `message_reactions`, `message_feedback`	Chat history is operator-handled (row above). That note is a placeholder for a decision, not the decision.
`user_peer_consent`	The subject’s recorded consent state — arguably must survive as proof of consent, arguably must go as their data.
`peer_card_audit`	The audit trail of the `peer_cards` the cascade erases. Whether it is accountability (excluded) or content (erased) is the `approvals_queue` argument (#2233) again.
`memory_proposals.decided_by_user_id`	A `CHECK` requires a decided proposal to name its decider (“HITL approval trail integrity”). Nulling violates the constraint; re-attributing would falsify an accountability record.
`agent_config_history.changed_by`	`NOT NULL REFERENCES users(id)` on a versioned config log. Needs a migration relaxing the constraint before it can be anonymised.
`backup_locks.acquired_by`	A transient lock row, deleted on release and evicted on expiry; it never outlives the backup that took it.
`workspace_members`, and the instance-scoped tables (`users`, `accounts`, `sessions`, `cli_tokens`, `skills`, `skill_reviews`, `rate_limit_overrides`, `keeper_runtime_settings`, `keeper_aux_settings`, …)	Membership is a separate operation; instance-scoped rows belong to an account-deletion path that does not exist yet. A workspace erasure cannot speak for a person’s other workspaces.

For verified private synchronous whole-run sources, hard deletion also appends an atomic, content-free approval.source_retired journal marker (workspace and approval ID only). It retains no request, answer, user or chat/run metadata; its purpose is to keep existing immutable source history private after erasure. A failed marker append prevents deletion of that source.approvals_queue is erased on Article 17 but is not part of the Article 15 export bundle above — it lacks a data_subject_id column, so it doesn’t fit the export’s “every table keyed by data_subject_id” shape, and adding a requested-by/decided-by-keyed export is tracked separately rather than folded into this cascade. Its own retention sweep (internal/harbormaster/retention.go, workspaces.approvals_retention_days, default 90 days) bounds how long an undecided-to-erase row survives on its own — see Migrations — 20260901134904 — but a live SAR ticket cannot wait out that window, which is why the cascade above erases it directly rather than relying on the sweep.

No per-subject marker survives the erasure. Each peer card and operator model is written under a <user_slug>.md.lock sentinel, and that sentinel is now removed with the file it guards — on the Art. 17 cascade, on crewship privacy user-model delete, and on the opt-out purge alike. It used to stay: a zero-byte file named after the subject, left in a directory whose other artefacts were all gone. user_slug is sha256(user_id ‖ 0x00 ‖ workspace_id)[:16] and carries no personal data, but it is recomputable by anyone holding the workspace id and a list of users, so a listing still answered “did this workspace ever hold a record about this person?” after the record itself was erased. A purge for a subject who never had a card or a model now writes nothing at all, rather than creating the sentinel it was called to remove.

Known gap: a dormant crew’s search index is not purged. Every crew’s sidecar keeps an FTS5 index (index.sqlite) alongside .memory/, built by walking the memory tree — including users/{user_slug}.md — at container startup and on a 60-second tick while the sidecar is running. The Art. 17 and Art. 15 cascades and crewship privacy user-model delete all run host-side and only touch the .md file and its .lock sentinel; none of them open index.sqlite. For a crew whose container is running when the erasure happens, the next 60-second reindex tick naturally drops the erased content from the index — it walks the tree fresh and the file is gone. For a dormant crew (a container that is stopped — typically because the operator has since moved to a different crew, the exact condition this page’s per-crew-directory delete exists to reach), the erased content’s search chunks persist in that crew’s index.sqlite until its container is next started, and memory.search scoped to that crew would still surface them. Proposed fix: extend the host-side delete to also open each crew’s index.sqlite (when present) and remove rows for users/{user_slug}.md, matching what Engine.ReindexPath already does for a file that has disappeared from disk — gated on the index file already existing, so a crew with no engine yet never gets one created just to record an absence.

The response confirms what landed. rows_deleted is the single total of rows that went away; the per-table breakdown is in scope, and its keys carry the verb, because “anonymised” and “revoked” are different answers to give the person who filed the request:

{
  "action_id": "gdpr_act_…",
  "data_subject": "usr_…",
  "workspace_id": "ws_…",
  "rows_deleted": 151,
  "scope": {
    "peer_cards": 23,
    "memory_versions": 117,
    "inbox_items": 4,
    "user_models": 1,
    "user_model_provenance_removed": 3,
    "approvals_queue": 2,
    "pages_transferred": 1,
    "page_versions_anonymised": 12,
    "page_grants_removed": 3,
    "page_public_tokens_revoked": 1,
    "page_webhooks_revoked": 0,
    "saved_views_removed": 2,
    "trust_grants_revoked": 1,
    "credentials_reattributed": 1,
    "agents_anonymised": 4
  }
}

(Abridged: the real object carries one key per table in the cascade, every one present even at zero.) pages_transferred, every …_anonymised key and credentials_reattributed are deliberately outside rows_deleted: nothing was deleted in any of those cases — a page changed owner, a version lost an author, a credential got a custodian. The …_removed / …_revoked counts are inside it. The same object is stored on the audit row as gdpr_actions.scope_json, so the breakdown survives the response. A key at zero is not the same as a key missing: the #1976 and #2308 steps each run in one transaction that rolls back whole on failure, and their keys are then reported at zero, so “the rollback undid it” and “there was nothing to do” read differently from a key that was never there.

Idempotency

Running the cascade twice for the same subject is safe:

Already-deleted rows are silently skipped (cascade is row-set based, not snapshot-based)
Each invocation creates a new gdpr_actions row, so the audit trail records BOTH attempts (operators sometimes re-run a cascade weeks after the first attempt to verify completeness — both runs land in the audit)
The action_id returned in the response is the audit row id, not a transaction id — quoting it back to the operator’s ticketing system gives a stable handle

This matters because regulators sometimes ask “did you delete this subject’s data on 2026-03-14 AND again on 2026-04-02 in response to two separate confirmation requests?” — the answer comes from SELECT * FROM gdpr_actions WHERE data_subject_id = ? AND action = 'delete' ORDER BY initiated_at and shows both runs without ambiguity.

Verifying a cascade landed

After running the cascade, the operator verifies completeness by re-running the export:

curl -X GET \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data"

A successful cascade returns:

{
  "subject_user_id": "usr_…",
  "exported_at": "2026-05-21T18:45:30Z",
  "scope": {"peer_cards": 0, "memory_versions": 0, "inbox_items": 0, "user_models": 0, "approvals_queue": 0},
  "peer_cards": [],
  "memory_versions": [],
  "inbox_items": [],
  "user_models": []
}

…with all scope counts at zero. If any non-zero remains, the cascade either had a partial failure (check the previous gdpr_actions row’s status and error columns) or there’s data without a data_subject_id foreign key that won’t be reached by the cascade (escalate to engineering — likely a column added since the v107 migration).

The export is not a full verification. It covers the tables keyed by data_subject_id, so a zero there says nothing about the tables that name the subject through some other column — approvals_queue, and the four Pages tables above, are erased by the cascade but never appear in the export bundle. For those, the scope on the gdpr_actions row is the evidence: it records what each statement actually removed or anonymised, per table, at the time it ran.

Audit table reference

gdpr_actions schema (added in migration v107):

Column	Type	Notes
`id`	`TEXT PRIMARY KEY`	`gdpr_act_` + cuid suffix
`workspace_id`	`TEXT NOT NULL REFERENCES workspaces(id)`	Cascade to workspace delete
`data_subject_id`	`TEXT NOT NULL`	The user being acted on
`actor_user_id`	`TEXT NOT NULL`	The admin who initiated
`action`	`TEXT NOT NULL` CHECK IN `('export','delete','view')`
`scope_json`	`TEXT`	Per-table counts for delete; per-table row count for export
`initiated_at`	`TEXT NOT NULL`	RFC3339
`completed_at`	`TEXT`	NULL while in progress
`status`	`TEXT NOT NULL` CHECK IN `('in_progress','completed','failed')`	Defaults to `in_progress`
`error`	`TEXT`	Populated on `status='failed'`
`reason`	`TEXT`	Required for `action='delete'` via a table-level CHECK (`action <> 'delete' OR length(trim(reason)) > 0`)

Indexes:

idx_gdpr_actions_subject (workspace_id, data_subject_id) — fast SAR lookup
idx_gdpr_actions_initiated (initiated_at) — chronological browse

Querying the audit

Every Article 15 + Article 17 attempt for a subject:

SELECT id, action, status, initiated_at, completed_at, actor_user_id, reason
FROM gdpr_actions
WHERE workspace_id = ? AND data_subject_id = ?
ORDER BY initiated_at DESC;

All cascade deletes performed by an admin in the last 90 days:

SELECT g.id, g.data_subject_id, g.initiated_at, g.completed_at, g.reason
FROM gdpr_actions g
WHERE g.workspace_id = ?
  AND g.action = 'delete'
  AND g.actor_user_id = ?
  AND g.initiated_at > datetime('now','-90 days')
ORDER BY g.initiated_at DESC;

Failed exports the operator should retry:

SELECT id, data_subject_id, initiated_at, error
FROM gdpr_actions
WHERE workspace_id = ?
  AND action = 'export'
  AND status = 'failed'
ORDER BY initiated_at DESC;

UI surface

Both endpoints are reachable from Admin → Users: search for the person, open their row, and the two actions are there — Export data and Erase data. They used to live behind their own “GDPR actions” nav row, which carried its own user picker: a second roster of the same people the Users list already showed, kept in step by hand. The actions belong to a person, so they live where people live.

The roster searches by name, email or user id; one row opens at a time, because one of these actions is irreversible and two open panels invite the wrong one being used
Export data downloads the JSON snapshot; Erase data opens a confirmation dialog with a required reason field and an “I understand this is irreversible” checkbox
The dialog stays open during the async DELETE (no auto-close) — a failed call surfaces the error toast without wiping the operator’s input, so they can retry without re-typing

From a terminal, the same two operations are crewship admin gdpr export and crewship admin gdpr delete --reason … --yes, which is the better surface for a queue of requests. The reason field is the same one that lands in gdpr_actions.reason — operators are encouraged to paste their ticketing system’s identifier (“SAR ticket #1234”) rather than free-form text, so the audit query reads naturally.

What’s NOT exposed

Crewship intentionally does NOT provide:

A self-service deletion endpoint for end users — Article 17 requests are mediated by the operator because the cascade affects content the operator owns (agent decisions, audit records that have to survive operator’s own retention obligations)
A bulk delete endpoint (“delete every user matching this filter”) — every cascade is one subject at a time, by design, because each gdpr_actions row needs a justification specific to that subject
Auto-deletion on user account close — closing a Crewship user account doesn’t trigger Article 17 (the user might have other obligations to a different workspace tenant within the same Crewship instance); the explicit cascade endpoint is the only path

Cross-references

Threat model — Tenant isolation on internal-auth handlers — how the GDPR cascade endpoints fit into Crewship’s tenant-isolation surface area
Audit logging — broader audit log shape; gdpr_actions is a specialized table for the GDPR cascade subset
Encryption at rest — operator-side encryption that protects gdpr_actions rows in backups + filesystem snapshots
Agent memory — the operator model — how peer cards get created and what data_subject_id they end up with
Admin API — schemas for the two endpoints

Get Started

Guides

Security

Configuration

Manifest Reference

GDPR — Article 15 access + Article 17 cascade

Two endpoints, one audit table

Article 15 — exporting a subject’s data

What’s in the export

What’s NOT in the export

Article 17 — cascade delete

The contract: unnamed in this workspace

What the cascade touches

What stays excluded

Idempotency

Verifying a cascade landed

Audit table reference

Querying the audit

UI surface

What’s NOT exposed

Cross-references

​GDPR — Article 15 access + Article 17 cascade

​Two endpoints, one audit table

​Article 15 — exporting a subject’s data

​What’s in the export

​What’s NOT in the export

​Article 17 — cascade delete

​The contract: unnamed in this workspace

​What the cascade touches

​What stays excluded

​Idempotency

​Verifying a cascade landed

​Audit table reference

​Querying the audit

​UI surface

​What’s NOT exposed

​Cross-references

GDPR — Article 15 access + Article 17 cascade

Two endpoints, one audit table

Article 15 — exporting a subject’s data

What’s in the export

What’s NOT in the export

Article 17 — cascade delete

The contract: unnamed in this workspace

What the cascade touches

What stays excluded

Idempotency

Verifying a cascade landed

Audit table reference

Querying the audit

UI surface

What’s NOT exposed

Cross-references