dds

# Obligation profiles

The engine is obligation-neutral; everything a framework demands lives
here, one profile per obligation source — symmetric with
`../platforms/` (the code's dialect) at the layer above (the law's /
contract's dialect).

- `_core.json` — the regime-free data-protection core: the party
  kinds, the facet law PER PARTY KIND (person datums carry the
  identifiability/category/provenance law; organization/internal
  datums carry the classification law), the activity law, the
  governance stems (`basis.*` · `retention.*` · `terms.*` — the
  neutral slots every framework projects onto).
- `<name>.json` — a profile, activated by DECLARATION (never
  detection: which obligations govern is itself a judgment). The repo
  declares in `docs/governance.md`:

      Regime: gdpr, ferpa        ← law regimes
      Scope: confidentiality     ← protection scopes

  Each token must name a carried profile; an unknown token is a
  structural finding; `Regime: TODO` is the honest hole — the check
  runs core-only and says so. Multiple profiles union.

  Profile fields the engine consumes (a FIXED rule set — profiles
  parameterize rules, they never carry logic):
  - `require_activity_authority` — activities must carry the
    authority field (`Lawful basis`, holes welcome);
  - `required_person_subject_facets` — e.g. `Minor`;
  - `required_governance_stems` — stems that must have at least an
    entry or an honest hole;
  - `classified_store_gating` + `classified_tiers` — scope rule: a
    store carrying an org/internal datum at these tiers must have a
    policy gate (witness-joined, CUBE finding);
  - `terminology` — how the neutral slots render under this profile
    (carried into the walk for downstream labeling).
- `<name>.md` — the human guide: what the profile maps, what counsel
  sources.

Mark new profiles `"sketch": true` until a real repo has run them —
the report says so. Adding a framework is data + one guide file,
never engine code.