Knowledge Base Content Lifecycle: An 8-Stage Operating Model

Last verified: July 30, 2026. This guide separates our vendor-neutral operating model from documented product behavior. We checked current Microsoft, ServiceNow, Atlassian, Knowledge-Centered Success (KCS®), ISO, NIST, and Google sources directly. We also ran a public lifecycle-signals audit across 12 systematically selected guides and this page as a declared sentinel. Product status names, permissions, and retention obligations vary, so validate the workflow in your own platform and policy environment.

The quick answer

A knowledge base content lifecycle is the operating process that moves an article from a documented need to a controlled final disposition. It covers intake, drafting, factual validation, approval, publishing, observation, revision, and retirement or archive. A reliable lifecycle tells a team who can move an article, what evidence is required, what users can see, which version is live, and what must happen when the answer changes.

The lifecycle is not just “draft, review, publish.” Publishing begins the evidence loop: readers search, use, rate, challenge, and link to the article; products and policies change; owners receive correction signals; and a revised version may need to pass the same controls as the first one. The goal is not to keep every article forever or refresh dates on a schedule. It is to keep the right answer available to the right audience, with enough evidence to trust its current state.

Model, not standard: the eight stages below are our practical, vendor-neutral operating model. They are not an ISO-mandated sequence or a claim that every knowledge base product uses the same statuses.

Lifecycle stage, status, confidence, audience, and disposition are different

Many implementations fail because one field called “Status” is expected to answer five different questions. Separate these concepts even if your software requires you to represent some of them with custom fields.

Concept	Question it answers	Example values
Process stage	What work is happening now?	Drafting, validating, publishing, revising
Workflow status	Where is the record allowed to move next?	Draft, In review, Approved, Published
Confidence	How strongly has the answer been validated?	Work in progress, Not validated, Validated
Audience and visibility	Who may find or use it?	Public, authenticated customer, internal, restricted
Disposition	Should it remain an active answer?	Active, Deprecated, Retired, Archived, Disposed

This separation is consistent with the current Knowledge-Centered Success Article State guidance, which treats confidence, audience, and governance as distinct metadata and describes the article lifecycle as non-linear. Microsoft’s Dynamics 365 model, by contrast, documents product states including Draft, Approved, Scheduled, Published, Expired, Archived, and Discarded. These are useful reference implementations, not interchangeable definitions.

The eight-stage knowledge base content lifecycle

Stage	Suggested status	Evidence gate	Normal next state
1. Intake and triage	Requested	Real need, duplicate check, audience, risk, source, and owner recorded	Draft or No article
2. Draft	Draft	Approved template, source evidence, scope, prerequisites, and limits	In review
3. Validate and review	In review	Required factual, editorial, security, policy, and accessibility decisions	Approved or Draft
4. Approve and prepare release	Approved / Scheduled	Visibility, version, metadata, publication time, and rollback confirmed	Published
5. Publish and distribute	Published	Live rendering, access, links, navigation, search, and current version checked	Observe
6. Observe and route signals	Published + flags	Feedback and change signals reach the accountable owner	Published or Needs review
7. Revise and revalidate	Needs review / Updating	New version, impact, evidence, review, and change note completed	Published or Disposition review
8. Disposition	Deprecated / Retired / Archived / Disposed	Replacement, links, search, AI, translations, retention, and approval addressed	Archive, dispose, or republish if allowed

1. Intake and triage

Start with evidence of a reusable need: repeated tickets, a failed search, a product release, a policy change, an incident, user feedback, or an identified risk. Search for an existing answer before approving a new article. The output is not automatically a draft; it may be a decision to improve an existing page, add a synonym, change navigation, create an internal note, or reject a one-off request.

The intake record should identify the audience, knowledge domain, risk tier, accountable owner, and authoritative source. For support-derived content, use a dedicated ticket-to-article workflow so private case details do not leak into reusable guidance.

2. Draft

A draft converts the approved need into an answer that another person can validate. It should state who the article applies to, the required access or conditions, the expected outcome, and any known limits. Attach the authoritative sources or test evidence reviewers need; do not rely on an author’s memory or an unsupported AI-generated summary.

The exit gate is lifecycle evidence, not perfect prose: correct scope, a complete source trail, no unnecessary sensitive data, and conformance with the relevant knowledge base style guide. If the request duplicates a current answer, return it to triage rather than publishing another competing page.

3. Factual validation and quality review

Review requirements should follow content risk. A product setup article may need a product subject-matter expert. Billing, security, legal, privacy, or regulated instructions may require additional approvers. Editorial and accessibility checks confirm that a valid answer can actually be followed, but they do not replace factual validation.

Record a decision: approved, rejected, or changes requested. A review comment without a decision leaves the workflow ambiguous. A rejected or incomplete article returns to Draft with the missing evidence identified.

4. Approval and release preparation

Approval means the required evidence gates passed. It does not necessarily mean the page is already visible. Before release, confirm audience, permissions, category, canonical URL, version, translations, publication time, related links, and the person who can reverse a faulty change. A Scheduled status is useful when documentation must appear with a release, but it is optional.

Microsoft documents both Approved and Scheduled states and allows a publisher to define publication and expiration behavior. ServiceNow documents instant and approval-based publish flows. Your implementation may be simpler, but the transition should still show who authorized the release and which version was approved.

5. Publish and distribute

Publishing is a controlled state transition, not merely clicking a button. Test the article as the intended reader: public, authenticated, internal, partner, or restricted. Confirm that the expected version renders, meaningful images and code work, links resolve, and the article appears in the correct navigation and internal search surfaces.

Distribution means updating the places that should lead to the answer: related articles, release notes, support macros, in-product help, agent-assist systems, and approved AI knowledge sources. It does not mean adding the page everywhere. Each placement creates a dependency that must be changed if the article is later replaced or retired.

6. Observe and route signals

A live article stays Published while the team observes evidence. Useful signals include explicit correction reports, failed searches, reproducible negative feedback, a relevant release, an incident, changed permissions, broken links, and translation lag. Views alone do not prove that an article works; high traffic can mean high value or recurring confusion.

Define who receives each signal and how quickly high-risk reports are triaged. The public correction path found in our audit is useful only if reports reach someone empowered to investigate them. For a broader inventory and prioritization process, use the separate knowledge base content audit guide.

7. Revise and revalidate

A correction should create a controlled revision, not silently overwrite the only trusted copy. Where the platform supports it, keep the current version live while a new version moves through Draft, Review, and Approval. Microsoft’s current knowledge article versioning documentation is one product example: a new major or minor version can pass the standard workflow without disrupting the live article, and only one version is published at a time.

Record what changed, why, which evidence was rechecked, who approved it, and whether links, screenshots, translations, search indexes, or AI sources were affected. Updating a visible date without a substantive change is not a review. Google’s byline-date guidance says dates must describe the page’s actual publication or significant update and should not be changed merely to appear fresh.

8. Disposition

When an article should no longer serve as the current answer, choose a specific outcome. Update it if the same user need remains. Merge and redirect a duplicate when one stronger answer exists. Deprecate it when legacy users still need the old guidance. Retire or archive it when it should leave active journeys but history must remain. Dispose of it only when the applicable policy permits or requires removal.

Neither archive nor deletion is universally safer. NIST SP 800-171 Rev. 3, for example, requires CUI to follow applicable retention requirements and warns that keeping CUI after an agreement ends can increase attack surface. That rule applies to CUI, not every knowledge base, but it demonstrates why disposition must follow the actual legal, security, contractual, privacy, and operational context. Use the full knowledge base deprecation strategy for redirect, noindex, internal-search, and AI-index execution.

State-transition rules

Primary path
Requested → Draft → In review → Approved → Scheduled (optional) → Published

Revision loop
Published → Needs review / Updating → In review → Approved → Published

Disposition branch
Published or Needs review → Deprecated / Retired → Archived or Disposed

Rejection loop
In review or Approved → Draft / Updating

• Every transition needs an actor and evidence. “Changed to Approved” is incomplete without the approver, version, decision time, and evidence reviewed.
• Scheduled is optional. Use it only when release timing matters.
• Expired is a trigger, not a disposal policy. Configure whether expiry returns the article for review, removes it from search, retires it, or causes another approved action.
• Published can coexist with Updating. The live version and working version must be identifiable.
• Translations need their own state. Retiring or updating a source article may not automatically change its translated children.
• Search and AI are downstream consumers. A CMS status change is incomplete if a retired version remains retrievable in internal search, a chatbot, or a vector index.

Evidence gates for common transitions

Transition	Minimum evidence	Decision owner
Requested → Draft	User need, duplicate search, audience, source of truth, owner, risk	Intake owner or domain owner
Draft → In review	Complete scope, cited evidence, prerequisites, limits, sensitive-data check	Author
In review → Approved	Required factual and risk reviews; changes resolved; version identified	Authorized approver
Approved → Published	Visibility, release timing, rendering, links, metadata, rollback path	Publisher
Published → Needs review	Qualifying trigger with reproducible evidence or mandated review	Article/domain owner
Needs review → Published	Revalidated version, change note, affected dependencies checked	Required reviewer and publisher
Published → Retired	Reason, replacement, redirect/search/AI actions, translations, retention decision	Owner plus risk-required approvers
Archived → Disposed	Retention authority, disposal approval, audit record, recovery decision	Policy-defined authority

A reusable lifecycle record

Store this record in the knowledge platform or its connected workflow system. Do not expose internal names, sensitive evidence, or restricted source links on a public article.

KNOWLEDGE ARTICLE LIFECYCLE RECORD

Article ID:
Canonical URL:
Title:
Knowledge domain:
Audience and visibility:
Article type:

Accountable owner:
Backup owner:
Factual validator / SME:
Required approver(s):
Publisher:

Risk tier:
Authoritative source(s):
Product / policy / process version:
Locale and translation dependencies:

Current workflow status:
Confidence / validation status:
Current working version:
Current live version:
Status entered at:

Created at:
Last substantive change:
Last validated:
Maximum review interval:
Next review due:
Event-triggered review conditions:

Change evidence:
Review decision:
Approval evidence:
Change note:

Replacement article:
Redirect required:
Search index action:
AI / RAG source action:
Translations affected:

Retention authority:
Archive location:
Disposition decision:
Decision owner:
Rollback / restoration path:

Transition log

ARTICLE STATE TRANSITION

Article ID:
Previous status:
New status:
Transition date and time:
Trigger:
Requested by:
Executed by:
Evidence reviewed:
Approver:
Version affected:
Audience / visibility impact:
Link and redirect impact:
Search / AI index action:
Translations affected:
Rollback path:
Notes:

Use scheduled and event-triggered review together

One calendar interval for every article either wastes review effort on stable content or leaves volatile content wrong between reviews. Calculate the next review from the earliest applicable trigger:

Review due =
the earliest of:
1. a qualifying product, policy, security, or process change;
2. a legal, contractual, or policy deadline;
3. the article risk tier's maximum interval;
4. a verified feedback or quality threshold.

Common event triggers include a UI or API release, changed permissions, pricing or plan changes, a security advisory, a new approved workaround, an owner departure, a broken dependency, translation lag, or reproducible feedback showing that the stated outcome no longer occurs. Any interval such as 90, 180, or 365 days should be labeled as an organization’s starter configuration, not an external standard.

Our public lifecycle-signals audit

On July 29, 2026, we ran a logged-out public check on a fixed, systematic sample of 12 Guide URLs and treated this lifecycle page as a separate declared sentinel. We created the eligible Guide URL manifest first, sorted the canonical URLs, selected evenly spaced positions, and kept the target outside the sample denominator. The test checked public technical and transparency signals; it did not inspect WordPress history, private analytics, internal approvals, or account-only workflow settings.

Public signal	Systematic sample	Lifecycle-page sentinel
Final HTTP response was 200	12/12	Pass
Canonical was self-referencing	12/12	Pass
Robots allowed index/follow	12/12	Pass
BlogPosting JSON-LD parsed	12/12	Pass
Clear lifecycle-date phrase inside the content	2/12, both labeled “Last verified”	Not present
Public correction path present	12/12	Present

The results show consistent public technical hygiene in this sample: the tested pages loaded, identified themselves canonically, allowed indexing, and exposed parseable BlogPosting markup. They also expose a transparency gap: only two sampled guides displayed a clear lifecycle-date phrase in the article content, and the target page did not. A correction path was available throughout the sample and on the sentinel.

These checks do not establish factual accuracy, prove that a subject-matter expert reviewed a page, or show that Google has indexed it. Schema dates can be generated by a content system and do not prove substantive review. A visible “Last verified” statement is useful only when it reflects a real review. The audit also cannot see unpublished versions, owner assignments, approval records, next-review dates, Search Console data, internal search, or AI retrieval indexes. Results are a point-in-time public snapshot, not a guarantee of future behavior.

This distinction follows Google’s guidance: provide a prominent, accurately labeled visible date and keep it consistent with structured data, but do not change dates merely to make content appear fresh. Google also recommends original information and clear sourcing in its people-first content guidance.

Minimum viable lifecycle configuration

1. Define a short status set and the allowed transitions.
2. Assign one accountable owner and one backup owner per article or domain.
3. Define factual validators and extra approvers by risk tier.
4. Require evidence for Draft, Approved, Published, and Retired transitions.
5. Keep working and live versions distinguishable and retain change notes.
6. Connect releases, policy changes, feedback, broken links, and owner changes to review triggers.
7. Record replacement, redirect, search, AI, translation, retention, and rollback actions before disposition.
8. Measure overdue transitions and unresolved correction signals without treating views or one composite score as proof of quality.

The broader policies, decision rights, and quality controls belong in a knowledge base governance framework. The lifecycle should implement those rules without duplicating the entire governance program inside every article workflow.

Frequently asked questions

What is a knowledge base content lifecycle?

It is the controlled process that takes a knowledge article from a documented need through drafting, validation, approval, publishing, observation, revision, and final disposition. It defines statuses, transition evidence, responsibilities, versions, triggers, and downstream actions.

Is there one official knowledge article lifecycle?

No universal status sequence was found in the official sources reviewed. Microsoft, ServiceNow, Atlassian, and Knowledge-Centered Success use different models. ISO 30401:2018 addresses establishing, maintaining, reviewing, and improving a knowledge-management system, but its public abstract does not prescribe article statuses or review intervals.

Standards status (checked July 30, 2026): ISO 30401:2018 remains the current published edition, together with Amendment 1:2022 and Amendment 2:2024. ISO/DIS 30401, the proposed second edition, is still under development and has not yet replaced the 2018 edition.

How often should an article be reviewed?

Review it when the earliest qualifying event, policy deadline, risk-tier maximum interval, or verified quality signal occurs. Fast-changing or high-risk content needs tighter controls than stable explanatory content. A fixed interval is an internal configuration, not a universal standard.

Can a published article be updated without taking it offline?

Yes, if the platform supports separate working and live versions. Keep the approved version available while the revision passes review, then publish the new version through a controlled transition. Confirm the exact behavior and permissions in your product.

What is the difference between expired, retired, archived, and deleted?

Expired normally means a time condition was reached. Retired means the article is no longer an active answer. Archived means it is preserved outside normal use. Deleted or disposed means it is removed according to the applicable policy. Platforms implement these terms differently, so document your own definitions and next actions.

How does Knowledge-Centered Success relate to the lifecycle?

Knowledge-Centered Success (KCS®) integrates reuse, improvement, and creation into the flow of work. Its current Article State guidance treats the lifecycle as non-linear and separates confidence, audience, and governance. Teams can use those principles without copying KCS state names into a platform where they mean something different. KCS® is a service mark of the Consortium for Service Innovation™.

Conclusion

A dependable knowledge base does not rely on publication dates, memory, or an annual cleanup. It uses explicit states, permitted transitions, evidence gates, accountable decisions, protected versions, change triggers, and controlled disposition. Start with the smallest workflow your team can enforce, record why each article changes state, and expand controls only where risk or evidence requires them. That makes the lifecycle auditable without turning it into a bottleneck—and keeps the current answer available while the knowledge continues to evolve.