Legacy Capsule Erasure Policy

Status: APPROVED (DPO decision D-051-01, 2026-05-20, approved with conditions). Counsel reply: docs/legal/decisions/gdpr-art17-counsel-thread-legacy-capsule-erasure-reply.md. Per-class retention map: docs/legal/legacy-capsule-retention-map.md.

Legacy Decision Capsules are historical evidence_locker.decision_capsules rows created before Sprint 20260518_051 introduced the no-PII capsule guard. They remain sealed audit evidence. Stella Ops does not rewrite their manifest_json or dsse_envelope bytes and does not re-sign them, because doing so would invalidate the DSSE signature, break deterministic replay, and create verification confusion against cached/distributed attestations.

Legal framing (read this first)

Immutability alone is not the legal reason for refusal. The legal reason is mapped retention necessity: each retained legacy capsule class is mapped to a concrete legal or regulatory retention obligation (or a defensible legal-claims need). Immutability only explains why erasure cannot be applied without destroying the required evidence.

Primary basis: GDPR Article 17(3)(b) — processing necessary for compliance with a legal obligation requiring retention of the historical record.
Secondary basis: GDPR Article 17(3)(e) — establishment, exercise, or defence of legal claims, attached only where a legal-claims rationale exists for the capsule class (see the retention map).
Article 23 is NOT cited in any requester-facing response. Internal notes may reference Article 23 analysis as “not relied upon unless counsel maps a specific legislative restriction.” The code never emits Article 23 externally (article_23_relied_upon: false).

Classification

The startup baseline 001_v1_evidencelocker_baseline.sql (line 1175 onward; folded in from the pre-1.0 011_legacy_pii_audit.sql, now archived and not embedded) adds pii_policy_version to capsule and evidence tables:

Version	Meaning
`0`	Legacy row not proven PII-free, or a capsule that failed the legacy scan.
`1`	Row passed the no-PII policy at write time or passed the legacy audit scan.

After the migration lands, new rows default to pii_policy_version=1. Existing rows start at 0; the deploy-time scanner reads each legacy capsule’s canonical manifest and applies CapsulePiiGuard. Clean rows are upgraded to 1. Rows that fail remain 0 and are recorded in evidence_locker.legacy_pii_capsules with the detected JSON paths and action erasure_refused_signature_integrity.

Read-path tomb-stoning (mandatory)

Embedded legacy personal data is suppressed from ALL ordinary read paths — capsule reads (replay/export), operator views, SAR export, search indexes, and analytics/dashboards. Ordinary reads return the tombstone token:

legacy_personal_data_suppressed_retained_under_art_17_3_b

The canonical manifest bytes and DSSE signature are never modified; the content hash and signature continue to verify against the original bytes. The redacted read projection is explicitly non-canonical and non-signature-preserving (legacyPiiSuppressed: true in the projected output).

LegacyCapsuleReadPathSuppressor performs the suppression; CapsuleEndpoints applies it to ordinary GET and CapsuleService applies it on ReplayAsync and ExportAsync for pii_policy_version = 0 rows. Even when the bounded detector finds no PII-shaped scalar, the legacy GET projection is marked and re-serialized rather than returning the raw signed bytes. Malformed, empty, whitespace-only, and non-object legacy manifests return a fixed fail-closed suppression projection.

Raw-access escalation (break-glass)

Access to the original signed manifest bytes is exceptional. It requires a privileged role + purpose code + ticket reference and emits an immutable audit event. In code, the break-glass path passes rawAccess: true to CapsuleService.ReplayAsync / ExportAsync; callers MUST emit the break-glass audit event before returning raw bytes. Raw access is limited to compliance, security, regulatory, audit, and legal-defence workflows (raw_access_policy = compliance_legal_regulatory_break_glass_only).

Erasure response

When an Art. 17 erasure request targets an actor referenced by a pii_policy_version=0 capsule, Stella Ops erases the mutable actor identity (shared.actor_identity + mutable copies) and refuses to rewrite the sealed capsule. The structured response is partial (counsel §5):

{
  "partial": true,
  "status": "partially_completed",
  "erased": [
    "shared.actor_identity",
    "mutable_identity_copies",
    "ordinary_display_identity_fields"
  ],
  "retained": [
    {
      "recordType": "legacy_evidence_capsule",
      "reason": "cryptographically signed historical audit record retained for compliance/audit/regulatory/security/legal purposes",
      "legalBasis": ["GDPR Article 17(3)(b)", "GDPR Article 17(3)(e) where applicable"],
      "ordinaryReadPathSuppressed": true,
      "rawAccessRestrictedAndAudited": true,
      "retentionReview": "<date-or-criteria>"
    }
  ],
  "article23ReliedUpon": false,
  "complaintRights": "You may lodge a complaint with a supervisory authority and seek a judicial remedy."
}

EvidenceLocker emits actor.erasure.legacy_capsule_refused for this condition. The audit event records request_id, decision_id (D-051-01), actor_ref, the shared.actor_identity side-table erasure proof, and per-capsule retained_personal_data_categories (categories such as email/ip_address, never raw values), canonical_manifest_modified: false, dsse_signature_preserved: true, ordinary_read_path_suppressed: true, raw_access_policy, retention_basis (GDPR_ART_17_3_B), optional secondary_basis (GDPR_ART_17_3_E), mapped_obligation, and retention_expires_at_or_criteria. It never includes the rejected PII value.

Requester-response wording (prose for operators)

Use this verbatim as the external partial: true communication:

We have completed the erasure of the mutable identity records associated with your request, including the identity mapping held in our actor-identity table and related mutable copies under our control.
A limited part of your request cannot be completed in full. Some historical evidence capsules created before our current no-personal-data capsule policy contain personal data embedded in cryptographically signed, append-only audit records. Altering those original signed records would invalidate their integrity guarantee and would impair records retained for compliance, audit, regulatory, security, and legal-defence purposes.
We are therefore retaining the original historical evidence capsules only to the extent necessary for those purposes. The basis for this retention is Article 17(3)(b) GDPR, where processing is necessary for compliance with a legal obligation requiring retention of the historical record. Where applicable, Article 17(3)(e) GDPR also applies for the establishment, exercise, or defence of legal claims.
We have restricted further processing of the retained historical records. The personal data embedded in those legacy capsules is suppressed from ordinary product, operator, search, analytics, and export views. Access to the original signed records is limited to authorised compliance, security, regulatory, audit, or legal personnel and is logged.
Your erasure request is therefore recorded as partially completed: mutable identity data has been erased, while specific historical signed evidence records are retained under the limited grounds described above. The retained records will remain subject to our retention schedule and will be reviewed or removed when the applicable retention basis expires.
You may contact our Data Protection Officer at [DPO contact] if you want further information about this decision. You also have the right to lodge a complaint with a supervisory authority and to seek a judicial remedy.

`actor_ref` linkability

After the shared.actor_identity mapping is erased, run the linkability assessment across logs, exports, support tooling, SIEM, warehouse, backups, and third-party processors. If no reasonably available relinking path remains, mark actor_ref_linkability = destroyed. If relinking remains, keep actor_ref under GDPR handling and either erase the remaining mapping or document a separate retention exception. Do not regenerate or preserve identifying mapping data solely to answer future SARs (GDPR Article 11). The audit event records the linkability assessment status.

Supervisory-authority response procedure

Retrieve the actor.erasure.legacy_capsule_refused audit event(s) for the request_id — these are the auditable record of the partial refusal.
Provide the per-capsule mapped_obligation and retention_expires_at_or_criteria from the retention map.
Confirm mutable identity erasure (shared.actor_identity side-table proof).
Confirm read-path suppression is in effect and raw access is break-glass-only.
State the Article 17(3)(b)/(e) basis; confirm Article 23 was not relied upon.
Honour Article 12 timing: respond without undue delay (within one month) and inform the data subject of complaint and judicial-remedy rights.

Operator position (summary)

The refusal is limited to sealed historical capsules where deletion or rewrite would damage the integrity of regulated release evidence. Operators cite the mapped retention obligation (DORA / NIS2 / CRA per the retention map) and the Article 17(3)(b) basis, confirm that mutable identity data outside the sealed capsule was erased, and confirm that the embedded data is tomb-stoned on all ordinary read paths.