Label presets (sensitivity tiers / compliance regimes) instead of manual label selection

[martsokha]

Summary

Instead of asking a policy author to hand-pick individual entity labels, offer presets they choose from — either sensitivity tiers (low → high) or compliance regimes (GDPR, HIPAA, PCI-DSS, SOC 2, ISO 27001, …). The preset expands to a curated label set behind the scenes.

Manually selecting from ~60 builtin labels is error-prone and requires the author to know which labels matter for their obligation. A preset encodes that expertise: "GDPR" or "high sensitivity" → the right label set, no per-label decisions.

Current state

• Policies own the label vocabulary (as of runtime #352): PolicyDefinition.labels: LabelCatalogParams ( builtins: Vec<String> names + custom: Vec<Label> ), unioned by the engine into the detection catalog. See the policy-owned-labels work on branch feat/policy-owned-labels.
• Builtin labels already carry compliance-relevant tags. elide's builtin set tags labels with pii (~34), phi, pci, financial, biometric, credentials, demographic, contact_info, network_identifier, location, etc. A preset can be expressed as a selection over these tags or an explicit label list.

So a preset is essentially a named, curated LabelCatalogParams — this issue is about authoring UX + a preset catalog, not new engine plumbing.

Proposal

1. Preset catalog — define named presets, each resolving to a set of builtin label names (+ optional custom). Two framings (could ship both):
   • Sensitivity tiers: low / medium / high — progressively broader label coverage.
   • Compliance regimes: gdpr, hipaa, pci_dss, soc2, iso_27001 — each mapping to the labels that regime concerns itself with (e.g. PCI-DSS → payment_card, card_security_code, card_expiry; HIPAA → the phi/health labels; GDPR → broad pii).
2. Authoring surface — policy create/update accepts a preset reference; the server expands it to LabelCatalogParams when persisting (or stores the preset ref and expands at run time — see open questions). Advanced users can still drop to manual label selection.
3. Composability — presets union (a policy can select GDPR + PCI-DSS); manual additions/removals on top of a preset.

Open questions

• Store expanded, or store the preset reference? Expanding at author time freezes the label set (reproducible, but stale if the preset definition changes); storing the reference keeps policies current but makes a run's behavior depend on the preset catalog version. Leaning toward storing the reference + resolving at run time, with the resolved catalog already snapshotted into Audit.scope for reproducibility.
• Where do preset definitions live? Server constant, config, or a DB table editable per deployment? Compliance mappings are opinionated and may need legal review — probably server-owned + versioned, not customer-editable initially.
• Accuracy/liability — a preset named after a law implies a compliance claim. Mappings must be defensible and clearly documented as "coverage of common data types," not "certified compliance."
• Tier vs regime — are sensitivity tiers and compliance regimes two separate preset kinds, or is "high sensitivity" just an alias for a broad regime union?
• Relationship to file classification tags (Tag-based file access control (in addition to workspace roles) #194) and detection — presets drive what gets detected/redacted; keep distinct from access-control tags.

Out of scope

• Legal certification of any regime; presets are a curated starting point, not a compliance guarantee.

🤖 Generated with Claude Code