The auto-docs flow
An event in one of the source systems becomes a drafted, cited wiki page — normalized, routed, written by an LLM, and opened as a pull request for a human owner to review.
Pipeline
event → normalizer (Service Bus docs.changes) → n8n router → AI drafter (+front-matter +citation) → pull request → owner review → publish
- PR-gated — nothing publishes on its own;
git revertrolls any generated page back. - Restricted / confidential content is link-only, never mirrored into the wiki.
- Every generated page carries a source citation and lives only under
/_generated— a CI hand-edit guard keeps humans out of that tree. - Alert → runbook naming is preserved end to end, so the page you expect is the page you get.
Drive it live — the flow API
The whole pipeline is exposed as a dependency-free HTTP API. It runs offline against a mock provider by default, so you can drive it end to end on your laptop before pointing it at a live model.
Run it
Endpoints: GET /health · GET /example · POST /draft · POST /pipeline
The ServiceNow fix
Change automation now branches on the state model, not on free text — so it fires exactly once, on the right transition, keyed on a value that never changes.
The rule
The old check parsed the typed status string ("Implementing", and its typos) and keyed on the record name, so it missed changes when the wording drifted and made duplicate pages when a record was renamed. Branching on the numeric state and keying on the immutable sys_id removes both failure modes.
The moving parts
Three layers do the work: adapters turn source systems into normalized events, the core routes and drafts them into a PR, and a pluggable LLM layer writes the prose.
Docs & where to go next
Read the design behind the pipeline, walk the full setup, or step across into the neighbouring sections.