Knowledge base update trigger

A knowledge base update trigger turns a completed close into a candidate article when the record shows the team lacked a reusable answer. The agent does not publish. It detects the gap, drafts a structured article from the closure evidence, and places that draft in a review queue for a knowledge owner.

This page is for the person who owns operations knowledge quality: the reviewer who decides whether a draft is accurate, scoped correctly, and ready to go live. Related work often sits next to lessons-learned extraction, SOP gap identification, and automated closure summary. Those outputs can feed this trigger, but they are not substitutes for a reviewed knowledge base article.

The trigger fires only when both of the following are present and usable:

1. A closure record that identifies the work item, the outcome, the people involved, and the resolution path.
2. Gap evidence that shows why existing knowledge failed the team: missing article, outdated procedure, conflicting guidance, or a workaround that had to be invented under pressure.

Typical gap signals include repeated ad-hoc research during the incident, a resolution that depended on tribal knowledge, a documented procedure that did not match the real system state, or an explicit note that no authoritative source existed. A clean close with a known playbook and no residual ambiguity should not create a draft.

If the closure record is missing, incomplete, or the gap evidence cannot be tied to that closure, the agent returns empty output. Empty output is the correct result. It prevents speculative articles that invent process from thin air.

Given a valid closure and gap evidence, the agent assembles a draft article rather than a free-form note. The draft should be readable as a first cut for publication, not as a dump of ticket text.

A useful draft typically includes:

• A precise title that names the situation, not the ticket ID
• The conditions under which the guidance applies
• The steps or decision criteria that resolved the issue
• Preconditions, constraints, and failure modes discovered during close
• Links or references to the source systems and the originating closure (for audit, not for end users)
• Explicit unknowns: anything the closure did not settle

The agent should ground every substantive claim in the closure record or the attached gap evidence. Where the record is silent, the draft should mark the gap instead of filling it with plausible language. That habit keeps review honest: the knowledge owner can see what still needs a human decision.

Tone stays instructional. The audience for the eventual article is the next operator who hits the same condition, so the draft should read like guidance, not like a postmortem narrative. Narrative detail that helped diagnose the case can stay in linked close artifacts; the article should carry what someone must know to act.

Human-in-the-loop is mandatory. The agent proposes; the reviewer publishes, edits, merges, or rejects.

Review focus usually covers four questions:

Is the gap real? Confirm that existing articles do not already cover the case under a different title, or that an update to an existing page is better than a new one.

Is the draft accurate? Check steps, thresholds, ownership, and system names against how the environment actually works today, not only against how this one close unfolded.

Is the scope right? A draft that over-generalizes from a single edge case can create worse guidance than silence. Narrow the article or fold the content into an SOP update when the pattern is not yet stable.

Is it publishable? Fix clarity, remove internal-only identifiers where needed, attach ownership for future maintenance, and set the visibility or audience rules your knowledge base uses.

Rejection is a valid outcome. Common rejection reasons include insufficient evidence, duplicate coverage, unresolved safety or compliance questions, and closures that were unique enough that writing them down would mislead the next reader. When rejecting, leave a short reason so the trigger can be tuned and so operators do not re-open the same draft cycle without new evidence.

Required inputs

• Closure record with identifiers, timestamps, resolution summary, and linked artifacts
• Gap evidence: missing or failed knowledge references, reviewer or resolver notes, or structured flags from related close-stage jobs
• Knowledge base context for duplicate detection: titles, tags, and article status for overlapping topics

Expected output

• A draft article in the staging or review queue
• Provenance: which closure and which gap signals produced the draft
• A short reviewer brief: why the gap was flagged and what still needs confirmation

Empty output

Return nothing when the closure record is absent, when gap evidence is absent or cannot be attributed to that closure, or when duplicate detection shows an equivalent article already exists and no material delta is present. Empty output should be logged as a non-event, not as a failed run, so monitoring does not treat healthy restraint as an error.

Treat this trigger as part of close hygiene, not as a content farm. Volume is not the goal. The goal is that each published article removes a real failure mode from the next similar incident.

Practical operating habits:

• Keep the review SLA short enough that drafts still match current systems, and long enough that reviewers can verify claims.
• Prefer updating an existing article when the gap is obsolescence rather than absence.
• Align tags and ownership with your knowledge taxonomy so drafts land with the right reviewer.
• Feed accepted and rejected outcomes back into detection rules so the same false gap does not keep reappearing.
• Coordinate with lessons-learned and SOP-gap workflows so one closure does not spawn three conflicting artifacts about the same fact.

When the loop works, closures that expose missing knowledge leave a reviewed article behind, and closures that do not expose a gap leave the knowledge base alone.