1. Purpose & Scope
The Change Management & Versioning Process governs how the CIAO Standard, its derived frameworks, and its supporting governance documents change over time. It defines what counts as a change, who proposes and reviews changes, how changes are scheduled, how versions are numbered and announced, and what commitments members and implementers can rely on between releases.
This Process applies to every document published under the CIAO Standard parent reference C-AO/STD/001:2026 and to every artefact derived from it across the nine CAO content domains and the three Aggregate Frameworks (OPF, ECF, IDF). It also applies to the Standard’s source mapping register and to the Standard’s published governance instruments (Governance Charter, Code of Practice, Membership Guidelines, Partnership Guidelines, Practitioners Guidelines, Panel Advisor Guidelines, Multitier Licensing, Usage Terms, Volunteer Contribution & Compensation Disclosure).
The Process does not apply to the operational website infrastructure (theme, plugins, CDN, search), to commercial collateral published outside the document registry, or to internal Secretariat working materials that are not published under a C-AO/... reference. Those are governed separately by site operations protocols.
2. Principles
The Process is bound by five principles, in declared priority order.
Stability of meaning. A document’s substantive normative content does not change between major releases except through this Process. Members and implementers can rely on a published document’s normative requirements remaining in force for the duration of its release window.
Traceable lineage. Every change leaves a trail. Every published document carries a version number, an issued date, a review date, an approver attribution, and a version history that records what changed, when, and by whom. The complete change set that produced a given release is reconstructable from the registry.
Public transparency. Changes are published before they bind. The Release Calendar is published. The change pipeline is visible. Members are notified of upcoming changes that materially affect their implementation, with adequate lead time to adapt.
Volunteer governance integrity. Changes are reviewed by volunteer experts under the conflict-of-interest recusal protocol. Commercial pressure does not override editorial process. The Editorial Submission Framework channels practitioner contribution into the Process; commercial partners do not have privileged change rights.
Backward compatibility by default. Changes are designed to extend rather than break. Where a breaking change is necessary, it is announced in advance, accompanied by migration guidance, and held to a major release boundary.
3. Change Categories
Every proposed change is classified into one of four categories. The category determines the review pathway, the release window, and the notification commitments owed to members.
Editorial. Cosmetic or presentational changes that do not affect normative meaning: typography, formatting, broken-link repair, structural reordering of equivalent content, accessibility fixes, translation corrections that preserve meaning, and chip-discipline application as set out below. Editorial changes may be made at any time without member notification, and are recorded in the document’s version history under a minor patch increment.
Chip-discipline application. Every clause-bearing bullet, paragraph, or normative statement in CIAO content carries a machine-readable scope declaration via the shortcode pattern. The shortcode names the source standard (using the standard’s short code as listed in the Canonical Source Standards Register), the clause or article reference, the relationship type (satisfies, partially satisfies with stated gap, or informs), and any additional qualifiers. The shortcode sits inline next to the prose reference and produces a coloured visible chip plus an internal scope marker the rendering engine reads.
Chip discipline is bound by four rules. First, a normative reference to a registered source standard requires a chip; bare-prose references without a chip are treated as undeclared scope and are not filterable by member portfolio. Second, a bullet referencing multiple registered standards carries one chip per standard, each chip naming its specific clause and relationship type. Third, a bullet without any source-standard reference (tier-bound but standard-agnostic prose) carries no chips and is always-visible to all portfolio configurations. Fourth, a bullet may not reference a source standard not in the Register; proposals to introduce such a reference are handled as Register Addition Requests per Section 5.
Chip-discipline application is classified as Editorial when applied to existing prose without changing normative meaning (retrofitting chips on a document compiled before chip discipline existed). It is classified as Material when the chip pattern reveals a previously-undeclared mapping the author wishes to make explicit, because the act of declaring scope is itself a substantive normative act.
Functional. Operational changes to the Standard’s surfaces and tooling — mapping table re-renders, source standards register additions, document control header refinements, navigation hygiene, footer template changes, dynamic-selection behaviour adjustments — that do not change the normative content of any policy, framework, manual, process, procedure, or sub-artefact. Functional changes are made at any time, are recorded in version history, and are member-notified through the Release Calendar feed.
Material. Substantive changes to the normative content of one or more documents within an existing scope: clause additions, clause modifications, mapping additions or refinements, control framework refinements, sub-policy expansion within an existing CAO domain. Material changes go through the full review pathway and are released at scheduled minor or major release windows. Members affected by a material change in their selected source-standards portfolio are notified in advance.
Structural. Changes to the Standard’s architecture itself: addition or retirement of a CAO domain, restructuring of the tier model, change to the numbering grammar, change to the Aggregate Framework triad, change to the source standards register’s mapping-type vocabulary, change to the Constitution. Structural changes are reserved for major releases and require Panel review, Oversight Board approval (once seated), and a public consultation window of at least sixty days before binding.
A single proposal may carry changes of multiple categories. Each category in the proposal is reviewed and released independently under its appropriate pathway, even if the proposal is presented as a single bundle.
4. Cadence & Release Calendar
The CIAO Standard is released on a three-tier cadence.
Major releases occur every three years. Each major release may carry structural changes. The first major release of the published Standard is v1.0, issued 1 January 2026. The next major release is therefore scheduled for v2.0, 1 January 2029. Major release windows accept structural and material changes and act as the boundary at which breaking changes (if any) take effect. The fixed three-yearly cadence aligns with ISO management system Standard review cadences and gives implementers a predictable horizon for re-certification, re-mapping, and re-training planning.
Minor releases occur as needed within a major release window, typically two to four times per year. Minor releases carry material changes that extend rather than break, plus accumulated functional changes. Minor versions increment the second digit: v1.0 → v1.1 → v1.2. The first scheduled minor release within v1.x is announced through the Release Calendar with at least thirty days advance notice. Members affected by material content changes receive direct notification at the same time.
Editorial patches are made continuously and do not require advance notice. They increment the third digit (v1.0.1, v1.0.2) and are visible in the document’s version history but do not trigger member notification.
The Release Calendar is a single canonical page listing the next scheduled minor release date, the major release horizon, and the cumulative change pipeline by category. It is updated at every release event and at any change to the schedule.
5. Triggers
A change is triggered through one of five named pathways. Only changes triggered through a recognised pathway enter the workflow.
Practitioner pipeline. Any paid-tier member submits an implementation note, gap finding, proposed clarification, emerging-practice observation, industry-vertical nuance, or anonymised case snippet through the structured submission form gated by their tier. The submission is timestamped, attributed to the contributing tier (with optional individual attribution per the contributor’s election), and entered into the triage queue. The Practitioner pipeline is the priority-one source of change input for the Standard.
Panel-initiated proposal. Any seated Panel Advisor proposes a change within their declared domain or in coordination with another Advisor whose domain is also affected. Panel-initiated proposals enter the workflow at the review stage, bypassing triage.
Secretariat-initiated proposal. The Secretariat, through its routing function, may initiate a proposal in response to a regulatory development, a source-standard update, a recurring Practitioner pipeline theme, or a coordination need across regions. Secretariat-initiated proposals enter triage.
Errata. Any reader (member, implementer, or external observer) may report an error — broken cross-reference, factual inaccuracy in a mapping clause citation, a typographical fault that changes meaning, a stale source-standard reference. Errata enter a separate fast-path workflow described in Section 10.
Source-standard re-issue. When a referenced source standard in the Canonical Source Standards Register is itself revised by its issuing body (a new ISO version, a regulatory amendment, a NIST CSF update), a Secretariat-initiated proposal is automatically created to assess the impact on every CIAO mapping that references the affected standard.
Register Addition Request. A submission proposing CIAO content amendment that engages a source standard not yet in the Canonical Source Standards Register is reclassified by triage as a Register Addition Request. The substantive amendment is held; the addition is processed under three sequential steps: (a) the patented multi-framework mapping methodology is applied to the candidate standard, producing its normalized cross-mapping with the entire existing CIAO content; (b) the new entry is added to the Register at the next scheduled release event; (c) existing CIAO documents are progressively re-rendered to incorporate the new mappings across one or more subsequent minor releases. The Register’s expansion is eventually-consistent: no individual submitter has standing to compel an immediate major release, and the back-mapping of existing CIAO content to a new Register entry proceeds under the established release cadence rather than as a single-event Material change. Once the new entry is in the Register, the submitter’s original substantive amendment is reconsidered under the standard workflow with the new standard now eligible as a normative reference.
6. Workflow
Every triggered change moves through six stages.
Stage 1 — Submission. The proposal enters the system through one of the five trigger pathways. It is logged with a unique submission ID, the trigger source, the proposer’s identity (or contributing tier for practitioner submissions), the affected document(s), and a free-text description of the proposed change.
Stage 2 — Triage. The Secretariat reviews the submission and classifies it: change category (Editorial / Functional / Material / Structural), affected CAO domain(s), affected document(s), urgency, and assigned review pathway. Triage produces a triage memo published in the change log. Submissions found out of scope are returned to the proposer with a written explanation; the proposer may revise and resubmit.
Stage 2.5 — Register-scope check. Every submission proceeds through a Register-scope check before review. The check verifies that all source standards engaged by the submission are present in the Canonical Source Standards Register. Submissions that engage only registered standards proceed to Stage 3 Review under their assigned category. Submissions that engage one or more unregistered standards are reclassified as Register Addition Requests per Section 5: the Register-addition workflow is initiated as the primary process, and the original substantive amendment is held pending completion of the addition. The Register-scope check is automated where the submission form’s affected-source-standards selector is bound to the Register; manual triage handles cases where unregistered references appear in submission prose despite form-level constraints.
Stage 3 — Review. Material and Structural proposals are referred to the Panel Advisor(s) whose declared domain(s) the proposal affects. The reviewing Advisor(s) produce a written review memo within thirty days that recommends accept, accept-with-modifications, defer, or reject. Functional proposals are reviewed by the Secretariat editorial function. Editorial proposals skip review and proceed to Stage 5.
Stage 4 — Editorial. Accepted proposals enter editorial drafting. The change is rendered into the affected document(s) under stealth and licensing conventions. Cross-references, mapping table entries, footer metadata, document control headers, and version history entries are all updated as part of the editorial pass. Before publication, the editorial draft passes through the quality gates defined in the Document Quality Control instrument — metadata completeness, version history discipline, supersedes-chain maintenance, MVE freshness, chip-discipline conformance, and cross-reference integrity. A draft that fails any gate returns to drafting for resolution. The editorial draft is held in a staging state until the release event.
Stage 5 — Publication. At the scheduled release event (minor or major release date), or immediately for editorial patches, the editorial draft replaces the live document(s). The new version is recorded in the document control header, the version history, and the registry. A change announcement is published.
Stage 6 — Notification. Members affected by material or structural changes — affected here meaning the change touches a document or mapping in the member’s selected source-standards portfolio or active tier scope — receive direct notification. The Practitioner pipeline contributor receives notification of the publication of any change incorporating their submission. The change is reflected in the Release Calendar’s change log.
A change is closed when Stage 6 completes. The full audit trail (submission, triage memo, review memo, editorial draft, publication record, notification confirmations) is preserved indefinitely and is referenceable by the submission ID.
7. Roles & Responsibilities
The Process distributes responsibility across seven role classes.
Secretariat. Process authority. Operates triage, manages the Release Calendar, runs the editorial function, executes publication, and dispatches notifications. The Secretariat does not author normative content; it manages the flow of normative content through the workflow. Secretariat decisions on scope and triage are appealable to the Panel.
Panel Advisors. Normative review authority within declared domain(s). Produce review memos on Material and Structural proposals affecting their domain. Apply per-seat conflict-of-interest recusal as required by the Governance Charter.
Oversight Board (once formally seated). Approval authority on Structural changes. Final authority on appeals from Secretariat triage decisions. Custodian of the Constitution and of the integrity of this Process itself.
Editorial function. Drafts the publishable form of accepted changes. Sits within the Secretariat. Does not exercise normative authority; renders Panel-approved normative content into publication-ready form.
Practitioner contributors. Paid-tier members who submit through the Editorial Submission Framework. The turbine of the virtuous cycle. Receive contribution attribution at tier-level by default and individual-level by election.
Members. Recipients of notifications. Holders of the right to expect stability of meaning between releases and adequate lead time on material change.
Regional Partners. Channel for member feedback and for regional-implementation insight that may inform Secretariat-initiated proposals. Do not have privileged change rights.
8. Versioning Convention
The CIAO Standard uses a three-segment semantic version: MAJOR.MINOR.PATCH.
MAJOR increments at the three-yearly major release boundary, when structural changes take effect or when accumulated material changes exceed what minor releases can absorb without a coherence break. Major increments reset MINOR and PATCH to zero.
MINOR increments at scheduled minor releases within a major window. Minor increments reset PATCH to zero. The Release Calendar lists the upcoming MINOR increment date and pipeline.
PATCH increments at editorial patch publication. Patches are continuous; the Release Calendar does not announce them in advance.
Each document under the Standard carries its own version that follows this convention, but document versions are never lower than the parent Standard’s version. When the Standard moves from v1.0 to v1.1, every document in the registry advances to at least v1.1 even if its substantive content is unchanged; the version history line for the unchanged document records “no substantive change at this release.”
9. Backward-Compatibility Commitments
Within a major release window, the CIAO Standard commits that the normative requirements in any document do not become more restrictive in a way that requires already-compliant implementations to add new controls or evidence. (Clarifications that make existing scope clearer are not “more restrictive” for this purpose.)
Source-standard mappings do not become weaker in a way that lets a previously-satisfying CIAO control no longer satisfy its mapped source clause. Where the underlying source standard itself has changed, the impact is published as a source-standard re-issue trigger and is handled at the next minor release with full notification.
Document references (C-AO/...:YYYY) do not change for the duration of a major release window. A document does not move between domains, types, or tier ladders within a major release. Where a structural reorganisation is necessary, it is reserved for the major release boundary.
Tier scope does not contract — a tier never loses content within a major release window. Tier scope may expand when a release adds material at the existing tier.
Across a major release boundary, breaking changes are permitted but are individually justified, individually announced at least sixty days before binding, and individually accompanied by migration guidance for affected implementations.
Register expansion is additive. The addition of a new entry to the Canonical Source Standards Register is always backward-compatible: a member’s existing mappings against previously-registered standards are not affected by the addition of a further standard. The new standard’s coverage of existing CIAO content is back-rendered progressively across subsequent minor releases under the eventually-consistent expansion model set out in the Register’s own maintenance section. Members are notified of new Register entries through the Release Calendar and through direct notification where the new standard materially affects the member’s selected portfolio scope.
10. Errata Process
Errata follow a fast-path separate from the main workflow. Reported errata are reviewed within seven days. Errata that are confirmed (the report is correct: there is an error in the published material) are corrected within fourteen days as an editorial patch. The version history records the patch with a brief erratum note.
Errata that affect the normative meaning of a clause (e.g., a wrong source-standard clause reference that misrepresents what the CIAO control satisfies) are not handled as errata patches. They are escalated into a Material change proposal under the standard workflow, because their resolution may require Panel review and may bind member-facing notification commitments.
The Secretariat publishes a quarterly Errata Summary listing all confirmed errata patches in the preceding quarter. The summary is part of the change log and is linked from the Release Calendar.
11. Hooks
This Process integrates with two other administrative instruments and with the Constitution.
The Editorial Submission Framework is the input plumbing. The Practitioner pipeline form, its tier-gating, its routing into the triage queue, and its attribution mechanics live there. This Process owns the workflow once the submission has entered triage.
The Document Quality Control instrument is the quality plumbing. It defines the pre-publication gates this Process invokes at Stage 4 (Editorial), and the post-publication rendering — including the document control header, the three document-footer sections (Version History, Linked Documents, References) — that surfaces the document’s control state to readers. Document Quality Control sources its rendered data from the document control header metadata maintained by this Process.
Constitution. Sections 4, 6, 7, 8, and 9 of this Process — categories, workflow, roles, versioning, backward-compatibility — require Constitutional codification once the Constitution is ratified. Until ratification, this Process operates under the transitional provisions of Section 12.
12. Transitional Provisions
The CIAO Standard is currently operating in its founding period. The Constitution is not yet ratified. The Oversight Board is not yet seated. The Panel of Advisors is partially seated. Until those bodies are fully operational, the following transitional provisions apply.
The Founding Secretariat holds full Process authority for triage, editorial, publication, and notification.
Panel review is exercised by seated Advisors within their declared domains. Where a proposal affects a domain whose Panel seat is not yet filled, the Founding Secretariat may either route the proposal to the closest-domain seated Advisor with a written rationale or hold the proposal in the queue pending seating.
Oversight Board approval on Structural changes is held by the Founding Secretariat with the requirement that any such change is published with an explicit “founding-period structural change” note and is subject to ratification by the Oversight Board within ninety days of seating.
The first Constitution-ratifying body is the Oversight Board on its formal seating. This Section 12 itself sunsets when the Constitution is ratified.
Part of the CIAO Standard administrative instruments — see Standard Administration for the canonical index of operational policies and processes.
Part of the CIAO Standard architecture — see Standard Architecture & Tier Content Depth for the canonical domain spine and tier-by-tier content ladder.