Erasure Proof — GDPR Article 17 Compliance

When a user exercises their right to erasure, GRAFOMEM doesn't just delete the data — it issues a cryptographic erasure certificate proving the deletion happened, all references were scrubbed, and the certificate is Ed25519-signed for independent verification.

Not just deletion — proof of deletion

Most systems delete data and hope for the best. GRAFOMEM produces a tamper-evident, Ed25519-signed certificate that you can hand to a DPA (Data Protection Authority) or the data subject themselves.

Withdrawn claim — backup-restore independence (2026-09-10)

Earlier material described an erasure ledger that survives a database restore, so that erasures performed after a backup was taken would be re-applied automatically when that backup is restored. That property does not currently hold and the claim is withdrawn: the erasure ledger presently resides in the same database as the data it records, so a restore rolls both back together. Erasure certificates remain valid as signed evidence that each erasure occurred; what is withdrawn is only the automatic re-scrub-after-restore guarantee. This notice stays until the ledger is relocated to a store independent of the primary database, and will be updated, dated, when that lands.

The erasure workflow

1. Fact is deleted from memory store
   ↓
2. All references scrubbed from Decision Trail records
   (content replaced with "[REDACTED — GDPR Article 17]")
   ↓
3. Content hash computed — BLAKE2b-128 of deleted content
   (proves what was deleted WITHOUT retaining PII)
   ↓
4. Certificate ID = BLAKE2b-128(tenant_id ‖ fact_ref ‖ timestamp)
   ↓
5. Certificate Ed25519-signed
   ↓
6. Certificate persisted to PostgreSQL

Certificate schema

Field	Type	Description
certificate_id	string	BLAKE2b-128 hex digest
tenant_id	string	Tenant that requested erasure
fact_ref	int	Memory ref that was deleted
fact_content_hash	string	BLAKE2b-128 hash of the content (proof without PII)
governance_record	JSONB	Protocol 3.4 formal effect record (declared/observed/result/freshness)
coverage	JSONB	(Legacy) Subsystems where content was checked or removed
scrubbed_decision_ids	string[]	IDs of affected decision records
erasure_requested_at	datetime	When erasure was requested
erasure_completed_at	datetime	When erasure completed
legal_basis	string	e.g. "GDPR Article 17 — Right to Erasure"
requested_by	string	Who requested: data_subject, dpo, or automated
signature	bytes	Ed25519 signature
public_key	bytes	Signer's public key
verified	bool	Whether signature was verified at issuance

API reference

POST /v1/erasure/issue

Issue a signed erasure certificate.

curl -X POST https://cloud.grafomem.com/v1/erasure/issue \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "fact_ref": 42,
    "fact_content": "Aria lives in Rome",
    "requested_by": "data_subject"
  }'

The fact_content field is never stored

It is only used to compute a BLAKE2b-128 hash. The hash proves you knew what was deleted, without retaining the PII itself.

GET /v1/erasure/stats

Summary: total certificates, total decisions scrubbed, signed count, first/last erasure dates.

GET /v1/erasure/{certificate_id}

Retrieve a single erasure certificate by its ID.

GET /v1/erasure/{certificate_id}/verify

Independently verify the Ed25519 signature:

{
  "valid": true,
  "certificate_id": "28b5813a622ed648...",
  "detail": "Ed25519 signature verified — certificate is authentic"
}

The verification reconstructs the canonical data, recomputes the BLAKE2b-256 digest, and verifies the Ed25519 signature against the stored public key.

GET /v1/erasure/fact/{fact_ref}

Find the erasure certificate for a specific fact ref.

GET /v1/erasure/

List all erasure certificates for the tenant (paginated).

Configuration

Set ERASURE_SIGNING_KEY as a hex-encoded 32-byte Ed25519 seed:

export ERASURE_SIGNING_KEY=$(python3 -c "import secrets; print(secrets.token_hex(32))")
grafomem serve --cloud --db postgresql://...

All certificates will be automatically signed at issuance.