Content governance model
Purpose: Define who may change what — content, templates, policies, taxonomy — and how those rules are enforced in the platform.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Tech leads | Model designers |
| All engineers | Where the guardrails come from |
The layers of "content change"
| Layer | Examples | Change agent | Enforcement |
|---|---|---|---|
| Page content | PHI plan copy, images | Authors | ACLs + workflows |
| Publication | Going live | Reviewers/approvers | Replicate permission + approval workflow (Lab 9) |
| Structure | New sections, page moves | Senior authors/content ops | ACLs on parent nodes |
| Templates & policies | New template, allowed components | Template authors (small group) | /conf ACLs + promotion process |
| Models & taxonomy | CF models, tag namespaces | Governance board cadence | /conf + /content/cq:tags ACLs |
| Code | Components | Engineering | Pipeline only |
The platform expresses governance as groups + ACLs + workflows (users & groups); if a rule exists only in a Confluence page, it does not exist.
A workable default model
- Per-site author/reviewer/admin groups; publication of regulated content (like PHI plan terms) always via approval workflow.
- Template/policy changes: made on stage by the template-author group, reviewed, promoted to prod via package by engineering — runtime template editing on prod restricted to break-glass.
- Taxonomy and CF model changes batched through a fortnightly review (they are schema changes).
- Quarterly access review: dump group memberships, business owners confirm (audit & compliance).
Signals the model is failing
Everyone is in the admin group "temporarily"; workflows bypassed via direct replication rights; template drift between stage and prod; orphan tags multiplying. Each has a page in this wiki — none fix themselves.