How OPDA develops and approves standards

    How OPDA proposes to turn evidence and domain expertise into reviewed, tested and ratified standards. AI and editors accelerate the work; people with recorded authority decide what advances.

    Proposal — not yet an operative OPDA rule

    This page explains ADR-0068, which remains proposed. It becomes operative only when the Executive Committee, Board or a constitutionally valid delegate records its acceptance. The current published ontology, schemas and technical change procedure remain unchanged in the meantime.

    From evidence to an OPDA Standard

    Each stage says what has—and has not—been approved. Publishing a website preview does not move a candidate to a new stage.

    flowchart LR E["`**Evidence record** screened input`"]:::data C["`**Editor's candidate** AI/editor draft`"]:::process W["`**Working Draft** basis for work`"]:::service P["`**Public Review Draft** wide review`"]:::warning R["`**Release Candidate** gates complete`"]:::process S["`**OPDA Standard** ratified release`"]:::success M["`**Maintain** errata · supersede · withdraw`"]:::infra E --> C --> W --> P --> R --> S --> M P -.material feedback.-> C R -.failed gate.-> C M -.revision.-> C
    The proposed maturity path. Review can return work to an earlier stage whenever evidence, feedback or validation identifies a material problem.
    StageWhat readers may rely onWhat advances it
    Evidence record A source, transcript, comment or observation—not model content. Rights, provenance, sensitivity and security screening.
    Editor's candidate An AI/editor-authored preview that may be incomplete or wrong. Enough deterministic validation and disclosed uncertainty for review.
    Working Draft The group has adopted it as a basis for work—not as consensus or an OPDA endorsement. A recorded group decision plus published scope, status, provenance, changes and open issues.
    Public Review Draft The group considers it complete enough for wide review. Domain consensus, Interoperability concurrence where needed, and permission to open review.
    Release Candidate Comments are disposed and the normative model is technically complete. Every release gate passes and no blocking objection remains unresolved.
    OPDA Standard An immutable, normative and versioned OPDA release. Ratification of the exact release pack by the authorised body.

    The working-group loop

    The lifecycle preserves the way of working introduced to the Finance and Banking Working Group: gather real evidence, create a candidate, publish it for human scrutiny, then feed adjudicated feedback into the next modelling pass.

    1. Intake. Register permitted files, transcripts, standards, examples and participant knowledge with provenance and rights.
    2. Scope. Freeze the evidence, competency questions, bounded context, modelling dimensions and acceptance checks for the run.
    3. Draft. Human-directed AI agents and editors produce a candidate, alternatives and explicit uncertainties.
    4. Check. Run deterministic RDF, OWL, SKOS, SHACL, provenance, coverage, duplication, authorisation and profile tests.
    5. Publish for review. Present definitions, diagrams, dictionaries, shapes, generated familiar artefacts, evidence references, open questions and a change diff.
    6. Discuss and dispose. Link feedback from Teams, meetings, the website and email to one durable issue and record the outcome.
    7. Re-run. Put accepted feedback and resolved evidence requests into a new frozen work order; never silently rewrite a reviewed draft.
    8. Advance or continue. Iterate again or open a recorded stage decision when the exit criteria appear satisfied.
    AI → ontology → useful outputs—and back again

    Participants do not need to understand ontology technology or adopt AI. They provide evidence and judge whether the resulting meaning is correct. AI helps OPDA draft and challenge the ontology; the governed ontology can then generate schemas, forms, validation, documentation and integrations that people already use. Feedback on those outputs becomes evidence for the next candidate.

    Who decides what

    ActorAuthority in the proposed lifecycle
    Domain Working Group Owns consensus on meaning inside its bounded context and recommends stage advancement.
    Interoperability Working Group Owns the common boundary, context map, cross-domain mappings and shared conventions; it does not control a domain's internal meaning.
    Technical Review Independently verifies architecture, identifiers, provenance, generated artefacts, tests, compatibility and release completeness.
    Compliance and Risk Reviews privacy, security, law, competition, intellectual property, accessibility and evidence handling.
    Executive Committee / Board Charters the work, accepts residual organisational risk and ratifies or withdraws OPDA Standards.
    General Assembly Retains constitutional, member and reserve powers; it is not the routine approval body for individual terms.
    Chair, editor and secretariat Facilitate, author and preserve the record. None may substitute personal preference for consensus or ratification.
    AI agents and councils Extract, compare, challenge, draft and test. They have no membership, vote, approval or ontology authority.

    AI guardrails

    AI mayAI may not
    Extract candidate concepts and evidence references.Turn a source statement directly into accepted model content.
    Compare sources, standards, candidate definitions and model routes.Decide which stakeholder, domain or source has authority.
    Draft, challenge and test candidates under a frozen work order.Accept feedback, close its own issue or silently rewrite a reviewed draft.
    Surface disagreements, uncertainty, missing evidence and validation failures.Establish human consensus, approve residual risk or dispose of a Formal Objection.
    Generate familiar artefacts from the governed ontology.Write directly to an accepted branch or advance a maturity stage.

    Material runs record the evidence snapshot, model/provider route, role, task envelope, relevant tool and standards versions, output digest, disagreements and validation results. Public drafts disclose AI-assisted authoring while keeping accountable humans and decision reasons visible.

    Consensus, not popularity

    Default call

    10 working days

    The exact proposal, diff, evidence, open risks and deadline are posted in the group's persistent channel.

    Active support

    Independent organisations

    Unless a charter is stronger: at least three organisations across two materially affected stakeholder categories.

    Meeting decisions

    5-day confirmation

    A proposal first discussed live remains open for asynchronous confirmation. Silence is abstention, not consent.

    Consensus means substantial active support and no unresolved sustained objection after legitimate views have been considered. It does not require unanimity. If good-faith discussion reaches deadlock, the Chair may call an exceptional recorded vote: one vote per represented organisation and a two-thirds threshold. The record must explain why consensus failed; a vote cannot waive a legal, privacy, security, competition or intellectual-property block.

    Objections and appeals

    A Formal Objection identifies substantial technical or procedural harm, its evidence and, where possible, a remedy. It is not an automatic veto, but it must receive a reasoned, equally visible response. Unresolved objections are routed to the relevant Domain Working Group, Interoperability Working Group, Technical Review or Compliance and Risk function. A participant may appeal within 10 working days to independent reviewers appointed by the Executive Committee or Board.

    Public review and proof that it works

    • First Public Review Draft: at least 30 calendar days.
    • Material changes after review: the affected material receives at least a further 15 calendar days.
    • Every material comment: acknowledged, linked to an issue and given a reasoned disposition.
    • Every normative feature: a conformance test or a documented reason objective testing is impossible.
    • Independent use: evidence from at least two organisations, including one that did not author the feature.

    What accompanies a Release Candidate

    Scope

    Authority & traceability

    Approved charter, requirements, immutable versions, content digests and traceability from sources to model constructs and exclusions.

    Quality

    Technical evidence

    Ontology, vocabulary, SHACL, generated artefact and conformance results, plus independent implementation evidence.

    Accountability

    Human record

    Comment dispositions, consensus, objections, appeals, interoperability review, independent technical review and risk sign-off.

    Adoption

    Release readiness

    IPR checks, release notes, compatibility class, migration and deprecation plans, and named maintenance owners.

    Versions and maintenance

    Change classMinimum route
    EditorialNo normative change; editor plus one independent reviewer and a change-log entry.
    Compatible substantiveDomain consensus, affected-context review and a minor-version release.
    Breaking / materialFull public review, implementation evidence, migration/deprecation plan and major-version ratification.
    Urgent legal/security erratumA clearly marked provisional correction after Compliance and Risk plus Technical Review; expires after 90 days unless completed through the ordinary route.

    Every ratified OPDA Standard would receive a systematic review at least every 24 months; this governance process would be reviewed annually. Historical releases remain available and visibly labelled when superseded or withdrawn.

    Existing versioned artefacts

    OPDA already maintains artefacts on separate version tracks. At the time this page was updated, the legacy PDTF schema package was 3.5.0, the trust-framework package was 0.3.0, and the API corpus included 1.x and 2.0.0 definitions. These facts describe the current corpus; they do not imply that ADR-0068 has governed those earlier releases.

    Before the first Property Pack public review

    • Approve the relevant Domain Working Group and Interoperability Working Group charters.
    • Create the canonical issue/disposition register and maturity-stage register.
    • Adopt contribution, feedback, copyright and patent terms.
    • Prepare consensus-call, Formal Objection, public-review and release-manifest templates.
    • Dry-run one candidate from evidence through feedback, re-run, validation and a human stage decision.

    Comments

    Loading comments…