Change management process

Two distinct change pathways exist at OPDA: constitutional / governance change (the rules of the Association itself) and technical / schema change (the PDTF artefacts). Each has its own approval route and authority.

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 PDTF schema, overlays, and trust-framework artefacts follow the canonical 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

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.

Approval thresholds

• 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

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:

• source/03-standards/trust-framework/docs/proposal.md — Standard Change Proposal Form (step 1).
• source/03-standards/trust-framework/docs/proposal-impact-assessment-form.md — Impact Assessment Form (step 3).
• source/03-standards/trust-framework/docs/change-notification-template.md — Change Notification Template (step 7, non-breaking).
• source/03-standards/trust-framework/docs/breaking-change-notification-template.md — Breaking Change Notification Template (step 7, breaking).
• source/03-standards/trust-framework/docs/compliance-and-policy-checklist.md — Compliance and policy checklist (pre-release).

Canonical source

The single authoritative reference for the technical change procedure is source/03-standards/trust-framework/docs/governance.md. If this page and that file disagree, governance.md wins.