content-governance-system

Content governance system

Give content owners a manageable way to keep enablement material accurate, approved, and easy to find.

Fails. "Classify all 400 assets, stand up a content council, and review everything quarterly."

Passes. "Each Wednesday: owners clear due and overdue reviews, intake picks one request, publishers ship only approved versions. Live assets stay published while overdue for review. Urgent launch changes use a 48-hour exception with a named follow-up owner."

A one-time coverage audit and backlog is content-gap-analysis.

Inputs

Reuse supplied context first. If a missing company fact would change the result, check the relevant sections of .enablement/context.md when available. Preserve source dates and approval limits.

Ask only for the inputs that change the operating model:

1. Repositories and content types in scope
2. Who already owns accuracy, claim approval, and the right to publish
3. Current pain: sprawl, stale claims, unclear source of truth, or blocked launches
4. Who will own recurring review and publishing work, and how much time they have

If ownership or system-write authority is unknown, leave it unknown. Do not invent usage.

Supporting material

Read references/governance-model-template.md for publication and review states, approval boundaries, and a sustainable operating cadence. Read references/source-system-guide.md when the rules must map into publishing systems the team already uses.

Procedure

1. Set a workable review rhythm. Name the owner, decisions, time budget, and events that require attention. Use an existing cadence where it works. A small team may review asynchronously; proposed dates and service levels need owner confirmation.
2. Set decision rights. Content approval, publish authorization, and system write are three different rights. A claim owner may approve wording and still lack permission to publish.
3. Keep two independent axes. Publication: draft, in_review, approved, published, retired. Review: current, due, overdue, blocked. A live asset stays published while due or overdue. Review status must not hide it from published denominators.
4. Trigger review from risk, not a universal calendar. Legal, security, pricing, and product claims need review when their source changes or validity ends. If a published asset contains a known harmful or unauthorised claim, propose a targeted withdrawal or correction to its authorised owner; an overdue date alone does not justify retirement.
5. Define intake that matches capacity. One prioritization path for new requests. No shadow queues. Urgent work uses a time-boxed exception that cannot skip legal or security approval.
6. Name the quality checks that can fail a publish. Message accuracy, proof, audience, compliance. Cosmetic checks that nobody enforces do not go in the model.
7. Separate canonical source from distribution copies. One content ID and version. Changes happen in the canonical source, then propagate. Do not create a second source of truth to "make it easier to find."
8. Scale to the team you have. Unused councils, unused gates, and unused metadata fields are failed governance. Measure current-content rate, orphan rate, and review completion — not a usage number you do not have.