Four Questions Hiding in Every CSDM Argument

Design order, implementation depth, attribution confidence, attribution scope — separate them and most CSDM arguments stop being arguments. This paper names the four questions, then rebuilds the service-model interview on top of them: questions generated from the model’s own gaps, answers checked against device evidence, the bar recorded in every run. The model is rendered as data throughout, so the argument can be checked on the page.

CSDM — ServiceNow's Common Service Data Model, the published standard for how business services, applications, and infrastructure relate in the CMDB — generates arguments wherever it is implemented. The usual explanation is that the model is underspecified, or that consultants disagree because disagreeing is how consultants differentiate. Neither is right. Here is what is actually happening: there are four questions, and everyone is answering a different one while believing they are all answering the same one. An argument like that cannot be won, but it can be decided — separate the questions and most of it stops being an argument at all. That is the vocabulary the rest of this paper runs on.

The four axes

Axis A — design order. Which layer do you model first?

Axis B — implementation depth. How much of what you modelled do you actually deploy right now?

Axis C — attribution confidence. What evidence do you require before you assert that a device supports a particular service?

Axis D — attribution scope. Which devices are eligible to carry a business-service claim at all? C sets the bar; D says who is standing at it. In a coverage figure, C governs the numerator; D governs the denominator.

These are independent. A method can be top-down on A, crawl-stage on B, willing to accept structural defaults on C, and server-first on D — and be perfectly coherent. Two practitioners can agree completely on A and B and still argue bitterly, because their real disagreement is on C or D and neither of them has named it. Two people quoting "98% coverage" and "2% coverage" about the same estate are usually not disagreeing about evidence at all; they are disagreeing about a denominator neither has declared.

Once you have the four axes in your hand, most CSDM arguments stop being arguments and start being specifications.

Taken one at a time, none of these observations is ours, and this is the place to say so. The split between design order and deployment order was published by a ServiceNow employee in 2014. That the adoption stage should govern what gets deployed is the position of ServiceNow's own CSDM 5.0 White Paper — the standard's authoritative text, and the document every bare page reference in this paper cites — where staged adoption is "not only acceptable but highly recommended" (p.51). The evidence question ships today as a settings dropdown in at least one commercial CMDB product. What we add is narrower than a discovery: the four named together, shown independent, and each turned into a recorded choice instead of an ambient assumption.

The scope-versus-threshold pattern behind D is itself old in the abstract: epidemiology calls it the denominator problem, healthcare quality measures formalize denominator exclusions as governed specification components, and ServiceNow's own CMDB Health dashboard scopes its measured population through inclusion rules. What we have not found named anywhere is this dial applied to business-service attribution — the population of CIs eligible to carry a business claim, declared and governed independently of the evidence any claim must meet.

An earlier version of this paper named three. The fourth forced itself on us while we were working an open question in our own doctrine — where do end-user devices belong? — and found that no setting of the other three answers it. A practitioner who requires strong evidence on C must still decide whether a laptop is eligible for business attribution at all; one who accepts structural defaults must still decide the same thing. A question that survives fixing every named axis is the definition of a missing axis. So: is there a fifth? Our admission test is exactly that — fixing every other axis must leave the question open, conformant practitioners must be able to differ on it, and it must not be re-derivable from the axes already named. And there is a live candidate: decomposition grain — two offerings or twenty. We have not admitted it, and honesty requires saying our first instinct was to wave it into axis B, which does not survive inspection: the stage machinery gates which layers emit, never how finely a layer is cut, so a run-stage practitioner still faces the grain question with all four axes fixed. It sits in our open questions under the same scrutiny D passed. If it passes, this becomes a five-axis paper; an axis does not need to be convenient to be real. Nor ours — we have not searched for prior art on D the way we searched on the others, so if someone named it first, good.

The sources keep A and B apart — the arguments don't

It would be tidy if the confusion started in the careful sources. It does not — and checking that is worth a minute, because the two most careful sources available look like a contradiction until you read them to the end.

A widely-read March 2026 practitioner post on CSDM remediation, published in ServiceNow's community, argues that a durable taxonomy is designed from the top of the CSDM hierarchy down. The white paper appears to say the opposite: its staged adoption runs Foundation, Crawl, Walk, Run, Fly — and Business Capability, the very top of the hierarchy, arrives at Fly. The last thing you implement.

But the community post closes by separating the two orders itself: "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. Design top-down, deploy top-last: two orderings, opposite directions, no tension, and each source careful about which one it means.

The tension appears 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 shout 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.

The proof: a dispute with money on it

Slogans mislabelled across axes are cheap to fix. Here is the expensive version: a live dispute between two delivery positions. The vocabulary dissolves the part that was never really a disagreement, and the model's own hard edges decide the part that was — which half is which matters, so we keep them separate below.

One delivery method opens an engagement with two deliberately coarse Business Service Offerings covering the entire estate. The argument is that a complete map deployed shallowly beats a partial map deployed deeply — you get every device attributed on day one, and you refine later along a path you already designed. In the vocabulary above, that is a stated position on B — deploy shallow, refine along a designed path — and, less visibly, a position on D: the entire estate, endpoints included, is eligible for business attribution from day one.

Another position holds that this breaks ServiceNow outright.

Both are right, about different things, and the disagreement is resolvable by reading the model rather than by arguing about philosophy.

Coarse offerings are conformant. The white paper asks that every operational business or technology management service have at least one offering. It sets no lower bound on granularity anywhere. Two offerings is a granularity decision, not a correctness one. Anyone asserting that two offerings "isn't CSDM" is asserting a constraint the specification does not contain.

But an offering wired directly to devices is not conformant — because that relationship does not exist. Look at the prescribed relationship set: there is no Business Service Offering → Infrastructure CI relationship in CSDM 5. Not deprecated. Absent. A business offering reaches devices only through a Service Instance. The technology-management side — a Technology Management Service Offering and its Dynamic CI Group — is the other way a device acquires an owner, not a second route from a business offering: no prescribed edge joins a business offering to a Technology Management Service.

So both positions are correct, and what reconciles them is the two middle layers that neither side usually draws.

What actually breaks — and it isn't coarseness

This is the part worth internalising, because it is specific, checkable, and almost always mis-stated.

The failure mode is not offering coarseness. It is membership exclusivity. The white paper is explicit (p.44): a CI should not be related, through Dynamic CI Groups, to more than one Technology Management Service. Managed By, Support Group and Change Group are copied from the offering onto its Dynamic CI Groups and then onto the member CIs. Let a CI sit in groups belonging to two different Technology Management Services and Data Sync will overwrite exactly the fields you were trying to govern.

Two coarse offerings with exclusive membership: safe. Twenty carefully-designed offerings with overlapping membership: broken, quietly, in a way that surfaces months later as "why does this server keep changing support group?"

The number of offerings was never the risk. Nobody was arguing about the right thing.

Where the model genuinely rules

Shape-neutrality is not "anything goes". CSDM 5.0 has hard edges, and knowing precisely where they are is what lets you say yes to someone else's method without saying yes to everything. A representative set:

• There is no Business Service Offering → Infrastructure CI relationship in the prescribed set. The paper introduces Figure 16 as "the relationships that are used" rather than as a closed list, so read this as absent from the prescription, not as impossible.
• A CI should not reach multiple Technology Management Services through Dynamic CI Groups — the paper's own word (p.44). We enforce it as hard; the source recommends it.
• Business Application is not an operational CI and should not be selected in Incident, Problem or Change. Neither is SDLC Component. Here the paper is emphatic, capitalising the NOT (p.53).
• Omit the Business Application → Application Service relationship and Technology Portfolio Management risk assessment stops working.
• Business Capability hierarchies are capped at six levels, with no circular parentage.
• Every operational service should have at least one offering — with no stated bound on how coarse or fine that offering may be.

One thing the boundary conspicuously does not contain: a rule about which device classes may sit in the business half of the model. The first constraint is role-blind — a hosting server cannot be wired straight to a business offering any more than a laptop can — so nothing in the boundary settles which devices are eligible for business attribution at all. That is axis D, and the specification leaves it open: the white paper's own worked example of a Business Service Offering is tiered desktop support (p.45) — end-user equipment, squarely in the business half — and its Business/Technology split is drawn by audience, never by device class. Our own default parks end-user devices under the technology management service that operates them. That is a declared position on D, held as a default with declared exceptions, not a reading of the specification; stating it as a prohibition would be asserting a constraint the specification does not contain.

Inside that boundary: your call, and a delivery partner should be free to make it. Outside it: a defect under our enforcement, and a recommendation in the source — the distinction is worth keeping, because we are the ones who hardened it.

The useful move is to stop arguing doctrine and start asking which axis someone is on, then check the boundary. That conversation converges. The other one doesn't.

The thing we did not expect to find

Turning the figure into data made one property computable that reading it never would: which arrows an engine can actually follow.

CSDM 5.0 prescribes 35 relationships. Only 26 of them are real cmdb_rel_ci rows. Five are reference fields — foreign keys — and four are many-to-many maps. Impact analysis traverses the first kind and cannot traverse the other two. To its credit the source figure does distinguish them in its legend; the derivative diagrams that circulate in decks and blog posts almost never do.

Practitioners have hit pieces of this for years — community threads on why an impacted-services list comes back empty usually end with someone explaining that a reference field is not a relationship. What we have not seen anywhere is the whole computed at once. Two results fall out of doing that:

For four of the 26 entities, every prescribed relationship is a reference field or a map. Value Stream, Value Stream Stage, Service Portfolio — and Technology Management Service, whose only two relationships in the figure run to its own Offering and to the Service Portfolio, both by reference. None of them can be reached by traversing the prescribed set. So the traversable projection is not one graph: it is a single connected core of 22 entities plus those four, each stranded alone. Five components, but the shape is one core and four orphans rather than five fragments — worth stating precisely, because the imprecise version sounds like a broken model and the accurate one is a model with four entities nothing traverses to.

Be precise about what that does and does not mean: the paper separately describes Technology Management Service as an operational CI used for impact analysis, and says the figure lists the relationships that are used rather than every relationship that can exist. The finding is about the prescribed set, not about what a real instance can do.

The canonical spine has a foreign key in the middle of it. Business Capability → Business Service → Business Service Offering → Service Instance → Application → Infrastructure CI is the path everyone draws from business intent to metal. Hop two — Business Service to its Offering — is a reference field, and an engine walking that path halts there.

Further down there is a step that looks like a second break and is not — in one direction. Application Service to Service Instance is class inheritance, not a relationship: an Application Service record is a cmdb_ci_service_auto record, so nothing needs traversing. The converse does not hold, and the distinction matters. Inheritance runs upward only: a Data or Facility Service Instance is also a cmdb_ci_service_auto record and is not an Application Service at all (p.38, p.47), so walking down from an arbitrary Service Instance to an Application Service really can fail. It matters only because published diagrams draw inheritance and relationships with the same arrow — which is exactly why that path so often appears broken when someone tries to follow it.

None of this is a criticism of the model. It is a criticism of drawing it as undifferentiated arrows — and it is invisible until the picture becomes queryable.

The part nobody writes down: where the top of the model comes from

Axis C says attribution has degrees of confidence. Follow that honestly and you arrive somewhere uncomfortable, so let me state it plainly.

A CSDM model has two halves, and they are filled by completely different means.

The lower half is discoverable. Devices, the software installed on them, the service instances that software forms — scanners find it, and finding it is a solved problem. Most organisations are further along here than their maturity assessment suggests.

The upper half is not. What the organisation promises, to whom, at what commitment, and who is accountable when it breaks: no packet on the wire carries any of that. Buying better discovery does not move it, because there is nothing there to find. Discovery climbs to the service instance and stops dead.

We rendered this to check it, taking one worked estate and removing everything a person had declared, leaving only what discovery alone could produce. Zero capabilities, zero services, zero offerings, and not one configuration item reaching the business. That is not a story about immature tooling. It is the ceiling.

So the top of the model comes only from declaration, and the derivation above is the receipt. Someone says it, in the room or in a document; nothing finds it.

Asking is also the expensive part — not because questions are hard to write, but because of what it takes to ask the right one. Doing it well means knowing which question comes next out of hundreds, which answers are worth recording and which are someone being helpful, that a service nobody consumes should be reclassified rather than published, and that a stakeholder has drifted from describing their business into describing their org chart. That judgement is real, it is scarce, and the people who have it are booked. So the asking arrives as an engagement, measured in months, and the model that comes out is as complete as the engagement was long.

So we rebuilt that engagement as a process — one that asks unattended, which means it will walk into the arguments above and cannot charm its way out of them; the four axes are what let it decide instead of argue. The interview runs continuously instead of concluding. Its questions are generated from the model's own gaps, not from a script; each is ranked by what answering it would unblock, and addressed to whoever could actually know. And the evidence bar — the standard a device must meet before anyone may assert it supports a business service — is not a value in a consultant's head. It is a governed, per-customer declaration, guard-railed so it cannot be quietly loosened. The engine that enforces it also records it, writing it into every run's record beside the answers it governed: value, source, and who set it there. (Its companion, the scope declaration — which populations are eligible at all — is declared and recorded the same way today; enforcement does not yet read the recorded value, and every report that shows the declaration says so.)

Almost none of the vocabulary underneath this is ours, and this paper says so wherever it borrows. Three things in it are, as far as we can find, new in this domain — and "as far as we can find" is doing real work. Each is stated precisely where it appears, beside its nearest prior art, so you can check the claim at the moment it is made. The rest has been said before, sometimes by ServiceNow's own people, and is credited as it comes up. Transcribing the source's own figure also surfaced the places it contradicts itself; the errata are published, with what we emit for each.

Three things we got wrong before we got the asking right.

"I don't know" is not one answer. It is at least four — nobody knows, not applicable, ask someone else, or disputed. Treat them as one and you discard the most valuable output a stuck question has, which is usually who to ask next.

Order by what a gap unblocks, not by what is next on the list. A service publishing no offering blocks everything beneath it. A stranded device class blocks only itself. Working top to bottom feels tidy and wastes the one session you get with a busy executive.

And the one that matters most: not every gap is a question. Some close with evidence, and putting them to a human is actively harmful. Ask a business lead whether a particular switch supports pharmacovigilance and you will get an answer, because people are helpful. That answer is a guess. The guess is recorded as a claim. The claim survives in the CMDB for years, and by then nothing distinguishes it from evidence.

So gaps sort into three kinds and only two are ever put to a person. A person can settle who owns a service and what it promises. A person can inform what a class of equipment is for — which becomes a hypothesis to verify, never an attachment. And a person cannot settle whether one specific machine supports one specific service, which is a search, not a question.

Here is what surprised us when we ran the cycle to convergence. Settling every question a human could settle drove orphaned devices to zero and corrected two things that had been declared as business services but turned out to be IT operating its own technology. Business attribution moved by almost nothing — partly because most of the fleet was never in scope for it, and partly for a reason that took longer to see.

The scope part is axis D, visible in a number. Roughly nine devices in ten on that estate are end-user equipment; under our declared default they park under the service that operates them, and no amount of interviewing was ever going to move them. Before D had a name, that read as a disappointing result. Named, it reads as a denominator behaving exactly as declared.

The slower reason is no defect either. Interviews eliminate ignorance. Attribution comes from evidence found on the devices. In our own implementation this is architecture rather than policy: a recorded claim can contribute a pattern — an installed application, a hostname convention — but a device is only attributed when its own evidence matches that pattern, and the coverage number never reads a stakeholder's claim directly. A stakeholder cannot talk a device onto a business service, even if everyone in the room wants them to; the most their words can do is tell the evidence where to look. One governed exception exists on purpose: an operator can ratify a specific placement as recorded intent, and that ratification is a ledger entry with a name on it — judgment on the record, not a claim in disguise.

Scope is the same kind of thing, and a separate dial. The parking of end-user devices is a global doctrine setting, and an offering that genuinely is delivered by a fleet of endpoints — a trading floor, a clinical bench — can declare an exception, inside which the full evidence machinery runs unchanged. The bar and the scope compose; neither is the other at a different setting.

A goal that does not have to be reached

"A journey, not a destination" is the oldest sentiment in CMDB writing, and it has been said well recently — including on ServiceNow's own community, where the best framing we have seen is that CSDM is a direction you commit to rather than a project you finish. We agree, and we did not originate it. Nor are the two mechanisms below novel one at a time — staged emission is the white paper's own recommendation, and gating an attribution on an evidence threshold appears in vendor patents. Even recording a threshold beside the results it governed is long-standing practice elsewhere — data-quality frameworks embed the expectation with every validation result, lineage standards carry the asserted threshold beside the observed value, and regulated laboratories have bound results to their processing parameters for decades. What we have not found is a CMDB or service-attribution engine that does it: the incumbents keep the equivalent configuration live-referenced and absent from run output. So the narrow claim is this — the pair run together as one continuous process, with the attribution bar written into each run's own record — and that pair is what stops the sentiment from being an excuse.

If the questions are generated from the model's own gaps rather than from a script, the interview stops being an event and becomes a process. Generating questions from a knowledge base's own gaps is an old idea — expert-system tooling did it in the 1970s, and modern systems route data-deficiency prompts to the right people on a standing basis. The piece we have not found anywhere is the fusion: each generated question ranked by what its answer would unblock in the model's own dependency graph, combined with that routing, in a loop that never concludes. There is always a next question, it is always the highest-ranked gap — what a person can settle comes before what needs evidence, and within each kind, whatever answering would unblock the most — and it is always addressed to whoever could actually know. Nobody has to remember where they got to.

That changes what the goal can be.

The honest goal is narrower than it first looks. Most of an estate is equipment people use rather than equipment that delivers anything, and by default we place those under the service that operates them — a scope decision, declared, with exceptions where a fleet genuinely does deliver a business service. The goal is that every device sits under the service accountable for it, and that every device delivering a business service is attributed on its own evidence. Almost nobody reaches it, because the estate keeps moving. Devices arrive. Services change owner. A reorganisation invalidates a quarter of the business layer overnight. Today that means the model is accurate on the last day of the engagement and decays from then on, and the next refresh is another engagement.

A continuously running interview does not need the goal to be reachable. It needs the goal to be directional. You can stop at walk — deliberately, with the remaining layers designed and visibly deferred — and still hold a model that is complete and conformant for the stage it is at. Then you can resume in six months without re-establishing context, because the unanswered questions are still there, still ranked, still addressed to a named role.

Two properties make that safe rather than reckless, and without both it would be reckless.

The first is that the stage licences what gets emitted, independently of how much has been designed. An incomplete model is not a broken model; it is a correct model at a declared depth, and the layers not yet emitted are visible as designed rather than missing.

The second is the one above: interviewing more cannot manufacture attribution. Coverage is bounded by the evidence on the devices — a claim can unlock evidence that was already sitting there unmatched, but it cannot substitute for it. If asking more questions could raise the number, a process that never stops asking would produce a number that never stops rising and never means anything. Because it cannot, the process only ever converts unknown into known-and-parked or known-and-attributed. It cannot inflate. And "parked" is worth a second look: it is axis D operating in the machinery before we had named it — the scope decision was load-bearing in this design before it was a word in this paper.

What none of this replaces is the judgement. Someone still has to decide that a named service is really IT operating technology, that a coarse offering is the right granularity for this organisation, that this stakeholder and the one in a different department cannot both be right. What it replaces is the part that never finishes and that nobody can afford to keep paying for: the asking, the ranking, the routing, the remembering, and the resuming.

The expensive scarce thing was never the questionnaire. It was knowing which question is next, and being there to ask it again next quarter.

Why we turned the picture into data

One practical note on how this was checked.

CSDM 5.0 publishes its prescribed relationships as a figure — a picture, on a page. You cannot query a picture. So we transcribed it: every entity, every relationship, in ServiceNow's own [Parent::Child] descriptor notation, with the distinction most diagrams lose — whether an arrow is a real CMDB relationship that impact analysis can traverse, a reference field, or a many-to-many map. Those three things look identical in almost every CSDM diagram ever drawn, and they behave completely differently.

Doing that surfaced things reading the prose does not: two tables that each carry two different conceptual entities, distinguished only by a legacy classification value that survived a rename. Five new service-instance types in CSDM 5 that the paper says are "provided as a data model ONLY requiring manual creation and maintenance" (p.38) and are excluded from event impact analysis — we read that as meaning no shipped interface, but the phrase is ours, not the paper's. And several places where the document contradicts itself, which is what happens when a reference architecture ships as slideware.

We put the result behind an interactive explorer, because a model you can interrogate beats a model you can only look at. It renders from the transcribed dataset rather than from a hand-drawn diagram — which means the picture cannot drift from the model. That is the whole point.

We should be precise about what is new here, because encodings of CSDM exist: at least one commercial data-governance product ships the model as in-platform blueprints, paid and inspectable only from inside an instance. And ServiceNow publishes a machine-readable mirror of its own documentation in which the CSDM entity list appears as tables — while the relationship set, the part impact analysis actually needs, is carried as images and simply omitted from the data. As far as we can find, an open, inspectable transcription of the prescribed relationship set — queryable outside any instance — did not exist before this one.

The position

We are shape-neutral, and that is a stance rather than a shrug.

We support any position on any axis, provided it is conformant. We do not sell a doctrine. We make the doctrine an explicit, governed, recorded choice — so that six months later you can reconstruct not just what shape your model is, but which question you were answering when you chose it, and why.

We call the result the Armature Service Model, after the rigid inner skeleton a sculptor builds flexible material around. The offering path does not bend — how a device reaches an offering is fixed by the model — while the offerings themselves, their number and their grain, take whatever form your services actually have.

If you have a CSDM argument that will not resolve, try this: work out which of the four axes each side is actually on. In our experience it is usually not the same one — and the argument was never the argument.

Where to read next

Everything above renders from the same transcribed dataset, and all of it is open. In the order it builds:

Doctrine and positions — the four axes as a reference rather than an argument, the conformance boundary with its page citations, and the two-coarse-offerings dispute worked through end to end. Start here if you want to check the reasoning rather than read the case for it.

The CSDM 5.0 model — all 26 entities and all 35 relationships that appear in the prescribed set of Figures 15 and 16 — not every entity CSDM 5 defines; the domain chapters name others, including the AI classes — filterable by kind, with the traversable subgraph you can switch on and off. Also the same model as a matrix, where the 5.2% density makes the sparsity visible, and six places the white paper contradicts itself — three of which will break an importer if you transcribe them faithfully.

Quality and scope — the interview cycle, including the live question generator and the derivation above at full size. Also how service models fail, and where a given class of device actually ends up once you follow it hop by hop.

If you think we have a relationship, a direction, or a constraint wrong, tell us. It is transcribed by hand from a published figure, we have already found six errors in the source and corrected two of our own, and we would rather be corrected than confident.