CSDM
CSDM doctrine: where practitioners disagree
Ask five CSDM practitioners how to build a service model and you will get five answers, delivered with confidence, that appear to contradict each other. The usual explanation is that CSDM is underspecified. That is not what is happening. Most CSDM arguments are people taking positions on different questions while believing they are answering the same one.
There are four questions, not one. Separate them and most of the disagreement resolves into compatible positions — and the residue that remains is genuinely interesting.
The four axes
| Axis | The question it answers | Commonly mistaken for |
|---|---|---|
| A — Design order | Which layer do you model first? | Implementation depth |
| B — Implementation depth | How much of the modelled estate do you deploy now? | Design order |
| C — Attribution confidence | What evidence do you require before asserting a placement? | Both of the above |
| D — Attribution scope | Which populations of the estate are eligible to carry a business-service claim at all? | Attribution confidence |
A method can be top-down on axis A, crawl-stage on axis B, willing to accept structural defaults on axis C, and server-first on axis D — hosting infrastructure eligible for business claims, end-user devices not — and be entirely coherent. Two practitioners who agree on A and B can still argue bitterly, because their real disagreement is on C or D and neither has named it. C and D compose rather than compete: in any coverage figure, C governs the numerator and D the denominator — two people quoting wildly different coverage for the same estate are usually disagreeing about a denominator neither has declared. D is the newest of the four, and its pattern is old elsewhere — epidemiology calls it the denominator problem, and ServiceNow’s own CMDB Health scopes its measured population through inclusion rules. What we have not found anywhere is this dial named for business-service attribution; the prior art is walked in our paper, Four Questions Hiding in Every CSDM Argument.
The sources keep A and B apart — the slogans don’t
It would be tidy if the confusion between A and B started in the careful sources. It does not. A widely-read practitioner post on CSDM remediation, published in ServiceNow’s community (March 2026), argues that a durable taxonomy is designed from the top of the CSDM hierarchy down. ServiceNow’s CSDM 5.0 White Paper — the model’s authoritative text, and the document every page reference on this page cites — puts Business Capability, the very top of that hierarchy, in the Fly stage of its staged adoption, the last thing you implement. That looks like a contradiction, and neither source makes one.
The post separates the two orders itself, in its own closing line: “Design the taxonomy before the CMDB. Govern it after.” Design first; populate later, under governance. And the white paper stages what you implement — it never says don’t model capabilities early, it says don’t populate them early (p.56, with staged adoption recommended at p.51). Design top-down, deploy top-last: two orderings, opposite directions, no tension — each source careful about which one it means.
Where the tension actually lives
Downstream, where the axis gets stripped off in transit. “Start with capabilities” and “capabilities come last” are both faithful summaries of their sources, and two delivery teams can argue them across a table for an afternoon without discovering that one is a claim about A and the other a claim about B. The sources kept the distinction; the slogans lost it.
Where the model actually rules
Shape-neutrality is not “anything goes.” CSDM 5.0 contains hard edges, and they are the referee in any disagreement. A representative set:
- There is no Business Service Offering → Infrastructure CI relationship. Not deprecated — absent. Business offerings reach devices only through a Service Instance or a Technology Management Service-side Dynamic CI Group.
- A CI should not reach multiple Technology Management Services through Dynamic CI Groups — the paper’s own word (p.44), and it gives the mechanism: Data Sync copies Managed By, Support Group and Change Group down through the group onto the CI, so overlapping membership overwrites CI data. We enforce it as hard; the source recommends it.
- Business Application is not an operational CI and should not be used in Incident, Problem or Change — p.53, which capitalises the NOT. Neither is SDLC Component.
- Omit the Business Application → Application Service relationship and Technology Portfolio Management risk assessment stops functioning.
- Every operational business or technology management service should have at least one offering. Beyond that minimum, no bound on granularity is stated anywhere.
- Business Capability hierarchies are capped at six levels, with no circular parentage.
Everything outside that boundary is a choice — and a delivery partner should be free to make it. If you deliver CSDM and want to see your doctrine run on this frame — your design order, your depth, your bar — write us: info@swipeleft.ai. That conversation starts with which axis you are on, and it is the fastest way to find out whether we are wrong.
Check any pairing against it. The verdict is not our opinion — it is either a relationship from the prescribed set, or a documented absence with the legal route offered in its place.
Business Service Offering has 1 prescribed relationship out of 25 possible targets — marked ● in the list. The count beside each entity on the left is its outbound total. Most are 1 or 2: 35 relationships across 676 possible pairs is 5.2% density, and the empty cells are the majority of the model.
This relationship does not exist
The prescribed set contains no Business Service Offering → Infrastructure CI relationship. The dependency routes run through a Service Instance, or through a Technology Management Service Offering and its Dynamic CI Group. Not the only traversable routes: edge 26 is bidirectional, so 26 → 28 → 24 also reaches infrastructure — it carries data flow rather than dependency, but it is a cmdb_rel_ci row and impact analysis walks it.
What to do instead
Through a Service Instance
The final hop is membership rather than a prescribed relationship — a query-based Service Instance carries its CIs through a CMDB Group.
What the platform already does — and which axis each answers
A fair question to ask anyone writing about CSDM: do they know what is already in the box? The platform ships a great deal of machinery that touches these axes, some of it excellent, and any position that pretends otherwise is not worth reading. So here is the honest map — each mechanism, what it decides, and what it leaves behind.
| Mechanism | What it decides | What it leaves behind |
|---|---|---|
| Service Mapping | Which components belong to an application service — top-down patterns, traffic fingerprinting, tag-based maps | The connection, flagged if a human added it by hand rather than discovering it |
| ML connection suggestions | A confidence tag per suggested connection — and a connection rule can add suggestions automatically; the documented example is a rule for any connection with confidence High | The connection, plus a Decision marker on the suggestion that reverts to Undecided if the rule is later retired |
| IRE reconciliation | Which source may write a CI attribute, by a precedence rank configured in advance | That a source won; CMDB 360 retains the values that lost |
| CI attestation | Whether a CI still exists and is still managed | Attested or Rejected, plus an audit line |
| Data certification | Whether field values on a record are accurate | Pass or fail per field, with an optional comment |
| CMDB Health | Completeness, correctness, compliance | Whether fields are populated, well-formed, and policy-conformant |
Read the right-hand column downward and a pattern is hard to unsee. The platform records what was decided thoroughly, and why it was decided almost nowhere. That is not a defect — it is a different job, and mostly a later one. But it is the reason axis C needed a name.
The clearest example, and it is theirs, not ours
Service Mapping’s machine learning scores each suggested connection with a confidence level — High down to Very low. A connection rule can then add suggested connections to the service automatically, and the platform documentation’s own example condition is a rule for any connection with confidence level High. So the review step — a person deciding whether this component really belongs to this service — becomes configuration.
The platform even marks the suggestion when this happens: its Decision attribute is set to Added By Rule. But that marker is operational state, not history — retire the rule and the Decision reverts to Undecided, the rule-to-suggestion association is removed, and connections no other rule covers are taken back off the service. Nothing durable records who authored the rule, why the bar sits where it sits, or which of today’s live relationships arrived through it. That is axis C, implemented and shipped, and left undeclared. We are not arguing the bar should be higher. We are arguing it should have a name on it — a declared setting, a rationale, and the value written beside the results it governed.
Two places worth being precise, because they get conflated
Attestation and certification are not the same thing, and neither is aimed at a relationship. Attestation asks whether a configuration item still exists — a binary, deliberately answerable by someone without an ITIL role, because the person who knows is often not in IT. Certification asks whether field values are right. Both are re-confirmation mechanisms, and both are good at it. Attestation even has its own automatic mode — smart detection can auto-attest CIs based only on recent discovery results, and it ships enabled by default: the same review-step-becomes-configuration pattern as the connection rules above, in a second product.
What neither is designed to capture is the original assertion: who first said this service runs here, in what words, answering what question. Attestation is scheduled and recurring — which means it produces a series of confirmations with no first entry. That is a different object from a decision record, not a weaker version of one.
It also explains something visible in public: practitioners keep asking how to certify a relationship, and keep answering each other with workarounds — a second policy pointed at the relationship table, or helper fields copied onto the CI so there is something certifiable to point at. The business-service-to-device edge is the object everything downstream depends on, and it is the one nobody is asked to sign for.
None of this is a gap we invented to sell into. The platform arbitrates attributes, scores populations, and re-confirms records — and it does all three well. The layer we work on sits beside it: not whether the field is filled, but whether the relationship can say who asserted it and what confirmed it.
The dispute this settles
A live disagreement in the field: one delivery method opens with two deliberately coarse Business Service Offerings covering the whole estate, on the argument that a complete map deployed shallowly beats a partial map deployed deeply. Another position holds that this breaks ServiceNow outright.
Both are right, about different things. Coarse offerings are conformant — the model requires at least one offering per service and sets no granularity floor. But an offering wired directly to devices is not conformant, because that edge does not exist. The two positions are reconciled by the two layers neither side usually draws: the Service Instance and the Technology Management Service Offering → Dynamic CI Group path.
What actually breaks
The failure mode is not offering coarseness. It is group membership — and it helps to be precise about what a device is a member of. Devices are never members of a service or an offering. They are members of exactly one thing: a Dynamic CI Group, the query-based record that binds an offering to the CIs delivering it. The offering connects to the group; the group contains the devices. That group layer is where the danger lives.
Here is the mechanism, from the white paper itself (p.44). CSDM Data Sync — a scheduled job, with an Execute Now for admins who cannot wait — copies three governance fields — Managed By, Support Group, Change Group — from an offering down through its Dynamic CI Groups onto every member CI. The group has to be classified as a technology management service for the copy to fire at all. Now put one server into groups under two different Technology Management Services: both syncs write those same three fields on the same CI, and the last writer wins. The server’s support group silently changes every time either side syncs. Nothing errors. It surfaces months later as “why does this box keep changing owners?” — with the audit trail pointing at nobody.
There is a quieter version of the same failure, and it is far more common: the offering carries none of those three fields. Then the chain is exclusive, conformant, and copies nothing — every device beneath it has a group and no owner. We report that as its own state and count the devices it strands, because a model that passes every structural check and answers no operational question is the failure this page exists to name. See Where devices attach.
Notice what this failure does not depend on: how many offerings you have. Two deliberately coarse offerings whose groups never share a device are perfectly safe. Twenty finely-designed offerings whose groups overlap are quietly broken. The argument everyone has is about offering count; the thing that breaks is overlap.
ServiceMatch closes it by construction, not by review: each device is routed exactly once, membership is keyed by the device itself, so a second group cannot claim one — an overlapping membership is not caught and removed, it is impossible to write. On a full run that reads as 9,142 membership rows, 9,142 distinct devices, zero in more than one group — a number that could not have come out any other way.
Armature: one frame, many doctrines
The Armature Service Model is a fixed core with a flexible form — the rigid inner skeleton a sculptor builds around, holding whatever shape your business services actually take. It is not a competing opinion about how to model services — it is the frame that holds every conformant position, including ones we did not author. Each doctrine below is the same engine and the same referee, producing a different emitted shape.
| Doctrine | Design order | Depth | What it emits |
|---|---|---|---|
| Offering-first | Middle-out, starting at Service Delivery | Crawl → walk; planning layers deferred | Offerings carry SLA, KPI, cost and support group; capability tier deliberately absent |
| Layered bottom-up | Technical infrastructure services first | Walk-heavy; each layer completed before ascending | Dynamic CI Groups as the managed-group mechanism; business services last |
| Design-complete, deploy-minimal | Top-down; the whole business mapped up front | Crawl only, with the expansion path pre-declared | Full design retained, crawl subset emitted, deferred layers visible as designed-not-emitted |
| White-paper staged | Middle-out, application-first | Crawl → fly, in order | Business Application and Application Service first; capabilities last |
The fourth column is the point: four shapes, no code change. Which doctrine a partner runs is configuration and a recorded decision, not a rebuild. Today the depth axis is fully governed by adoption stage; design order is expressed through interview sequencing and template choice.
Attribution confidence and scope — ours, declared
Axes C and D are the ones most often left unstated, which is precisely why practitioners talk past each other. We state ours plainly, as choices rather than as CSDM’s ruling.
The upper layers of CSDM — capabilities, business services, ownership — cannot be discovered; they can only be declared by people who run the business. The layers below them can be, and the platform discovers them well: top-down mapping, traffic fingerprinting, tag-based maps, sign-in and usage telemetry. What no discovery mechanism supplies is the link between the two halves — because that link is an assertion of accountability, not an observation. ServiceMatch builds the service model from evidence-backed stakeholder claims, then attributes devices to it under one rule: never fake a business placement.
- Multi-signal scoring places hosting infrastructure at business-service granularity across a dozen signal types, with frequency-based damping so a signal shared by a fifth of the fleet contributes nothing.
- Evidence matching upgrades placements to named offering leaves when device-content evidence supports it, with the full evidence trail on the assignment.
A placement is confirmed only when evidence found on the device itself supports it — installed applications, registered services. Corroborating context can support a confirmation but never anchor one, and structural defaults confirm nothing. Everything below the bar stays pending, visible, and waiting for a person.
End-user devices are not force-attributed to business services on soft signals like department or location. They attach to the technology management service that actually operates them, with departmental context preserved as an overlay for the day real evidence arrives.
That parking is a position on axis D, not on C — a declared default with declared exceptions, never a prohibition. CSDM 5 does not mandate it: the white paper’s own worked Business Service Offering example is tiered desktop support (p.45) — end-user equipment, squarely in the business half — and its Business/Technology split (p.43, p.45) is drawn by audience, never by device class. An offering genuinely delivered by a fleet of endpoints — a trading floor, a clinical bench — can declare an exception, inside which the full evidence machinery on C runs unchanged. The bar and the scope compose; neither is the other at a different setting.
Design principle
Coverage is always reported as business-attributed / management-service / unassigned — computed by one shared predicate, so the dashboard, the exports and the emitted relationships can never disagree. A single flattering percentage is banned vocabulary.
This is a strict bar, and it is ours rather than the model’s. A partner who opens with structural defaults at crawl stage is not doing CSDM wrong. They are answering axis C differently — and the honest thing is to say so out loud, and to record which answer was chosen.
CSDM 5.0-conformant output
With the service-model chain enabled, emitted entities target the CSDM 5.0 table mapping, pinned by conformance tests — including the details that trip implementations up, like the legacy service_classification value that survives the Technology Management Service rename, and the two tables that each serve two conceptual entities. Stacks running the older flat relationship shape — a deliberate legacy default some customers still depend on — get exactly that shape, stated as legacy, not passed off as the chain. The CSDM 5.0 workbook is generated from the governed model on demand; it is a view of the model, never a source edited by hand.