MinistryCentral Europe
This document defines how content moves from idea to approved, canonical documentation within MinistryCentral Europe, and how authority, visibility, and change control are applied at each stage.
It operationalizes the principles established in the Canonical Authority Model and governs when content becomes official, enforceable, and referenceable.
1. Purpose of This Document
This document exists to:
- Define clear content states (lifecycle stages)
- Prevent ambiguity about what is “official”
- Eliminate silent or accidental changes
- Establish canonical precedence across tools
- Protect contributors, editors, and administrators alike
It answers the question:
“What is the current status of this content, and what does that status allow?”
2. Canonical Principle (Summary)
Content becomes canonical through approval — not through creation, editing, or publication alone.
Canonical status is determined by:
- Role-based authority
- Explicit approval
- Placement in the canonical residence
For details on authority assignment, see:
→ Canonical Authority Model (link)
3. Content Lifecycle Stages
Every piece of documentation follows the lifecycle below.
Stage 1 — Draft
Purpose: Ideation, exploration, early development
Characteristics:
- May exist in Notion, Word, or other working formats
- Incomplete, experimental, or provisional
- No enforcement power
- May change freely
Rules:
- Draft content is not authoritative
- Drafts must be clearly labeled as such
- Drafts may not be cited as official guidance
Typical Owners:
Contributors, Editors, Coordinators
Stage 2 — Review
Purpose: Structured evaluation and refinement
Characteristics:
- Content is substantially complete
- Under editorial, theological, or operational review
- Feedback and revisions are expected
Rules:
- Changes should be tracked or discussed
- Review comments must not be silently applied post-approval
- Still not canonical
Typical Owners:
Editors, Coordinators, Subject Authorities
Stage 3 — Approved
Purpose: Formal authorization
Characteristics:
- Explicit approval by a role with canonical authority
- Approval may be recorded via:
- Notion status
- Written confirmation
- Governance log
- Content meaning is now frozen
Rules:
- No material changes without reopening review
- Approved content is eligible for canonical residence
- Approval ≠ publication
Typical Owners:
Designated Authority Roles
Stage 4 — Canonical (Published)
Purpose: Official reference and enforcement
Characteristics:
- Content is published in the Echo Knowledge Base at
- This is the primary canonical residence
- Content is considered stable and authoritative
Rules:
- Echo KB takes precedence over all other locations
- If discrepancies exist:
- Echo KB > Notion > Other copies
- Canonical content may be referenced publicly
Typical Owners:
Editors (publication), Platform Admins (system integrity)
Stage 5 — Deprecated / Archived
Purpose: Controlled retirement
Characteristics:
- Content is no longer current
- Retained for historical or audit reasons
- Clearly marked as deprecated
Rules:
- Deprecated content must not be edited
- Replacement or superseding content should be linked
- Archived content is not authoritative
4. Canonical Residence Rules
Canonical authority is location-aware but not tool-created.
Order of Canonical Residence
- Echo Knowledge Base
Primary, authoritative reference location
- Notion
Editorial and working environment
- Other formats (Word, PDF, exports)
Derivative or transitional only
Publication in Echo KB does not create authority, but it does establish canonical precedence once approval has been granted.
5. Change Management Rules (Summary)
Once content is canonical:
- ❌ No silent edits
- ❌ No “small tweaks” without review
- ❌ No direct changes in Echo KB without authorization
Instead:
- Changes must re-enter the lifecycle at Review
- Superseding versions must be approved
- Previous versions may be archived
Full details are defined in:
→ Change Management Rules (link)
6. What Different Roles Need to Know
Contributors
- You work primarily in Draft
- You do not create canonical content
Editors
- You shepherd content through Review and Publication
- You protect meaning and consistency
Coordinators / Leads
- You initiate and validate approvals
- You ensure alignment with strategy and theology
Platform / Admin Roles
- You protect canonical residence and system integrity
- You do not change meaning without approval
7. Relationship to Other Governance Documents
This document works in concert with:
- Canonical Authority Model – defines who may approve
- Change Management Rules – defines how canonical changes occur
- Documentation Workflow – defines where work happens
- Content, Platform & Documentation Operations Guide – defines the full operating context
8. Summary
- Authority comes from approval, not tools
- Canonical status is explicit, not assumed
- Echo KB is the primary reference location
- Notion is the authoritative working environment
- Clear lifecycle stages protect everyone involved
When in doubt: check the status first.