Skip to main content

Knowledge Asset Lifecycle: From Draft to Active to Retired

The lifecycle around AI context matters as much as the context itself. If a draft document can influence production answers the moment someone uploads it, your grounding layer becomes a liability. Keeptrusts solves that by making knowledge assets move through explicit states before the gateway is allowed to recall them.

Teams often describe this as a path from draft to active to retired. In the current user docs, the formal end-of-life state is archived, and some enterprise journeys include an intermediate review step before activation. The important operating principle is consistent: content should not become runtime context until it is approved, and old content should stop influencing responses without losing its audit history.

Use this page when​

  • You are defining a review and approval process for Knowledge Base content.
  • You need a simple way to explain when an asset is safe for runtime use.
  • You want a clean end-of-life path for outdated content without deleting the record.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Knowledge owners, compliance reviewers, technical leaders

The problem​

Knowledge content changes constantly. Policies get revised, pricing rules move, regional guidance changes, and support teams update playbooks after incidents. Without a formal lifecycle, those edits become dangerous in two opposite ways.

First, unfinished content leaks into production too early. A draft that was only meant for peer review becomes visible to the model, so the assistant starts answering from language that nobody has approved. Second, outdated content lingers too long. Teams upload a newer file, but the older version keeps shaping answers because there is no explicit activation step or no clear retirement path.

That is especially risky when AI answers affect customers, money, or regulated workflows. A model that cites yesterday’s shipping rule or last quarter’s internal policy is still wrong, even if the answer sounds polished.

The root cause is usually not malicious behavior. It is the lack of a publishing workflow for runtime context. Documents get edited like files, but they should be handled like controlled releases.

The solution​

Keeptrusts gives knowledge assets a governed progression instead of a loose save-and-hope workflow. In the current Knowledge Base docs, the canonical states are draft, reviewed, active, and archived. In customer journey material, enterprise flows may refer to in_review before activation. In practical terms, teams can map those states like this:

  • draft: content exists, but it is not eligible for recall
  • reviewed: content is ready for approval or governance sign-off
  • active: content can be recalled by the gateway when it is also bound to an agent
  • archived: content is retired from runtime use but preserved for audit

This model solves three important problems at once.

It separates authoring from activation. People can create and revise content without changing live model behavior. It makes approval explicit. A production response should be influenced by a promotion event, not by the mere existence of a newer file. And it preserves history. When an older version is no longer appropriate, you can remove it from runtime use without erasing evidence that it once existed.

That is why lifecycle matters for knowledge governance. It is not just about tidy states in a UI. It is how you keep grounded AI from becoming stale or premature.

Implementation​

Treat each asset like a controlled publication.

# Create the asset in a non-live state
kt kb create \
  --name "returns-policy" \
  --scope org \
  --kind upload

# Upload a reviewed change as a new version
kt kb upload --manifest returns-policy-v2.json --asset-id kb_returns_policy

# Inspect versions before changing runtime behavior
kt kb versions kb_returns_policy

# Promote the approved version to active
kt kb promote kb_returns_policy --version 2 --note "Reviewed by support operations"

After promotion, bind the active asset to the relevant agent if it is not already bound. If the policy is replaced later, update the asset, review the new immutable version, then promote that version instead of editing the active content in place.

For end-of-life, use the documented archive path rather than deleting the asset immediately. Operationally, many teams call this “retiring” the asset because it stops affecting runtime answers, but the audit trail remains available. That historical visibility is useful during incident review, legal discovery, and post-change analysis.

Learned knowledge should follow the same rule. When a conversation produces useful reusable guidance, the resulting learned_session asset should still be reviewed and promoted before it becomes active production context.

Results and impact​

Lifecycle controls reduce two expensive failure modes: draft leakage and stale guidance. Teams no longer need to choose between agility and control because they can iterate on content quickly while keeping the active version stable. That creates a safer operating loop for every group involved.

Authors get a place to work on content without impacting production. Reviewers get a clean approval checkpoint. Operators get a clear rule for what the gateway may recall. Leaders get a historical story that makes sense during audits: this version was created here, promoted here, and retired here.

That is the difference between “we uploaded a document” and “we govern the knowledge that shaped this AI answer.”

Key takeaways​

  • The formal Keeptrusts lifecycle keeps drafting, approval, activation, and retirement separate.
  • Only active assets that are also bound to an agent can influence runtime responses.
  • “Retired” is the operating idea; the documented end-of-life state is archived.
  • Immutable versions make it possible to improve content without silently rewriting production behavior.
  • Lifecycle discipline is one of the main reasons governed grounding stays reliable over time.

Next steps​