Scope and package: eight concerns, six connected outputs

    Assess the meaning a context must own, the agreements it can reuse and the evidence needed at its boundaries. Bring the results together as one versioned semantic package, not a collection of independently drifting documents.

    Technical modelling guide

    Method basisUpdated

    A carefully gathered portfolio keeps different review materials connected through one shared binding.

    Do not turn three useful structures into one hierarchy

    The eight retained modelling concerns tell us what to consider. The six semantic outputs tell us what practitioners should be able to review. The four dispositions record where responsibility for each concern belongs. They are different structures: a concern can affect several outputs, while one output can draw on several concerns.

    A bounded context gives the package its semantic home. It identifies the coherent language and responsibility for its meaning, not a folder, department or set of screens. A package then brings definitions, relationships, governed choices and their supporting contracts into a versioned agreement that can be inspected and challenged.

    The aim is complete consideration within a declared scope, not maximum ontology size. A package that reuses a well-fitting vocabulary can be more complete than one that creates a redundant vocabulary and leaves its relationship to the shared meaning unexplained.

    Eight retained concerns, with their method identifiers

    01Domain structure
    Identify the things and their relationships.
    Not a copy of the form.
    02Vocabulary
    Give choices and concepts governed meanings.
    Not every list is closed.
    05Classification
    Describe the model through independent facets.
    Not another inheritance tree.
    07Constraints
    State and test the conditions on supplied data.
    Not proof that a claim is true.
    08Correspondences
    Qualify the connection between defined terms.
    Not automatic equivalence.
    09Provenance
    Make sources and responsibility inspectable.
    Attribution is not endorsement.
    10Time
    Distinguish occurrence, validity and recording.
    Not one generic timestamp.
    11Sensitivity
    Describe privacy, role and policy scope.
    Not operational enforcement.

    Text equivalent: assess domain structure (1), vocabulary and taxonomy (2), classification metadata (5), validation (7), mappings (8), provenance and quality (9), time and history (10), and sensitivity and access policy (11) across one connected package.

    Eight concerns are a coverage contract, not eight mandatory files or separate ontologies. The original category numbers preserve traceability to the source framework.

    Assess a concrete question across all eight concerns

    For Harbour Court, ask: “Which subject did the 12 August 2026 inspection concern, and which report version supports the information we are using?” The fictional building contains Flat 1 and Flat 2. Report version 1 appears on 14 August; a correction produces version 2 on 20 August. That small question touches more than the obvious class and date fields.

    The following is a proposed assessment for the teaching case, not a completed OPDA package register. Each row identifies an evidence obligation; naming a disposition does not demonstrate that the obligation has been met.

    Eight-concern assessment of the fictional inspection-report package
    ConcernProposed dispositionWhat must be established
    1 · Domain structuremodel hereDistinguish building, dwellings, inspection, claim and report version. Keep the title record separate; leave subdivision identity unresolved until reviewed.
    2 · Vocabulary and taxonomyreuse sharedIdentify a governed report-status vocabulary whose definitions fit this use. Pin its version; do not assume a similarly named list is suitable.
    5 · Classification metadatareuse sharedUse reviewed subject and information-type facets for discovery without turning those facets into inheritance or transferring ownership.
    7 · Validation and constraintsmodel hereDefine the receiving profile’s required inspection-subject and report-version links, with positive and counterexamples and explicit graph assumptions.
    8 · Cross-domain mappingsboundary contributionSupply the receiving context’s needs and paired definitions. Review term correspondences and strategic applicability separately; do not invent an exact match.
    9 · Provenance and qualitymodel hereIdentify the claim and report evidence, sources and versions. Distinguish faithful extraction from confidence that the reported observation is true.
    10 · Temporal state and historymodel herePreserve the 12 August event and the 14/20 August report-generation dates. Keep a receiving system’s recording time distinct where needed.
    11 · Sensitivity and access policymodel hereEstablish which information needs handling restrictions and for what purpose. Do not treat a classification as evidence of runtime access enforcement.

    If the proposed shared vocabulary fails the meaning comparison, change the disposition or narrow the package’s scope rather than marking reuse complete. Likewise, a mapping register with no reviewed entries can coexist with a required mapping discipline. An empty register is an implementation gap, not evidence that the concern is irrelevant.

    For concerns 2 and 5, work through vocabularies and classification. Its decision procedure separates value-set closure from an open population, and the base facet pattern from the stricter Category 5 completeness profile. A package must name which of those requirements it claims.

    Make the ownership decision explicit

    A completed assessment assigns one of four dispositions to each retained concern for the declared context package. Record the owner, supporting evidence and any dependency that qualifies the decision. Shared vocabulary dependencies can support locally modelled content without becoming a second, competing owner of its meaning.

    model here
    The context owns substantive meaning or a local requirement. Identify its constructs, evidence, reviewer and open questions; do not equate ownership with approval.
    reuse shared
    A governed shared or external agreement meets the need. Record the exact terms and version, how they are used and what falls outside that reuse.
    boundary contribution
    The context supplies requirements or correspondences for an interoperability agreement. Name the affected contexts, the consumer question and the proposed handoff.
    not applicable
    The concern genuinely does not apply to the stated scope. Give a reviewable rationale and the change that would reopen the decision.

    “Not applicable” must not mean “we have not investigated”, “there is no data yet” or “the generator cannot emit it”. Leave such gaps visible until the assessment can be completed. In the Harbour Court case, sensitivity cannot be dismissed simply because the teaching fixture contains no real personal data; the intended report-exchange use still needs examination.

    Let six outputs expose the same reviewed meaning

    The package presents six related kinds of review material. These are coordinated views or projections of one agreement, not six autonomous standards and not necessarily six files. A projection can be generated only when its source and derivation contract are known; calling it a projection does not prove that such generation already exists.

    Six reviewable outputs in the Harbour Court illustration
    OutputWhat a practitioner inspects
    Business glossaryThe meanings of inspection, inspection subject and report version, with examples and exclusions.
    Data dictionaryThe recorded elements, their value expectations and which meaning each one expresses; an inspection date is not a report date.
    TaxonomiesReviewed broader/narrower organisation of relevant concepts, without pretending the browsing tree is class inheritance.
    Controlled vocabulariesThe governed status or choice concepts, definitions, identifiers and closure decisions used by this package.
    ResourcesThe identifiable kinds of thing and their descriptions, including the distinction between the building and its report.
    RelationshipsHow a report refers to an inspection, how its subject is identified and which participation or mapping needs qualification.

    A mapping set can be an interoperability attachment aligned with Relationships; it is not a seventh semantic output. Shapes, inference profiles and evidence receipts support the package across these views. They must remain aligned with the reviewed meanings rather than becoming a hidden alternative definition.

    Follow one reviewed change across the package

    Suppose reviewers find that “inspection subject” was described too loosely as “the property”. They agree that the package must distinguish a whole-building inspection from a dwelling-specific inspection. That is one semantic change with several consequences, not a request to edit a glossary sentence and stop.

    1. Meaning: revise the glossary definition and its Harbour Court counterexample; record the reason and the deciding authority.
    2. Structure: check resource and relationship definitions so the intended subject can be identified without equating a building and dwelling.
    3. Recorded data: align the dictionary’s subject reference and any applicable choice vocabulary or taxonomy; record a checked “no change” where appropriate.
    4. Contracts: update the receiving shape and examples, and review mappings that depended on the older definition.
    5. Release evidence: identify the package version, changed and unchanged outputs, dependencies, derivations and checks actually completed.

    Do not silently relabel old report data as conforming to the revised definition. Determine whether the original evidence distinguishes its subject, whether a qualified migration is possible and what remains unknown. Nor does this change alter the inspection date or settle the unresolved subdivision criterion: its scope must remain explicit.

    Keep the exclusions visible without erasing programme responsibilities

    The source framework has fourteen categories. OPDA excludes process modelling (3), service architecture (4), governance and compliance as an ontology (6), capability and intent (12), source mapping (13), and data products (14) from this selected ontology scope.

    Working groups still govern decisions. Delivery systems still need architecture and access controls. Sources and historical schema mappings still provide evidence. These activities do not automatically require the excluded ontology categories. In particular, describing a semantic package does not adopt a separate data-product ontology, and linking a source requirement to a model construct does not adopt an executable source-mapping model.

    A change in that scope requires an explicit decision. It must not arrive unnoticed through a diagram, a new namespace or a claim that a convenient tool needs every category.

    A package handoff is a receipt, not a claim of completion

    Identify the scope and semantic owner; package and source versions; concern dispositions; the six output views; vocabulary and mapping dependencies; relevant validation and inference profiles; and unresolved questions. Where a view is generated, state its source, generator and derivation. Where it is manually maintained, explain how alignment is checked.

    A package diff and appropriate rerun evidence make a synchronisation claim reviewable. The method requires that evidence; this explanatory page neither performs those checks nor certifies today’s candidates. Technical conformance and human adoption remain distinct.

    Source contract

    OPDA ODR-0046 R1 supplies the fourteen-category framework; child records ODR-0047 / ODR-0048 / ODR-0049 / ODR-0050 / ODR-0051 / ODR-0052 / ODR-0053 / ODR-0054 govern the retained concerns. OPDA ADR-0063 and ADR-0067 establish the selected scope and connected semantic outputs; the package is not an adoption of excluded category 14. Supporting property, mapping, temporal and policy rules retain their own amendments and applicability boundaries.

    Adoption provenance: upstream revision 67174057e6384b79d0b28b7736fe70a66e112895, 5 September 2026. See standards and decisions for local adoption scope and upstream provenance. The assessment and proposed change above are fictional illustrations, not populated candidate records or conformance results.

    Comments

    Loading comments…