Model review and decisions

    Members review business meaning, evidence, examples and consequences. They are not expected to author ontology syntax, and a generated candidate does not become a standard merely because it appears on the website.

    The current review path

    1. Evidence: members submit authorised sources, scenarios and domain explanations.
    2. Questions: the group makes ambiguity, gaps and competency questions explicit.
    3. Candidate: facilitators and tools produce a versioned, reviewable proposal.
    4. Review: members challenge definitions, relationships, constraints, examples and omissions.
    5. Revision: accepted corrections and new evidence inform a visible next candidate.

    ADR-0065 describes a fuller evidence-to-model cycle, but ADR-0065 remains proposed. Treat it as the documented direction and keep each workspace's actual candidate and review status visible.

    What to check

    • Does the definition match how practitioners use the term in this context?
    • Are two different things being merged, or one thing being duplicated?
    • Do the relationships, roles and direction make business sense?
    • Are required distinctions, exceptions, lifecycle states or time conditions missing?
    • Does a controlled value set use the right terms and scope?
    • Can the candidate answer the group's competency questions and represent real examples?
    • Does it cross another context boundary, and if so, is the ownership and mapping explicit?
    • Does the published change view explain what moved and why?

    Cross-boundary comparisons follow the Category 8 mapping method: tools may suggest a candidate, but affected semantic owners and Interoperability decide whether there is a mapping and which predicate the evidence supports.

    Make feedback actionable

    When commenting, identify:

    • the page, term, relationship, example or version affected;
    • the problem and its practical consequence;
    • supporting evidence or a counterexample where available;
    • the change you think should be considered; and
    • whether the issue is local to the group or crosses a boundary.

    Use the relevant Teams thread for discussion and the page's website comments for contextual feedback. Neither reaction counts nor a comment alone is a decision record.

    Who may decide what

    ActorResponsibilityBoundary
    Domain or scheme working groupReviews meaning inside its stated scope.Does not unilaterally redefine another context.
    Interoperability Working GroupReviews the common boundary, context map and cross-context mappings.Does not redesign internal domain meaning.
    Technology Working GroupSupplies implementation, validation, compatibility and release-readiness evidence.It is not a ninth modelling context and does not ratify a standard.
    Property Technology working groupOwns platforms, workflow, integrations and operational feedback in its bounded context.It is not the cross-cutting Technology Working Group.
    Facilitators and AIExtract, compare, draft, challenge and test proposals.AI has no decision authority, membership or vote.
    Authorised OPDA governanceControls any later adoption or ratification.The detailed lifecycle in ADR-0068 is still proposed.

    Comments

    Loading comments…