Data lifecycle / erasability as a candidate scheme

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.

Start by reading the open lifecycle-shape question in #2, the FIDES precedent in #4, and the emitter/consumer and policy patterns in #5 and #1. Confirm the direction before implementing anything; done would be an agreed scheme shape, an emitter/consumer fixture in the #5 style, and a corresponding policy.py check.