Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group

    Change management process

    OPDA has constitutional machinery for changing the Association's rules and an 8-step procedure for implementing changes to the existing PDTF schema corpus. A separate, end-to-end standards-development and ratification lifecycle is now proposed.

    Do not confuse implementation approval with standards ratification

    The current 8-step SOP remains the baseline for the legacy schema implementation workflow. ADR-0068's proposed standards lifecycle adds working-group consensus, public review, objections, independent checks, implementation evidence and formal ratification. It is not operative until accepted by the Executive Committee, Board or a valid recorded delegate.

    flowchart LR C["`Constitutional change`"]:::process T["`Existing schema implementation`"]:::process S["`Standards-track proposal *(proposed)*`"]:::warning GA["`General Assembly *majority vote*`"]:::infra TR["`Technical Reviewers *current SOP*`"]:::service WG["`Domain WG / Interoperability WG *human consensus*`"]:::service GATES["`Independent technical + risk gates`"]:::process RAT["`Executive Committee / Board *ratification*`"]:::success C --> GA T --> TR S --> WG --> GATES --> RAT
    Three related routes with different authority. Blue paths are current constitutional or technical procedures; the standards route is proposed in ADR-0068.

    A. Constitutional & governance change

    Changes to OPDA's foundational documents — the Constitution, Articles of Association, Code of Conduct, or policies — are governed by company law and the Articles, not by the PDTF SOP.

    Constitution amendment rule

    This constitution may be amended by a majority vote of the General Assembly. Proposed amendments shall be communicated to the members at least thirty (30) days prior to the Annual General Meeting.

    Source: OPDA Constitution 2026.pdf p.6 (Amendments)

    General Assembly — the decision body

    The Constitution names the General Assembly as the “overall decision-making body of the association”. It consists of all members and convenes at least once a year to approve the Constitution, receive reports, approve budgets, elect or re-elect Executive Committee members, and discuss matters of importance. Decisions are made by majority vote of members present or by proxy voting.

    • AGM date. Held annually no later than 31 October each year (Articles art. 24(1)).
    • Quorum. Minimum two member attendees (Articles art. 25).
    • Voting. One member, one vote. Decided on a show of hands unless a poll is demanded (Articles art. 29).
    • Poll votes. Demandable by the chair, directors, two or more voting members, or members representing not less than one tenth of total voting rights (Articles art. 31).
    • Proxies. Permitted by written notice (Articles arts. 32–33).
    • Amendments to resolutions. Ordinary resolutions may be amended with 48 hours' notice; special resolutions only by the chair to correct non-substantive errors (Articles art. 34).

    Source: Articles of Association 2026.pdf Part 3 (Members), arts. 24–34.

    Members' reserve power

    Day-to-day management sits with the directors under their general authority (Articles art. 4). However, Article 5 reserves the ultimate power to the members:

    (1) The members may, by special resolution, direct the directors to take, or refrain from taking, specified action. (2) No such special resolution invalidates anything which the directors have done before the passing of the resolution.

    A special resolution has the meaning given in section 283 of the Companies Act 2006 (requiring a 75% majority). This is the mechanism by which the membership can override the Executive Committee on a specified matter, though it has prospective effect only.

    Source: Articles of Association 2026.pdf art. 5; defined terms art. 1.

    B. Technical & schema change

    Changes to the existing PDTF schema, overlays, and trust-framework artefacts currently use the Standard Operating Procedure documented in source/03-standards/trust-framework/docs/governance.md § 6. The current published schema version is 3.5.0 (per schemas/package.json).

    The 8-step SOP

    flowchart LR S1[1. Submission]:::process S2[2. Implementation]:::process S3[3. Impact assessment]:::process S4[4. Review]:::process S5[5. Documentation]:::process S6[6. Approval]:::process S7[7. Stakeholder notification]:::process S8[8. Release]:::process S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8
    PDTF SOP for schema changes (governance.md § 6). Each step is owned by named roles inside the Technical Review group.
    1. Submission. Open a GitHub issue using the Standard Change Proposal Form. Required fields include a change reference identifier, change type (change or bug fix), justification, technical details, impacted areas (flagging any “stable” areas of the schema), and stakeholder impact.
    2. Implementation. Complete the work in a new branch linked to the issue.
    3. Impact assessment. Conduct a documented impact assessment for risks and compliance concerns using the Impact Assessment Form.
    4. Review. Raise a pull request to the next branch. Resolve review comments, squash incoming commits, and link the PR to the issue. Higher review barriers apply for “stable” schema elements or backwards-compatibility implications.
    5. Documentation. Update all relevant documentation to reflect the change.
    6. Approval. Notify stakeholders of intent to merge from next to master, summarising change, breaking-change implications, and intended merge date. Tag the commit with a release version.
    7. Stakeholder notification. Send the Change Notification Template (standard) or Breaking Change Notification Template (stability or breaking). For breaking changes, notify before the approval step.
    8. Release. Once fully approved the release is operational. Stakeholders are advised to update the Stakeholder Version Register.

    Current implementation-review thresholds

    These reviewer thresholds belong to the existing schema SOP. They are not the proposed consensus or ratification thresholds for a new OPDA Standard.

    • Promotion to next. At least X Technical Reviewers must approve (the SOP placeholder — specific number still TBD).
    • Technical proposals (general). Approval from at least two members of the Technical Review group (governance.md § 3.B).
    • Standard changes to master. At least two reviewers from different stakeholders.
    • Stable schema or backwards-compatibility changes. Higher barrier — three reviewers or broader consensus, with additional compliance and risk assessment if needed.
    • Feedback window. Minimum of X working days for stakeholder feedback after the approval announcement (specific number still TBD in the SOP).

    Source: governance.md § 3.B (Technical Review — processes) and § 6 (Approval Requirements).

    Semantic versioning

    The schema follows semantic versioning (MAJOR.MINOR.PATCH):

    • Patch (3.5.x). Bug fixes, no breaking changes.
    • Minor (3.x.0). New fields, backward compatible.
    • Major (x.0.0). Breaking changes, migration required.

    Source: schemas/README.md § Versioning.

    Release cadence

    Cadence not yet codified

    The canonical SOP at governance.md does not specify a fixed release cadence (monthly / quarterly / annual). Approval thresholds and the consultation period (“minimum of X working days”) carry X placeholders pending decision by the Technical Review group. The earlier stub on this page claimed a monthly minor / twice-yearly major / 6-month migration cadence; those figures were not in the source documents and have been removed.

    Public consultation & stakeholder engagement

    The Engagement function (governance.md § 3.D) is responsible for inviting external comment, gathering and consolidating stakeholder feedback on roadmap priorities and schema changes, notifying impacted parties, and publishing regular updates on progress. Compliance and Risk (§ 3.C) conduct a compliance check of proposed major schema releases before release and provide guidance on potential changes.

    Trust Registry update

    Where a change affects accredited issuers or credential types, the Trust Registry — a public JSON-LD document listing approved Issuers, their DIDs, legal names, status, and authorised credential types — must be updated and re-signed by the Governance Authority for authenticity (governance.md § 4).

    Templates & reference forms

    OPDA already publishes the templates referenced by the SOP:

    Sources and relationship between the procedures

    For the existing schema implementation workflow, the authoritative reference remains source/03-standards/trust-framework/docs/governance.md. If this page and that file disagree about the current 8-step SOP, that file wins. The proposed standards lifecycle addresses the broader route from evidence to an OPDA Standard and would become authoritative only after ADR-0068 is accepted.

    Comments

    Loading comments…