When an agent proposes a production change, Jira Service Management is the wrong place to store its reasoning. The JSM ticket is the change record. What the agent saw, which runbook it pulled from Confluence, and which human signed off belongs in a structured surface the agent writes and a reviewer reads in one pass. That surface is Dock, sitting next to the change request with a hard pointer back to it.
Jira Service Management and Confluence stay the system of record for the raw data: the change ticket, implementation plan, linked runbook, CAB decision log. Dock is the system of record for what the agent interprets. Each Dock row carries a pointer back to the JSM change (jsm_change_id) and Confluence page (confluence_page_id), plus agent identity, rationale, reviewer, and timestamps. The agent re-fetches JSM and Confluence via fresh API reads whenever it needs current state.
The Dock surface: change-drafts
| jsm_change_id | confluence_runbook_id | agent | change_type | blast_radius | rationale_excerpt | approver_1 | approver_2 | status |
|---|---|---|---|---|---|---|---|---|
| CHG-4821 | RB-PG-FAILOVER | argus@dock | normal | prod-db-primary | "Patch CVE-2026-1133 on pg-primary-1. Runbook RB-PG-FAILOVER step 4 covers cutover. Read replica lag under 200ms across last 24h." | govind@dock | scout@dock | approved |
| CHG-4822 | RB-K8S-NODEPOOL | argus@dock | standard | staging-only | "Recycle staging-nodepool-b. Matches standard change template SC-07. No customer traffic." | dustin@dock | (auto) | auto-approved |
| CHG-4823 | RB-DNS-FAILOVER | argus@dock | emergency | prod-edge | "Failover api.dock.team to secondary region. p95 latency 4200ms last 10min. Runbook RB-DNS-FAILOVER step 2." | govind@dock | sentinel@dock | pending |
One change, end to end
Argus detects a CVE on the primary Postgres node. It opens CHG-4821 in JSM as a normal change. In Dock, it writes a change-drafts row with rationale, runbook section, and the read-replica lag that justifies the cutover window. Because the change touches prod-db-primary, the row is dual-keyed: two human reviewers must approve before Argus can transition CHG-4821 to "ready for implementation." Govind approves first. Scout checks the runbook excerpt against the live Confluence page and adds the second key. Only then does Argus call the JSM transition API. The Dock row records both approvers, both timestamps, and the API response.
Why this matters
Jira Service Management already supports standard, normal, and emergency change types, Change Advisory Board approvals, and risk insights (Atlassian, "Change management in Jira Service Management"). It does not have a native concept of an agent author with its own credential, a recorded chain of evidence the agent consulted, or a two-human gate that the agent cannot satisfy alone. Those belong in Dock.
ITIL 4 frames change enablement around authorized change types and explicit change authority (Wikipedia, "ITIL"). When the change author is an agent, "authorized" has to mean something stronger than a service account approval. It has to mean the agent's identity, the reviewer's identity, and the evidence the reviewer looked at are all immutable and queryable later.
This is why Dock treats production changes as a dangerous operation. The agent drafts, Dock holds the rationale, and the two-key handshake gates the JSM transition. Auditors get one query that reconstructs the entire change, with both keys cryptographically bound to the irreversible action.
See the full IT operations pattern.
FAQ
Where does the change record live?
In Jira Service Management. Dock stores the agent's draft rationale, blast-radius assessment, and approval chain, with a jsm_change_id pointer back to JSM.
What prevents the agent from approving its own change? The dual-keyed gate. Production rows require two distinct human approvers before Argus can call the JSM transition API. See agent identity.
Does the agent re-read Confluence at decision time? Yes. The runbook excerpt is captured at draft time, but Argus re-fetches the live Confluence page before executing, so any edit between draft and execution is detected.
How is this auditable?
Every row is immutable once approved. The audit query joins change-drafts to JSM and Confluence by ID, returning agent, approvers, timestamps, and runbook revision. See agent audit and compliance.
