A change-management workflow with dual-keyed approval routes a proposed production change through three checkpoints: an agent drafts the change request, a Change Advisory Board reviews it inside the ticket of record, and two named principals must both sign before a deploy can run. Jira Service Management or ServiceNow holds the change ticket. Dock holds what the agent decided, who reviewed, and which two keys turned. The deploy fires only after both signatures land on the same Dock row.
The architecture
Jira Service Management and ServiceNow stay the system of record for the raw change ticket: the CR number, the affected CI, the planned window, the rollback plan, the linked incident. Dock is the system of record for what the agent interprets from that ticket. Each Dock row carries a pointer back to the platform record as jira_change_id or snow_change_id, the agent identity that drafted the request, the CAB decision, the two reviewers, and the timestamp of each signature. The agent re-fetches the current ticket state via fresh API reads before it asks for the second key, so a CAB rejection landed in ServiceNow after the first signature cannot be missed.
The Dock surface
| change_id | jira_change_id | agent | risk | cab_decision | key_1 | key_2 | deploy |
|---|---|---|---|---|---|---|---|
| CHG-4471 | JSM-CHG-8821 | agent.ops.drafter | medium | approved 2026-05-29 | govind 14:02 | sentinel 14:07 | fired |
| CHG-4472 | SNOW-CHG-2210 | agent.ops.drafter | high | deferred to next CAB | pending | pending | blocked |
| CHG-4473 | JSM-CHG-8830 | agent.ops.drafter | low (standard) | pre-approved template | dustin 09:11 | flint 09:14 | fired |
The table is the audit trail. Anyone asking "who approved CHG-4471" reads two names and two timestamps from one row, not a thread.
The worked workflow
A noisy alert fires on the payments API. The agent opens the linked incident, drafts a change request, and posts it to Jira Service Management as JSM-CHG-8821. It writes a paired Dock row with the proposed diff, the rollback script, the blast radius, and its own confidence score. The CAB reviews inside Jira, marks the change approved, and the agent re-reads Jira to confirm. The Dock row now needs two signatures: one from the on-call SRE, one from a service owner. The first key lands. The agent re-fetches Jira one more time, sees no late objection, and waits for the second. When both keys are recorded on the row, the dual-keyed gate fires the deploy. If either key is missing at the deploy window, nothing runs.
Why it matters
ITIL 4 describes change enablement as a practice that maximises successful changes by ensuring risks are assessed, changes are authorised, and a schedule is managed [1]. ISO/IEC 20000-1:2018 requires that changes to services be planned, approved by an authorised party, and recorded [2]. Both standards assume an auditable trail of who decided what, and when. The Dock row is that trail in machine-readable form.
The architecture also closes the credential gap. The agent never holds deploy keys. It drafts, posts, and waits. The deploy script reads the Dock row and refuses to run unless both signature fields are filled by named agent identities inside the approval window. This is the dangerous-ops contract applied to production: the action is irreversible, so it requires two principals to authorise it.
The CAB does not lose visibility either. Jira Service Management still shows the change record, the linked incident, and the deploy outcome. Dock adds the interpretation layer: the agent's draft reasoning, the reviewer notes, the gate state. Compliance auditors get a single export covering both halves.
Read the IT-ops pillar for the full surface map, including incident response and the broader dangerous-ops contract Dock enforces on every production write.
FAQ
Does the agent ever push the deploy itself? No. The agent drafts and posts. The deploy script reads the Dock row and runs only when both signature fields are filled by valid agent identities.
What happens if the CAB rejects after the first key is in? The agent re-fetches Jira or ServiceNow before requesting the second key. A rejection blocks the second-key request, and the gate stays closed.
Why two systems instead of one? Jira Service Management and ServiceNow are designed for ticket lifecycle. Dock is designed for agent-decision records. Splitting them keeps each system honest about what it owns.
Are standard pre-approved changes still dual-keyed? Yes. Even low-risk standard changes record two signatures on the Dock row. The keys may be faster to obtain, but the trail is the same.
[1] AXELOS, ITIL 4 Foundation, change enablement practice guidance, axelos.com. [2] ISO/IEC 20000-1:2018, Information technology, Service management, Part 1: Service management system requirements, iso.org.
