What does Dock add on top of ServiceNow ITSM?
ServiceNow stores the incident. Dock stores the agent's reading of it. When a triage agent classifies INC0012348 as Sev-2 and drafts a runbook, ServiceNow keeps the ticket. Dock keeps the agent identity, severity rationale, runbook draft, reviewer, and timestamp. The same pattern works against Jira Service Management. Incident in the platform, interpretation in Dock, joined by a stable pointer.
Architecture
ServiceNow ITSM and Jira SM stay the system of record for the raw incident: ticket number, state, assignment group, priority, work notes, CMDB links. Dock is the system of record for what the triage agent interpreted from that incident. Each Dock row carries a pointer back to the platform record (servicenow_incident_id or jira_sm_issue_key), the agent identity, the decision, the reviewer, and the timestamp. When the agent needs current ticket state, it re-fetches from ServiceNow's Table API or Jira's REST API.
The triage table in Dock
| servicenow_incident_id | agent | severity_call | runbook_draft | reviewer | decided_at |
|---|---|---|---|---|---|
| INC0012348 | argus.triage | Sev-2, auth latency, single region | rb-auth-latency-v3 | govind | 2026-05-30 09:14 UTC |
| INC0012351 | argus.triage | Sev-3, disk pressure on logs-03 | rb-disk-pressure-v2 | dustin | 2026-05-30 09:41 UTC |
| INC0012356 | argus.triage | Sev-1, checkout 5xx, multi-region | rb-checkout-incident-v5 | govind | 2026-05-30 10:02 UTC |
Severity is a structured field. The runbook draft is a versioned pointer. Every row names a reviewer.
A worked flow
A monitor opens INC0012356. The agent reads the incident via the ServiceNow Table API, checks the change calendar, scans the CMDB for affected CIs, and writes a Dock row: Sev-1, suspected cause the 09:48 checkout deploy, runbook draft rb-checkout-incident-v5 with a proposed rollback. The row is unapproved. Govind opens it, edits one paragraph, and approves. Only then does the agent post the runbook as a work note on the ServiceNow incident. The rollback is a dangerous op and runs under a two-key handshake before any production change.
Why this matters
ServiceNow tells you what is broken. It does not tell you which agent decided it was Sev-1, which runbook it drafted, or who approved. That gap is where agent-on-ITSM deployments lose their audit trail.
ITIL 4 frames an incident as "an unplanned interruption to an IT service or reduction in the quality of an IT service" and asks the practice to restore "normal service operation … as quickly as possible" (Incident management (ITSM)). Speed is the goal. Attribution is the price of doing it with agents. ServiceNow is itself described as a platform for "the creation and management of automated business workflows" (ServiceNow); automation without attribution is what auditors flag.
Dock closes that gap with one row per decision, each pointing back at the ServiceNow record. That is the shape your SOC 2 evidence needs.
Get started
Read the cluster pillar at Dock for IT operations and wire ServiceNow as the system of record, Dock as the interpretation layer.
FAQ
Does Dock replace ServiceNow ITSM?
No. ServiceNow keeps the incident, the CMDB, the change calendar, and the SLA clock. Dock keeps the agent's severity call, runbook draft, reviewer, and timestamp, with a pointer back to the ServiceNow incident.
How is this different from writing work notes on the incident?
Work notes are free text. Severity, runbook version, and reviewer become structured fields in Dock, queryable for agent audit and compliance and reusable as Dock for compliance evidence.
What stops the agent from running a rollback on its own?
The runbook draft is unapproved by default. Rollback is bound to the dangerous-ops contract and executed under a two-key handshake, attributed to the agent's identity provisioned through the agent identity lifecycle.
Does this work for Jira Service Management too?
Yes. Swap servicenow_incident_id for jira_sm_issue_key. Platform holds the ticket, Dock holds the interpretation, agent re-fetches current state on every read.