The CSDM 5.0 model

Here is the one-sentence version of CSDM that settles most modeling arguments: every entity in the model exists because a specific workflow consumes it — and an entity nothing consumes should not exist. The diagram isn't an org chart for technology; it's a set of contracts between data and the processes that run on it. Read the ladder that way and the design decisions mostly make themselves. The authoritative text throughout is ServiceNow's CSDM 5.0 White Paper — every bare page reference on this page cites it.

The ladder, read by consumer

Explore the model

The white paper publishes its prescribed relationships as a picture. A picture can't be queried, so we transcribed it: 35 relationships across 26 entities, with the distinction most diagrams lose — whether an arrow is a real CMDB relationship that impact analysis can walk, a reference field, or a many-to-many map. Everything below is drawn from that one dataset. Select any entity to see exactly what the model prescribes, and where it is silent. Transcribing it also surfaced the places the source contradicts itself — checkable against the document you already have, with what we emit for each.

Then press Show my numbers. The map stops being a poster and becomes a way in: each class carries how many records of it exist in the estate and how many configuration items sit beneath them. A class with nothing under it is a finding, not a blank. (The numbers here are from a fabricated example estate; in the product they are yours.)

Walk it

The map shows you everything at once. Sometimes you want the opposite — to stand on one entity and move. Below, the cursor stays where you put it while you change lens, and the Plain English toggle changes the language without changing the model: one node, two labels, never two diagrams that quietly disagree.

The same model as a matrix

A node-link map cannot show you sparsity, and it cannot show you that one entity is a solid column of inbound arrows. The same relationships as a grid answer a different question: not “what connects to what” but “how much of this model is deliberately empty”.

Say it in your words

The hard part of CSDM is rarely the schema. It is translating what people actually say into what the model actually stores. Below are things a stakeholder says out loud, and where each one lands.

The Armature Service Model — a fixed core, a flexible form

ServiceMatch ships three standard target shapes: Full Rollup (every device under its device-management service), Full CSDM (the complete capability tree), and the Armature Service Model — the flexible middle. The Armature shape models only the layers that run workflows today: technology-management offerings that park every device with an accountable owner, plus the business offerings your evidence actually supports. Business capabilities and application portfolios are deliberately deferred — they're planning objects, and modeling them before anyone consumes them produces diagrams, not operations.

The name is the message. An armature is the rigid inner skeleton a sculptor builds the flexible material around: the form can change completely, the skeleton holding it up does not. The offering layer is that skeleton — every device parked, every offering owned, every relationship exclusive. The business tier above it takes whatever shape your services actually have. It flexes by adoption stage — the crawl and walk shapes emit the Armature model; run and fly unlock the capability tier — and it firms up as interview claims and device evidence accrue. Capture is never gated; only the emitted shape flexes. Staged emission is governed by Adoption stages.

Offerings stratify commitment, not software

The most common offering mistake is treating offerings as a list of applications. An offering answers "delivered to whom, at what level?" — Email — Executive, 24×7 and Email — Standard are offerings. Exchange is not; it's the application underneath. If two offerings would have identical support structure, audience, and commitments, they are one offering wearing two names.

Which is the test for whether an offering is real: an offering is the things it carries. Strip the commitments off and two offerings that looked distinct become the same record twice — because the audience, the support structure and the terms were the only things telling them apart. That is why the model puts SLA, support group and change approval on the offering rather than on the service above it. The service is what people call it; the offering is what you promised, to whom, and who answers.

The application ≠ service test

The single most common CSDM failure is collapsing Business Applications into Business Services. The test is callable: would the help desk take a ticket for it, and is one person accountable for it? Email passes — it's a service. The mail platform doesn't — it's an application in the portfolio. Our stakeholder interview probes this distinction explicitly, because stakeholders volunteer application names and almost never volunteer services.

Run something you are unsure about through the same four questions our interview asks:

Where devices attach

Infrastructure joins the service layer through Dynamic CI Groups: living, query-populated memberships that follow the estate as it changes. One offering-to-group relationship replaces thousands of hand-made CI relationships, and support-group data propagates through it — so "who supports this box" is a property of the model, not a spreadsheet. End-user devices attach to the technology management services that operate them; hosting infrastructure earns business placements on evidence (see CSDM doctrine).

What 5.0 changed — and the rename that didn't rename the data

• →"Technical Service" is now "Technology Management Service" — but the service_classification choice value still says Technical Service. Labels moved; stored values didn't. Automation keyed to the display name breaks quietly. Our emission pins the legacy value in conformance tests.
• →Service Instance generalizes Application Service, extending the pattern to data, network, and operational services — additive, not breaking.
• →5.0 is incremental, not a rewrite. The paper calls it “an incremental and expanded version” of CSDM 4 (p.3) and says not all products must adopt it at once (p.50) — though it does ship migration guidance, so “backward compatible” would be our word, not theirs. Adoption is incremental, which is why staged emission (see Adoption stages) is the delivery shape the spec itself implies.
• →5.0 is still moving. A July 2026 addendum published under the 5.0 banner formalises AI assets in the model — AI Function, AI Model Deployment, MCP Function, AI Application — plus a new Digital System class that groups Business Applications, a re-introduced DevOps Package, and two new lifecycle states. Worth knowing what it is and is not: it is guidance on modeling AI as configuration items, not guidance on AI populating the model. The dataset on this page is the May 2025 white paper; the addendum is not in it yet, and we would rather say so than let a reader assume the transcription is current with every supplement.

Non-negotiables we validate

Stage 4.5 checks a model against these and reports what fails. Two of them restate the white paper; three are ours, flagged because the model is unactionable without them. Which is which matters more than the rules do — the source describes far more than it mandates, so treat anything below phrased as a requirement as a ServiceMatch choice unless the second column says otherwise.

The rules themselves:

Where the source contradicts itself

Transcribing the figures rather than reading the summaries turned up six places where the white paper disagrees with itself. They are recorded here because anyone building an importer against that document will hit them, and because absence of errata in every other CSDM resource is not evidence that the document is clean.