Skip to content

Data lifecycle / erasability as a candidate scheme #6

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions