# Revision Management

### Governance Structure

A governance structure is established to promote accountability, transparency, and formal decision-making in the management and revision of standards. This structure includes:

<figure><img src="https://646606628-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF9fu0tIY1rJUsF03WdAv%2Fuploads%2FzAkMiuYK2uedtVuaviBH%2FScreenshot%202026-01-19%20at%201.41.37%E2%80%AFPM.png?alt=media&#x26;token=ed3a0bc3-3935-4a03-bd3c-bf71ddb68dc7" alt=""><figcaption></figcaption></figure>

For a detailed overview of the governance structure, consult the Governance Document, which describes the purpose, composition, and responsibilities of each team.

### Process for Managing Change Requests

The change request process ensures that modifications to SPDCI schemas, APIs, and modules are implemented in a controlled and predictable manner.

#### Cycle Initiation&#x20;

Revisions to the standards can be initiated in two ways:&#x20;

* Triggered Reviews – Requests submitted via the SPDCI Git repository tracker.&#x20;
* Scheduled Reviews – Annual review cycle conducted by the DCI Standards Development Team to assess adoption and identify needed updates.&#x20;

#### Submission & Documentation&#x20;

All change requests are submitted via the SPDCI Git repository tracker using the Proposed Change Documentation (PCD) template, which must include:&#x20;

* Requester details&#x20;
* Description of the change&#x20;
* Reason for the change&#x20;
* Impact assessment (technical and operational)&#x20;
* Proposed timeline for implementation&#x20;

The requester must also:&#x20;

* Select the repository where the change is suggested&#x20;
* Identify the affected module(s)&#x20;

The DCI Standards Development Team validates the request, adds assessment details, and confirms the proposed timeline.&#x20;

<figure><img src="https://646606628-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF9fu0tIY1rJUsF03WdAv%2Fuploads%2FtCOFIusM79x6qn8RcsPv%2FScreenshot%202026-01-19%20at%201.42.06%E2%80%AFPM.png?alt=media&#x26;token=dcecca5c-090e-48eb-ab5e-d1f4cc72fbbe" alt=""><figcaption></figcaption></figure>

#### Review Process&#x20;

| Change Type                                            | Reviewed by                    | Approval Required from           | Notes                                                    |
| ------------------------------------------------------ | ------------------------------ | -------------------------------- | -------------------------------------------------------- |
| Bug Fix                                                | DCI Repository Management Team | DCI Standards Development Team   | No impact on schema/API functionality                    |
| Minor Non-Altering Change (e.g., documentation update) | DCI Repository Management Team | DCI Standards Development Team   | Must not affect interoperability                         |
| Enhancement / Feature Addition                         | DCI Standards Development Team | Relevant Module Committee        | New fields, new endpoints, or module-specific extensions |
| Breaking Change (affecting compatibility)              | DCI Standards Development Team | Relevant Module Committee        | Requires migration/transition plan                       |
| Core Change (affecting all modules)                    | DCI Standards Development Team | Special Committee (multi-sector) |                                                          |

Key Rules:&#x20;

* Bug fixes and minor changes → DCI standards development team approves and implements directly.&#x20;
* Module-specific changes → Reviewed by Module Committee before implementation.&#x20;
* Core-wide changes → Convene special multi-sector committee for approval.&#x20;

#### Implementation&#x20;

* Bug Fixes / Minor Changes – Implemented directly by the DCI Repository Management Team.&#x20;
* All Other Changes – Implemented after committee approval. &#x20;

For non-trivial changes, the DCI Standards Development Team prepares an implementation plan, including:&#x20;

* Risk mitigation strategies&#x20;
* Testing and validation approach&#x20;
* Migration/deprecation considerations&#x20;
* Communication plan for stakeholders&#x20;

<figure><img src="https://646606628-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF9fu0tIY1rJUsF03WdAv%2Fuploads%2F6jUTIuUfKV6ln0cQUBpn%2FScreenshot%202026-01-19%20at%201.43.30%E2%80%AFPM.png?alt=media&#x26;token=2467a71d-07b2-477c-ac68-0382c8bcd70c" alt=""><figcaption></figcaption></figure>

#### Standard Revision Categories&#x20;

Standards revisions are categorized by impact:&#x20;

| Category | Description                                            | Process                                                                         |
| -------- | ------------------------------------------------------ | ------------------------------------------------------------------------------- |
| Patch    | Minor technical modifications or clarifications        | Reviewed and approved by DCI Standards Development Team                         |
| Minor    | Small enhancements or updates (e.g., new endpoint)     | Requires DCI Standards Development Team +Steering Committee review and approval |
| Major    | Changes affecting core functionalities or data objects | Requires DCI Standards Development Team + Steering Committee approval           |

#### Versioning&#x20;

Objective: Maintain accurate history and traceability of changes.&#x20;

Semantic Versioning:&#x20;

* Major Update: X+1.0.0 → Significant changes &#x20;
* Minor Update: X.Y+1.Z → Small improvements &#x20;
* Patch Update: X.Y.Z+1 → Bug fixes or clarifications; documented for transparency&#x20;

Action Steps:&#x20;

* Use GitHub for version control&#x20;
* Tag each revision with version number, date, and summary&#x20;
* Maintain records of approvals, meeting minutes, and forms&#x20;

#### Compatibility Management Process&#x20;

This process applies when a proposed or implemented change to the DCI standards creates a compatibility issue that affects interoperability across systems or country's implementations. (i.e. change of type of a field, removing of a field ... )&#x20;

Process:&#x20;

1- Detection&#x20;

* Compatibility issues may be identified during:&#x20;
  * Technical review of proposed changes in the SPDCI tracker.&#x20;
  * Regression and interoperability testing conducted by the DCI Repository Management Team.&#x20;
  * Feedback from country implementers, partners, or other stakeholders after deployment.&#x20;

2- Assessment&#x20;

* The DCI Repository Management Team evaluates the issue to determine:&#x20;
  * Which module(s) or APIs are affected.&#x20;
  * Whether the issue is minor (limited operational impact with workarounds possible) or major (interoperability breakage with no feasible workarounds).&#x20;

3- Escalation&#x20;

* Minor issues (e.g., patch-level fixes) are resolved directly by the DCI Standards Development Team.&#x20;
* Major issues are escalated to the relevant Module Committee for review and resolution. &#x20;
* If the issue impacts the DCI core standards (cross-cutting and affecting all modules), a Special Committee with members from multiple sectors is convened to ensure broad consensus.&#x20;

4- Resolution Planning&#x20;

* The responsible body (DCI Standards Development Team, relevant Committee) develops a resolution plan, which may include:&#x20;
  * Issuing a corrective patch or hotfix.&#x20;
  * Providing dual-version support &#x20;

5- Implementation&#x20;

* Once approved, the DCI Repository Management Team applies the fix in the Git repository.&#x20;
* Testing and validation are conducted to confirm that the resolution restores interoperability without introducing new issues.&#x20;

6- Communication & Documentation&#x20;

* All compatibility issues and resolutions are logged in the Git-based Change Log and reflected in GitBook.&#x20;
* Stakeholders (e.g., country implementers, development partners) are notified of the issue, the resolution, and any required actions.&#x20;

&#x20;