MinistryCentral Europe
This document defines how changes to approved and canonical content are proposed, reviewed, approved, and applied within MinistryCentral Europe.
It exists to protect:
- Canonical integrity
- Editorial trust
- System stability
- Contributors and editors from unintended authority violations
It applies after content has reached Approved or Canonical status, as defined in the
→ Status Lifecycle & Canonical Rules (link)
1. Core Principle
Once content is canonical, change is intentional — never silent.
Any modification to canonical content must be:
- Visible
- Traceable
- Authorized
- Reversible
2. What Counts as a “Change”
A change is any modification that alters one or more of the following:
- Meaning
- Scope
- Instruction
- Interpretation
- Structure
- Applicability
- Enforcement expectations
This includes:
- Text edits
- Rewording
- Additions or deletions
- Reorganization
- Embedded media changes
- Linked reference changes
3. Changes That Do Not Require Review (Very Limited)
Only the following may be made without reopening review:
- Spelling corrections
- Grammar corrections
- Formatting consistency (headings, lists)
- Broken link fixes
- Image alt-text corrections
Conditions:
- Meaning must remain unchanged
- No new information introduced
- Editor must be confident the change is non-substantive
If there is any doubt, the change must be reviewed.
When in doubt, treat it as substantive.
4. Change Categories
A. Non-Substantive Changes
(Low risk)
Examples:
- Typographical errors
- Formatting cleanup
Process:
- Editor applies change
- No lifecycle reset required
- Change may be logged informally
B. Substantive Changes
(Medium to high risk)
Examples:
- Clarifying a rule
- Updating a process
- Adjusting wording with interpretive impact
- Adding or removing guidance
Process:
- Content re-enters Review
- Changes are discussed or documented
- Approval is re-obtained
- Updated content replaces canonical version
C. Structural or Policy Changes
(High risk)
Examples:
- Governance updates
- Authority changes
- Workflow redesign
- Platform-wide implications
Process:
- Formal review initiated
- Explicit approval by system-level authority
- Version supersession documented
- Prior version archived
5. Lifecycle Interaction
When a substantive or structural change is proposed:
- Canonical content temporarily loses canonical status
- Status reverts to Review
- Publication in Echo KB is updated only after re-approval
This ensures:
- No “invisible drift”
- No partial authority
- No parallel truths
6. Where Changes Are Made
Working Location
- Notion (preferred)
- Or documented review environment
Canonical Location
- Echo Knowledge Base
Rules:
- Drafting and discussion occur outside Echo KB
- Echo KB is updated only after approval
- Direct editing in Echo KB without authorization is prohibited
7. Versioning & Supersession
When content is updated:
- The new version becomes canonical
- The prior version is:
- Archived, or
- Explicitly superseded
Best practice:
- Add a short “Last updated” note
- Reference what changed when meaningful
8. Role Responsibilities
Contributors
- May suggest changes
- Do not apply changes to canonical content
Editors
- Evaluate whether a change is substantive
- Enforce review rules
- Protect meaning and clarity
Coordinators / Leads
- Validate alignment and intent
- Confirm approvals when required
Platform / Technical Roles
- Ensure system integrity
- Do not change meaning independently
9. Prohibited Practices
The following are not allowed:
- Silent edits to canonical content
- “Quick fixes” without review
- Parallel versions in multiple tools
- Untracked policy changes
- Treating publication as approval
These practices undermine trust and consistency.
10. Relationship to Other Documents
This document works together with:
- Canonical Authority Model – defines who may approve changes
- Status Lifecycle & Canonical Rules – defines when content is canonical
- Documentation Workflow – defines how changes move operationally
- Operations Guide – provides overall system context
In case of conflict, authority and lifecycle rules take precedence.
11. Summary
- Canonical content is stable by design
- Change is allowed — but controlled
- Approval is explicit
- Echo KB reflects the current truth
- Prior truth is preserved, not erased
Change is a feature. Drift is a failure.