# 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:
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
Revisions to the standards can be initiated in two ways:
* Triggered Reviews – Requests submitted via the SPDCI Git repository tracker.
* Scheduled Reviews – Annual review cycle conducted by the DCI Standards Development Team to assess adoption and identify needed updates.
#### Submission & Documentation
All change requests are submitted via the SPDCI Git repository tracker using the Proposed Change Documentation (PCD) template, which must include:
* Requester details
* Description of the change
* Reason for the change
* Impact assessment (technical and operational)
* Proposed timeline for implementation
The requester must also:
* Select the repository where the change is suggested
* Identify the affected module(s)
The DCI Standards Development Team validates the request, adds assessment details, and confirms the proposed timeline.
#### Review Process
| 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:
* Bug fixes and minor changes → DCI standards development team approves and implements directly.
* Module-specific changes → Reviewed by Module Committee before implementation.
* Core-wide changes → Convene special multi-sector committee for approval.
#### Implementation
* Bug Fixes / Minor Changes – Implemented directly by the DCI Repository Management Team.
* All Other Changes – Implemented after committee approval.
For non-trivial changes, the DCI Standards Development Team prepares an implementation plan, including:
* Risk mitigation strategies
* Testing and validation approach
* Migration/deprecation considerations
* Communication plan for stakeholders
#### Standard Revision Categories
Standards revisions are categorized by impact:
| 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
Objective: Maintain accurate history and traceability of changes.
Semantic Versioning:
* Major Update: X+1.0.0 → Significant changes
* Minor Update: X.Y+1.Z → Small improvements
* Patch Update: X.Y.Z+1 → Bug fixes or clarifications; documented for transparency
Action Steps:
* Use GitHub for version control
* Tag each revision with version number, date, and summary
* Maintain records of approvals, meeting minutes, and forms
#### Compatibility Management Process
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 ... )
Process:
1- Detection
* Compatibility issues may be identified during:
* Technical review of proposed changes in the SPDCI tracker.
* Regression and interoperability testing conducted by the DCI Repository Management Team.
* Feedback from country implementers, partners, or other stakeholders after deployment.
2- Assessment
* The DCI Repository Management Team evaluates the issue to determine:
* Which module(s) or APIs are affected.
* Whether the issue is minor (limited operational impact with workarounds possible) or major (interoperability breakage with no feasible workarounds).
3- Escalation
* Minor issues (e.g., patch-level fixes) are resolved directly by the DCI Standards Development Team.
* Major issues are escalated to the relevant Module Committee for review and resolution.
* 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.
4- Resolution Planning
* The responsible body (DCI Standards Development Team, relevant Committee) develops a resolution plan, which may include:
* Issuing a corrective patch or hotfix.
* Providing dual-version support
5- Implementation
* Once approved, the DCI Repository Management Team applies the fix in the Git repository.
* Testing and validation are conducted to confirm that the resolution restores interoperability without introducing new issues.
6- Communication & Documentation
* All compatibility issues and resolutions are logged in the Git-based Change Log and reflected in GitBook.
* Stakeholders (e.g., country implementers, development partners) are notified of the issue, the resolution, and any required actions.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://standards.spdci.org/standards/dci/revision-management.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.