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.
The use cases (UC-1…UC-5) and
trust-annotationscover 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
evidenceRefslot, the same place FIDES sits in #4 — not an extension. Candidatetypewould carry:retention— declared bound, or noneerasability— whether persisted data can be erased on request, and the signal for itpersistence— none / session / durableA 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.pycheck in #1, if the direction is wanted.