Exit, Export & Deletion

Service exit is not a Delete button

A SaaS customer terminates service and requests export followed by deletion. Primary records are deleted, one subprocessor is still PENDING, backups expire later, one record must remain under a documented retention exception, and an API token is still active. Declaring closure_state=COMPLETE after deleting the customer row would overstate the evidence. This lesson builds Service Exit, Export, Deletion & Residual-Data Closure Ledger v1 so export, delete/return, retention, backup/subprocessor, credential/integration and residual states remain separate.

Boundary and decision route

AGN-011 owns exit/export/deletion. AGN-010 owns IP/Rights and AGN-012 owns Billing Adapter. Freeze the inventory; determine export/return requirements; close export with format, integrity and delivery evidence; separate deletion scope from retention exceptions; track primary, backup and subprocessor states independently; revoke credentials and integrations; verify residual state; only then declare COMPLETE, PARTIAL or HOLD.

Mental model: seven independent gates

Keep inventory, export/return, retention, primary deletion, backup/subprocessor closure, credential/integration shutdown and residual verification distinct. Passing one gate proves only that gate. Successful export does not prove deletion. Primary deletion does not prove backup deletion. A certificate without reconstructable residual evidence does not prove complete closure.

The 22-dimension ledger

The contract locks 22 fields: exit_case_id, asset_inventory_ref, data_inventory_ref, agent_memory_inventory_ref, export_scope, export_format, export_integrity_hash, export_delivery_state, deletion_scope, retention_exception_ref, retention_until, primary_delete_state, backup_delete_state, subprocessor_delete_state, credential_revoke_state, integration_disconnect_state, residual_scan_ref, residual_state, deletion_certificate_ref, legal_review_required, closure_state, audit_ref. The Lab adds visible helper fields for retained-data basis, return requirements, active credentials/integrations and transfer recomputation.

Separate Fact, Inference and Design

FACT: GDPR Article 20 defines a conditional data-portability right for certain personal data in a structured, commonly used and machine-readable format. FACT: Article 28(3)(g) requires delete or return, at the controller's choice, after processing services end, unless applicable law requires storage. INFERENCE: service exit is more auditable as multiple closure states. DESIGN: exact export formats, retention windows, proof artifacts, backup policy and final closure authority remain local MAKNOW/contract/legal decisions.

Baseline: why PARTIAL is correct

The baseline has a delivered export with SHA-256 evidence. Primary data is deleted, backup is SCHEDULED_FOR_EXPIRY, subprocessor deletion is PENDING, one credential remains ACTIVE, an integration is disconnected, and one billing record has a valid retention exception. The bounded result is EXIT_PARTIAL_REVIEW_READY. primary_delete_state=DELETED is not enough for COMPLETE.

Mutation 1: pending subprocessor + COMPLETE -> HOLD_FALSE_COMPLETE_PENDING_SUBPROCESSOR. Mutation 2: retained data but no retention basis -> HOLD_RETENTION_BASIS_MISSING. Mutation 3: VERIFIED export with no integrity hash -> HOLD_EXPORT_INTEGRITY_MISSING. Mutation 4: residual=CLEAR while a credential is active -> HOLD_ACTIVE_CREDENTIAL_RESIDUAL_CONFLICT.

Failure modes

1. Primary deletion treated as total exit. 2. Export without integrity evidence. 3. Retained data without a valid basis. 4. Pending backup hidden under COMPLETE. 5. Pending subprocessor hidden under COMPLETE. 6. Active credential after exit. 7. Connected integration after closure. 8. Residual=CLEAR while known residuals remain. 9. Certificate without reconstructable evidence. 10. Legal review required but bypassed. 11. Transfer copies baseline basis or closure.

COMPLETE, PARTIAL, HOLD and RETURN

COMPLETE requires every required state to be closed or explicitly excepted with valid evidence. PARTIAL is correct when export or primary deletion is complete but backup/subprocessor/credential/residual closure remains. HOLD is required for decisive missing or contradictory evidence. Some processor relationships require RETURN instead of deletion; model that separately from data portability.

Experienced bridge: backups, subprocessors and legal holds

Real systems may not erase every copy instantly. Backup copies can age out through a controlled expiry schedule; subprocessors need separate closure evidence; legal holds can require temporary retention. Do not call a valid exception a failure, and do not disguise a failure as an exception. Preserve basis, expiry, owner/legal review and residual evidence.

Guided and independent practice

Run the baseline and explain PARTIAL. Mutate one field at a time: subprocessor, retention basis, export hash, credential, integration, residual scan and certificate. Name the first broken gate. Then solve the transfer case: some processor-held data must be returned, no portability right applies, but a contractual machine-readable export is promised. Recompute from the new evidence without seeing the baseline decision label.

What must be reconstructable?

A reviewer must reconstruct the inventories, export scope/format/hash/delivery, deletion scope, retained data basis and expiry, primary/backup/subprocessor states, credential and integration shutdown, residual scan, certificate linkage, legal-review requirement, and the exact reason closure is COMPLETE/PARTIAL/HOLD. “The account was deleted” is not sufficient evidence.

Transfer: Return instead of Delete plus contractual export

The second case requires RETURNED for some processor-held data. No portability right applies, but the contract promises a machine-readable export. Record CONTRACTUAL_PROMISE as export basis, verify return, recompute retention and residual states, and derive closure independently. Reusing the baseline jurisdictional basis or closure must fail. With complete evidence the fixture can reach TRANSFER_EXIT_REVIEW_READY.

Sources and freshness

FACT: the official GDPR text continues to state the Article 20 portability right under defined conditions and the Article 28(3)(g) delete-or-return processor obligation with a storage-required-by-law exception. The European Commission continues to publish controller–processor SCCs under Article 28(7). INFERENCE: these boundaries support separate exit states. DESIGN: exact closure policy remains MAKNOW and contract/legal-review authority. Recheck legal sources by 2026-11-02 or earlier on material change.