Epic: Semantic classification and safeguard profiles

## Outcome

Registry Stack can describe data fields using versioned authoritative semantic vocabularies, attach reviewed privacy and handling classifications, explain the minimum safeguards those classifications require, and enforce supported controls consistently across Relay disclosure surfaces.

The design keeps three concerns separate:

1. **Semantic concepts** describe what data means, using PublicSchema, EU SEMIC, FHIR, SDMX, national vocabularies, or other selected authorities.
2. **Classifications** describe privacy, identifiability, confidentiality, or protection-state properties through governed terms.
3. **Safeguard profiles** map classifications to minimum enforceable controls and identify responsibilities outside Registry Stack.

## 1.0 boundary

This epic is post-1.0. Registry Manifest v1 remains compatible and existing concepts, dataset sensitivity, audit-sensitive flags, and explicit Relay policies retain their current behavior.

The two 1.0 prerequisites are tracked separately:

- #587 decides whether sensitive datasets may use scope-only access with no governed binding.
- #589 defines and tests the existing Manifest concept and vocabulary contract.

## Durable invariants

- Semantic or classification metadata never grants access.
- Derived controls may add restrictions but never remove explicit restrictions.
- The most restrictive applicable control wins; policy precedence never depends on display names, lexical order, or creation time.
- Unknown policy-driving classifications fail closed in enforcement mode.
- Vocabulary and profile artifacts are versioned, digest-pinned, and resolved locally. Relay performs no mutable runtime vocabulary lookup.
- Inferred classifications remain proposals until reviewed and recorded in a governed artifact.
- Concept mappings do not transfer security classifications unless a pinned profile explicitly defines that derivation.
- Pseudonymized or de-identified state cannot relax controls without reviewable evidence.
- Every Relay route exposing or querying classified fields consumes the same compiled control plan.
- Unsupported DPI Safeguards responsibilities are reported honestly and are not labeled as enforced.

## Delivery sequence

1. Versioned semantic profile packages and pinned vocabulary artifacts.
2. Additive field classification bindings in Manifest and Relay catalog output.
3. Safeguard profile schema and an explain-only compiler.
4. DPI Safeguards coverage profile with enforceable, declared, and unsupported outcomes.
5. Field-aware Relay and PDP enforcement across every disclosure surface.
6. Catalog and authoring UX integrated with existing editor contracts.
7. Optional advisory classification suggestions with mandatory human review.

## Success criteria

- [ ] All child issues are complete with compatibility, security, documentation, and migration evidence.
- [ ] A golden workspace uses an authoritative semantic profile, reviewed field classifications, and a pinned safeguard profile.
- [ ] `registryctl` can explain every effective per-field control and its source without exposing field values.
- [ ] Relay applies the compiled plan consistently to rows, filters, relationships, aggregates, OGC adapters, SP DCI adapters, and attribute release where those surfaces are enabled.
- [ ] Missing, ambiguous, or unsupported policy-driving metadata has deterministic diagnostics and fail-closed enforcement behavior.
- [ ] Public documentation distinguishes metadata description, runtime enforcement, external responsibility, and unsupported safeguards.

## Non-goals

- A general enterprise data marketplace
- Arbitrary table-query or warehouse-policy parity
- Hosted scanning of raw registry records
- AI activation of policy, legal basis, consent, or eligibility decisions
- A hardcoded PublicSchema-only semantic model
- A claim that implementing this epic alone establishes DPI Safeguards compliance

## Child issues

- [ ] #591 Support versioned semantic profile packages and pinned vocabulary artifacts
- [ ] #592 Add field classification bindings to Manifest and Relay catalog metadata
- [ ] #593 Define safeguard profiles and compile an explainable per-field control plan
- [ ] #594 Enforce compiled field controls across Relay routes and the shared PDP
- [ ] #595 Publish a DPI Safeguards-aligned coverage profile with honest enforcement status
- [ ] #596 Add classification review and safeguard explanation to authoring and catalog UX
- [ ] #597 Offer advisory field-classification suggestions with mandatory human review

## Dependency graph

```text
#589 -> #591 -> #592 -> #593 -> #594
| |
| +-> #595 runtime-enforced outcomes
+----------> #595 descriptive coverage

#592 + #593 -> #596
#592 + #596 -> #597
#587 ---------> #594
```

`#595` may begin its descriptive mapping after #593, but it cannot report a runtime outcome as enforced until #594 supplies and tests that enforcement point.

Start by reading the prerequisite #589 and child issues #591–#597, then inspect the existing Manifest, Relay, shared PDP, and registryctl contracts. The epic is done when the child issues and compatibility, security, documentation, and migration evidence are complete, including consistent field-control explanations and tested fail-closed behavior across enabled Relay surfaces.

Written by the indexing model from the issue text.