Bounded contexts & industries
The UK property transaction is a multi-industry process. Each actor has its own ubiquitous language, rules, and concerns — a bounded context in Domain-Driven Design terms. OPDA's PDTF doesn't try to replace any of those internal models; it acts as the Published Language between them.
The PDTF semantic model should treat each industry as its own bounded context with its own concepts, its own canonical forms, and its own owners. The ontology binds them through shared root concepts (Transaction, Property, Participant, Claim) and explicit inter-context translations — not by trying to impose a single, unified vocabulary on the whole sector.
A bounded context is a domain-layer idea — a business function
with its own language and rules (Estate Agency, Conveyancing, …). A
PDTF overlay is a schema-layer artefact — a single JSON-Schema
file that adds one form, search or document to the base transaction
(baspi5.json, ta6.json, …). They map cleanly onto each
other (many overlays per context) but they're not the same thing. See the
dedicated PDTF overlays page for the full
catalogue and merge mechanics.
Six primary industry contexts
Each is a community of practice with its own regulators, professional bodies, forms, software ecosystems, and language. The OPDA member firms are deliberately drawn from across these contexts — named below in each row.
| Context | Industry stewards (regulators / pro bodies) | OPDA members in this context | Canonical forms / data |
|---|---|---|---|
| Estate Agency | Propertymark; portals (Rightmove, Zoopla); regulated by NTSELAT (transitioning to MHCLG) |
Founders: OnTheMarket, Homely. Association: Connells Group. |
Listing data, viewings, offers, BASPI v4/v5, NTS Material Information |
| Conveyancing (Legal) | Law Society, SRA, CLC, Society of Licensed Conveyancers, CILEX, CILEx Regulation |
Founders: LMS. Association: Smoove, Movera, Movemnt. |
TA6, TA7, TA10, LPE1, contracts, searches, exchange & completion documents |
| Mortgage Lending | UK Finance, BSA; regulated by FCA |
Founders: United Trust Bank (UTB), OMS. Association banks: HSBC UK, Nationwide, NatWest, Lloyds Banking Group (Halifax, BM Solutions, Scottish Widows), Santander. Lending tech: Finova, Phoebus, MAB (intermediary network), L&C Mortgages, Lenderhive. |
FME1, DIP, mortgage offer, valuation requests, drawdown instructions |
| Surveying / Valuation | RICS |
No founding members. Gap. Association (AVM-adjacent): Hometrack, Experian. |
PIQ, condition surveys (Levels 1–3), AVMs, RICS Red Book valuations |
| Property Data Services | COPSO |
Founders: Sprift, Groundsure, TM Group, Kotini, Inventory Base. Association: Hometrack, Experian, Credas (identity data), Property Deals Insight, Armalytix. |
CON29R, CON29DW, LLC1, OC1, RDS, BASPI; EPC datasets; HMLR title data |
| Property Technology (orchestration) | — |
Founders: Moverly, Coadjute, PEXA. Association: HSP, VMC, Clozy, C2C, e4, Novus Strategy. |
System-to-system messages; orchestration; UX surfaces for each above context |
Surveying / Valuation has no founding OPDA member. RICS is on
the DPMSG steering board but doesn't have a member-firm on OPDA's roster.
Worth flagging: the surveying overlay (piq.json) currently lacks an
OPDA member with practical implementation skin in the game. Stakeholder
engagement for the linked-data project should prioritise bringing a surveying
firm into membership.
Five supporting / cross-cutting contexts
Each industry context is bordered by — and dependent on — several government-owned or regulatory contexts. These have their own languages too; PDTF treats them as upstream contexts and consumes their data rather than trying to redefine it.
| Context | Steward | What it owns |
|---|---|---|
| Land Registry | HMLR | Title register, charges, official copies (OC1), local land charges (LLC1) |
| Local Authority | 308 LAs in England + Wales | CON29R search data, planning permissions, building control, council tax band — being progressively migrated into HMLR's national LLC service |
| Material Information | MHCLG (replacing withdrawn NTS rules) | The minimum disclosures a listing must contain — under the DMCC Act 2024 |
| Identity & Verification | DSIT (DIATF); regulated by ICO; MLR 2017 | Identity proofing, AML / KYC, attribute exchange |
| Trust & Verifiable Claims | W3C (VC + DID specs); ToIP Foundation; PDTF v2.0 spec | Cryptographic provenance: who issued what claim, when, with what evidence |
Two spanning concerns
Cutting across every industry and supporting context, two concerns are irreducibly system-wide:
Transaction lifecycle
The end-to-end journey from listing → offer → instruction → searches →
valuation → mortgage offer → exchange → completion → registration.
PDTF's pdtf-transaction.json is the spine. State transitions
are the events different contexts care about.
Participants & their roles
The same legal entities appear in multiple contexts wearing different hats (a single firm might be agent + property data provider; a single person is buyer + borrower + tenant). PDTF models participants once via DID and lets them play role-typed parts in transactions.
DDD context map
Following Eric Evans's notation. Relationship labels: Upstream / Downstream; PL = Published Language; OHS = Open Host Service; ACL = Anti-Corruption Layer; CF = Conformist; C/S = Customer / Supplier.
JSON Schema + OpenAPI + VC + DID
Open Host Service"]:::pl EA[Estate Agency]:::primary CV[Conveyancing]:::primary ML[Mortgage Lending]:::primary SV[Surveying]:::primary PD[Property Data]:::primary PT[Property Tech]:::primary HMLR["Land Registry (HMLR)"]:::gov LA["Local Authority"]:::gov MI["Material Information (MHCLG)"]:::gov ID["Identity & Verification (DIATF)"]:::gov TV["Trust & Verifiable Claims (W3C)"]:::tech EA <-->|PL via OPDA accreditation| PDTF CV <-->|PL| PDTF ML <-->|PL| PDTF SV <-->|PL| PDTF PD <-->|PL| PDTF PT <-->|PL| PDTF PDTF -->|CF / consumes| HMLR PDTF -->|CF / consumes| LA PDTF -->|CF / implements| MI PDTF -->|CF / wraps| ID PDTF -->|CF / built on| TV
Inter-context relationship patterns
Each pair of contexts has a specific DDD relationship. The pattern dictates how translations are designed.
| Pair | Pattern | What it means in practice |
|---|---|---|
| PDTF ↔ each industry context | Published Language + Open Host Service | PDTF publishes the wire format and API. Each industry's software implements an Anti-Corruption Layer between its internal model and PDTF. |
| PDTF → HMLR | Conformist | HMLR's title register format is the canonical truth. PDTF consumes it as-is via the OC1 / LLC1 overlays; doesn't redefine title concepts. |
| PDTF → Local Authority searches | Conformist via search providers | 308 LAs have varying data; PDTF adopts the CON29R standard form as the canonical interface. |
| PDTF → MHCLG Material Information | Conformist (regulatory) | Whatever MHCLG defines, PDTF's nts.json-successor overlay must implement. No design discretion on what counts as material. |
| PDTF → W3C VC / DID | Conformist (technical) | PDTF v2.0 uses W3C VC Data Model verbatim for the claim structure. DID for participant identity. |
| Estate Agency ↔ Property Data | Customer / Supplier | Agents (customers) consume data products from search firms and aggregators (suppliers). PDTF formalises the supply contract. |
| Conveyancing ↔ Mortgage Lending | Partnership | Both parties need each other to complete; neither subordinate. PDTF formalises the handshakes (certificate of title, source of funds, completion monies). |
| Mortgage Lending ↔ Surveying | Customer / Supplier | Lender (customer) instructs surveyor (supplier). PDTF formalises valuation requests & reports. |
| Property Tech ↔ all primary contexts | Open Host Service | Software platforms expose PDTF-compatible APIs to the industry-specific contexts they serve. |
How each context maps to a PDTF schema overlay
Reassuringly, this isn't a new architecture — PDTF's overlay model already reflects this bounded-context thinking. Each overlay is a context's view of the shared transaction. Full catalogue of all 18 main + 16 extension overlays — and how they're defined and merged — on the dedicated PDTF overlays page; the mapping itself sits here.
| Context | Main overlays |
|---|---|
| Estate Agency | baspi4 (legacy) · baspi5 · nts (legacy) · nts2 · ntsl (legacy) · ntsl2 |
| Conveyancing | ta6 · ta7 · ta10 · lpe1 |
| Mortgage Lending | fme1 |
| Surveying | piq |
| Property Data Services | rds · oc1 · llc1 · con29R · con29DW · sr24 |
| Property Tech | The base pdtf-transaction.json + verified-claims wrapper — no overlays of its own |
The 16 extension overlays (jk, tf,
as …) are modular sub-pieces of NTS2, so they all belong to
Estate Agency. They let adopters stage their NTS → NTS2 migration one
sub-feature at a time.
Where the model needs to extend
Today's overlay set covers the residential sale transaction well. Future bounded contexts that PDTF will likely need to accommodate:
- Lettings / private rented sector — same actors but different legal/regulatory frame; tenant-fees, deposit protection, EICR/gas safety, RoPA. Hinted at by the existing NTS Lettings v1.0 overlay.
- New-build / off-plan — different conveyancing patterns, warranties (NHBC), stage payments, build defects.
- Leasehold & commonhold management — service-charge, major works, RTM. LPE1 covers part; full leasehold lifecycle is broader.
- Probate / executor sales — title transfers without willing sellers; grant-of-probate workflows.
- Commercial property — different forms (CPSE.1 etc.), different statutory rules. Probably out of scope for PDTF v1.
- Auction — short timelines, different contract structures.
- Insurance — buildings + contents at completion; potential future context.
- Utilities & energy — meter readings, supplier switching, EPC currency.
- Tax — SDLT calculation and submission; council tax band confirmation.
Each future extension would be a new overlay (preserving the base
pdtf-transaction.json), with its own bounded-context owner who
stewards the wording.
Implications for the linked-data work
- Ontology design — bind the contexts via a shared upper ontology (Transaction, Property, Participant, Claim, Document) and use SKOS schemes per context for vocabulary that's context-specific (e.g. "instruction" means different things to a lender vs a conveyancer).
-
JSON-LD contexts — one per overlay. Each maps the
context-specific JSON property names to RDF terms in the shared ontology,
with explicit
@contextrules per overlay. - SHACL shapes — define per-overlay validation that reflects each context's stewardship rules. The conformist overlays (HMLR, NTS, W3C) have shape definitions effectively dictated by their upstream contexts.
- Glossary structure — three-tier: shared kernel terms (apply across all contexts), context-specific terms (qualified by context), deprecated / superseded terms (with their replacement context).
- Governance per context — under ToIP Layer 4, each industry context probably warrants its own working-group equivalent (this echoes DPMSG's existing Comms / Policy / Technical / Regulator / Engagement structure, though that's organised functionally not by industry).