What the Guidebook could mean for SPDTF

The Guidebook addresses everything to "schemes" and "participants", and never separates an obligation on a scheme operator (something an organisation must do) from an obligation on a data standard (something a vocabulary must be able to say). This page makes that separation, ask by ask — and says plainly where an ask creates no data-modelling obligation at all, rather than manufacturing one.

Read these as conditional modelling questions, not compliance findings

Smart Data and SPDTF are two different initiatives. The PDTF schema is the existing Digital Property Pack schema; its schema-derived ontology is separate evidence. SPDTF is the first scheme draft being authored collaboratively across industry and stakeholders. None is bound by the Guidebook. A ❌ below is a capability finding about what the existing evidence can say, describing what might be needed if and when property became a designated Smart Data scheme. It is never an assertion of non-compliance.

How the right-hand column was produced

Every verdict about the schema-derived ontology is checked against the committed TTL corpus in source/03-standards/ontology/, not against the ontology's aspirational layer plan. That distinction matters: six claims that looked true on the plan turned out to be false in the corpus — including one this page originally got backwards, asserting a capability that a council had deleted. See the reality check below.

Reality check: what the schema-derived ontology contains

The ontology's planned layer stack (OWL2 · SKOS · DCAT · SHACL · DPV/ODRL · PROV/RML · OWL-Time · DPROD) is a plan. What is actually in the committed corpus today is narrower, and any capability claim must rest on the corpus:

Layer	In the corpus?	Evidence
PROV — claim provenance	✅ Real, and SHACL-enforced	Every `opda:Claim` must carry `prov:wasDerivedFrom` (`sh:minCount 1`); `prov:wasGeneratedBy`, `prov:wasAttributedTo`, `prov:generatedAtTime` all in active use; core classes subclass `prov:Entity`/`prov:Activity`
DPV — personal data & legal basis	⚠️ Narrow, and two-layered	`dpv-pd:hasPersonalDataCategory` is asserted. Lawful basis exists at two layers: `opda:lawfulBasis` is the class-level co-annotation (reference-not-import, ODR-0012), while `dpv:hasLegalBasis` is the instance-level predicate the SHACL Cat-4 shape enforces — and instance-level lawful basis is Phase-2 per ODR-0012, so it is not yet exercised. No consent/processing-event model exists to hang it on.
SKOS / OWL / SHACL	✅ Real	The core of the separate schema-derived ontology
OWL-Time	⚠️ Minimal, but structural	`opda:LeaseTerm rdfs:subClassOf time:ProperInterval`, with `time:hasBeginning` / `time:hasDurationDescription` — a genuine adoption, but confined to lease terms. Nothing time-models consent, delegation or status validity.
ODRL — permissions, duties, policies	❌ Absent	Zero occurrences
DCAT / DPROD — dataset & data-product metadata	❌ Absent	Zero occurrences
Selective disclosure	❌ Not supported — and we currently claim otherwise	`Ed25519Signature2020` Linked Data Proofs (MUST, per the access specification). No BBS or SD-JWT suite. Yet `trust-framework/docs/governance.md` asserts "selective disclosure enforced" — a capability OPDA publicly claims and does not have
Assurance levels	❌ Removed	`opda:assuranceLevel` deleted 2026-07-05 (ODR-0009, exact source wording: "zero PDTF schema basis"). See below — do not claim this as a strength
Consent · delegation · accreditation · audit-event · decision classes	❌ None exist	(`opda:consentsObtained` is a leaf inherited from the PDTF schema — a yes/no property fact, not a consent artefact)

One live defect this analysis surfaced in our own artefacts

We published a selective-disclosure capability we do not have. trust-framework/docs/governance.md said "Data minimization and selective disclosure enforced". With an Ed25519Signature2020-only proof suite, selective disclosure is not possible. That sentence has been withdrawn — see gap SD8.

A defect this analysis wrongly reported, and retracts

An earlier draft of this page claimed the legal-basis SHACL shape "can never pass", on the grounds that it validates for dpv:hasLegalBasis while the corpus asserts opda:lawfulBasis. That was wrong. The two are different layers, not a mismatch: opda:lawfulBasis is the class-level co-annotation (reference-not-import, per ODR-0012), whereas dpv:hasLegalBasis is asserted on instance data — which ODR-0012 makes explicitly Phase-2, because a lawful basis is irreducibly an assertion about a processing act. The shape is correct and simply not yet exercised (no exemplar carries special-category data). dpv:hasLegalBasis stands as the instance-level predicate.

Evidence SPDTF can build on

Three evidence-backed points OPDA can make, provided their provenance and status remain clear:

The schema-derived ontology demonstrates a shared semantic layer. The Preamble demands "a shared semantic layer — a common language of attributes, roles and consent concepts" and never says who builds it. Chapter 2 asks for "ontological models to define the meaning of data fields, attributes and claims". Chapter 3 says interoperability should come from "aligning the meaning of key concepts, rather than requiring identical technical implementations". That is an OWL/SHACL/SKOS standard, described three times, by three different chapters, with no owner named.
Claim-level provenance, mandatory and machine-checked. Chapter 4 asks that "the origin and lineage of data can be verified"; Chapter 2 says "attribute-level assurances and provenance rules are essential for data with legal effects" — in its section about property. The schema-derived ontology refuses to accept an unprovenanced Claim: its SHACL shape makes prov:wasDerivedFrom a hard requirement. This is the one place the Guidebook describes a problem for which OPDA already has useful semantic evidence.
Data quality. Chapter 4 asks for "responsibility for data quality". A separate Quality framework produced alongside the PDTF schema already defines six dimensions. It is evidence for SPDTF, not part of the PDTF schema itself.

The asks, by chapter

Preamble

Ask	Layer	What SPDTF may need to model	Existing evidence
"Computed outputs (e.g. risk indices) must carry provenance and purpose metadata"	Data standard	A derived value with its inputs, the activity that produced it, and a purpose on the output itself	⚠️ Partial — PROV covers derivation; there is no purpose-on-output and no derived-vs-asserted distinction
"Trust registries that publish machine-readable permissions, status/revocations and accreditation"	Both	Participant · role · permission scope · accreditation status · revocation, with validity dates	❌ No accreditation/status vocabulary
ATPs authorised only for data categories appropriate to their assurance level	Both	A per-attribute sensitivity/risk classification over PDTF schema paths or SPDTF terms, bound to an assurance level	⚠️ Partial — special-category PII exists; a general risk tiering over the corpus does not
Origin, history and transformation "persistently linked to the data throughout its lifecycle"	Data standard	Provenance that survives export and re-sharing (per-claim, not per-document)	✅ Strong in the schema-derived ontology — mandatory claim provenance, separate from the PDTF schema
Data quality per ISO 8000 / ISO 25012	Both	Quality dimensions attachable to a value	⚠️ Framework exists as policy; not yet a vocabulary (no DQV)
Verifiable delegation for assisted/vulnerable users	Both	Delegator · delegate · scope · evidence · validity · revocation	❌ None
FAPI · mTLS · ISO 27001 · encryption · monitoring	Scheme operator only	—	🚫 Not an SPDTF modelling obligation. Say so plainly.

Chapter 1 — Identity, roles and trust

Ask	Layer	What SPDTF may need to model	Existing evidence
Role assertion "including the scope of permitted actions"	Both	Infrastructure roles (ATP, data holder, relying party, interface body) and a permission scope	❌ The PDTF schema and its derived ontology have transaction roles only — see the role collision
Power of Attorney, deputyship, executors as verifiable delegation credentials	Data standard	A statutory-delegation credential: authority type, evidence, scope, validity, revocation	❌ None — and property is the delegation-heavy sector (probate, LPA, divorce)
Delegation chains, validatable "at each step"	Data standard	A recursive, traversable chain — not a flat credential	❌ None
Accreditation status distinct from operational status	Both	Two orthogonal status axes on a registry entry	❌ None
Selective disclosure / minimisation (P2, Example D)	Data standard	A credential proof suite supporting selective disclosure	❌ Cannot — `Ed25519Signature2020` Linked Data Proofs only. A capability gap against the Guidebook, and a real defect in its own right: our own governance doc wrongly claims we support it.
Credential revocation / suspension at point of reliance	Both	Status list + a status endpoint per credential	✅ Bitstring Status List — but suspension as distinct from revocation needs confirming
Consent as a machine-readable, scoped, revocable signal that data holders must not re-interpret	Both	A consent object with scope, purpose, duration and revocation	❌ None. The largest single hole — see the consent model Ch.3 implies
Credential Bill of Materials — per journey step: format, issuer, holder, verifier, assurance type, status endpoints	Data standard	A manifest over the credential concepts proposed for SPDTF, mapped where relevant to the PDTF schema	❌ Most ingredients exist (VC types, issuers, Bitstring Status List). Assurance type does not — it was removed. A CBOM is still the cheapest high-visibility conformance demonstration available, but it needs SD13 first.

Chapter 2 — Governance and legal

Chapter 2 hits OPDA at both analytical layers, because OPDA has an internal, prospective role in property scheme accreditation criteria. No property Smart Data scheme has been designated; this does not confer government approval or statutory scheme-body status. Most asks are on OPDA the organisation, not on the PDTF schema or schema-derived ontology — those are set out on the chapter page. The data-standard residue:

Ask	Layer	What SPDTF may need to model	Existing evidence
Registry publishes roles, permissions, keys, status (active/suspended/revoked)	Both	Participant lifecycle state as a controlled vocabulary	❌ None
Provenance schema with "issuer, inputs, timestamps, assurance level, and revocation checks"	Data standard	Those five fields on a provenance record	⚠️ Issuer, inputs and timestamps: ✅. Assurance level and revocation-check record: ❌
Signed, provenance-rich computed results retaining "issuer, inputs, methods, timestamps and purpose"	Data standard	A derived-claim class — a property pack is exactly this	❌ The highest-value gap. It is simultaneously OPDA's largest modelling gap and its largest liability gap, and they are the same gap.
Liability allocation (Clause D)	Scheme rules	—	🚫 SPDTF does not necessarily need a `liableParty` property. It needs the evidence the rule operates on: who issued a signal, when, at what assurance, and whether a status check happened. Encode the evidence, not the verdict.
UKAS-anchored equivalence · appeals · tribunals · annual reports	OPDA the organisation	—	🚫 No data-modelling obligation. Do not manufacture ontology work from these.

Chapter 3 — User lifecycle

The chapter most likely to be waved away as "just UX". It is not. Consent, withdrawal and delegation leave data trails a standard must be able to represent. Full analysis and the implied record structure: the consent-record model Chapter 3 implies.

Ask	Layer	What SPDTF may need to model	Existing evidence
Consent records in both machine- and human-readable form	Both	A consent class with labels	❌ None
View active, expired and withdrawn permissions and how they changed over time	Both	A status vocabulary and an append-only history — a withdrawn consent cannot be deleted	❌ None
Confidentiality obligations continue after sharing ends	Both	A duty on the recipient that outlives the consent — permissions alone cannot express this	❌ None (this is what ODRL `Duty` is for; ODRL is absent)
Delegated authority "visible, attributable and revocable" (Clause A)	Both	All three are stored facts, not screens	❌ None
Provenance signal: verified / self-reported / derived	Data standard	A three-way origin facet, user-facing	⚠️ Provenance exists; the derived-vs-asserted axis does not
Dashboard layout, plain language, no dark patterns	Product / UI	—	🚫 No SPDTF modelling obligation — but the dashboard's four required views can only be populated from a model that has all four. The dashboard is theirs; its data dependencies are ours.

Chapter 4 — Stewardship, privacy and ethics

The richest chapter for a standards body — this is ontology territory throughout.

Ask	Layer	What SPDTF may need to model	Existing evidence
Source / derived / insight / profiling — a four-way categorisation of every data item	Data standard	An origin facet (per house doctrine: a facet with `sh:in`, not a subclass tree)	❌ None — and it is cheap. Do this first: it unlocks three other gaps.
Individual-linkable vs aggregated/anonymised derived output	Data standard	An identifiability flag — it drives the whole proportionality carve-out	❌ None
"Whether automation or AI has been used" to generate a decision	Data standard	A decision/outcome artefact + AI-involvement flag + the model that produced it + human-oversight level	❌ None, and unplanned. Genuinely new: neither the PDTF schema nor its derived ontology has a notion of an actor's output — only property facts.
Audit record of every access / share / use, supporting dispute resolution	Both	An event class: actor, time, dataset, purpose, legal basis	❌ No audit-event class. (OPDA operates audit logging as a scheme control — but that control produces logs no vocabulary can currently express. The control is not the artefact.) PROV + DPV supply every part; nobody has assembled the shape.
Onward sharing: rules "continue to apply downstream" (Clause H, I)	Both	Policy propagation — the obligation travels with the data	❌ None (ODRL `nextPolicy` is the primitive; ODRL is absent)
Retention: deleted or anonymised once purpose is fulfilled	Both	Retention duration + disposition (retain / delete / anonymise)	❌ None — but very easy (DPV has the terms)
Machine-readable and human-readable outputs	Data standard	Every term carries a label/definition	✅ Structurally — but "we can label everything" ≠ "everything is labelled". Ship a SHACL shape requiring it and the soft claim becomes auditable.
Risk assessed at use-case and ecosystem level, not dataset level	Data standard	A `UseCase` class	❌ None — structural mismatch. The existing evidence is property/dataset-centric. Closing this in SPDTF needs a council.
Real-time monitoring · dashboards · enforcement · AI inventories	Scheme operator	—	🚫 Not SPDTF's modelling job. Disclaim these explicitly, or the scheme will be held to them.

Chapter 5 — Security, risk and fraud

Almost entirely scheme-operator territory — which is precisely why it is the chapter where the layer separation earns its keep. See the chapter page.

Ask	Layer	What SPDTF may need to model	Existing evidence
FAPI · OAuth 2.0 · ISO 27001 · NIST CSF · NCSC CAF baseline	Scheme operator	—	🚫 Not an SPDTF modelling obligation.
Continuous assurance; suspend/restrict participants	Scheme operator	—	🚫 Not an SPDTF modelling obligation.
Trust should be dynamic — machine-readable suspension status, risk scoring, incident notifications, credential validity	Both	The signals are data: participant status, risk score, incident notice, credential validity	❌ This is Chapter 5's one real data-standard ask, and neither the PDTF schema nor its derived ontology can emit these signals — gap SD12. Note this is the chapter with the live 24 July deadline.

What is not a data-standard obligation

Stating this is as important as stating the gaps. If OPDA does not draw the line, the standard will be held to obligations it structurally cannot meet — and, worse, may be let off the ones it should meet because nobody assigned them to the standards layer.

None of these create work for the ontology:

Security profiles — FAPI, mTLS, DPoP, ISO 27001, encryption, key management, penetration testing
Incident response, real-time monitoring, live compliance dashboards, continuous assurance
Accreditation decisions, enforcement, suspension machinery, appeals, tribunals
Consent UI, dashboards, plain language, dark-pattern avoidance, journey testing
WCAG / assisted channels / non-digital options (with one exception — see below)
Charters, KPIs, annual reports, fee models, SME impact assessments, carbon footprint
AI inventories and lifecycle tracking

The exception worth catching

"Non-digital options for consumer engagement" (Which?, on property) looks like pure UI — but a consent captured on paper still needs a machine-readable record, with an attestation of how it was captured. SPDTF should be able to say "consent given in writing, witnessed by X, recorded by Y". A purely-digital model would never think to include a consentCaptureMethod.

The role-model collision

Chapter 1's infrastructure roles and the existing transaction roles are orthogonal axes, not competing lists — and this is the single most likely place for a damaging misalignment.

DBT's roles are infrastructure roles, per interaction: data holder, Authorised Third Party (ATP), interface body, relying party, issuer, plus the five DVS provider roles (IDSP, ASP, HSP, OSP, CSP).
The PDTF schema contains transaction-role values; the schema-derived ontology renders them semantically, per person per transaction. Precisely, the ontology has three OWL classes (opda:Seller, opda:Buyer, opda:Proprietor — the last founded by a Proprietorship relator, a different axis from Transaction) plus a 12-member SKOS RoleScheme: Seller · Buyer · Prospective-Buyer · Sellers-Conveyancer · Buyers-Conveyancer · Buyers-Agent · Estate-Agent · Lender · Mortgage-Broker · Surveyor · Landlord · Tenant.

The existing role evidence has no bare "Conveyancer" — it already splits the role by side. That is a real modelling asset and exactly the kind of nuance a cross-sector mapping table would destroy.

A seller's conveyancer is not "a data holder" or "an ATP". Depending on the flow, the same firm is a data holder (they hold the forms), an ATP (they fetch the seller's data), a relying party (they check a title claim), and an issuer (they issue a completion certificate). Any honest mapping is many-to-many and context-dependent.

Chapter 1's guardrail — "roles must be aligned with cross-sector patterns to avoid ambiguity" — will be read as pressure to adopt DBT's names. Done by simple substitution, that is a category error that would flatten Seller/Buyer/Conveyancer into "end user" and "ATP" and lose the sector's actual accountability structure. DBT has promised a cross-reference table mapping Guidebook terminology to sector terms. OPDA should supply the property column rather than let it be drafted for us.

The schema-derived ontology has no assurance-level vocabulary — it was removed

Correcting a claim it would be easy to make

It is tempting to say "the existing ontology has assurance levels, DVS has assurance levels, therefore we are aligned". That would be false. opda:assuranceLevel was removed from the schema-derived ontology corpus on 2026-07-05 (ODR-0009 removal amendment — "zero PDTF schema basis" (exact ODR-0009 wording); the tombstone is still visible in the exemplars. Its values were eIDAS-style (Low/Substantial/High), and opda:AssuranceLevel now survives only as an orphan UFO annotation with no class declaration, no label and no SKOS scheme.

So this is a gap, not a strength. Chapter 2 asks for a provenance schema carrying "issuer, inputs, timestamps, assurance level, and revocation checks"; Chapter 1 asks for assurance metadata per credential (and the CBOM requires an assurance type per journey step). Neither the PDTF schema nor its derived ontology can currently express all of it.

That said, the conceptual point still stands and is worth making to DBT, because the three ladders genuinely measure different things and any SPDTF assurance vocabulary must not be conflated with the identity ones:

Ladder	Answers the question	Property of…
GPG 45 identity confidence	Is this person who they say they are?	a person
GPG 44 authentication strength	Is this the same person as last time?	a session
An evidential-provenance scale (which neither existing layer has)	How authoritative is this fact about this house?	a claim

The opportunity is real but unbuilt: no other sector in the Guidebook has an evidential-provenance ladder, and the schema-derived ontology's mandatory claim provenance is a natural substrate for one. But it must be proposed as future work (gap SD13), never presented as something OPDA already ships.

Gap register — the same gaps, ranked by effort to close, with the closing move for each.
Standards stack — the ontology's planned layers (the plan this page checks reality against).
Ontology — provenance — claim-provenance machinery in the separate schema-derived ontology.
Data security framework — controls published separately alongside the PDTF schema.