Chapter 3 — User Lifecycle and Experience

The chapter most likely to be waved away as "just UX, not our problem". It is not. Consent, withdrawal and delegation leave data trails that a standard must be able to represent — and this chapter, read carefully, raises a consent-record question for SPDTF that neither the PDTF schema nor the separate ontology extracted from it currently addresses.

Its own framing: user experience is "an emergent property of smart data trust frameworks" — the combined effect of identity, consent, governance and data-use decisions as experienced over time. Not interface design.

The six-stage lifecycle

Entry and awareness — the user must understand who they are dealing with: "the role, status and trust framework of participating organisations".
Identity and onboarding — verification proportionate to risk (GPG 45/44/46). Property transactions are named twice as a high-assurance trigger ("decisions [that] have significant or long-term consequences").
Consent and authorisation — what data, with whom, for what purpose, for how long. Onward sharing disclosed at consent time. Multi-party consent (joint owners, delegates) treated as normal, not exceptional.
Data sharing and use — provenance surfaced to the user as a simple signal: verified / self-reported / derived. A clear accountable contact per datum. Correction rights.
Ongoing management — see and manage active, expired and withdrawn permissions, and track how they changed over time. Withdrawal must be as easy as consent.
Exit and withdrawal — what is retained, deleted or anonymised; portability of validated data; and reducing wasted effort where transactions do not complete (the property case).

Plus a cross-cutting redress pathway — explicitly not a stage — available at any point of failure.

Delegation is a first-class pathway

The chapter's single densest data-modelling requirement is in its model clause:

"The Scheme SHOULD ensure that users can understand, review and withdraw permissions throughout this lifecycle, and that delegated authority is visible, attributable and revocable."

Visible, attributable and revocable is a triple of properties only a data structure can carry. And property is the delegation-heavy sector: elderly sellers, probate and executor sales, divorce, lasting power of attorney, co-ownership with unequal digital capability. Every one of those is a delegation or multi-party consent case — which is to say, a data-modelling problem: the authority under which a person acts, its scope, its evidence, its validity window and its revocation are all facts to be recorded, not screens to be drawn.

The chapter never says "data model". But Clause A plus §3.1 plus §2.3, read together, over-determine one. This is the most valuable thing in the chapter, and the existing schema-derived ontology today can satisfy roughly one line of it.

Append-only, not mutable

Because the user must see expired and withdrawn permissions and how they changed over time, and because confidentiality duties survive withdrawal, a consent record can never be mutated in place or deleted. Modification produces a new record revising the old; the old becomes superseded, not nothing. A binary active/inactive flag fails this chapter.

Three distinct parties — conflating them is the classic error

Data subject — who the data is about (possibly both co-owners).
Grantor — who actually performed the grant. Usually the subject; in property, frequently not — an attorney under an LPA, an executor, a solicitor with a letter of authority.
Grantee / recipient — who may receive the data, plus any onward recipients.

Where grantor ≠ subject, the record must carry the delegated authority it was made under. That link is the whole of "attributable".

Scope, purpose, and time

Scope — a machine-checkable selector over PDTF schema paths and schema-derived ontology terms, not free text. This is the join between the consent layer and the property-data layer. If SPDTF does not give consent a stable vocabulary of things-to-consent-to, every scheme invents its own and the chapter's "alignment of meaning" fails at exactly the point it matters.
Purpose — a controlled vocabulary (conveyancing, mortgage underwriting, valuation, AML/KYC, insurance, marketing…). Purpose limitation is unenforceable without it.
Time — validFrom/validUntil, with validUntil required: the chapter explicitly warns that default states "must not lead to unintended ongoing data sharing". A standard that permits an absent expiry enables the harm.

Duties that outlive the consent — the sleeper requirement

§2.3 (common-law confidentiality) is easy to miss and structurally important. Confidentiality, purpose limitation on data already received, and onward-sharing prohibitions must be modelled as obligations attached to the recipient, with their own validity — possibly indefinite — and explicitly not terminated by the consent's expiry or withdrawal.

A permission-only model cannot say: "you may no longer receive this, and you must still keep secret what you already received." That is what ODRL Duty is for — and ODRL has zero occurrences in the schema-derived ontology corpus.

Withdrawal is an event, not a flipped boolean

It needs: who withdrew (possibly a different party from the grantor — a subject revoking what their attorney granted, or one co-owner revoking a joint consent), under what authority, when, effective from when, and what obligations survive. It must also carry a disposition instruction per data category — retain (with legal basis and retain-until), delete, or anonymise — because withdrawal does not undo sharing that already happened.

Withdrawal in a property transaction is semantically ugly — and the chapter doesn't touch it

Once a lender has underwritten on a datum and a searches provider has relied on it, "withdraw consent" cannot mean "unshare". The chapter's own §2.3 and §3.1 imply the answer — withdrawal terminates future sharing and converts the recipient's position into a duty-bearing one — but it never says so. A scheme reading only Clause A could reasonably build something incoherent. SPDTF should model the distinction rather than wait for it.

Multi-party consent

One record, n grantors, plus a revocation rule (any-one / unanimous / per-grantor-partial). This is a scheme policy choice — but it must be a recorded one, otherwise the behaviour of a joint consent is unknowable from the data. In property this is not exotic: two co-owners, one abroad, one having instructed a solicitor, mid-divorce.

The one-sentence version

Chapter 3 requires that, for any datum in a property transaction, a machine can answer: who consented to this being here, under what authority, for what purpose, until when, has that been withdrawn, what obligations survive the withdrawal, who is accountable for the datum's accuracy, and who has relied on the identity check behind it — and the schema-derived ontology can answer roughly one of those nine.

The Which? response

Not a critique of the draft — a submission to DBT's Call for Evidence. Which? is a consumer champion, an OPDA-listed stakeholder, and is cited in the chapter's own authority list. Its position is politically load-bearing:

It wants requirements, not SHOULDs. "Clear requirements in the guidebook"; standards "universally adopted by service providers"; regulatory intervention for vulnerable people. That is the live fault line with the chapter's non-prescriptive posture.
On property specifically it asks for: clear and accessible information including non-digital options; and — directly relevant to the progression from the PDTF schema to SPDTF — "Data sources must be trusted, and consistent data standards must be used for comparisons between datasets and interoperability across systems." On the data-standards question, Which? is an ally.
The harm the chapter has no answer to. Its Financial Inclusion Centre piece argues that richer shared data enables finer, discriminatory segmentation — a harm that transparency and user control do not fix. In property it manifests as differential mortgage and insurance pricing. Neither DBT nor OPDA currently has a position. Worth having one before being asked.

What this could mean for SPDTF

Full table on the overlap page. In short:

The entire consent/delegation/withdrawal cluster is gap SD5 — the largest hole, and it needs ODRL, which the corpus does not have.
The "verified / self-reported / derived" provenance signal needs the origin facet — gap SD3, and the cheapest thing on the register.
The dashboard is theirs; its data dependencies are ours. Chapter 3's required dashboard views (active/expired/withdrawn permissions, who holds data, change history, act to revoke) can only be populated from a model that has all four. The screen is a product problem. The model behind it is an SPDTF question.
DBT cites bare “PDTF” for a capability the existing work does not ship. §4.1 credits "emerging PDTF work" (the source document's wording) with showing the importance of delegated authority controls, provenance and attribute-level assurance. Provenance is present in the separate schema-derived ontology. Delegated-authority controls are present in neither the PDTF schema nor that ontology. The citation is a reputational exposure and a question for the collaboratively authored SPDTF draft.

Gap register — SD3 and SD5
Ch.1 — Identity, roles and trust — where the consent signal is first assumed
Ch.4 — Stewardship & ethics — the derived-data half of the same problem