Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group

    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.

    See also: Ontology manual — Concept tier

    The Concept tier of the Ontology manual shows how the seven ontology modules (foundation, property, agent, transaction, claim, governance, descriptive) map onto the entity landscape these bounded contexts share. The DDD framing here and the module structure there are two views of the same ontological commitment.

    Design stance

    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.

    Bounded contexts vs schema overlays

    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.
    Association (RICS-regulated surveying): Survey Shack; Countrywide Surveyors (within Connells Group); Pinnacle Surveyors (within MAB).
    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 (former member), Coadjute, PEXA.
    Association: HSP, VMC, Clozy, C2C, e4, Novus Strategy.     		System-to-system messages; orchestration; UX surfaces for each above context
    Gap

    Surveying / Valuation has no founding OPDA member, though RICS-regulated surveying is present in association membership — Survey Shack, plus Countrywide Surveyors (within Connells Group) and Pinnacle Surveyors (within MAB). RICS itself is on the DPMSG steering board. Worth flagging: the surveying overlay (piq.json) still lacks an OPDA member with practical implementation skin in the game. Stakeholder engagement for the linked-data project should activate one of these surveying firms as an implementer (or recruit a dedicated surveying member).

    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.

    ContextStewardWhat it owns
    Land RegistryHMLRTitle register, charges, official copies (OC1), local land charges (LLC1)
    Local Authority308 LAs in England + WalesCON29R search data, planning permissions, building control, council tax band — being progressively migrated into HMLR's national LLC service
    Material InformationMHCLG (replacing withdrawn NTS rules)The minimum disclosures a listing must contain — under the DMCC Act 2024
    Identity & VerificationDSIT (DVSTF); regulated by ICO; MLR 2017Identity proofing, AML / KYC, attribute exchange
    Trust & Verifiable ClaimsW3C (VC + DID specs); ToIP Foundation; SPDTF specCryptographic 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:

    Spanning

    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.

    Spanning

    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.

    flowchart TB PDTF["`**PDTF — Published Language** JSON Schema + OpenAPI + VC + DID *Open Host Service*`"]:::infra EA[Estate Agency]:::user CV[Conveyancing]:::user ML[Mortgage Lending]:::user SV[Surveying]:::user PD[Property Data]:::user PT[Property Tech]:::user HMLR["Land Registry (HMLR)"]:::external LA["Local Authority"]:::external MI["Material Information (MHCLG)"]:::external ID["Identity & Verification (DVSTF)"]:::external TV["Trust & Verifiable Claims (W3C)"]:::security 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
    PDTF is the Published Language at the centre. Each primary industry context has a bidirectional relationship via Anti-Corruption Layers (each firm's adapter to PDTF). Upstream government/standards contexts are consumed in conformist mode — PDTF doesn't try to redefine their language.

    Inter-context relationship patterns

    Each pair of contexts has a specific DDD relationship. The pattern dictates how translations are designed.

    PairPatternWhat 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) The SPDTF (Smart Property Data Trust Framework) 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.

    ContextMain 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:

    Potential extensions to the PDTF model
    Potential contextWhy the model needs to extend
    Lettings / private rented sectorSame actors but different legal and regulatory frame; tenant fees, deposit protection, EICR, gas safety and RoPA. Hinted at by the existing NTS Lettings v1.0 overlay.
    New-build / off-planDifferent conveyancing patterns, warranties such as NHBC, stage payments and build defects.
    Leasehold & commonhold managementService charges, major works and right-to-manage. LPE1 covers part; the full leasehold lifecycle is broader.
    Probate / executor salesTitle transfers without willing sellers and grant-of-probate workflows.
    Commercial propertyDifferent forms, such as CPSE.1, and different statutory rules. Probably out of scope for PDTF schema.
    AuctionShort timelines and different contract structures.
    InsuranceBuildings and contents cover at completion; a potential future context.
    Utilities & energyMeter readings, supplier switching and EPC currency.
    TaxSDLT calculation and submission, and 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

    Linked-data implementation implications
    Linked-data areaImplementation implication
    Ontology designBind the contexts via a shared upper ontology (Transaction, Property, Participant, Claim and Document) and use SKOS schemes per context for context-specific vocabulary. For example, “instruction” means different things to a lender and a conveyancer.
    JSON-LD contextsUse one per overlay. Each maps context-specific JSON property names to RDF terms in the shared ontology, with explicit @context rules per overlay.
    SHACL shapesDefine per-overlay validation that reflects each context's stewardship rules. The conformist overlays (HMLR, NTS and W3C) have shape definitions effectively dictated by their upstream contexts.
    Glossary structureUse three tiers: shared-kernel terms that apply across all contexts; context-specific terms qualified by context; and deprecated or superseded terms with their replacement context.
    Governance per contextUnder ToIP Layer 4, each industry context probably warrants its own working-group equivalent. This echoes DPMSG's existing Comms, Policy, Technical, Regulator and Engagement structure, although that is organised functionally rather than by industry.

    Comments

    Loading comments…