Help Center
< All Topics
Print
Posted
Updated
Byadmin

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:

  1. Content re-enters Review
  2. Changes are discussed or documented
  3. Approval is re-obtained
  4. Updated content replaces canonical version

C. Structural or Policy Changes

(High risk)

Examples:

  • Governance updates
  • Authority changes
  • Workflow redesign
  • Platform-wide implications

Process:

  1. Formal review initiated
  2. Explicit approval by system-level authority
  3. Version supersession documented
  4. 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

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:

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.

Table of Contents
Scroll to Top