Home/Systems/Documentation automation
OP-06 · AI WORKFORCE · REPLACES THE DOCS BACKLOG

Documentation automation that keeps your docs current.

Documentation automation with AI is a system that reads your product, your support history, and your existing docs, finds where the documentation is missing or wrong, and drafts the fix, with a person approving every change before it is published. The version Paul Rahme built at a US marina-management software company, for its marina-management software audits the docs against the product and the support log, drafts what is missing, files each draft for review, and applies the approved updates. It is the same documentation the support agent and the voice agent answer from, so this audit is what keeps their answers true.

2 workflows docs-gap audit and apply-updates Human review on every draft before it ships Feeds the support and voice agents
Book the Automation Audit → Watch the scale model ↓ Free · 30 minutes · you leave with a written Automation Map

Scale model of the system

docs.audit — scale model

Scale model of documentation automation: documentation scanned against the product and support log, gaps found, drafts filed for review.

THE GRIND IT REPLACES

Why the docs backlog never gets written

Every product team has a docs backlog. Features ship and the docs lag. Support answers the same how-to question in ten different tickets because the article that should exist does not. Nobody owns the gap: the engineers who know the answer are shipping the next thing, and the support team that sees the gap every day does not write the docs.

The cost hides in the support log. Each missing article is a question answered by hand, again and again, and a ticket a machine could have closed if the answer had been written down. When a support agent or a phone agent may only answer from documentation, every gap is a call it must hand to a person. A manual audit takes days and is stale a week later. That is the shape of work a system should do.

WHAT THE SYSTEM DOES

AI that drafts the missing docs and files them for review

Audits the docs against the product as it is today, not as it was when the page was written.
Reads the support log for the questions customers keep asking that the docs never answer.
Finds genuine gaps: missing articles, outdated steps, answers that contradict the product.
Drafts the missing or corrected content in the structure and voice of the docs around it.
Tags and files every draft for review, so a person sees what changed and why.
Applies approved updates to the documentation source once a reviewer signs off.
Feeds the support agent and the voice agent, which answer only from these docs.
Does not publish on its own. Nothing goes live without a human approval.
HOW IT WORKS

How the documentation gap analysis runs, step by step

Two workflows with a person between them. The docs-gap audit finds and drafts. The apply-updates workflow publishes what a reviewer approved.

01

Collect

Each run pulls the current documentation source, the product it describes, and the recent support log into one working set.

02

Compare

Docs against product: which steps, settings, and screens no longer match. Docs against support log: which questions keep returning with no article to answer them.

03

Judge the gap

Not every mismatch is a gap. The workflow drops duplicates, one-off questions, and cosmetic differences, and keeps what is genuinely missing or wrong.

04

Draft

For each genuine gap, the model drafts the missing article or the corrected section, matching the docs around it and citing what prompted it.

05

Tag and file for review

Each draft is tagged and filed in GitHub. The reviewer sees the draft, the evidence behind it, and the exact change to the source.

06

Apply approved updates

Once a reviewer approves, the apply-updates workflow writes the change into the documentation source. Anything rejected does not ship.

UNDER THE HOOD

What documentation automation runs on: n8n, GitHub, and LLM review

n8n orchestrates: it runs both workflows, holds state, queues drafts, and pings the reviewer. Node workflows read and diff. LLMs judge and draft. GitHub holds the docs source and the review queue, so every change is versioned.

N8NNODE WORKFLOWSCLAUDE / LLMSGITHUB
ORCHESTRATION
n8n runs both workflows, keeps state between steps, queues drafts, and notifies a person when one is needed.
MODELS
LLMs for comparison, gap judgement, and drafting, chosen per task. The workflow, not the model, decides what ships.
KNOWLEDGE
Three inputs: the documentation source, the product it describes, and the support log. Output goes back to the same source.
GUARDRAILS
Proposes only. Every draft carries its evidence. Nothing publishes without approval.
INTEGRATIONS
GitHub for the docs source and review queue. The support agent and the voice agent read the same documentation.
OBSERVABILITY
Every run leaves a record: what was compared, which gaps were kept, which drafts were filed, who approved what.
DATA & SECURITY
Model calls run through your own AWS account (Bedrock), so your data is not used to train provider models and Aldenebai holds no keys. Ticket content and the audit trail stay in your systems; PII is redacted before model calls where required; retention is set by you.
WORKS WITH
Runs today on n8n and GitHub with LLM review. The same workflows run against Confluence, Notion, GitBook, or a docs repo on GitLab, and take their gap signals from Zendesk, Freshdesk, or Intercom.
RUNS ON
Your infrastructure, under your access controls.
GUARDRAILS & THE HUMAN IN THE LOOP

Why a reviewer sees every draft before it ships

A documentation system that writes confidently and wrongly is worse than no system. The support agent and the voice agent answer only from the docs, so one bad article becomes a bad answer at scale. The workflow is built around that risk. It proposes; it does not publish. Every draft is tied to its evidence, so the reviewer checks a claim against its source instead of reading blind.

The reviewer sees three things: the draft, what prompted it, and the exact change. Approve, and the apply-updates workflow ships it. Reject, and nothing moves. The judgement stays with your team. The reading, the comparing, and the first draft move to the machine.

Proposes only. No draft is published without a human approval.
Evidence on every draft: the ticket, the product behaviour, or the outdated step behind it.
Gap filtering before drafting, so reviewers see real gaps, not noise.
Versioned through GitHub, so every update is reviewable and reversible.
Tagged drafts, so corrections can be taken before new articles.
Docs-only downstream: the agents that read these docs answer from nothing else.
RESULTS IN PRODUCTION

What changes when the docs stop lagging

2
workflows: docs-gap audit and apply-updates, a reviewer between them
0
drafts published without a human approval
~60%
of tickets the support agent resolves from these docs (the agent’s figure, not this system’s)

Documentation automation has no published figures of its own yet; the ~60% is the support agent’s, defined on its case study.

WHO THIS IS FOR

Knowledge base automation for support teams and the engineers behind them

Software teams with a product that changes, a support queue that repeats itself, and a knowledge base that should answer the questions but does not. It matters most for teams running or planning an AI support agent or a phone agent, because those agents are only as good as the docs they read.

You need three things: a documentation source the system can read and write (a repo, a help centre, a knowledge base), a support log, and one person who owns review. The Automation Audit maps the rest. The build is fixed scope, fixed price, agreed before any work starts, on the same workflow automation foundation as the other systems.

B2B SAASMARINA & DEALER SOFTWARESUPPORT TEAMSHELP CENTRES
Not sure how far behind your docs are?
The Automation Audit looks at your docs, your product, and your support log — and tells you where the gaps are and what closing them would return, before you spend anything.
Book the Automation Audit →

Questions teams ask about documentation automation with AI

What does documentation automation with AI actually do?

It reads your documentation, your product, and your support log, finds where the docs are missing or wrong, drafts the fix, and files it for a person to review. Approved changes are applied to the documentation source. Nothing is published on its own.

How does the documentation gap analysis decide what is a real gap?

It compares the docs against the product as it is today and against the questions that keep returning in the support log. Duplicates, one-off questions, and cosmetic differences are dropped. What is left is missing, outdated, or contradicts the product, and each kept gap carries the evidence behind it.

Will the AI publish documentation without a human reading it?

No. The system is two workflows with a person between them. The docs-gap audit drafts and files; the apply-updates workflow ships only what a reviewer has approved. Reject a draft and nothing moves.

How does this feed an AI support agent or a voice agent?

Both agents answer from documentation only, so every gap in the docs is a question they must hand to a human. Keeping the docs current widens what they can resolve on their own. The voice agent also files a GitHub issue each time a caller hits a documentation gap, one more signal of where the docs are thin.

What do we need in place for knowledge base automation to work for our support team?

A documentation source the system can read and write, such as a repo, a help centre, or a knowledge base; a support log; and one person who owns review. The Automation Audit maps the rest. The build is fixed scope, fixed price, agreed before any work starts.

Stop writing docs by hand. Start reviewing them.

The free Automation Audit looks at your documentation, your product, and your support log — and tells you honestly where the gaps are and what a system would close. 30 minutes, written Automation Map included.

Audit: free, 30 min →