CSDM

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 ladder, read by consumer

Entity	Table	Who consumes it
Business Capability	cmdb_ci_business_capability	Strategy and portfolio planning — what the business does, independent of any technology.
Business Service	cmdb_ci_service_business	The help desk and the business: what people would call about, with an accountable owner.
Business Service Offering	service_offering	The catalog and its subscribers: the commitment tier — audience, environment, SLA.
Business Application	cmdb_ci_business_app	Application portfolio management: rationalization, spend, lifecycle. Never incident routing.
Application Service	cmdb_ci_service_auto	Operations: incident routing, change impact, event correlation — the deployed, running instance.
Technology Management Service	cmdb_ci_service_technical	IT itself: how the estate is operated; default assignment when a CI has no support group.
Dynamic CI Group	cmdb_ci_query_based_service	The membership machinery: query-populated groups binding offerings to the CIs that deliver them.
Device CIs	cmdb_ci_* (leaf classes)	Everything above — which is why identity and classification quality decide the whole model’s fate.

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. Exchangeis not; it's the application underneath. If two offerings would have identical support structure, audience, and commitments, they are one offering wearing two names.

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.

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 Attribution & coverage).

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 deliberately backward compatible. 4.0 investments stand and adoption is incremental — which is why staged emission (see Adoption stages) is the delivery shape the spec itself implies.

Non-negotiables we validate

Every Application Service has a corresponding Business Service Offering.
Every CI references a Product Model.
Every Business Application maps to at least one Application Service.
Every Business Service has a named Service Owner.
Applications handling regulated data carry Information Objects.

Why table-level precision matters

These entities drive incident routing, change impact, and portfolio reporting. A model that's right at the diagram level and wrong at the table level fails exactly when those workflows fire — which is the worst possible time to find out.