How the modelling work is done

You do not need to arrive with a model

Think of a question you regularly have to clarify: “Which arrangement makes this person the borrower?”, “What does this area include?” or “Does completed mean the visit ended or the report was issued?” The expertise lies in noticing which distinction matters to the work. You do not need to propose a field, draw a formal diagram or know an ontology language before the question is useful.

OPDA's approach begins with the materials practitioners already use—standards, definitions, forms, policies, examples and other authorised evidence. This is the resource-first starting point: bring the resources that explain the question, rather than trying to construct the whole ontology live in a kick-off meeting. It is not an instruction to turn each document or field into a model term.

Facilitators help make that knowledge explicit and formal. AI can assist with examining sources and drafting a candidate. The candidate returns to people as readable definitions, examples, relationships and questions. Its purpose is to make judgement possible, not to ask practitioners to endorse an answer hidden inside technical syntax.

Work inside the documented boundaries

OPDA's contextual boundaries are established inputs for this development phase. New participants are not being asked to rediscover the context map. A semantic home identifies responsibility for a meaning; it is not necessarily the profession, working group or system in which somebody encounters the term. Several contexts can use a meaning without each owning a competing definition.

The context register supplies the maintained description; the contexts chapter explains how to read it. A small common boundary is not a general folder for unresolved ownership. Where two contexts need different meanings, a carefully justified connection may be preferable to one imposed definition. Boundary agreements belong with the Interoperability Working Group and the affected meaning owners, not with an individual drafter acting alone.

From a useful source to a reviewable proposal

Start with a question and its scope

Identify what someone needs to understand, which subject the question concerns and where the problem arises. Add a normal example and a difficult case. “Which report version supports this statement about an inspection?” is a modelling question. “Add a download button” may be a useful product request, but it does not yet identify a missing meaning.

Bring evidence that another person can interpret

A source needs a title or reference, version, relevant passage, intended use and handling conditions. Distinguish its wording from your interpretation. Existing schemas and forms may expose a missing distinction; they do not automatically settle it. Restricted evidence must remain within authorised handling arrangements. Describing an ambiguity need not mean sharing customer records or copying an entire restricted document.

Draft the agreement in inspectable forms

A facilitator can propose definitions, identify separate subjects, label relationships and make examples consistent. AI-assisted drafting can help compare material and expose questions, but an attractive definition may still lack support. Keep the source, proposed interpretation and unresolved question distinguishable. The six output views allow different readers to inspect the same proposed agreement.

Check the package and exercise human judgement

Technical checks can assess declared structure and requirements. Examples can test whether a question is answerable and whether a rule excludes a legitimate case. Practitioners judge whether the distinction matches the domain and its evidence. A technically valid sentence can still express the wrong meaning; a familiar sentence may still be too ambiguous for a useful check.

Make the reason for revision visible

A revision should explain what was challenged, why the wording or structure changed, what stayed the same and what remains unresolved. Another context may need to review a boundary consequence. Retaining a well-founded distinction can be a successful outcome: progress need not mean forcing every participant to use a single word in exactly the same way.

This explains the accepted evidence-led method. It does not claim that every proposed intake, discussion or review-control mechanism is implemented as a live service. Current participation mechanics belong in the member guide, not in a copied meeting schedule or submission promise here.

A small package, examined from eight concerns

Use one fictional package: a report version describes an inspection of an identified dwelling. It records an issue date and a physical access outcome, and cites the source supporting its statements. The retained concerns help people notice omissions around that package. They are a completeness aid, not eight new models to build or a sequence to memorise.

For each concern, the method calls for a recorded disposition: model here, reuse shared, boundary contribution, or not applicable with a reason. For this example, the group might define its inspection meaning locally, reuse a suitable shared concept for source attribution, and refer the recipient's ambiguous date requirement for boundary work. Those are illustrative possibilities, not decisions about the actual candidate.

“Not applicable” needs a rationale, not a blank cell. Equally, considering sensitivity does not require a property group to invent its own scheme policy. Relevant distinctions can be reused or connected through their documented home. Model-review governance concerns evidence, ownership, decisions and versions; it is not synonymous with the wider SPDTF Trust Framework.

A proposal is not an approval

Keep several questions separate. Is this a reviewable draft? Has a specified technical check run? What technical determination has been recorded? Which domain meanings have been reviewed? Has a release been authorised? Is there external recognition? One answer does not automatically supply the others. Read the status of the particular artefact rather than inferring it from the sophistication of its website.

AI agents can assist and challenge, but have no vote or ontology authority. Domain participants judge meaning; the Interoperability Working Group handles the agreements at boundaries without overriding local meaning. Promotion and release require recorded authority through OPDA's governance. A passing check, an informal consensus or a generated proposal cannot authorise release alone. Broader process controls that remain proposed must not be described as a settled response cadence or an automatic adoption mechanism.