Data lifecycle / erasability as a candidate scheme

[cayerbe]

The use cases (UC-1…UC-5) and trust-annotations cover what data is (HIPAA/PII/financial), where it goes (UC-4), and how it propagates (UC-2). They don't cover how long it lives or whether it can be erased.

That's a separate axis. A host can know a result is PHI and still not know whether the tool retains it, for how long, or whether it can honor a deletion request. Under GDPR Art. 17 and the EU AI Act's deletion duties, that posture is its own policy input — it sits next to classification, not inside it. It also maps to two entries already in the Enterprise IG Pain Points catalog (modelcontextprotocol/modelcontextprotocol#2761, 3.3 and 7.1).

This fits as a scheme behind the evidenceRef slot, the same place FIDES sits in #4 — not an extension. Candidate type would carry:

• retention — declared bound, or none
• erasability — whether persisted data can be erased on request, and the signal for it
• persistence — none / session / durable

A coarse hint can ride the wire next to sensitive; the record stays out of band and recomputes in the #5 style. Lifecycle declarations touch the wire-hint vs host-resolved question open in #2, so the shape should follow whatever that lands on.

A scheme is a claim, not proof that the tool honors it — same as the other schemes. Verification is a separate problem.

I can write the emitter/consumer fixture for it in the #5 style, and a policy.py check in #1, if the direction is wanted.

[SamMorrowDrums]

Thanks for sharing, this is indeed interesting and definitely something we can factor in, you're more than welcome to provide an example, we are using issues and PRs to share use-cases and implementation examples as you reference, we will only merge the actual extension and documentation though, and I need to clean up current PRs ASAP for this really.

@kapil8811 did awesome work with trial implementation and I'm sure he'd be happy if you wanted to try out data retention policy stuff also.

[kapil8811]

@cayerbe Agree the axis is real and not currently covered. For grounding on what is in the SDK today: we have regulated data classes (Regulated/Regulated Scope), an outcome severity axis (benign/consequential / irreversible) and a policy engine that enforces over them in three modes - audit / warn / enforce. On the MCP side there's readOnlyHint, and our destination enum has an ephemeral value but that's spatial (where an input is routed), not a retention bound, so you're right that TTL / retention / erasability is genuinely absent.

Where I'd push back is on the mechanism. Retention disclosure ("this is kept N days") is a passive claim and could sit behind evidenceRef like FIDES. But erasability is an actuation "honor a deletion request" is a callable, not a label and evidenceRef, like every scheme, declares rather than acts. A static erasable: true annotation is unverifiable and does nothing; what a host actually needs is to discover a tool it can invoke to erase. That makes erasability a better fit for capability negotiation the host learns which tools expose lifecycle/ALM operations over regulated data than for the annotation/evidenceRef surface.

So, I'd split it: a coarse retention/persistence hint can ride alongside sensitive as you describe, but the erasability half should be negotiated capability, not annotation. Happy to be wrong on this if the scheme is only ever meant to advertise the signal and the actuation lives elsewhere - in which case we're closer than it looks.

Here's the link to the PR: #1. Please feel to review it and we can build on top of it.

[cayerbe]

@kapil8811 Agreed on both halves. Retention and persistence are passive disclosure: a declared bound and a lifetime class. So yes, they sit behind evidenceRef, same as FIDES, with the coarse hint riding next to sensitive.
You're also right that a flat erasable: true is unverifiable and does nothing. But let me narrow the point: erasability here declares the signal that an erase path exists, plus a discovery reference. It advertises and points; it doesn't act. The actuation — the actual operation a host calls to honor a deletion — is capability negotiation, this is your layer. So the field stays a declaration; the callable stays where you put it.
The way I see it, we are dealing with three layers:

1. Declaration (this scheme): The signal that an erase path exists, plus the pointer/discovery reference.
2. Actuation (capability negotiation): The operation the host discovers and invokes.
3. Verification (separate): Whether an erase that was invoked actually held.

When you point out that a flat label does nothing, you're describing the natural claim ceiling for the declaration layer. A scheme saying that an erase path exists proves the tool advertises the signal. It doesn't prove it honors a deletion (actuation) or that it held (verification).
One quick naming note so the axes don't get read for each other: destination: ephemeral is spatial (where an input routes), whereas persistence here is temporal (how long a result lives). I'll ensure the naming keeps those strictly distinct.
A few quick next steps on my end:

• Wire shape: Stays loose for now and follows whatever the open wire-hint question lands on (no pre-commitment on encoding).
• PR added initial scaffolding files with python ref SDK #1 Review & Integration: I'll review added initial scaffolding files with python ref SDK #1 and build policy.py directly on top of it. I'll consume your regulated-data classes, the benign/consequential/irreversible severity axis, and the audit/warn/enforce modes to avoid adding parallel vocabulary.
• Deliverables: I'll follow up with the scheme doc plus an emitter/consumer fixture in the recomputable-from-bytes style on this agreed shape, and come back once it's ready.