Adapter Contract Specification §7.1

Right to Erasure

How CCL is designed to make erasure verifiable across distributed systems and AI agents.

The Distributed Erasure Problem

When a user or subject submits an erasure request under GDPR Art. 17, CCPA, or a comparable regulation, their contextual data has typically propagated to dozens of downstream systems: CRM platforms, analytics pipelines, data warehouses, AI agents, recommendation engines, and custom APIs. Each downstream system received a copy of the context at propagation time.

Traditional erasure processes rely on sending deletion instructions to each downstream system individually and trusting that each system executed the deletion completely. There is no shared key, no unified proof mechanism, and no technical way to confirm that an AI agent's embedded context, a cached analytics record, or a replicated CRM field was actually destroyed — not merely flagged.

As AI systems multiply the number of downstream consumers for any given context — including vector embeddings, model fine-tuning datasets, and agent memory stores — the gap between "we sent a deletion request" and "we can prove it is gone" widens substantially. CCL is architected to close that gap through cryptographic key destruction rather than coordinated deletion requests.

How CCL Is Designed to Implement Erasure

STACCR's erasure architecture is built on a single cryptographic primitive: AES-256-GCM encryption of the context payload under a per-subject, per-tenant key — stored in the customer's own KMS environment (AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault, or HSM). STACCR never holds the key.

Key Destruction

When an erasure request is authorized, STACCR is designed to trigger the rotation and destruction of the AES key that encrypted the subject's context envelope within the customer's KMS. Because the payload was never stored in plaintext — and the key is held exclusively in the customer's KMS — destroying the key renders the context permanently and computationally inaccessible across every adapter that ever received a token for that subject, without requiring STACCR to chase individual copies across downstream systems.

The result is that erasure becomes a property of the cryptographic architecture, not a coordination problem. Once the key is destroyed, the payload cannot be recovered regardless of how many copies exist in how many systems.

Adapter Contract Confirmation

Every adapter participating in the STACCR ecosystem is designed to operate under a CE Adapter Contract — a binding technical and legal obligation that includes acknowledging erasure events with an HMAC-signed confirmation receipt. When a key destruction event is issued, each adapter is designed to receive a signed notification and return a confirmation that it has invalidated any cached tokens, purged any locally held context references, and acknowledged that the payload is no longer recoverable.

These per-adapter acknowledgments are the building blocks of the Verifiable Erasure Certificate. No certificate is issued until all registered adapters for the subject have confirmed.

Audit Trail Integrity

The audit ledger records the key destruction event and all per-adapter acknowledgments as immutable, HMAC-signed entries. Unlike the context payload itself — which becomes inaccessible after key destruction — the audit record is retained. This is intentional: the audit trail is the cryptographic evidence that erasure occurred, even though the erased content can no longer be read. The ledger is architected to satisfy regulatory evidence requirements without requiring the payload to remain accessible.

Target Erasure SLOs

The following service-level objectives describe the target timeline for each stage of the erasure lifecycle. These are designed targets for the production platform; actual timelines will depend on customer KMS latency, adapter response times, and partner-specific integration characteristics.

What Is Retained After Erasure and Why

After the erasure lifecycle is complete, STACCR is designed to retain the following categories of data:

• The audit trail record of the erasure event — retained as cryptographic evidence that erasure occurred and available for regulatory inspection. Retention of the audit record does not constitute retention of the erased payload.
• The Verifiable Erasure Certificate — retained as the signed, regulator-ready artifact produced by the erasure process.
• Per-adapter acknowledgment receipts — retained as per-adapter confirmation that the erasure event was received and executed.
• Aggregate or anonymized analytics — retained only where not linked to the subject identifier and not within scope of the erasure request.

The context payload, consent records linked to the subject, and any subject-linked contextual state is rendered permanently inaccessible through key destruction. STACCR is designed to hold no recoverable copy of the erased payload.

Regulatory Alignment

The following table describes how CCL's cryptographic erasure architecture is designed to address each regulatory requirement. This is an architectural mapping, not a compliance certification. Organizations should conduct their own legal assessment for their specific jurisdiction and use case.

The Erasure Certificate

When the erasure lifecycle is complete — key destruction confirmed, all adapter acknowledgments received — STACCR is designed to issue a Verifiable Erasure Certificate: a signed, machine-readable document that captures the erasure event, confirms that each connected adapter acknowledged it, and establishes the cryptographic basis for the certificate's claims.

The certificate is architected to serve as regulatory evidence: an auditor or regulator can verify that erasure was technically enforced — not merely administratively asserted. The certificate includes the certificate identifier, subject reference (redacted), the DEK versions destroyed, per-adapter acknowledgments with signed status, test decryption result confirming inaccessibility, issuance timestamp, and issuer attribution.

{
  "certificate_id": "cert_01HXYZ9Q2...",
  "subject_id": "[REDACTED]",
  "dek_versions_destroyed": ["v1", "v2", "v3"],
  "destruction_confirmation_token":
    "[REDACTED — held by customer KMS]",
  "test_decryption_result":
    "FAILED — token unrecoverable",
  "adapter_acknowledgments": [
    { "adapter_id": "adp_crm_01...", "status": "ACKNOWLEDGED", "signed": true },
    { "adapter_id": "adp_analytics_02...", "status": "ACKNOWLEDGED", "signed": true },
    { "adapter_id": "adp_ai_agent_03...", "status": "ACKNOWLEDGED", "signed": true }
  ],
  "issued_at": "2026-06-11T17:42:09Z",
  "issuer": "STACCR™ / Context Layer Systems"
}

Sample certificate — redacted, pre-GA format. Not a production certificate.