What is an anti-CMDB

An anti-CMDB is a system of record for an organization's people, devices, applications and access that maintains itself from the systems that already hold that data, rather than depending on people to keep records accurate by hand. The term is a deliberate break from the configuration management database (CMDB), the component of traditional IT service management that was meant to be the single source of truth and, in most organizations, became the single source of doubt.

Why CMDBs fail

A CMDB is a database of configuration items, the servers, applications, devices and services an IT team manages, and the relationships between them. The design assumes someone will enter each item and update it when things change. That assumption held when an enterprise ran a few hundred servers in its own data center. It does not hold when the estate is thousands of laptops, hundreds of SaaS apps, cloud accounts that appear and disappear hourly, and an org chart that changes every week.

The result is predictable and widely reported: the CMDB is populated once during an implementation, drifts immediately, and within a year nobody trusts it. Discovery tools help with hardware but know nothing about who owns what, which team actually uses an application, or whether a contractor's access should have expired. Every process built on top of the CMDB, change management, impact analysis, incident correlation, inherits the staleness.

What an anti-CMDB does differently

Four properties separate an anti-CMDB from the database it replaces:

1. It is built from sources, not entered. Identity providers, HR systems, device management, cloud accounts and SaaS admin consoles already know most of what a CMDB is supposed to contain. An anti-CMDB ingests from them continuously and never asks a person to type a record.
2. It reconciles identities. The same person is user 4471 in the IdP, employee E-2093 in HR and a hostname in device management. An anti-CMDB resolves those into one entity with every ID attached, so a question about a person returns everything about that person.
3. Every fact carries provenance. Each attribute records which system it came from, when it was observed and how confident the system is. A reader can trace any answer back to its source and see how fresh it is.
4. It stores relationships as first-class data. Who reports to whom, which app talks to which, what a firewall rule affects. That is what makes impact analysis a query rather than a research project.

What it enables

With a model that is actually current, an AI agent can act on it. It can answer "who has access to the production database" without a ticket, compute the blast radius of a change before the change runs, notice that a departed employee still has three active accounts, and resolve an access request knowing the requester's role, device status and approver without asking. None of that is safe on a CMDB that is 40% wrong.

Anti-CMDB and Axiom™

Axiom™ is STLabs' implementation of this idea: a live graph of people, devices, apps and access at the center of the platform, built from the tools an organization already runs and kept current without manual maintenance. It is the reason the term exists. See how Axiom™ works or the FAQ for how it differs from a traditional CMDB.

Related terms

• CMDB (configuration management database): the manually maintained system of record in traditional ITSM
• Configuration item (CI): a single tracked thing in a CMDB
• Digital twin: a general term for a live model of a real system; an anti-CMDB is a digital twin of an organization's IT and people
• Knowledge graph: the data structure most anti-CMDBs use, storing entities and relationships rather than rows
• IT asset management (ITAM): the discipline of tracking hardware and software assets; an anti-CMDB covers assets as one entity type among several