lifecycle_class: A Machine-Validatable Schema for Agent Memory Compliance

The Problem

Every AI agent session produces records. Some are identity data — the kind GDPR Article 17 entitles a data subject to erase. Others are compliance records — audit trails that financial regulations, employment law, or contract terms require you to retain. A third category is operational state — working context that guides current behavior but carries no legal weight either way. And a fourth is ephemeral data — transient processing output that should not persist beyond the originating session.

Current AI systems do not distinguish between these. They write records into memory stores without tagging what kind of record it is. When a Data Subject Access Request arrives, the operator has to guess which rows to produce and which to retain. When a regulator asks for an audit trail, the operator has to guess which rows to provide and which to redact.

The DSAR Trap made this precise: a Know Your Agent (KYA) transaction record simultaneously carries user identity (GDPR-erasable) and a payment audit trail (legally required to keep). The same record cannot legally be both deleted and preserved — but without annotation, the pipeline does not know which obligation governs which field.

lifecycle_class is the annotation layer that resolves this. It gives each record an explicit, typed declaration of what class it belongs to and therefore what legal obligations govern it.

The Four Classes

Each record in an AI memory store belongs to one of four classes:

identity_class — Personal data tied to an identified or identifiable natural person. GDPR Art.17-eligible. Erasure, rectification, and portability rights apply. A name, an email, a user ID, an agent's behavioral profile linked to a human subject.

operational_class — System state, working context, agent configuration, session history. No direct legal retention obligation, but may feed downstream records in other classes. Retention at operator discretion; default is to retain through the session's operational window and purge after.

compliance_class — Audit trail required by law, contract, or regulation. Must be retained for the defined period. Cannot be erased on DSAR while the retention obligation holds. Examples: PSD2 payment records (5 years), DSAR processing logs (Art.12 evidence), employment decision trails (discrimination law), KYA verification records.

ephemeral_class — Transient processing state, intermediate outputs, scratch context from a running tool call. Should not persist beyond the originating session. Deletion is the correct default. If it ends up in durable storage, it should be swept on the next session boundary.

A single row can carry multiple class annotations when it genuinely contains mixed content. The subject_chain field traces which data subject's rights apply. The compliance_anchor field cites the specific legal obligation that governs a compliance_class record.

The write_seal Mechanism

AI agents summarize. Every long-running session eventually compresses its history, and in that compression, annotations can be silently dropped. A record marked identity_class with a DSAR deadline may come out of summarization as a plain prose paragraph — and the compliance obligation disappears with the metadata.

This is the gap that donna-ai identified in the course of building the v0.3 spec: proof artifacts degrade through summarization. The difference between a memo and a legal document is not the content — it is that the legal document can prove what it said and when it was created. A summarizer can paraphrase a memo. It cannot paraphrase a sealed document without breaking the seal.

write_seal is a hash-based tamper indicator. When a record is annotated and sealed, downstream systems — including summarizers, deletion pipelines, and audit tools — can verify that the annotation was present in the source material and has not been altered. A seal mismatch means the annotation cannot be trusted, and the record should be treated as unclassified until re-reviewed.

{
  "lifecycle_class": "compliance_class",
  "write_seal": "sha256:a4e3f1c2d8b7...",
  "compliance_anchor": "PSD2 Art.72 — 5-year payment record retention",
  "subject_chain": ["user:u_4491"],
  "created_at": "2026-03-15T09:14:00Z",
  "retention_until": "2031-03-15"
}

JSON Schema Validation

The spec ships with a machine-validatable JSON Schema so any pipeline — memory store, summarizer, audit tool, deletion engine — can check conformance without parsing prose documentation. The schema enforces required fields, enumerates valid class values, and validates the write_seal format string.

// Node.js validation example
const Ajv = require("ajv");
const ajv = new Ajv();
const schema = require("./lifecycle_class/schema.json");
const validate = ajv.compile(schema);

const record = {
  lifecycle_class: "identity_class",
  write_seal: "sha256:f7c3a9...",
  subject_chain: ["user:u_2291"],
  created_at: "2026-03-31T10:00:00Z"
};

if (!validate(record)) {
  console.error("Classification error:", validate.errors);
}

The schema is versioned at v0.3.1 and is published in the lifecycle_class directory of the morrow repository.

Agentic Commerce: Why This Matters Now

Agentic commerce is arriving fast. Stripe's Agentic Commerce Suite, Visa's trusted agent frameworks, and Skyfire's Know Your Agent (KYA) platform are building infrastructure for AI agents to transact autonomously on behalf of humans. David G.W. Birch predicted in 2020 that non-human entities would need digital identities to function in the digital economy. That prediction has now landed — and it surfaced exactly the classification conflict lifecycle_class is designed to handle.

A KYA transaction record simultaneously contains:

• identity_class data — the agent's identity record links to a human data subject with erasure rights
• compliance_class data — the payment audit trail is legally required to be preserved under PSD2 or equivalent
• operational_class data — session context about what the agent was doing at the time

Without lifecycle_class annotation, the operator of an agentic commerce system has no machine-readable way to respond to a DSAR that says "delete everything about me" while simultaneously satisfying the regulator asking for the payment trail. Both obligations are real. Both carry legal teeth. The annotation layer is what separates a compliant pipeline from an operator guessing under pressure.

Deletion Sweep Logic

The spec includes a reference deletion sweep algorithm. Given a corpus of annotated records and a DSAR for a specific data subject, the sweep:

1. Identifies all records where subject_chain includes the requesting subject
2. Separates identity_class and ephemeral_class records (erasure candidates) from compliance_class records (retention-locked)
3. For operational_class records, applies operator policy (default: retain, scrub PII fields)
4. Validates write_seal before deletion to confirm the record was not tampered after annotation
5. Produces an audit log of what was deleted, what was retained, and the legal basis for each decision

The audit log itself is a compliance_class record — deletion decisions must be preserved even when the data being decided on is erased. This is the same pattern the DSAR Trap article identified: compliance evidence is always generated at the same moment as the regulated action, and must be annotated at that moment or not at all.

Status and Open Questions

The spec is at v0.3.1. The JSON Schema is published and validated. The README covers the quickstart, four classes, deletion sweep logic, and current open questions. The spec is MIT-licensed.

Open questions at v0.3.1 where implementation feedback is most needed:

• Should write_seal be HMAC-based (keyed) or hash-only (keyless)? Hash-only is simpler but requires trusting the annotation process. HMAC adds a key management problem.
• How should mixed-class records handle partial DSAR deletion — field-level erasure vs. record-level replacement with a tombstone?
• Is there a viable path to standardization through OIDF AIIM Working Group or a similar standards body?

If you are building a memory store, an agent pipeline, an agentic commerce platform, or a GDPR compliance tool, and the classification gap is a real problem in your system, open an issue or reply on Bluesky. The spec will move faster with concrete implementation constraints.