ContentOps

ContentOps (content operations) is the system that turns a content plan into content people can rely on: the workflow, roles, standards, tools and measures that take each piece from request to publication, keep it accurate while it is live, and retire it when it is no longer true or useful. Deane Barker put the boundary memorably in 2016: “Content Operations (CO) is concerned with everything between Content Strategy (CS) and Content Management (CM).”^[1]

Strategy decides what an organisation should say, to whom and why. A content management system (CMS) stores and delivers it. ContentOps is everything that has to happen in between, every day: briefs, drafting, reviews, approvals, translation, publishing to several channels, audits, corrections and retirement. When it works, a price change reaches every channel and language on the same day, every item has a named owner and a review date, and nobody copies text between systems.

Written for beginners, content practitioners, platform engineers and the leaders who fund them. Sources were last verified on 2026-10-23.

Content is cheap to publish and expensive to keep true. Organisations notice the problem late, through symptoms rather than causes:

• Contradiction. Two help articles describe the same task differently; the pricing page and the sales PDF disagree. Paul Boag’s well-known description of “ROT” (redundant, out-of-date and trivial content) lists the usual suspects: “products or services that no longer exist; campaigns that have long since ended”, phone numbers that no longer work, staff who have left.^[2]
• Nobody owns it. The person who wrote a page has moved on, and the web team that could delete it lacks the authority: in Boag’s words, digital teams “often do not own the content and so do not have the authority to remove it”.^[2]
• Copy and paste. The same paragraph lives in the website, the app, the PDF and the partner portal, so every change is four changes, and translation multiplies that by each language. Rahel Bailie’s summary of what has to change: “This copy and paste stuff has got to go.”^[3]
• Bottlenecks. Reviews wait days in someone’s inbox; launches slip because legal sees the copy on the last afternoon.
• The CMS is blamed. Barker described two recurring situations: organisations not ready to launch a new CMS because their content is a mess, and organisations not using the CMS they already have.^[1] Neither is fixed by buying another CMS.

Before ContentOps, content is a series of one-off projects. After it, content is a managed inventory whose changes flow through a known path with service levels, and the organisation can answer “how much of our content is current?” with a number.

• Not content strategy. Strategy decides goals, audiences, messages and priorities. Barker is explicit that content operations “is not digital marketing or content strategy”: it assumes the plan exists.^[1] In practice the two loop: operations data (what decays, what nobody reads) should change the strategy.
• Not the CMS. Barker again: it “is not technical content management”.^[1] Choosing and running the platform is engineering work that ContentOps depends on and specifies requirements for.
• Not “more content, faster”. Efficiency matters (Bailie calls it the point of the whole thing^[3]), but a system that publishes more while retiring nothing increases the maintenance load every month.
• Not KnowledgeOps. Both manage text with owners and expiry. This Atlas splits them by origin (an editorial distinction, made once here and linked from elsewhere): content that is planned and produced through an editorial workflow is ContentOps; knowledge captured while solving support cases or operations work (KCS articles, runbooks), even when published for customers, is KnowledgeOps. Shared rules such as owners and review dates should be identical on both sides, so readers do not notice the boundary.
• Not the neighbouring pipelines. Video and audio pipelines belong to MediaOps, search optimisation to SEO Operations, campaign process to MarketingOps, and hosting to WebOps; the relations table gives the handoff for each.
• Not DevOps for words. Docs-as-code borrows version control, review and automated tests from software,^[4] and ContentOps practitioners cite DevOps as a cousin, but content has different failure modes: a wrong sentence does not crash, it misleads quietly for years.

ContentOps has no founding manifesto. Its history is a convergence of three older threads, then a label.

1. Governance in content strategy (2008 onwards). Kristina Halvorson’s 2008 article in A List Apart described content strategy as planning “for the creation, publication, and governance of useful, usable content”, and asked who is responsible for content once it is published.^[5] Governance was already in the definition; operations is what governance looks like on a Tuesday.
2. Structured, portable content (2009). NPR’s digital team described “Create Once, Publish Everywhere (COPE)” as “one of the primary philosophies driving our systems”, with three principles: build content management tools rather than web publishing tools, separate content from display, and eliminate markup from content.^[6] This is the technical foundation of reuse.
3. Technical communication’s single-sourcing tradition. Standards such as DITA^[7] and XLIFF^[8] made reuse, conditional publishing and translation workflows routine in documentation teams long before marketing sites went headless.
4. The label (mid-2010s onwards). Barker’s 2016 post described a practice “we’re calling ‘content operations’” and listed its services, from content inventory and migration to QA, URL integrity and localisation support; he added that “in no way do we think we’re breaking any new ground”.^[1] Content Science defined content operations as “the behind-the-scenes work of managing content activities as effectively and efficiently as possible” and published a five-level maturity model.^[9][10] Rahel Bailie described ContentOps as “a set of principles” used “to optimize content production”.^[3] An abstract for one of Bailie’s tekom talks says the descriptor was in use “as far back as the early 2000s” but gained traction only after labels like DevOps spread;^[11] treat that as a practitioner’s recollection, not a history. An open-access collection, Content Operations from Start to Scale, edited by Carlos Evia, aims to explain content operations to both industry and academia; it grew out of Scriptorium’s Technical Writing 101.^[12]

The result has no standards body and no single definition. Definitions differ mainly in breadth; this page uses Barker’s broad one (everything between strategy and the CMS).

Hold three pictures. An inventory: content is a stock of items with owners, types and expiry dates, and you should be able to count it. An assembly line: each new or changed item flows through stations (brief, draft, review, approve, localise, publish) with queues, service levels and quality gates, and most delays are waiting, not working. A garden: once published, content grows stale and tangled unless someone prunes it; the pruning (audits, updates, retirement) is scheduled work, not a crisis response. Teams that see only the assembly line publish ever faster into an untended garden.

ContentOps sits in a cluster of business and product Ops. The table gives the shared scope and the editorial distinction for each.

flowchart TB
  CS["Content strategy"] --> IN["Intake and briefs"]
  IN --> PR["Produce and review"]
  PR --> PUB["Localise and publish"]
  PUB --> MT["Maintain, audit, retire"]
  MT -.->|"evidence"| CS
  MK["MarketingOps: campaigns"] --- IN
  SEO["SEO Operations: search"] --- PR
  PR <--> CMS["Platforms: CMS, DAM, TMS"]
  CMS --- WEB["WebOps: hosting"]
  MED["MediaOps: video, audio"] --- PUB
  KO["KnowledgeOps: support-born"] --- MT
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class IN,PR,PUB,MT core
  class CS,CMS,KO,MK,SEO,MED,WEB neutral

No official ContentOps manifesto exists. The charter below is this Atlas’s proposal; adapt the wording, keep the commitments measurable.

Mission. Every piece of content we publish is accurate, findable, accessible and owned, and reaches every channel and language it needs without being copied by hand. We produce it predictably and retire it deliberately.

Measurable goals. At least 95 % of live items in scope have an active owner and a review date that has not passed; median cycle time for standard items within the agreed service level; zero high-risk statements published without the named approver’s prior consent (emergency removals of wrong statements excepted, because they add no new claim); every retirement recorded with a redirect or notice.

Non-goals. Deciding brand strategy or campaign goals; running the CMS infrastructure; moderating user-generated content.

Principles, each with the trade-off it implies:

1. Model before you write. Decide content types and fields before producing at scale. Trade-off: slower first project, much cheaper fifth channel.
2. Separate content from presentation. Store meaning, not layout, as NPR put it: “Separate Content from Display” and “Eliminate markup from content”.^[6] Trade-off: authors lose some visual control; designers gain consistency.
3. One source of truth per fact. A price, a legal statement or a product name lives in one place and is referenced. Trade-off: references need a dependency view so editors see where a change lands.
4. Every item has an owner and an expiry. Ownership is a named role, not a team alias; a review date is set at publication. Trade-off: owners must be given time; unowned content must be reassigned or retired.
5. Review effort proportional to risk. Tier content by the harm a mistake can do; automate the checks a machine can do. Trade-off: someone must define and maintain the tiers.
6. Flow over heroics. Limit work in progress, make queues visible, and set service levels for reviews. Trade-off: saying “not this sprint” to requesters.
7. Retire as deliberately as you publish. In NN/g’s words, “Content won’t govern itself.”^[17] Trade-off: retirement needs authority, granted explicitly.

A working ContentOps has seven building blocks. Missing any one shows up as a predictable failure.

Small organisations combine these roles; large ones split them further. What matters is that each decision has exactly one accountable person.

RACI for the main decisions (R = responsible, A = accountable, C = consulted, I = informed):

The NN/g description of content strategy names four conceptual phases (planning, creation, maintenance and unpublishing) through which content cycles until it is removed.^[17] For operations, those phases need explicit states, because states are what a CMS can enforce and what a dashboard can count. The state machine below is this Atlas’s proposal.

stateDiagram-v2
  direction TB
  [*] --> Requested
  Requested --> Declined: not aligned or no capacity
  Requested --> Draft: brief accepted
  Draft --> InReview: submitted
  InReview --> Draft: changes requested
  InReview --> Approved: all required approvals
  Approved --> Scheduled
  Scheduled --> Live: published
  Scheduled --> Draft: launch changed
  Live --> ReviewDue: review date reached
  ReviewDue --> Live: confirmed accurate, new date
  ReviewDue --> Draft: needs update
  ReviewDue --> Withdrawn: no longer current
  Withdrawn --> Unpublished: redirect or remove
  Live --> Unpublished: duplicate or published in error
  Declined --> [*]
  Unpublished --> [*]

Two details matter more than they look. First, “review due” is a state, not a calendar reminder: if the owner does nothing, the item stays visibly overdue, which a dashboard can count and an escalation can act on. GOV.UK’s publishing tool works this way: search shows whether content is overdue for review, based on the date set at the last update.^[18] Second, withdraw and unpublish are different outcomes. GOV.UK withdraws content by keeping it at its URL with a “no longer current” banner and hiding it from site search; it unpublishes (removes, optionally with a redirect) only in limited cases such as content published in error, needs met elsewhere, personal details or copyright problems.^[16]

Governance answers four questions: who decides, by which rules, how often, and what happens when someone disagrees.

• Decision rights. Write down who can create a content type, who can publish in each risk tier, who can retire, and who can grant exceptions to the style guide. This Atlas treats the authority to retire as the first gap to close, because without it the problem Boag describes (teams that cannot remove content they do not own) persists.^[2]
• Cadences. A weekly intake and prioritisation meeting (30 minutes, ContentOps lead chairs); a daily or asynchronous review queue check; a monthly health review of freshness, ownerless items and backlog; a quarterly audit of one collection; an annual model and standards review.
• Service levels. Set them per tier: for example, editorial review in two working days, legal review for high-risk items in three, translation in five per locale. Publish them, measure them, and renegotiate rather than silently miss them.
• Exceptions: contain first, correct with consent. When wrong content is live, the emergency path separates two acts. Containment (removing the wrong statement, or replacing it with a link to an approved source) may be done at once by the on-duty editor without approval, because it adds no new claim. Correction (publishing a new tier-3 statement) always needs the risk approver’s consent before publication; in an emergency that consent may be given by phone or message, provided it is logged with the time and confirmed in the workflow afterwards. Both acts are recorded in the exception log.
• Escalation. Overdue reviews escalate to the owner’s manager after a set period; disputed retirement decisions go to a governance council (strategist, ContentOps lead, a legal representative, a product representative).

The council’s monthly decisions follow the measurement loop: evidence from the register and the workflow leads to a change of standards, capacity or ownership.

This is a logical architecture, not a product recommendation. Small teams can run all of it inside one traditional CMS; large ones split it across specialised systems. The components and their responsibilities:

flowchart TB
  REQ["Intake and briefs"] --> REPO["CMS or Git repository"]
  MODEL["Content model and schema"] --> REPO
  REPO <--> DAM["DAM: assets, rights"]
  REPO <-->|"XLIFF"| TMS["TMS: memory, terms"]
  REPO --> QC["Checks: schema, style, links, a11y"]
  QC --> API["Content API"]
  API --> WEB["Website"]
  API --> APP["Mobile app"]
  API --> OTH["Email, PDF, help"]
  WEB --> AN["Analytics and register"]
  APP --> AN
  OTH --> AN
  AN -.->|"audits, review dates"| REQ
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class REQ,REPO,MODEL,QC core
  class DAM,TMS,API,WEB,APP,OTH,AN neutral

Trust boundaries and alternatives. Three boundaries deserve explicit controls. Authoring permissions: who can publish in each tier (enforced in the CMS role model, not by convention). The translation boundary: content leaves the organisation for vendors, so send only what needs translating and never unpublished financial or personal data without a contract that covers it. The delivery API: preview and draft endpoints must not be publicly reachable, or embargoed content leaks. The alternatives (a coupled CMS, docs-as-code) are compared in the Decision framework.

The sequence below follows a typical medium-risk item (a help article for a new feature) through the happy path, with the two most common exception paths described after it.

sequenceDiagram
  autonumber
  participant OPS as Ops lead
  participant W as Writer
  participant SME as SME
  participant ED as Editor
  participant L as L10n
  Note over OPS: Request and brief from product
  OPS->>W: Assign, set tier
  Note over W: Checks: schema, style, links
  W->>SME: Accuracy review
  SME-->>W: Corrections
  W->>SME: Revised draft
  SME->>ED: Accuracy confirmed
  ED->>L: Approved source
  L-->>ED: Translations
  Note over ED,L: Published, review date set

Exception path 1: the launch moves. If the feature changes before launch, the scheduled item returns to draft and translation jobs already sent are cancelled or updated; translation memory limits the cost. The trigger is a change notice from product, so the request form should capture the launch dependency.

Exception path 2: a reviewer is the bottleneck. If the SME review breaches its service level, the ContentOps lead escalates once to the SME’s manager and, for medium-risk items, may publish with editorial approval and an “accuracy check pending” task on the owner. High-risk items never take this shortcut. The metric that exposes this path is review service-level attainment (see Metrics and KPIs).

1. Every request arrives through one form (see Templates); requests by chat or email are redirected to it.
2. The ContentOps lead checks the brief against the strategy’s priorities and the calendar, then accepts, defers or declines within two working days. A decline names the reason (no audience need, duplicate of existing item, no capacity).
3. Accepted briefs get a content type, a risk tier, an owner and a target date before any writing starts.
4. Acceptance criteria: goal and audience stated; existing content searched (a duplicate becomes an update request); owner named; risk tier set. Contingency: if a date-critical request arrives with no capacity, something else is explicitly moved, and the requester of the moved item is told.

Tiers are this Atlas’s proposal; the point is that review effort follows the harm a mistake could cause.

Rules that keep tiering honest: the requester cannot lower a tier; a tier-3 statement used as a component inherits tier 3 wherever it is reused; in an emergency the on-duty editor may remove a wrong tier-3 statement at once, but any new tier-3 statement needs the risk approver’s consent before it is published (see the Exceptions rule under Operating model and governance).

1. Inventory. Export every live item with URL, title, type, owner, last reviewed, review date, traffic for the last 90 days, and a regulatory flag. GOV.UK suggests exports from its publishing tool to find content that has not been updated recently.^[18]
2. Automated flags. Mark ownerless (owner missing or no longer active), outdated (review date passed or missing), likely redundant (several items on one topic, this one weaker) and likely trivial (very low use and no regulatory reason to exist). Lab 1 does this with a script.
3. Human judgement. Flags are proposals. Boag warns against automatic deletion: low-traffic content can serve a small but important audience or a regulatory need.^[2]
4. Decide and record. Keep, update, merge (and redirect), withdraw, or unpublish. GOV.UK’s guidance is a useful default: update guidance rather than withdraw it; withdraw other content when it is no longer current (GOV.UK gives news and press releases over a year old as an example); unpublish rarely.^[16]
5. Schedule the work in the normal calendar; an audit that produces a spreadsheet nobody acts on is an expensive inventory.

A real example of scale: a 2016 GOV.UK audit of early-years and childcare content, run by editors from several organisations, reviewed 723 items and marked 79 of them (10.9 %) for retirement.^[19] Your ratio will differ; the point is that even well-governed estates carry retirable content.

1. Internationalise the source. W3C defines internationalisation as design “that enables easy localization”;^[15] in content terms: no text in images, no sentences assembled from fragments, dates and prices as structured fields, room for longer translations.
2. Release source in batches once approved, not while drafting; every source change after hand-off costs a re-translation.
3. Exchange standard files. XLIFF exists “to store localizable data and carry it from one step of the localization process to the other, while allowing interoperability between and among tools”.^[8]
4. Maintain the term base and memory as owned assets; product names and regulated phrases go into the term base first.
5. Review in-market for tier 2 and 3 content: a native reviewer checks meaning, not only grammar.
6. Track localisation lag and locale coverage (see Metrics and KPIs) so that locales do not silently fall behind.

Barker’s list of content-operations services starts with inventory, extraction, migration, content QA, URL integrity and launch management;^[1] a CMS migration is where all of them meet. Owner: the ContentOps lead, with the CMS owner for steps 4–7.

1. Audit before you move. Run ROT triage (Lab 1) and retire or merge first. Acceptance: every item in scope has a keep, update, merge or retire decision and a named owner.
2. Map the model. Define the target content types and map each source type and field to a target field in a mapping sheet. Acceptance: every kept item maps to a type; each unmappable field has a recorded decision (drop, merge, new field).
3. Freeze and log. Announce a freeze window on the old system; urgent changes during it go into a change log that is re-applied after cut-over. Acceptance: the log has one owner and is empty after re-application.
4. Extract, transform, validate. Move content with scripts and validate it against the target model (Lab 2). Acceptance: zero schema errors on tier-2 and tier-3 items; remaining tier-1 errors listed with owners.
5. Map every URL. Each old URL with traffic or inbound links gets a new URL or a retirement target. Acceptance: a crawl of the old URL list returns no 404s.
6. Check content by tier. Compare rendering, links, images and locales: every tier-3 item, a sample of the rest. Acceptance: all tier-3 items checked and signed off.
7. Cut over with a way back. Keep the old system read-only until verification ends, with a stated rollback trigger (for example, redirect failures above an agreed level). Acceptance: freshness and ownerless baselines re-measured on the new platform; the decision is recorded with Template 5.

No standard governs ContentOps as a whole. These standards govern parts of it; separate the mandatory (law, contract) from the optional (industry practice).

Vendor-neutral categories first; named tools are examples, not recommendations, and capabilities change (as of October 2026).

Selection advice: write the content model and the workflow on paper first, then test two or three candidates against them with real content. A tool that cannot express your model or enforce your tiers will push the process back into spreadsheets.

Automation has an obvious, low-risk core in ContentOps: schema validation, style and terminology linting, link checking, accessibility checks, review-date reminders, routing to the right reviewer, and publishing to several channels from one source. Do these first; they remove waiting and copying without changing who is accountable.

Generative AI is useful for drafting variants, summarising, suggesting metadata and first-pass translation, and risky for the same reason: it produces fluent text that can be wrong. The NIST Generative AI Profile names this risk “confabulation”, “the production of confidently stated but erroneous or false content”, alongside information-integrity and intellectual-property risks.^[25] Operational rules that follow:

• Keep a named human accountable for every published item, whatever drafted it, and record which items had AI assistance.
• Never let generated text bypass the tier rules. A tier-3 statement drafted by a model still needs its risk approver.
• Ground generation in approved sources (the term base, approved components) rather than a model’s general knowledge.
• Check the law where you publish. In the EU, Article 50(4) of the AI Act requires deployers who publish AI-generated or manipulated text “published with the purpose of informing the public on matters of public interest” to disclose it. The exceptions are uses authorised by law for criminal investigations, and content that “has undergone a process of human review or editorial control” where “a natural or legal person holds editorial responsibility for the publication of the content”.^[26] The responsible party may therefore be the organisation, not a named individual; naming one is this Atlas’s operational advice, not the law’s requirement. These deployer duties have applied since 2 August 2026; the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force from 27 July, left them on that date and added a transitional period only for the labelling of synthetic content.^[27][28] This is not legal advice; check with counsel for your case.
• Search engines judge quality, not origin. Google’s 2023 guidance rewards high-quality content “however it is produced”; generating content primarily to manipulate rankings breaks its spam policies.^[29] Depth: SEO Operations.

The design below fits a mid-sized organisation (one website, one app, help centre, four locales, about 3,000 live items, a team of six to ten content people). Assumptions: a headless or hybrid CMS with workflow states and roles, a TMS that accepts XLIFF, CI available for checks. The artefacts are illustrative, not tied to one product; adapt field names to your CMS.

Artefact 1: a content type definition. The model states meaning, limits and ownership fields. The same structure drives the CMS configuration and the validation in Lab 2.

Example status: syntax-checked (JSON), not executed against a CMS.

{
  "type": "help_article",
  "description": "Task-based help for one user goal",
  "fields": {
    "title": {"kind": "text", "required": true, "max": 70},
    "summary": {"kind": "text", "required": true, "max": 160},
    "steps": {"kind": "list", "of": "step", "required": true},
    "applies_to": {"kind": "refs", "to": "product", "required": true},
    "disclaimer": {"kind": "ref", "to": "legal_component", "required": false},
    "audience": {"kind": "enum", "values": ["customer", "admin", "partner"]},
    "risk_tier": {"kind": "enum", "values": [1, 2, 3], "required": true},
    "owner": {"kind": "person", "required": true},
    "review_by": {"kind": "date", "required": true},
    "locales": {"kind": "list", "of": "locale", "required": true}
  }
}

Artefact 2: workflow states and rules. Encode who may move an item between states, per tier. The states and transitions are the same as in the lifecycle state machine: every arrow in the diagram has one rule here.

Example status: syntax-checked (YAML), illustrative; real CMSs express this in their own configuration.

workflow: editorial-v2
states: [requested, declined, draft, in_review, approved, scheduled,
         live, review_due, withdrawn, unpublished]
transitions:
  - {from: requested, to: draft, by: [contentops_lead],
     requires: [owner, risk_tier, brief]}
  - {from: requested, to: declined, by: [contentops_lead],
     requires: [reason]}
  - {from: draft, to: in_review, by: [writer]}
  - {from: in_review, to: draft, by: [editor, sme, risk_approver]}
  - {from: in_review, to: approved, by: [editor], when: "tier == 1"}
  - {from: in_review, to: approved, by: [editor], when: "tier == 2 and sme_ok"}
  - {from: in_review, to: approved, by: [risk_approver],
     when: "tier == 3 and editor_ok and sme_ok"}
  - {from: approved, to: scheduled, by: [editor], requires: [publish_at]}
  - {from: scheduled, to: live, by: [system], when: "now >= publish_at"}
  - {from: scheduled, to: draft, by: [contentops_lead],
     when: "launch changed"}
  - {from: live, to: review_due, by: [system], when: "today >= review_by"}
  - {from: review_due, to: live, by: [owner], sets: "review_by += 6 months"}
  - {from: review_due, to: draft, by: [owner], when: "needs update"}
  - {from: review_due, to: withdrawn, by: [owner]}
  - {from: withdrawn, to: unpublished, by: [contentops_lead],
     requires: [redirect_or_reason]}
  - {from: live, to: unpublished, by: [contentops_lead],
     requires: [redirect_or_reason], when: "duplicate or published in error"}
emergency:            # live content that is wrong; see Exceptions
  contain: {by: [on_duty_editor], allowed: [remove_statement, replace_with_link]}
  correct_tier3: {requires: risk_approver_consent_before_publish, log: true}
service_levels_working_days:
  editor_review: 2
  sme_review: 3
  risk_review: 3
  translation_per_locale: 5
escalation:
  review_due_overdue_days: 20
  escalate_to: owner_manager
  sme_sla_breach_tier2:   # exception path 2; never for tier 3
    by: [contentops_lead]
    allows: approve_without_sme
    creates: accuracy_check_task

Artefact 3: the content register columns. One row per live item, exported monthly from the CMS: id, url, title, type, collection, owner, owner_active, risk_tier, last_reviewed, review_by, locales, views_90d, regulatory, topic, status. Lab 1 runs on a subset of these columns.

Artefact 4: style rules as code. Terminology and house-style rules for Vale, shown in Lab 3.

Artefact 5: governance charter and templates. See Templates: request form, brief, review form, retirement record, decision record.

Labs 1, 2 and 4 use synthetic data, Python 3.8 or later and the standard library only; no accounts, no cost. They were run on 2026-10-23 exactly as printed (Python 3.8.10, Ubuntu Linux) and the expected outputs are copied from those runs. Lab 3 needs the Vale command-line tool and was not executed for this page.

Objective. Flag ownerless, outdated, likely redundant and likely trivial items in an inventory and compute three health metrics. Prerequisites. Python 3.8+, a bash shell. Time. 20 minutes. Risk. None (synthetic data).

1. Create the folder, the inventory and the list of active owners.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/contentops-labs/lab1 && cd ~/contentops-labs/lab1
cat > inventory.csv <<'CSV'
id,url,title,type,owner,last_reviewed,review_by,views_90d,regulatory,topic
C01,/pricing,Pricing plans,landing,ana,2026-09-01,2027-03-01,18200,no,pricing
C02,/pricing-2023,Pricing plans 2023,landing,ana,2023-02-10,2023-08-10,140,no,pricing
C03,/help/reset-password,Reset your password,help,raj,2026-05-20,2026-11-20,9400,no,login
C04,/help/password-reset,How to reset a password,help,,2024-01-15,2024-07-15,310,no,login
C05,/legal/privacy,Privacy notice,legal,lee,2026-02-01,2027-02-01,2100,yes,privacy
C06,/blog/office-party-2019,Our office party 2019,blog,tom,2019-12-20,,12,no,culture
C07,/help/export-data,Export your data,help,raj,2025-06-01,2025-12-01,4300,no,data
C08,/guides/api-quickstart,API quickstart,guide,mia,2026-08-15,2027-02-15,7600,no,api
C09,/guides/api-v1,API v1 guide,guide,mia,2022-03-01,2022-09-01,95,no,api
C10,/legal/terms-2021,Terms of service 2021,legal,lee,2021-05-01,,40,yes,terms
C11,/events/webinar-q3,Q3 webinar recording,event,tom,2026-07-30,2026-10-30,800,no,events
C12,/help/billing-faq,Billing FAQ,help,sam,2026-03-10,2026-09-10,5200,no,billing
CSV
printf 'ana\nraj\nlee\nmia\nsam\n' > active_owners.txt

2. Save the script as triage.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""ROT triage of a content inventory (synthetic data, stdlib only)."""
import csv
from collections import defaultdict
from datetime import date

TODAY = date(2026, 10, 23)        # fixed so the output is reproducible
LOW_TRAFFIC = 100                 # views in 90 days; tune per site
owners = {l.strip() for l in open("active_owners.txt") if l.strip()}
rows = list(csv.DictReader(open("inventory.csv", newline="")))

by_topic = defaultdict(list)
for r in rows:
    by_topic[r["topic"]].append(r)

def flags(r):
    f = []
    if not r["owner"] or r["owner"] not in owners:
        f.append("ownerless")
    due = r["review_by"]
    if not due or date.fromisoformat(due) < TODAY:
        f.append("outdated")
    peers = [p for p in by_topic[r["topic"]] if p is not r]
    if peers and int(r["views_90d"]) < min(int(p["views_90d"]) for p in peers):
        f.append("redundant?")
    if int(r["views_90d"]) < LOW_TRAFFIC and r["regulatory"] == "no":
        f.append("trivial?")
    return f

def proposal(r, f):
    if r["regulatory"] == "yes":
        return "KEEP-ARCHIVE (legal owner decides)" if f else "KEEP"
    if "redundant?" in f:
        return "MERGE/REDIRECT"
    if "trivial?" in f:
        return "RETIRE"
    if "outdated" in f or "ownerless" in f:
        return "REVIEW"
    return "KEEP"

print(f"{'id':<4} {'flags':<34} proposal")
counts = defaultdict(int)
for r in rows:
    f = flags(r)
    p = proposal(r, f)
    counts[p.split(" ")[0]] += 1
    print(f"{r['id']:<4} {','.join(f) or '-':<34} {p}")

n = len(rows)
fresh = sum(1 for r in rows
            if r["review_by"] and date.fromisoformat(r["review_by"]) >= TODAY)
ownerless = sum(1 for r in rows if "ownerless" in flags(r))
rot = sum(1 for r in rows if proposal(r, flags(r)) in ("RETIRE", "MERGE/REDIRECT"))
print(f"\nItems: {n}")
print(f"Freshness compliance: {fresh}/{n} = {fresh / n:.0%}")
print(f"Ownerless rate:       {ownerless}/{n} = {ownerless / n:.0%}")
print(f"ROT candidates:       {rot}/{n} = {rot / n:.0%}")
print("Proposals:", dict(sorted(counts.items())))

3. Run it with python3 triage.py.

Expected output.

id   flags                              proposal
C01  -                                  KEEP
C02  outdated,redundant?                MERGE/REDIRECT
C03  -                                  KEEP
C04  ownerless,outdated,redundant?      MERGE/REDIRECT
C05  -                                  KEEP
C06  ownerless,outdated,trivial?        RETIRE
C07  outdated                           REVIEW
C08  -                                  KEEP
C09  outdated,redundant?,trivial?       MERGE/REDIRECT
C10  outdated                           KEEP-ARCHIVE (legal owner decides)
C11  ownerless                          REVIEW
C12  outdated                           REVIEW

Items: 12
Freshness compliance: 5/12 = 42%
Ownerless rate:       3/12 = 25%
ROT candidates:       4/12 = 33%
Proposals: {'KEEP': 4, 'KEEP-ARCHIVE': 1, 'MERGE/REDIRECT': 3, 'RETIRE': 1, 'REVIEW': 3}

Validation. Check three rows by hand. C06 is owned by “tom”, who is not in the active list, has no review date and 12 views: ownerless, outdated, trivial, so retire. C11 is also Tom’s, current and used, so it needs a new owner, not retirement. C10 is old but regulatory: the script refuses to propose retirement and hands the decision to legal. Freshness: only C01, C03, C05, C08 and C11 have review dates on or after 2026-10-23, so 5 of 12.

Troubleshooting. ValueError: invalid isoformat string: a date is not YYYY-MM-DD; fix the export. All items flagged “redundant?”: your topic column is too coarse; use a finer topic or a canonical-URL field.

Teardown. rm -rf ~/contentops-labs/lab1

Objective. Enforce a content model in a script that could run in CI: required fields, length limits, allowed values, valid dates, no markup in plain-text fields (NPR’s “eliminate markup from content”^[6]) and resolvable references. Prerequisites. Python 3.8+. Time. 25 minutes. Risk. None.

1. Create the folder and the model.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/contentops-labs/lab2 && cd ~/contentops-labs/lab2
cat > model.json <<'JSON'
{
  "type": "product_notice",
  "fields": {
    "id": {"kind": "id", "required": true},
    "headline": {"kind": "text", "required": true, "max": 70},
    "summary": {"kind": "text", "required": true, "max": 160},
    "body": {"kind": "rich", "required": true},
    "audience": {"kind": "enum", "required": true,
                 "values": ["customer", "partner", "internal"]},
    "locale": {"kind": "enum", "required": true,
               "values": ["en-GB", "de-DE", "fr-FR", "ja-JP"]},
    "owner": {"kind": "text", "required": true, "max": 40},
    "review_by": {"kind": "date", "required": true},
    "related": {"kind": "refs", "required": false}
  }
}
JSON

2. Create entries.json with three entries (one valid, two with deliberate defects).

Example status: verified by execution on 2026-10-23 (JSON loaded by the script below).

[
  {"id": "N-100", "headline": "Scheduled maintenance on 2 November",
   "summary": "The billing portal is read-only from 01:00 to 03:00 UTC.",
   "body": [{"p": "Payments made in that window are queued."}],
   "audience": "customer", "locale": "en-GB", "owner": "ana",
   "review_by": "2026-11-03", "related": ["N-090"]},
  {"id": "N-101", "headline": "<b>New</b> export formats",
   "summary": "CSV and Parquet exports are now available to all plans.",
   "body": [{"p": "Choose a format in Settings."}],
   "audience": "everyone", "locale": "en-GB", "owner": "",
   "review_by": "2026-02-30", "related": ["N-999"]},
  {"id": "N-102",
   "headline": "Our biggest, boldest and most ambitious update to reports and dashboards",
   "summary": "Dashboards load faster.", "body": [],
   "audience": "customer", "locale": "en-US", "owner": "raj",
   "review_by": "2027-01-15"}
]

3. Save the validator as validate_content.py and run python3 validate_content.py; echo "exit=$?".

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Validate entries against a content model (stdlib only)."""
import json
import re
import sys
from datetime import date

model = json.load(open("model.json"))
entries = json.load(open("entries.json"))
known_ids = {"N-090", "N-100", "N-101", "N-102"}   # stand-in for the CMS index
MARKUP = re.compile(r"<[^>]+>|&[a-z]+;")

def check(e):
    errs = []
    for name, rule in model["fields"].items():
        v = e.get(name)
        if v in (None, "", []):
            if rule["required"]:
                errs.append(f"{name}: required")
            continue
        kind = rule["kind"]
        if kind == "text":
            if MARKUP.search(v):
                errs.append(f"{name}: markup in a plain-text field")
            if "max" in rule and len(v) > rule["max"]:
                errs.append(f"{name}: {len(v)} chars > {rule['max']}")
        elif kind == "enum" and v not in rule["values"]:
            errs.append(f"{name}: '{v}' not in {rule['values']}")
        elif kind == "date":
            try:
                date.fromisoformat(v)
            except ValueError:
                errs.append(f"{name}: '{v}' is not a valid date")
        elif kind == "refs":
            missing = [r for r in v if r not in known_ids]
            if missing:
                errs.append(f"{name}: unknown references {missing}")
    return errs

failed = 0
for e in entries:
    errs = check(e)
    print(f"{e.get('id', '?')}: {'OK' if not errs else 'FAIL'}")
    for msg in errs:
        print(f"  - {msg}")
    failed += bool(errs)
print(f"{len(entries) - failed} of {len(entries)} entries valid")
sys.exit(1 if failed else 0)

Expected output.

N-100: OK
N-101: FAIL
  - headline: markup in a plain-text field
  - audience: 'everyone' not in ['customer', 'partner', 'internal']
  - owner: required
  - review_by: '2026-02-30' is not a valid date
  - related: unknown references ['N-999']
N-102: FAIL
  - headline: 72 chars > 70
  - body: required
  - locale: 'en-US' not in ['en-GB', 'de-DE', 'fr-FR', 'ja-JP']
1 of 3 entries valid
exit=1

Validation. The non-zero exit code is the point: in CI it blocks a merge or a publish. Note what the model caught that a human reviewer might miss: an impossible date (30 February), a locale the organisation does not support, and a reference to an item that does not exist.

Troubleshooting. json.decoder.JSONDecodeError: a trailing comma or a smart quote in entries.json. If real CMS exports use other field names, map them before validation rather than loosening the model.

Teardown. rm -rf ~/contentops-labs/lab2

Objective. Turn two style-guide rules into automated checks with Vale, a tool that “brings code-like linting to prose”,^[30] and see which alerts fail a build. Prerequisites. Vale installed from its official distribution (latest release v3.25.1 as of 22 October 2026;^[24] rule inheritance needs v3.20.0 or later, not used here), a Git repository with Markdown files. Time. 30 minutes. Risk. Low; installing a binary may need approval on managed machines.

Example status: not executed (Vale not installed in the research environment); configuration follows the Vale documentation as read on 2026-10-23; YAML syntax-checked.

1. Create the configuration and a house style.

mkdir -p ~/contentops-labs/lab3/styles/House ~/contentops-labs/lab3/docs
cd ~/contentops-labs/lab3
cat > .vale.ini <<'INI'
StylesPath = styles
MinAlertLevel = suggestion

[*.md]
BasedOnStyles = House
INI
printf 'To log in, click here.\nThe app is very fast.\n' > docs/sample.md

2. Save styles/House/Terms.yml (a substitution rule at error level).

extends: substitution
message: "Use '%s' instead of '%s'."
level: error
ignorecase: true
swap:
  log in: sign in
  click here: select the link text

3. Save styles/House/Hedging.yml (an existence rule at warning level).

extends: existence
message: "Remove '%s'; say what is measurably true."
level: warning
ignorecase: true
tokens:
  - very
  - really
  - simply

4. Run vale docs/ (shows warnings and errors), then vale --minAlertLevel=error docs/ as the CI gate.

Expected output (not executed; described from the documentation). Two error-level alerts from House.Terms for “log in” and “click here”, and one warning from House.Hedging for “very”. Vale documents that only error-level alerts produce a non-zero exit code, so the second command fails the build because of the two errors, not the warning.^[31] Both commands fail only on errors, whatever the alert level shown; --minAlertLevel=error simply keeps CI logs to the alerts that block.

Validation. Fix the sentence to “To sign in, select Sign in.” and re-run: the error count should drop to zero and the exit code to 0.

Troubleshooting. An error naming StylesPath: the directory must exist relative to .vale.ini.^[32] No alerts at all: check that the section glob ([*.md]) matches your files and that BasedOnStyles names the directory House.^[33]

Teardown. rm -rf ~/contentops-labs/lab3

Objective. Compute cycle time (median and 85th percentile), review service-level attainment, first-pass approval and localisation lag from workflow events, the numbers used in Metrics and KPIs. Prerequisites. Python 3.8+. Time. 30 minutes. Risk. None.

1. Create the event log (five English items, some German and Japanese releases).

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/contentops-labs/lab4 && cd ~/contentops-labs/lab4
cat > events.csv <<'CSV'
item,locale,event,date
A1,en,brief_accepted,2026-09-01
A1,en,review_requested,2026-09-04
A1,en,review_done,2026-09-05
A1,en,approved,2026-09-05
A1,en,published,2026-09-08
A1,de,published,2026-09-15
A1,ja,published,2026-09-29
A2,en,brief_accepted,2026-09-02
A2,en,review_requested,2026-09-10
A2,en,changes_requested,2026-09-15
A2,en,review_requested,2026-09-17
A2,en,review_done,2026-09-18
A2,en,approved,2026-09-18
A2,en,published,2026-09-22
A2,de,published,2026-09-24
A3,en,brief_accepted,2026-09-03
A3,en,review_requested,2026-09-07
A3,en,review_done,2026-09-08
A3,en,approved,2026-09-08
A3,en,published,2026-09-09
A3,de,published,2026-09-11
A3,ja,published,2026-09-16
A4,en,brief_accepted,2026-09-07
A4,en,review_requested,2026-09-09
A4,en,review_done,2026-09-16
A4,en,approved,2026-09-16
A4,en,published,2026-09-17
A5,en,brief_accepted,2026-09-14
A5,en,review_requested,2026-09-21
A5,en,review_done,2026-09-22
A5,en,approved,2026-09-22
A5,en,published,2026-09-30
A5,de,published,2026-10-09
CSV

2. Save flow_metrics.py and run python3 flow_metrics.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Editorial flow metrics from an event log (synthetic data, stdlib only)."""
import csv
import math
from collections import defaultdict
from datetime import date
from statistics import median

REVIEW_SLA_DAYS = 3
ev = defaultdict(lambda: defaultdict(list))
for r in csv.DictReader(open("events.csv", newline="")):
    ev[(r["item"], r["locale"])][r["event"]].append(date.fromisoformat(r["date"]))

def days(a, b):
    return (b - a).days

cycle, reviews_ok, reviews, first_pass, lags = [], 0, 0, 0, []
items = sorted({i for i, loc in ev if loc == "en"})
for i in items:
    e = ev[(i, "en")]
    cycle.append(days(e["brief_accepted"][0], e["published"][0]))
    # Pair each review request with the next response (done or changes).
    answers = sorted(e["review_done"] + e["changes_requested"])
    for req, ans in zip(sorted(e["review_requested"]), answers):
        reviews += 1
        reviews_ok += days(req, ans) <= REVIEW_SLA_DAYS
    first_pass += not e["changes_requested"]
    for (j, loc), le in ev.items():
        if j == i and loc != "en":
            lags.append((loc, days(e["published"][0], le["published"][0])))

cycle.sort()
p85 = cycle[math.ceil(0.85 * len(cycle)) - 1]  # nearest rank
print("Cycle time (days, brief to publish):", cycle)
print(f"  median = {median(cycle)}  p85 = {p85}")
print(f"Review SLA ({REVIEW_SLA_DAYS} days): {reviews_ok}/{reviews} = "
      f"{reviews_ok / reviews:.0%}")
print(f"First-pass approval: {first_pass}/{len(items)} = "
      f"{first_pass / len(items):.0%}")
for loc in sorted({l for l, _ in lags}):
    v = sorted(d for l, d in lags if l == loc)
    print(f"Localisation lag {loc}: {v} median = {median(v)}")
covered = len(lags)
target = len(items) * 2          # every item should reach de and ja
print(f"Locale coverage: {covered}/{target} = {covered / target:.0%}")

Expected output.

Cycle time (days, brief to publish): [6, 7, 10, 16, 20]
  median = 10  p85 = 20
Review SLA (3 days): 4/6 = 67%
First-pass approval: 4/5 = 80%
Localisation lag de: [2, 2, 7, 9] median = 4.5
Localisation lag ja: [7, 21] median = 14.0
Locale coverage: 6/10 = 60%

Validation. By hand for item A2: brief accepted 2 September, published 22 September, so 20 days. Its first review took five days (10 → 15 September, changes requested) and missed the three-day level; the second took one day. A4’s single review took seven days. Those are the two misses in 4 of 6. Calendar days are used for simplicity; production metrics usually count working days.

Troubleshooting. IndexError on published: an item has no publish event yet; filter to published items or report it as work in progress. Percentiles on five items are fragile; report them only with the count.

Teardown. rm -rf ~/contentops-labs/lab4

Scenarios 1–3 are documented by the organisations themselves; their outcomes are as those organisations describe them, not independently measured. Scenario 4 is illustrative. The last column is this Atlas’s suggested measure for anyone copying the approach, not a measure the organisations published.

Problem. NPR wanted its content where its users were, not only on its website. Method. The three COPE principles described under Origins and evolution, with content in a central database independent of any presentation layer, so the same story can go to browsers, RSS readers, iPods, radio displays, mobile devices and TVs.^[6] Outcome as described. Because content was separate from display, NPR says it launched its NPR Music site “without refactoring the system architecture or our presentation layer code”.^[6] Pitfall for imitators. The principle is cheap to state and expensive to retrofit: rich-text fields full of layout markup must be remodelled before any API can reuse them, which is why Lab 2 rejects markup in plain-text fields.

Problem. Hundreds of departments, agencies and public bodies share one domain;^[34] stale content misleads citizens. Method. Review dates with a visible overdue status,^[18] explicit withdraw and unpublish rules (see The content lifecycle),^[16] and editor-run audits such as the 2016 early-years audit.^[19] Trade-off. Reviews consume editor time and depend on owners responding. What to copy. The vocabulary (overdue, withdraw, unpublish) and the default to update rather than delete.

Problem. A very large documentation set needs corrections from many people, including outside contributors. Method. Public GitHub repositories: minor fixes through an “Edit” link that opens a pull request, major changes through a fork and a pull request that is reviewed and signed off;^[35] reviewing pull requests is itself a listed contribution.^[36] Trade-off. Training modules are not open to public edits,^[35] and Git is a barrier for many subject experts. What to copy. The review workflow, history and automated checks come with the repository, which is the docs-as-code argument in short.^[4]

No standard set of ContentOps metrics exists. The set below is this Atlas’s proposal, grouped into flow (is production predictable?), health (is the live estate trustworthy?) and outcome (does content do its job?). Flow and health metrics are leading indicators; outcomes lag and are noisy.

Use the Lab 4 data and an illustrative register for a help-centre collection of 1,200 live items.

• Cycle time. Five items took 6, 7, 10, 16 and 20 days. Median = 10 days; 85th percentile by nearest rank: rank = ceil(0.85 × 5) = 5, so 20 days. Report “median 10, p85 20, n = 5”, because two slow items dominate.
• Review SLA attainment. Six review rounds, four answered within three days: 4 ÷ 6 = 67 %. The event log does not record who reviewed, so it cannot say where the delay sits. Suppose the review forms (Template 2) show both misses were SME rounds: that would point at SME capacity, not editors. In production, add a reviewer-role column to the events.
• First-pass approval. Four of five items needed no changes: 80 %.
• Freshness compliance. Suppose 1,020 of the 1,200 items have a review date on or after today: 1,020 ÷ 1,200 = 85 %. Items with no date at all count as non-compliant.
• Locale coverage. Lab 4 required German and Japanese for every item and found 6 of 10 locale versions: 60 %, while median German lag (4.5 days) looked healthy. Coverage reveals what lag hides.

Targets. Set targets from your own baseline, per tier, after two months of measurement; the charter’s 95 % freshness goal is a destination, not a starting point. Vanity traps. Pages published per month (rewards adding, never pruning); total page views (rewards popular content, not correct content); “AI-generated items” as a productivity figure without a defect escape rate beside it.

flowchart TB
  EV["Workflow events and register"] --> FLOW["Flow: cycle time, review SLA, first pass"]
  EV --> HEALTH["Health: freshness, ownerless, ROT, coverage"]
  USE["Research, analytics, support tags"] --> OUT["Outcomes: task success, contact reasons"]
  FLOW --> REV["Monthly health review"]
  HEALTH --> REV
  OUT --> REV
  REV --> ACT{"Council decision"}
  ACT -->|"queue too long"| WIP["Change WIP limits or reviewer capacity"]
  ACT -->|"stale or ownerless"| AUD["Audit; reassign or retire collection"]
  ACT -->|"rule or tier wrong"| STD["Change standards, model or tiers"]
  ACT -->|"content fails users"| STR["Revise brief or strategy"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class FLOW,HEALTH,OUT,REV core
  class ACT decision
  class EV,USE,WIP,AUD,STD,STR neutral

Content creates legal exposure in ways that are easy to underestimate. What applies depends on jurisdiction and sector; this section names the common categories and dates time-sensitive points (as of October 2026). It is not legal advice.

Least privilege in the CMS. Separate roles for drafting, approving and publishing; restrict who can edit tier-3 components; keep an audit trail of approvals for as long as your records policy requires (legal decides the period). Evidence retention. For regulated statements keep the approved version, the approver and the publication date; a CMS revision history is evidence only if it cannot be edited by the people it records.

The main cost of content is people’s time over the item’s whole life, not the CMS licence. Useful unit economics:

• Cost per published item = (hours × loaded hourly rate for writing, review and publishing + translation + tool cost share) ÷ items published. Illustrative: 6 hours × 60 per hour + 4 locales × 80 per locale + 15 tool share = 695 per help article.
• Cost of keeping an item = review hours per year × rate. At 0.5 hours a year, a 3,000-item estate costs 1,500 hours a year just to stay current, before any change. This is why retirement is a cost control, not housekeeping.
• Translation cost scales with new and changed words times locales; reuse and translation memory reduce it because unchanged segments are not re-translated. Freezing source text before hand-off is the cheapest saving.
• Capacity. Plan in item-equivalents per tier (for example, one tier-3 item consumes three tier-1 slots of review capacity) and set work-in-progress limits per stage; the binding constraint is usually SME or legal review, not writing.

Sustainability. Fewer pages mean less to crawl, store, translate and serve; page weight and delivery belong to WebOps and GreenOps. The stronger argument is human: an estate that only grows eventually consumes all capacity in maintenance.

How do you know the system works, not just that this month’s numbers look good?

• Quarterly audit of one collection, rotating, against stated criteria (current, owned, accurate, accessible, findable), with a sample checked by someone outside the team.
• Control tests. Pick five tier-3 items each quarter and verify that the recorded approver is the named risk approver and approved the version that went live.
• Exception log review. Emergency containments, emergency corrections and skipped reviews are counted; a rising count means the normal path is too slow.
• Risk indicators. Ownerless rate rising after reorganisations; overdue reviews concentrated in one owner; a collection whose traffic falls while support contacts about it rise.
• Feedback to strategy. Each quarter, report the collections that cost most to maintain and deliver least.

In this illustrative scenario, the team followed this runbook, in order:

1. Contain (owner: on-duty editor, target 30 minutes, no approval needed). Remove the comparison table from the article in all locales, or replace it with a link to the pricing page. Do not wait for translations: removing a wrong statement is faster than correcting it in eight languages, and it adds no new claim, which is why the governance rules allow it without approval.
2. Notify (ContentOps lead, 1 hour). Inform the risk approver (legal or pricing), support (with a reply macro) and the product owner. Record the time of each notification.
3. Diagnose (ContentOps lead and CMS owner, same day). Why was the price typed into a table instead of referenced? Check the item’s history: the table was pasted from a slide during a deadline, bypassing the price component, and tier-3 review did not trigger because the article was tier 2.
4. Correct (writer, risk approver, translators). Rebuild the table using the price component; the risk approver approves it before it is republished (by message if urgent, logged with the time); send only the changed segments for translation; publish all locales.
5. Verify. Script a search for the wrong value across all channels and locales; ask support to confirm no new contacts.
6. Remediate customers (product and legal). Whether customers are owed anything is a legal decision, not a content one.
7. Learn (within five working days). Blameless review: the control gap was that tier was set per item, not per statement. Actions: any item that contains a price must reference the price component (schema rule); tier is computed from the components an item contains; add “prices outside components” to the monthly scripted check.

flowchart TB
  A["Report: wrong statement live"] --> B{"Tier 3 or harmful?"}
  B -->|"yes"| C["Contain within 30 min, no approval: remove or link"]
  B -->|"no"| D["Normal correction through workflow"]
  C --> E["Notify risk approver, support, owner"]
  E --> F["Diagnose: history, copy or component, why review missed it"]
  F --> G["Correct source; approver consents before republish"]
  G --> H["Verify across channels and locales"]
  H --> I["Blameless review: control change, schema rule"]
  D --> H
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,C risk
  class B decision
  class E,F,G,H,I,D core

• “The new CMS will fix it.” A migration without an audit moves the mess and adds a deadline; see the migration playbook.
• Approval by committee. Five reviewers on every blog post produce delay without safety. Tier the reviews; make one person accountable per tier.
• Rich-text everything. One big formatted body field is quick to build and blocks reuse, validation and localisation. Model the parts that change or repeat.
• Owner = team alias. “Owned by Marketing” means owned by nobody. Name a role holder and re-check after reorganisations.
• Audit as a one-off project. A spreadsheet of decisions with no scheduled work behind it decays within a quarter. Put audit actions in the calendar and track completion.
• Myth: “Structured content is only for documentation teams.” Any content that appears in more than one place or language benefits; NPR’s case is news, not manuals.^[6]
• Myth: “AI makes governance unnecessary.” Generation increases volume and the risk of confident errors;^[25] it makes ownership, review and retirement more important, not less.
• Myth: “Deleting content hurts us.” Some retirements need care (inbound links, regulatory records), which is why the withdraw/unpublish distinction exists; but keeping wrong content has its own cost in support contacts and trust.

Invest in a deliberate ContentOps when several of these are true: content appears in more than one channel or language; more than a handful of people create or approve content; content carries legal, safety or pricing risk; the estate is large enough that nobody can name every item (this Atlas’s heuristic: about 300 items, as in the tree below); support contacts are caused by wrong or missing content; or a platform migration is coming.

Do not build a formal ContentOps function when:

• One person writes one small site. A style sheet, a review date in each page’s metadata and a quarterly self-audit are enough. A workflow tool would cost more than it saves.
• The strategy is missing. Operations cannot rescue content nobody needs. Fix the “what and why” first, with a small strategy exercise; then operationalise.
• The content is knowledge from support work. Use KnowledgeOps (see What ContentOps is not).
• The real problem is the platform. If editors cannot publish because the site is down or slow, that is WebOps work.
• You are about to rename the content team “ContentOps” without changing anything else. A label without decision rights, service levels and a register is a reorganisation, not an operating model.

Hidden responsibilities to budget for: owners’ time for reviews (often the scarcest resource), modelling and CMS configuration skills, translation vendor management, and the political cost of retiring other people’s content.

The most consequential architecture decision is how much structure to adopt. The tree below is this Atlas’s proposal; its assumptions are stated on each branch.

flowchart TB
  Q3{"Developer docs by Git users?"}
  Q3 -->|"yes"| A3["Docs-as-code, CI checks"]
  Q3 -->|"no"| Q1{"Reused across channels or locales?"}
  Q1 -->|"no"| A1["Coupled CMS; add workflow and audits at 300+ items or 5+ authors"]
  Q1 -->|"yes"| Q4{"Heavy reuse, 10+ locales?"}
  Q4 -->|"yes"| A4["Component CMS (DITA)"]
  Q4 -->|"no"| A5["Headless or hybrid CMS"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q3,Q4 decision
  class A3,A4,A5 core
  class A1 neutral

The thresholds (300 items, five authors, ten locales) are heuristics, not research findings; move them to fit your situation. Among the CMS options, reuse comes before size because a small estate published to a website, an app and six locales already pays the copy-and-paste cost on every change; size alone only decides how much workflow a single-channel estate needs. For tool choice inside a branch, a weighted comparison works better than feature lists:

This is this Atlas’s maturity model, built for self-assessment; it is not an industry standard. It can be read alongside Content Science’s five levels (Chaotic, Piloting, Scaling, Sustaining, Thriving),^[10] which run from ad hoc work through spreading formal operations across functions to optimising them and seeing return on investment; the levels below describe observable controls instead.

flowchart TB
  L1["1 Ad hoc: count nothing"] -->|"inventory and owners"| L2["2 Repeatable: intake and calendar"]
  L2 -->|"states, tiers, review dates"| L3["3 Governed: enforced workflow"]
  L3 -->|"content model, checks in CI"| L4["4 Structured and measured"]
  L4 -->|"outcomes drive strategy"| L5["5 Adaptive: routine pruning"]
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class L1,L2 neutral
  class L3,L4,L5 core

Most organisations should aim for level 3 before buying new platforms: a headless CMS at level 1 produces structured chaos.

The plan assumes one ContentOps lead with part-time help from an editor, a CMS owner and an analyst, and one pilot collection (for example the help centre).

Dependencies: legal’s agreement on tiers (start in week one), CMS configuration time, and access to support contact reasons for outcome measures.

Quick start (first week)

• Inventory exported with owner, review date and traffic columns
• Risk tiers drafted and sent to legal
• One intake channel announced
• Top 20 items by traffic have a named, active owner

Pre-publication (every item)

• Brief linked; content type correct; owner and review date set
• Automated checks pass (schema, style errors, links, accessibility)
• Required approvals for the tier recorded on this version
• Reused facts referenced, not copied
• Alt text, link text and headings meaningful
• Locales required for this collection scheduled

Launch readiness (multi-locale release)

• Source frozen and sent for translation by the agreed date
• Screenshots and images showing changed values updated
• Cross-channel check for changed facts scripted and run
• Support briefed; reply macros updated

Monthly health review

• Freshness, ownerless rate and overdue reviews by collection
• Review SLA attainment by reviewer group
• Exception log (emergency containments and corrections, skipped reviews)
• Actions from last month closed

Governance audit (quarterly)

• Five tier-3 items: approver and approved version verified
• CMS roles: who can publish tier-3 content, reviewed
• Retirement records: redirect present for retired URLs with traffic
• Rights expiry: assets past licence date removed

Retirement

• Owner approved; regulatory and legal hold checked
• Withdraw versus unpublish decided and recorded
• Redirect target chosen for URLs with traffic or inbound links
• Translations and reused components handled

Template 1: content request and brief

CONTENT REQUEST                                   ID: ____  Date: ____
Requester / team:
Goal (what should a reader be able to do or decide?):
Audience and channel(s):
Existing content checked? (links)   [ ] none found  [ ] update instead
Content type:                       Risk tier (1/2/3):
Owner after publication:            Review interval (months):
Locales required:                   Launch date / dependency:
Subject-matter expert:              Risk approver (tier 3):
Success measure (task, contact reason, other):
Decision: [ ] accepted  [ ] deferred to ____  [ ] declined, reason:

Template 2: review form (one per review round)

REVIEW                      Item: ____  Version: ____  Tier: __
Reviewer role: [ ] editor  [ ] SME  [ ] risk approver
Requested: ____ (date)      Answered: ____ (date)   SLA met: [ ]
Accuracy: [ ] correct  [ ] corrections listed below
Policy or legal: [ ] n/a  [ ] approved  [ ] blocked, reason:
Accessibility: [ ] alt text  [ ] link text  [ ] headings  [ ] tables
Decision: [ ] approve  [ ] changes requested
Comments:

Template 3: retirement record

RETIREMENT                  Item: ____  URL: ____  Locales: ____
Reason: [ ] outdated  [ ] duplicate  [ ] trivial  [ ] legal/rights
        [ ] personal data  [ ] published in error
Decision: [ ] update instead  [ ] withdraw (notice)  [ ] unpublish
Redirect to: ____               Inbound links checked: [ ]
Regulatory or legal hold checked by: ____
Reused components affected: ____
Approved by owner: ____  Date: ____   Done by: ____  Date: ____

Template 4: one-page governance charter

CONTENTOPS CHARTER — <collection or organisation>      Version __
Scope: <channels, collections, locales>   Out of scope: <...>
Mission: <one sentence>
Decision rights:
  New content type ........ <content architect>
  Publish tier 1 / 2 / 3 .. <editor> / <editor + SME> / <risk approver>
  Retire .................. <owner>, disputes to <council>
  Style exceptions ........ <managing editor>
Service levels (working days): editor 2, SME 3, risk 3,
  translation 5 per locale
Cadences: intake weekly; health review monthly; audit quarterly
Metrics and targets: freshness >= __%, ownerless <= __%,
  review SLA >= __%, locale coverage >= __%
Escalation: overdue review > 20 days -> owner's manager
Signed: <sponsor>, <ContentOps lead>, <legal>         Date: ____

Template 5: decision record for a platform or model change

DECISION RECORD  CR-___   Status: proposed | accepted | superseded
Context: <problem, constraints, volumes, channels, locales>
Options considered: <A>, <B>, <C>
Decision: <chosen option>
Consequences: <what gets easier, what gets harder, migration work>
Exit plan: <how content and model would be exported>
Review date: ____

For the comparison with neighbouring operating models, see the relations table.

Is ContentOps a job title or a team? It can be either, or one editor’s responsibility. What makes it ContentOps is the operating model (states, owners, service levels, metrics), not the name.

Do we need a headless CMS to do ContentOps? No. Workflow, ownership, review dates, audits and style rules work in any CMS. Headless helps when content must be reused across channels; see the Decision framework.

Who should own a page: the writer or the business? The business role that knows whether it is still true (product, policy, service owner). Writers create and edit; owners answer “is this still correct?” when the review date arrives.

How often should content be reviewed? By risk and volatility, not a single interval: prices and legal statements whenever they change plus a fixed interval; help articles with each product release that touches them; evergreen guidance perhaps yearly; news is time-bound and is usually withdrawn rather than reviewed (GOV.UK gives news over a year old as an example of content that can be withdrawn).^[16]

Can we let AI write first drafts? Yes, under the same tiers and ownership as human drafts, grounded in approved sources, with records of which items used AI. In the EU, AI-generated public-interest text needs either human review or editorial control, with a natural or legal person holding editorial responsibility, or a disclosure.^[26] Watch the defect escape rate.

What is a good first metric? Freshness compliance for one important collection: it forces you to build the register, set owners and review dates, and it shows progress within weeks.

• Content as data for AI assistants (emerging). Structured, owned, dated content is what retrieval systems need; stale content becomes confidently wrong answers. Engineering of retrieval belongs to LLMOps, corpus ownership for operational knowledge to KnowledgeOps; ContentOps contributes the model, the metadata and the retirement discipline.
• Computed risk tiers (this Atlas’s proposal). Tiers derived from the components an item contains, as in the worked incident, instead of being set by hand. We found no published source describing this as common practice.
• Content graphs and semantic metadata. Rich relationships between types (product, task, audience, region) enable personalisation and better navigation; they need taxonomy governance in the spirit of Z39.19.^[14]
• Machine translation with human post-editing. It changes the cost and lag of localisation; this page makes no claim about quality by language pair, so measure it on your own content and keep in-market review for tier 2 and 3.
• Provenance and labelling of AI output (regulatory, moving). Machine-readable marking duties in the EU fall on AI system providers (Art. 50(2)), with a transitional period for systems already on the market reported to end on 2 December 2026;^[28][27] publishers should know what their tools emit and keep human responsibility clear. Media provenance in depth belongs to MediaOps.
• Vendor marketing to discount. Claims that a platform “automates content operations” usually mean workflow features; the operating model (owners, tiers, retirement) is still yours to design.

• Prerequisites. None. Comfort with spreadsheets helps; basic Git helps for docs-as-code.
• One-day primer. Read What ContentOps is and Principles and operating model; read Barker’s post,^[1] Halvorson’s 2008 article^[5] and NPR’s COPE post;^[6] run Lab 1.
• One-week practice. Inventory one real collection (export only), propose tiers and owners, run Lab 2 and Lab 4 on a copy of your data, and draft the charter.
• 30-day progression. Run the first 30 days of the roadmap; set up Vale with five rules (Lab 3); read GOV.UK’s retirement guidance^[16] and the plain-language standard’s scope.^[21]
• Specialisations. Content modelling and information architecture; localisation operations (XLIFF,^[8] translation memory); structured authoring (DITA^[7]); content analytics; accessibility (WCAG 2.2^[20]).
• Portfolio project. Take a public website you know, build a 50-item inventory, run ROT triage, model one content type, write a one-page charter and a 90-day plan, and present the before-and-after metrics you would expect, labelled as estimates.
• Further reading. The open-access collection Content Operations from Start to Scale^[12] and Content Science’s maturity material.^[42]

Assumptions (illustrative). Each article takes a writer about 40 minutes to review properly, a sampled scripted edit about 10 minutes, and a retirement record with its redirect about 5 minutes; four writers have roughly 500 review hours in ten weeks; traffic is concentrated, with a few hundred articles receiving most visits; tier-3 statements (prices, data-retention terms) appear in perhaps 10 % of articles.

Why the attractive option is risky. Rewriting everything treats the stale third as worth keeping. A 5 % spot check means about 3,800 articles go live without a human reading them, including tier-3 statements, which breaks the tier rules. Generated text can be fluent and wrong (“confabulation” in NIST’s terms^[25]), and a rename touches product behaviour as well as names, so errors would be specific and plausible. Every article kept also keeps its maintenance cost for years. If the site serves EU users with public-interest information, publishing AI text without human editorial control would also raise a disclosure question.^[26]

The decision process.

1. Run ROT triage on the full inventory (Lab 1): suppose it proposes 1,500 items to retire or merge.
2. Withdraw or unpublish those with redirects, with owners’ approval; this alone removes 1,500 rename edits.
3. Split the remaining 2,500 by tier and traffic. Tier-3 and top-traffic articles (say 600) get AI-assisted drafts with full human review: 600 × 40 minutes = 400 hours, inside capacity.
4. The remaining 1,900 low-traffic tier-1 and tier-2 articles get a scripted name replacement (deterministic, reviewable as a diff), not free rewriting, plus a sampled review and a review date within six months.
5. Count the work that is easy to forget. A 10 % sample of the scripted edits (190 articles) at about 10 minutes each adds about 32 hours, so writers carry 432 of their 500 hours. Retirement records and redirects at about 5 minutes each add 1,500 × 5 minutes = 125 hours; under the RACI this is the ContentOps lead’s work (helped by the analyst), approved by owners. If the writers had to do it too, the total (about 557 hours) would exceed capacity, and the top-traffic set would have to shrink.

Uncertainty. The 1,500 retirement estimate could be wrong in either direction; if triage finds less ROT, the scripted replacement covers more articles and the review backlog grows. The plan protects the riskiest statements first and accepts slower voice changes elsewhere.

Why this is a judgement, not a rule. If the articles were mostly accurate and the change truly only cosmetic, a bulk AI rewrite with a larger sample might be defensible. The decision turns on the share of tier-3 content and the share of content worth keeping, both of which the audit measures before anyone commits.

After this page you should be able to explain where ContentOps sits between strategy and platforms and how it differs from KnowledgeOps; design a lifecycle with states, owners and review dates; specify a content type and validate entries against it; set risk tiers and service levels; calculate and interpret flow and health metrics; run an audit and a retirement; and choose an architecture and a maturity target for a given organisation.

ContentOps is unglamorous by design. It does not decide what an organisation should say, and it does not choose the shiny platform; it makes sure that what is said is true, owned, consistent across channels and languages, and removed when it stops being true. The field has a real literature and real foundations (governance in content strategy, NPR’s create-once principle, structured-content and localisation standards), but no standards body and no single definition, so be wary of anyone selling it as a product. The honest summary is a set of small, testable commitments: every item has an owner and a review date; facts that change live in one place; reviews are as heavy as the risk and no heavier; flow and health are measured; and retirement is as deliberate as publication. An organisation that keeps those commitments can adopt any CMS, any channel and any AI tool without losing control of what it tells people. One that skips them will publish faster and faster into a garden nobody tends.

All sources were opened on 2026-10-23 unless the ledger (research/contentops-ledger.md) says otherwise. Legal sources are for orientation, not advice; check official texts (for EU law, EUR-Lex) before relying on them.

Further reading is listed in the Learning path.

Changelog

• 2026-10-23: first published draft (research, ledger, 13 parts, 9 diagrams, 4 labs of which 3 executed); not yet independently reviewed.
• 2026-10-23 (revision r1, after independent review reviews/contentops-r1.md): legal accessibility baseline corrected (WCAG 2.1 AA in US Title II and EN 301 549 V3.2.1; V4.1.1 status; EAA small-business exemption for services); emergency rule unified as contain-without-approval, correct-with-prior-consent; workflow YAML now matches the state machine; decision tree asks about reuse first; migration playbook, DAM/TMS/CCMS glossary rows and a volatile-fact KPI added; governance and measurement loops merged (8 diagrams); attributions tightened (Barker, Halvorson, Boag, Evia, GOV.UK, AI Act Art. 50(4)); XLIFF 2.2 status; p85 formula fixed; Labs 1, 2 and 4 re-run.
• 2026-10-23, post-score polish: decision tree asks the Git-docs question first (matches the recap); WCAG 4.1.1 caveat; GOV.UK organisation count sourced; size threshold and naming callout labelled; Content Science levels in full; EAA changelog wording.