When an on-call engineer fixes an incident at 3am, the runbook in Confluence is usually wrong by morning. Dock fixes that gap. The agent watches the incident, drafts a runbook delta as a structured row in Dock, names the on-call reviewer, and waits. Confluence does not change until a human signs the proposal. The result is a runbook that drifts less and a paper trail showing who approved each edit and why.
Confluence and Notion stay the system of record for the runbook itself. Dock is the system of record for what the agent interpreted from the incident, the surrounding chatter, and the prior page version. Each Dock row carries a pointer back to the Confluence page (confluence_page_id) or Notion block (notion_block_id), plus the agent identity, the proposed diff, the on-call reviewer, the decision, and the timestamp. When the agent revises the proposal, it re-reads the live page through the Confluence API instead of trusting its own cache. See agent identity for the credential model and the audit and compliance pattern for why this split matters during postmortems.
The Dock proposal table
| dock_row_id | confluence_page_id | incident_id | proposed_change | reviewer | status | timestamp |
|---|---|---|---|---|---|---|
| rb_8821 | CONF-4711 | INC-2099 | Add step: rotate Redis replica before failover | @priya-oncall | approved | 2026-05-29 04:12 |
| rb_8822 | CONF-3380 | INC-2104 | Mark "restart api-gw" as deprecated, link to new GHA workflow | @marcus-sre | needs_changes | 2026-05-29 11:40 |
| rb_8823 | NOTION-91a | INC-2108 | Insert decision tree for partial region outage | @priya-oncall | pending | 2026-05-30 02:55 |
Each row is a complete claim: the page being edited, the incident that motivated it, the exact delta, the reviewer who owns the decision, and the state of that decision.
The workflow
The agent observes INC-2099 in PagerDuty and the Slack channel where the on-call resolves it. It reads the current Confluence runbook through the API. It drafts the delta as rb_8821, names @priya-oncall as reviewer, and pings her. Priya opens the Dock row, reads the diff against the live page, and approves. Dock then pushes the edit to Confluence under a service account that carries Priya's approval ID in the page version comment. If Priya marks needs_changes, the agent re-reads the page and re-drafts. The Confluence page never changes without that approval row. This is the same dangerous ops contract that governs production writes elsewhere, and for sensitive runbooks teams add a two-key handshake so a second reviewer signs before publish.
Why this matters
Stale runbooks are not a documentation problem. They are an incident response problem. Google's SRE workbook notes that playbooks "reduce stress, the mean time to repair (MTTR), and the risk of human error" precisely because they encode prior decisions. When the playbook lags reality, every line is suspect, and on-call engineers fall back to memory.
The conventional fix is to ask engineers to update Confluence after the incident. They do not, because they are tired and the next page is loading. Dock inverts this. The agent does the drafting work while the incident is fresh. The human does only the review, which is the part that needs judgment. The PagerDuty incident response case study referenced in the Google SRE workbook describes responders trying new recovery options "in a methodical manner" when runbooks fall short. Dock captures those new options as proposals the moment they work, so the runbook converges on reality instead of diverging from it.
The audit trail is the second payoff. Six months later, when a regulator or a new hire asks why step 4 was added, the Dock row points at INC-2099, names Priya, and timestamps the decision. The Confluence page is the artifact. Dock is the reasoning behind it. Teams running this pattern alongside their CI pipelines should also read Dock for DevOps, which covers the same split for deploy approvals.
Start with one high-traffic runbook. Wire the agent to read incidents, draft proposals into Dock, and require an on-call signature before any Confluence edit ships. See the full pattern in Dock for IT operations.
FAQ
Does Dock replace Confluence or Notion? No. The runbook lives in Confluence or Notion. Dock holds the proposal, the reviewer, and the decision. The platform stays canonical for the page content.
What stops the agent from editing Confluence directly? The agent's Confluence credential is read-only. The write path runs through a service account that requires a signed Dock approval row before it executes.
How does the agent know the page changed between draft and approval? It re-fetches the live page through the Confluence API at approval time and refuses to publish if the base version has moved. The reviewer sees a fresh diff.
Who is liable for a bad runbook edit? The reviewer named on the approved Dock row. The agent identity is recorded as the drafter, but the approval is the authoritative signature.
