The short answer
CMDB drift is structural. Discovery tools see one truth, the CMDB stores another, and the gap widens between audits. Dock for IT ops puts a reconciliation agent on the seam. The agent reads ServiceNow CMDB and Datadog infrastructure inventory on a schedule, writes a proposed reconciliation row into a Dock asset table, and pauses for the asset owner. The owner approves or rejects in Dock. Only after approval does the agent write back to ServiceNow. The platforms keep the records. Dock keeps the interpretation.
The architecture
ServiceNow CMDB and Datadog stay the system of record for the raw data. Dock is the system of record for what the agent interprets from that data. Each Dock row carries a pointer back to the source record (servicenow_ci_sys_id, datadog_host_id), agent identity, decision, reviewer, and timestamp. The agent re-fetches CMDB state and Datadog telemetry via fresh API reads when it needs current state, so a stale row in Dock never causes a stale write to ServiceNow. The pattern generalizes to the broader Dock for IT operations cluster.
The Dock surface
A single Dock table, cmdb_reconciliation_proposals, holds one row per proposed change.
| servicenow_ci_sys_id | datadog_host_id | drift_type | agent_proposal | confidence | owner | status |
|---|---|---|---|---|---|---|
| ci_8f2a... | host_44b1 | owner_mismatch | Change owner from "platform-team" to "data-platform" per last 30d deploy actor | 0.88 | priya.r | pending_review |
| ci_71c0... | host_92ee | missing_ci | Create CI for new k8s node observed in Datadog 6 days, no CMDB record | 0.94 | jordan.k | approved |
| ci_3d49... | (none) | stale_ci | Retire CI; Datadog has reported no host for 41 days, last incident closed | 0.79 | priya.r | rejected |
Every row stamps the agent identity that drafted it, the reviewer who acted, and the decision time. That stamp is the audit trail discussed in agent audit and compliance.
The workflow
The reconciliation agent runs every six hours. It pulls a delta from Datadog's infrastructure list, pulls the matching CIs from ServiceNow via the CMDB API, and diffs them. For each mismatch it drafts a row in cmdb_reconciliation_proposals with a confidence score and a one-sentence rationale citing the evidence. The named asset owner gets a review queue in Dock. They click approve or reject. On approve, the agent re-reads ServiceNow to confirm the CI hasn't moved since the draft, then writes the change. Retirements and bulk owner changes route through the dangerous-ops contract and require a two-key handshake before the agent can commit.
Why it matters
CMDB accuracy is a compliance asset, not a hygiene one. SOX, ISO 27001, and FedRAMP all assume the CMDB reflects production. When it doesn't, every downstream control inherits the lie. Routing reconciliation through a Dock review row gives auditors a single artifact: who proposed the change, what evidence, who approved, when the write landed.
The agent is faster than a human at the diff and worse at the judgment. That split is the point. The agent drafts every proposal it can defend. The owner decides which ones land. Neither side does the other's job.
This also lets you scale reconciliation without scaling the IT ops team. One owner can clear forty proposals in an afternoon when each one arrives pre-staged with evidence. The same review row plugs into the Dock for compliance audit packet and shows up in the agent's transcript when you run agent identity lifecycle reviews.
Start here
Pick one CI class. Point a reconciliation agent at it. Watch one week of proposals flow through Dock before you expand the scope.
FAQ
Does the agent ever write to ServiceNow without approval? No. Reads are unattended. Writes require an approved Dock row, and dangerous classes of write require two reviewers.
What if the agent's proposal is wrong? The owner rejects it. The rejection is logged with a reason code. Repeated rejections of the same pattern surface in the agent's weekly performance row.
How does this differ from ServiceNow's built-in IRE? The Identification and Reconciliation Engine merges incoming CI data automatically. Dock sits one layer up: it captures the agent's interpretation of cross-platform drift between ServiceNow and Datadog and routes the judgment call to a named human before any IRE write occurs.
Can the same pattern work for non-CMDB asset data? Yes. The reconciliation row schema is generic. Swap the platform ids and the rationale field and the same flow handles software license reconciliation, CMDB cleanup, or endpoint inventory.
