Domain-led bounded-context working groups for SPDTF development

Clarification — 2026-09-07, corrected Trust scope. Trust means the SPDTF Trust Framework being developed in relation to the wider government Smart Data programme, not a synonym for model-review governance. The Modelling section focuses on domain and ontology modelling; JSON-LD is a generated output, not a separate teaching subject. Retained categories describe and map privacy, access, provenance and other semantics that can support the framework; they do not implement it. Broader Trust recommendations belong to the programme’s scheme work. Linked-data-store guidance is informative; operating an application is outside this development effort. Documented context boundaries are established inputs.

Clarification — 2026-09-05. The operator confirmed that the relevant semantic-modelling ODRs are normative for the OPDA modelling method, not merely informative candidates. The scope is ODR-0071’s eight categories below, with the supporting decisions that apply to them; it is not adoption of the whole source project’s models, architecture or pipeline. The decision-basis guide records the reviewed source revision and the distinction from OPDA’s own ODR numbers.

Context and Problem Statement

OPDA’s earlier linked-data work started with the existing PDTF schema and supporting dictionary, glossary and overlays, then generated a schema-derived ontology, mappings, shapes and website views from that technical source. The current outputs are available through:

• https://opda.org.uk/ontology
• https://opda.org.uk/mapping
• https://opda.org.uk/schema/

That work proved that the existing schema can be traced into a linked-data representation. It also exposed a more important finding: a document schema is not a sufficient source of domain meaning, and neither the schema nor its derived ontology is an OPDA-endorsed predecessor scheme.

The generated model has several diagnostic weaknesses:

• semantic definitions are often weak or inherited from field-level annotations;
• depth is uneven, reflecting different levels of historical engagement;
• some areas are overdeveloped while others are underdeveloped;
• form-support concerns entered through overlays without first establishing whether they belong in the domain standard or how they relate to the whole;
• the result risks becoming a single, centrally designed “cathedral” model whose scope is too broad for domain experts to review effectively.

The schema-derived ontology remains valuable as a diagnostic baseline, traceability artefact and source of requirements. SPDTF development does not discard it or “start again”; it changes how domain meaning becomes authoritative through collaboration.

This ADR decides how SPDTF models are to be developed and governed.

Supporting evidence and the stakeholder case are recorded in docs/research/bounded-context-working-group-approach.md.

Decision Drivers

• Domain correctness — meanings and relationships must be agreed by practitioners who make decisions in the domain.
• Balanced coverage — each part of the property journey needs deliberate attention, rather than inheriting the participation pattern of the PDTF schema and forms.
• Bounded scope — a group must be able to understand and review its model without taking responsibility for the whole property ecosystem.
• Bottom-up modelling — domain meaning should be developed from practitioner evidence inside each bounded context, rather than imposed by one top-down model.
• Non-technical participation — contributors must be able to work through diagrams, definitions, examples and business rules rather than RDF, OWL, SHACL or JSON Schema syntax.
• Explicit interoperability — different domains must be connected deliberately, without flattening legitimate differences in language or practice.
• Governable outputs — every term, rule and mapping needs a clear owning group and review path.
• Complete modelling coverage — every group needs a common checklist covering domain meaning, vocabularies, classification, governance, validation, mappings, provenance, time and access.
• Incremental value — useful domain increments should be publishable without waiting for a complete sector-wide model.

Considered Options

• Option A — Continue refining the schema-derived ontology centrally. Retain the current ontology as the primary model and improve definitions and coverage through a general review process.
• Option B — Build one new sector-wide ontology centrally. Convene a single cross-industry modelling group and attempt to design the complete property model.
• Option C — Domain-led bounded-context groups plus an Interoperability Working Group (chosen). Develop each domain model with its own experts, using existing OPDA artefacts and external standards as evidence rather than presumed authority, then govern boundary concepts and mappings through a group composed of delegates from every domain group.

Decision Outcome

Chosen option: Option C — domain-led bounded-context groups plus an Interoperability Working Group.

SPDTF development will not treat the PDTF schema, its overlays, or the schema-derived ontology as the authority for domain meaning. They remain valuable evidence, traceability, implementation and migration inputs throughout the work. Each working group determines meaning through its agreed scope, use cases, practitioner language and reviewed evidence. This is a shift from one top-down, schema-derived model to bottom-up modelling within explicit bounded contexts: a schema-to-scheme continuation, not a numbered-version succession or a restart of the programme.

1. Working-group roster

OPDA will establish eight working groups: six property bounded-context groups, one cross-sector scheme group and one cross-cutting Interoperability Working Group.

The contextual boundaries and their documentation are established for this development phase. Model development works within them; any later boundary revision requires a separate governance decision. DBT Smart Data is the scheme working group, not being asserted as a seventh property bounded context. Its terminology, policy lifecycle, cross-sector authority and scheme-level questions are distinct from the property-transaction domains. It must not redefine the internal meanings owned by those groups.

Each domain and scheme group contains subject-matter experts and practitioners, supported by ontology and data-modelling facilitators. Domain members own the meaning; facilitators help make that meaning explicit, consistent and machine-readable. The Interoperability Working Group includes selected representatives from across those groups so that every context can explain its own language when boundary agreements are made.

The same real-world property may therefore have distinct, useful representations in lending, conveyancing, surveying, agency and other contexts. The programme will map those representations at their boundaries instead of forcing every group to adopt one universal definition. This preserves local precision while keeping exchange explicit.

2. Required outputs and publication artefacts

Every bounded-context and scheme group produces one coherent semantic package with six aligned content outputs:

1. Business glossary — agreed plain-language definitions, examples, scope notes, synonyms and ownership.
2. Data dictionary — the data elements used in the context, with definitions, value expectations, provenance and stewardship.
3. Taxonomies — agreed hierarchical organisations of domain concepts, including broader and narrower meanings.
4. Controlled vocabularies — governed terms, labels, definitions, codes and value sets used by the context.
5. Resources — the identifiable domain things and concepts that need stable meaning, descriptions and provenance.
6. Relationships — the meaningful links, roles and constraints that connect those resources.

The specification defines the agreed meaning and applicable data constraints. Its formal models and generated delivery artefacts serve different consumers:

• machine-readable RDF/RDFS/OWL models, vocabularies and SHACL shapes;
• generated JSON-LD exchange artefacts, including contexts and associated JSON Schemas, as the main route for most implementers;
• human-readable website pages, with exportable PDF and Markdown views.

These are different representations of one agreement, not independent specifications. Generation must preserve the agreed meaning and identify the constraints represented by each delivery profile. Authors document any constraint that needs additional checking. The working groups review business meaning without needing to author ontology syntax. These output requirements do not make generation or JSON-LD document design a learning objective: the Modelling section explains the ontology and its modelling method, with only a brief mention that JSON-LD artefacts are generated from it.

Model-development governance covers specification ownership, evidence, review, decisions, versioning and approval. It is not the programme’s Trust Framework, whose concerns include who may participate, act for another party and access or use data, with what permissions, assurance and accountability. Broader Trust recommendations are separate programme work, not the purpose of the Modelling learning section.

We provide material needed to implement a linked-data store as informative guidance. Store choice, hosting, runtime translation, enforcement engines and service operations belong to downstream implementations; they are not the domain-modelling specification. This does not make adopted privacy or access semantics optional: the model and generated delivery profiles must preserve their declared requirements. Authoring and generation tools do not make OPDA the operator of a data application.

2a. Domain-model support for the SPDTF Trust Framework

The archived DPMSG Smart Property Data Trust Framework Sandbox paper, pp2–4, describes a shared framework of participation rules, data standards, permissions, provenance and assurance. Its programme and sandbox remit is wider than this domain-modelling effort; the associated project plan is not evidence of completed delivery.

The DBT Guidebook analysis distinguishes what a data standard must be able to express from what a scheme operator must do. Chapter 1’s archived Draft V7, dated 10 May 2026, describes scheme identity, roles, accreditation, authorisation and trust frameworks; Chapter 4’s Draft V2, dated 25 June 2026, describes stewardship, privacy and data-use metadata. These are programme-design evidence, not automatic adoption of a government mandate, an implementation stack or a final SPDTF rule. Their separate existing documentation remains the home for broad Trust-framework explanation. This scope clarification does not designate a statutory scheme or ratify draft programme requirements. Adopted ontology-method requirements retain their own authority.

Within the eight retained categories, model the meaning needed to connect domain data to that framework: personal-data and sensitivity classifications; processing purpose and separately identified permission/lawful-basis concepts; access roles and scope; provenance and relevant time or status. Reuse or map scheme concepts through their documented semantic home, without redefining them inside every property context. ADR-0067’s resource-home rule and the Interoperability Working Group govern these seams.

A transaction role such as Seller is not an access-policy role, nor evidence of accreditation or permission. An explicit, scoped relationship may connect them when justified; never infer access from the domain role alone. Scheme permission, a legal basis for processing and recorded consent are not interchangeable. Model annotations and JSON-LD references describe these distinctions; they do not authenticate an actor, grant access, prove valid consent or implement role-based security.

Practitioners review those facts and distinctions in business language. Technical readers learn the selected ontology-modelling category profiles and representations. Neither audience needs a course in scheme accreditation, registry operation or enforcement. Category 6 remains excluded; this interface does not import a governance ontology.

3. Eight ontology categories required from every group

The outputs above say what each group agrees and the artefacts say how that agreement is published. The following eight categories say what kinds of meaning the ontology must consider. They adopt the subset of the 14-category framework in the semantic-modelling sibling project retained by ADR-0067.

Categories 3 (process modelling), 4 (service architecture), 6 (governance and compliance), 12 (capability and intent), 13 (source mapping) and 14 (data product) remain outside OPDA’s required ontology coverage. Specification governance is recorded in ADRs and procedures, rather than added as a property-ontology output. The deliberately small common ontology is an architectural boundary governed by the Interoperability Working Group rather than a ninth formal category.

The eight adopted categories form a completeness framework, not an instruction to over-model. For each category, every group records one disposition:

• model here — the group owns substantive domain content;
• reuse shared — the group uses a common or externally governed model;
• boundary contribution — the group supplies requirements or mappings for the Interoperability Working Group;
• not applicable — permitted only with a recorded rationale.

The category assessment is maintained alongside the outputs and reviewed at each release. It prevents silent gaps without forcing every group to create eight separate files or duplicate common terms.

3a. Normative source-method selection

The 5 September review uses source revision 67174057e6384b79d0b28b7736fe70a66e112895, read without modifying the source project. ODR-0071a/b/e/g/h/i/j/k supply the retained category detail. Supporting rules include ODR-0015/0040/0106 (context ownership), ODR-0016/0023 (controlled vocabularies), ODR-0025/0026 (roles, phases and property placement), ODR-0115/0118 (concern-led construction and foundational analysis), ODR-0087/0096/0098 (qualified mappings) and ODR-0127 (strategic context maps).

Later explicit amendments govern over retained older text. In particular:

• Source ODR-0014’s 28 and 30 August amendments retire repeated RDFS domains as documentary “any-of”. Each property side uses one universally intended RDFS domain/range, Schema.org applicability hints, or a governed waiver. SHACL enforces requirements; disabling inference never changes standard semantics.
• SSSOM 1.0 and SEMAPV are required for reviewed internal and external mappings under ODR-0071h/0087, not deferred until an external consumer appears.
• UFO/OntoClean supply normative analytical discipline, not an imported upper- ontology superclass tree. PROV-O, OWL-Time and DPV are selected within their concerns; source ODR-0089 conditionally selects the ODRL DPV profile where needed.

This scope supersedes conflicting earlier OPDA method wording, including the SSSOM deferral in OPDA ODR-0002 and the repeated-domain convention in OPDA ODR-0027 R5 and ODR-0032/0033. Those records retain historical implementation evidence. This clarification does not migrate a generator or the immutable Property Pack 0.1 candidate, fabricate mappings, approve domain definitions, adopt all external terms, or promote the proposed ADR-0065/0068 operating processes. Conformance and publication remain separately evidenced decisions.

4. Interoperability Working Group

The cross-cutting group is named the Interoperability Working Group, replacing the less precise working label “Common Modelling Working Group”.

Each domain and scheme group appoints representatives to the Interoperability Working Group. This group does not redesign domain models. It owns the agreements required at their boundaries:

• a deliberately small common boundary ontology containing concepts genuinely required for exchange;
• a context map showing where meanings originate, where information crosses a boundary, and which group owns each decision;
• mappings between controlled vocabularies and taxonomies, using SKOS mapping relationships where appropriate;
• shared conventions for identifiers, provenance, versioning and change control where cross-context consistency is required.

The Interoperability Working Group also maintains the programme-wide eight-category coverage matrix and the shared standards profile. The common ontology must remain small. A concept belongs there because multiple contexts need a stable exchange agreement, not because centralisation is convenient.

5. Working method

Each group follows an iterative, evidence-led method:

1. agree scope, users, exclusions and competency questions;
2. collect the language, rules, documents, forms, examples, diagrams, recordings and representative scenarios used by practitioners, subject to consent and information handling controls;
3. use an evidence-grounded council of AI agents, expert perspectives and multiple models to propose an ontology and its related semantic outputs;
4. publish diagrams, definitions, examples, questions and machine-readable artefacts as a reviewable website increment;
5. let practitioners challenge the draft in business language, then ingest the feedback and publish a visible revision;
6. distinguish domain entities and relationships from glossary terms, dictionary entries and controlled classifications;
7. complete the eight-category assessment, explicitly recording shared and not-applicable dimensions;
8. test the package against examples, competency questions and agreed validation rules;
9. refer genuine cross-context dependencies to the Interoperability Working Group;
10. repeat until the group considers the model stable enough to publish as its collaborative first draft.

Most participants encounter data through schemas and electronic forms, which present a tree-shaped view. The ontology presents the connected business model as a graph. That distinction should be explained in plain language, but working sessions do not require participants to learn either ontology syntax or schema engineering. Existing schemas and mappings remain inputs for traceability, migration and implementation, and new schemas can be generated and published from the governed ontology through tested transformations. Participants supply evidence and judgement; facilitators produce the formal artefacts. ADR-0065 proposes controls for that authoring cycle; its Proposed status does not establish a live service or adopted governance mechanism.

6. First group: Finance and Banking

The first working-group kick-off is Finance and Banking.

The Financial Industry Business Ontology (FIBO) is an established ontology for the finance domain. It is a useful reference and potential source of reusable concepts. Participants are not expected to know FIBO or ontology engineering, and the group will not import it wholesale before agreeing the bounded context’s scope and questions.

The session should use diagrams, semantic descriptions, a glossary, a data dictionary, examples and business-language validation outcomes. The current OPDA website may be shown as a demonstration of how models can be explored and discussed, but its current model must not be presented as the new Finance and Banking model.

The first step is resource-first: OPDA will ask participants for the standards, schemas, forms, definitions, policies, examples and other material they already use. The modelling facilitator will use that evidence, with AI assistance, to produce and publish the first candidate model for review. The group will then improve successive candidates through evidence, discussion and feedback rather than attempting to model the ontology live in the kick-off meeting.

7. Relationship to existing decisions and artefacts

This ADR does not delete the current generated corpus. ADR-0026, ADR-0039, ODR-0019 and ODR-0020 retain the provenance of how the schema-derived model and bounded-context scheme were produced; their living authority statements must be read with their dated schema-to-scheme amendments.

If this ADR is accepted, the next governance step is to identify and formally supersede or amend the normative claims in those records that make schemas, form overlays or the generated corpus authoritative for future domain modelling. Until that work is ratified:

• the existing site and ontology continue to document the current implementation;
• the new working-group outputs remain a separate development stream;
• no new domain model silently replaces an existing published term;
• migration and compatibility decisions are deferred until the new models have enough substance to compare.

Consequences

• Good, because domain definitions are challenged by the people who use them rather than inferred from document structure.
• Good, because each context receives dedicated attention and a clear owner.
• Good, because non-technical experts can participate directly.
• Good, because controlled vocabularies, taxonomies and validation rules are first-class concerns rather than afterthoughts.
• Good, because the eight-category checklist catches cross-cutting omissions such as classification, provenance, time and privacy.
• Good, because cross-context differences remain visible and are mapped explicitly.
• Good, because groups can publish useful increments without completing a universal model.
• Bad, because parallel domain groups create coordination and versioning work for the Interoperability Working Group.
• Bad, because eight categories can become bureaucratic if treated as eight mandatory models; the four-disposition rule and recorded not applicable outcome mitigate this.
• Bad, because some concepts will be modelled differently before mappings and common boundaries are agreed; this is expected discovery, not immediate convergence.
• Bad, because the eventual migration from the current corpus will require a separate, evidence-based plan.
• Neutral, because the current schema-derived artefacts remain useful for traceability and comparison but lose their presumed authority over future domain meaning.

Confirmation

• Every active domain group has a written charter naming its scope, exclusions, competency questions, membership and steward.
• All six bounded-context working groups, the DBT Smart Data scheme working group and the Interoperability Working Group are chartered.
• Every domain and scheme group plans all six required content outputs and the listed publication artefacts, and maintains an eight-category coverage statement using the four permitted dispositions.
• The Interoperability Working Group includes a representative from every active domain and scheme group and has an explicit “boundary agreements, not domain redesign” remit; it maintains the programme-wide coverage matrix and standards profile.
• Workshop material is understandable without knowledge of JSON Schema, RDF, OWL, SKOS or SHACL syntax.
• Participants can contribute source evidence and review model drafts without manipulating ontology syntax; AI-generated proposals retain source provenance and remain subject to human governance under ADR-0065.
• Finance and Banking is the first application of the method and records lessons before further groups adopt it.
• A follow-on governance record identifies the precise ODR/ADR amendments required before any new model becomes normative.
• No public website content is migrated piecemeal; publication follows ADR-0064.

More Information

• DBT Smart Data — standard versus operator responsibilities
• Guidebook Chapter 1 — identity, roles and Trust, with archived Draft V7
• Guidebook Chapter 4 — stewardship and privacy, with archived Draft V2
• ODR-0054 — sensitivity and bounded policy modelling
• ODR-0057 — conditional ODRL/DPV profile
• Research — bounded-context working-group approach
• ADR-0065 — AI-assisted evidence-to-model workflow with human-governed review
• Research — AI-assisted working-group method
• Presentation plan — July 2026 Exec and Finance and Banking workshop
• ADR-0064 — redesign the modelling website before publishing the new approach
• ADR-0039 — linked-data model as the SPDTF foundation
• ADR-0026 — bounded-context scheme emission
• ODR-0019 — bounded-context representation
• ODR-0020 — bounded-context scheme and mapping

Amendments

• 2026-08-22 — Chair-authority terminology correction. The existing input is the PDTF schema and supporting material; its extracted ontology is a schema-derived technical artefact. Neither is an OPDA-endorsed predecessor scheme. SPDTF is the first collaboratively authored scheme draft, and this working-group method governs that schema-to-scheme continuation. Historical derivation evidence and stable technical identifiers remain unchanged.