Knowledge Base & Runbooks

How resolved incidents turn into searchable articles and reusable runbooks automatically.

When an RCA result is approved or refined by a human, PulseServe automatically drafts a knowledge-base article and a matching runbook from it — so documentation is a byproduct of resolving the incident, not a separate chore.

Knowledge articles

Articles carry a title, body, category, tags, and a state: draft, in review, published, or retired. Visibility defaults to internal for new articles. Semantic (vector) search runs over published articles, falling back to keyword search when no embedding is available — this powers both the guidance chatbot and the search box on an incident.

Runbooks

Runbooks match incidents by category, subcategory, and configuration-item class, with more specific matches ranked higher. AI-drafted runbooks land in a pending-review state and require an admin or manager to approve them before they become eligible for matching; manually created runbooks default to approved.

Human approval gate

  • Knowledge articles: draft → submitted for review → in review → published (manager-only, when the tenant requires review before publish). Only published articles are returned by search.
  • Runbooks: AI-drafted → pending review → approved by an admin or manager. Only active, approved runbooks are used for matching.

Both are consumed at incident time by the AI triage routing agent (to surface precedent) and the guidance chatbot (to answer direct questions).

Publishing a draft article

A draft article — whether written by hand or auto-drafted from an approved RCA — needs a manager to move it through review to published before it shows up in search. Until then it exists, but only in draft: nobody outside the editor can find it.

Approving a runbook

AI-drafted runbooks land in a pending-review state. An admin or manager opens it and clicks Approve before it becomes eligible for matching — an unapproved runbook is invisible to the triage agent and the guidance chatbot, even though it already exists in the system.

Writing a runbook by hand

From the Runbooks library, click + New Runbook and fill in a title, category, subcategory, and one or more steps — each step gets a title, instructions, an optional expected outcome, and an Automatable checkbox. Steps can be reordered or removed before saving. A manually created runbook is approved immediately, no review queue.

The Automatable checkbox is a label for responders, not a trigger — marking a step automatable doesn't make PulseServe execute it. It just flags "this step could reasonably be scripted" so a human or a future automation effort knows where to look.

Editing a runbook

Click Edit on any runbook to change its content — but an edit never overwrites the existing version, it creates a new one and marks the old one superseded. Any runbook execution already in progress keeps following the version it started with, so editing a runbook mid-incident can't pull the rug out from under someone actively working through its steps. The Runbook detail view has a History toggle showing every past version and when it was superseded.

PulseServe can also propose its own edits: if a new resolution matches an already-approved runbook but includes a step the runbook doesn't have, it forks a new version combining old and new steps, tagged "Refines v{N}," and drops it in the same approval queue as any AI-drafted runbook.

Archiving a runbook

Click Archive to retire a runbook that's outdated or superseded by a better one. An archived runbook stops being suggested by the triage agent and can't have a new execution started against it, regardless of its review status.

Running a runbook against an incident

On an incident, matched runbooks show up with their match confidence and historical success rate. Click Start Execution to begin — this logs the start on the incident timeline and shows the runbook's steps as a checklist. Work through each step and mark it Done, Skip, or Failed (with an optional note), then click Complete Execution once everything's resolved, or Abandon if the attempt didn't pan out. Either way, a summary posts back to the incident timeline automatically.

Example

After the NTP problem above (see Problem Management) is resolved, its approved RCA auto-drafts a knowledge-base article titled "NTP drift causes certificate and auth failures across data centres" (in draft state) and a matching runbook (pending review) with the diagnostic and remediation steps broken out. A manager reviews and publishes the article; an admin approves the runbook. The next time a similar incident fires, the triage agent surfaces the runbook with a high match score; the responder clicks Start Execution, works through its checklist, and clicks Complete Execution once the fix is confirmed — the whole run is logged on the incident timeline.