Governance & PII

A PDTF transaction is dense with personal data — participant names, dates of birth, addresses, identity-document numbers, AML results, occupier names, and Article-10-adjacent terms like cautionOrConviction. Which classes bear personal data, of what category, under which lawful regime, is a modelling fact about the ontology (Pandit, ODR-0012) — so it is a TBox concern, governed by the DPV (Data Privacy Vocabulary) family. The floor is DPV Phase-1 annotation-only, referenced not imported. The PII-bearing Kinds below are read at build time from the committed annotation graph.

1 · DPV referenced, not imported

The governance module cites canonical DPV URIs (dpv, dpv-pd, dpv-legal, dpv-gdpr) via dct:references and enforces their use with local SHACL — but it issues no owl:imports (Kendall, ODR-0012 / ODR-0002 pattern). Reference-not-import keeps DPV's large class surface out of the OPDA graph while preserving dereferenceable URIs. The boundary is exact and was verified Council-side (session-033, Allemang): a model-constraining DPV lattice would require owl:import DPV and is deliberately out of scope; no DPV import, no in-graph range/property declaration, exists OPDA-side.

Three-graph separation

The governance module (opda-governance.ttl) declares the DPV machinery — the mapping records and the special-category scheme. The resulting per-Kind DPV co-annotation triples (and the opda:isPIIBearing flags) are emitted into the annotation graph (opda-*-annotations.ttl), never the class or shapes graph (ODR-0012 / ODR-0018 §Rule 4). The class graph stays clean of governance decoration.

2 · The PII-bearing Kinds

The Phase-1 PII floor (ODR-0018 §Rule 1) asserts opda:isPIIBearing "true" on exactly the baseline PII-bearing Substance Kinds. Each such class MUST carry a class-level dpv-pd:hasPersonalDataCategory baseline in its annotation file; the cross-cutting SHACL-AF rule PIIWithoutDPVCoAnnotationRule flags any isPIIBearing class lacking that co-annotation as a sh:Warning breach (silent PII leakage is high-impact). The flagged Kinds, read live:

opda:Person
opda:Property
opda:Address
opda:RegisteredTitle
opda:Claim
opda:EPCCertificate

opda:Organisation is intentionally unmarked (ODR-0006 §Q6: a legal entity is not a data subject) — its DPV mapping record carries no baseline category. The floor's enforcement is therefore value-precise: the SHACL-AF rule's target set is exactly these Kinds, and an un-annotated one is a finding, not a silent omission.

3 · Lawful basis via the DPV mapping record

Rather than import the DPV lattice, OPDA uses an authored mapping-record mechanism (ODR-0018 §3a): opda:DPVMappingRecord instances each opda:targetsKind a Kind class and name its opda:baselineCategory — a referenced DPV-PD category every instance of that Kind bears by default, with optional variant-conditional refinements. The mapping records, read live from opda-governance.ttl:

Mapping record	Targets Kind	Baseline DPV category
`opda:ClaimDPVMapping`	`opda:Claim`	`dpv-pd:OfficialID`
`opda:OrganisationDPVMapping`	`opda:Organisation`	`— (no baseline; not a data subject)`
`opda:PersonDPVMapping`	`opda:Person`	`dpv-pd:Name`

The lawful-basis layer is adopted and emitted in reference-not-import form (session-012 Q2, 10-0, reconciled by session-033). Consent records, a dpv:hasLegalBasis bound to a processing event, and any odrl:Policy instances are Phase-2 — a lawful basis is irreducibly an assertion about a processing act, which the TBox-only brief forbids. A held-as-live DA dissent (Allemang) defers anything beyond this floor, with re-open triggers recorded in session-033.

4 · Special-category (Article 10)

opda:SpecialCategoryScheme (a subclass of skos:ConceptScheme) is the GDPR Article 10 / DPA 2018 special-category scheme — the categories with elevated lawful-basis discipline (caution-or-conviction; AML result; etc.). The SHACL sensitivity gate raises a sh:Warning where a special-category-bearing term lacks its dpv:hasSpecialCategoryPersonalData annotation. Per ODR-0012, the scheme structure is class-declared now; member enumeration (the full Article-10 list) emits via the ODR-0010 SKOS substrate when a downstream driver scopes it — currently a class declaration only, no member enum scoped, recorded as deferred rather than silently absent.

5 · The purpose SKOS scheme

Purpose is modelled as a SKOS scheme, opda:PurposeScheme, grounded in the identity-verification / AML / source-of-funds chain implicit in the verified-claims envelope. Its concepts:

opda:IdentityVerification — verifying the claimed identity of a participant.
opda:AntiMoneyLaundering — AML / MLR 2017 customer due-diligence.
opda:ConveyancingDueDiligence — the conveyancing transaction due-diligence purpose.

The purpose scheme is ratified as the correct model (session-033, per ODR-0011 §8a method/plan-code mechanism), with emission gated on its first driver — a purpose-bearing field or an ODR-0009 worked example. So it is decided, not open; it simply has not yet been triggered into the emitted graph. That gate is itself the governance record: the model exists, and the trigger condition for materialising it is named.

The opda:Claim Kind that bears dpv-pd:OfficialID is detailed on Claims, evidence & provenance; the PIIWithoutDPVCoAnnotationRule and the sensitivity-gate sh:Warning are on SHACL shapes. Governing records: ODR-0012 (data-governance layer), ODR-0018 (DPV class-level co-annotation pattern), reconciled by Council session-033.