Runbook authoring & import

Most teams already have runbooks: prose pages aging in Confluence. InfraSage turns them into executable, reviewable automation, and drafts new ones from incidents and templates. Every authored runbook starts at trust zero and tier T2, and cannot execute until a human reviews and promotes it.

Four ways runbooks get written

Pipeline	Input	LLM involved
Document import	Paste prose, a URL, or a Confluence page id	Yes, converts steps to a spec
From incident	A resolved incident's timeline and RCA	Yes, drafts the remediation it wishes you'd had
From template	The built-in template library	Optional polish only
By hand	A YAML spec you write	No

Importing a document

Console → Knowledge → Runbooks → Import, or:

POST /api/v1/runbooks/import
{ "source_kind": "paste" | "url" | "confluence",
  "content": "...", "title": "Payment DB pool reset",
  "operator_notes": "from the old payments wiki" }

The importer converts prose into a stepwise spec. It is deliberately conservative:

• "Confirm X before doing Y" becomes an explicit manual_confirm checkpoint that pauses execution until a human answers, with the instruction and its source quoted.
• Commands and URLs are extracted verbatim; ambiguity becomes a checkpoint, not a guess.
• Provenance is stamped (source kind, reference, content hash), and strict variable mode is forced: an unresolved {{variable}} fails compilation instead of silently becoming an empty string.

Confluence import authenticates with an API token (CONFLUENCE_BASE_URL / EMAIL / API_TOKEN). An optional drift monitor re-checks imported pages and opens a fresh draft when the source document changes, so the runbook in production never silently diverges from the wiki.

The review gate

Drafts queue in Knowledge → Runbooks → Drafts showing the generated spec, its provenance, its diff against the closest existing runbook, and the authoring cost. A reviewer either promotes it (the runbook becomes executable at tier T2) or rejects it with a reason. Both outcomes are recorded in the authoring audit trail.

:::warning Non-negotiable guardrails LLM-drafted runbooks are always born at trust 0 / tier T2 regardless of what the generated spec claims. No authoring path can create a step that auto-invokes further AI analysis. LLM authoring spend is capped by a daily budget circuit breaker. :::

The trust ladder

Runbooks earn autonomy instead of being granted it. Every execution outcome feeds a per-runbook trust score with its history visible in the catalog:

• T2: whole-runbook human approval before anything executes (where everything starts).
• T1: step-level gating for sensitive steps.
• T0: pre-approved for the narrow, proven case.

Demotion is automatic on failures; promotion is a human decision informed by the record.

API sketch

GET  /api/v1/runbooks/drafts               # review queue
POST /api/v1/runbooks/drafts               # create from a YAML spec
POST /api/v1/runbooks/drafts/from-template
POST /api/v1/runbooks/drafts/from-incident
POST /api/v1/runbooks/drafts/{id}/promote
POST /api/v1/runbooks/drafts/{id}/reject

See Runbooks for the execution side: the spec format, the DAG engine, triggers, and the approval loop.