The flow below reduces this whole piece to one decision, asked twice. Keep it in front of you; the rest of this hangs off it.
A request landed to turn our docking stations into Configuration Items. The platform was already set correctly - docking stations were asset-only. The process team asked for the CI; the developers agreed, and proposed changing the model category to spawn one.
The platform was right. I'll say it plainly: the request, and the advice to action it, were both wrong.
Nothing about that failure was technical. The platform did exactly what it was built to do. What was missing was an artifact - a written, authoritative rule for what earns CI status. With nothing on paper to test against, the decision lands on the most knowledgeable person in the room. It lands there every time.
Asset and CI are a distinction of purpose
Asset and CI describe the same object for different reasons. An asset is a financial record: cost, ownership, contract, lifecycle. A CI is an operational record: service management, dependency, impact.
ITIL 4 drew that line when it split IT Asset Management from Service Configuration Management - two practices, divided on purpose, not on data; ServiceNow's own asset guidance says the same. I don't hold either up as scripture. They name the boundary the platform already enforces, and that's enough.
Consider also that it isn't always either-or. A model category can resolve to an asset, a CI, or both, and plenty of things are honestly both - a laptop is a financial asset and an operational CI at the same time. So the real question is rarely "asset or CI". It is whether the CI facet earns its place alongside the asset record.
In practice, many objects begin life as a financial asset and only earn the operational CI later, once integration or dependency data makes them matter to a service. The transition is the signal to create the CI, not the moment the asset was purchased.
It also matters more now than it used to. A modern, CSDM-aligned CMDB runs a scoped, deliberate set of models - not every class in the tree - and that scope is exactly what eligibility protects. Every CI you create that doesn't earn its place stretches the boundary CSDM depends on.
The first gate: demand
Before anything becomes a CI, put it through four questions.
- Log - will you raise an incident, problem or change against it?
- Map - do its relationships matter for impact or dependency analysis?
- Track - do you need to follow its operational state?
- Serve - does anything downstream consume it: event management, service mapping, impact calculation?
Four "no" answers means asset only. Docking stations score zero. Nobody logs a change against a dock; it carries no relationship that shifts an impact calculation; its operational state tells you nothing; and nothing downstream consumes it.
Those four questions aren't arbitrary. They are the operational-trust use cases from the first article in this series, asked in advance - business impact, triage, root cause, change risk, service dependency. A CI earns its place when it will carry weight in at least one of them. Serve none, and it isn't an operational record; it's an asset.
The second gate: sustainability
Demand earns a hearing, not a record. A thing can pass all four questions and still make a poor CI, because a CI you cannot keep accurate is worse than no CI at all.
So before you create it, test whether you can sustain it.
- Discover - can it be discovered and reconciled, or only typed in by hand? A CI with no automated source and no realistic update cadence washes out within weeks of go-live.
- Own - is there a named owner before the record exists, not after? Without one, it shouldn't be a CI.
- Scale - how many will it spawn? A high-count, low-value class floods the CMDB and drags the health metrics down with it.
- Change - does it carry a lifecycle of its own, or only live and die as part of its host? If it never changes state on its own, it's an attribute wearing a CI's clothes.
Then there's cost. Every CI is an ongoing maintenance cost, not a one-off creation cost. "Just in case" is the opposite of the piece you need to use today, and it almost never survives the only test that matters: value over a lifetime, set against the cost of keeping the record true.
Why capable people keep getting this wrong
Here's the part worth sitting with. The request didn't come from someone who didn't understand the platform. The Asset Manager knew the model. The CMDB Manager knew the model. The architects knew the model. Capability was never the gap. The gap was accountability. With no standard to point at, the decision had nowhere to land but a person - and people defer to the most senior voice, accommodate the loudest stakeholder, and re-argue the same call time after time after time. A decision that depends on who is in the room is not a decision. It is a negotiation that never ends.
That is an operating-model problem, not a configuration one. You don't fix it by training the team harder. You fix it with an artifact the team can test against when the person who knows the answer isn't there.
Where the canon stops
It's fair to ask why this isn't already solved. ServiceNow hands you CMDB Health, the Data Foundations dashboards, and CSDM; ITIL 4 hands you the asset-versus-configuration split. The tooling is sound. None of it answers the question.
Every one of those frameworks governs a CI once it exists - its quality, its relationships, its lifecycle, its owner. The eligibility decision sits upstream of all of them. The canon tells you how to keep a CI healthy; it stays silent on whether to create it in the first place. That silence is where this standard lives.
The standard as an artifact
A rule in one person's head doesn't scale. A standard does. The CI Eligibility Standard is four things, and none of them is heavy:
- A litmus test - the two gates above, demand then sustainability, written down and applied the same way every time.
- A class register - the classes you've ruled in and out, with the reasoning recorded, so the call isn't re-argued from cold each time it surfaces.
- A change gate - any change to a model category's tracking, specifically giving it a CI class so its models start spawning CIs, goes through review, not a developer's discretion.
- A named owner - one accountable owner for the standard itself, the same ownership discipline you already apply to the data.
Then encode it where the platform holds the line for you - in the model tracking strategy, the model category setting that decides whether a model is tracked as an asset, a CI, or both. A model category maps to an asset class and, optionally, a CI class; leave the CI class off and the model stays asset-only, with no CI spawned behind it. Set each category to match the decision, and route any change that would add a CI class through the gate. Those mappings are meant to be set deliberately, not flipped on a whim, so the platform is already on your side - the governance only has to make sure the setting reflects a tested decision, not a passing request. Guardrails, not case-by-case refereeing.
Isn't asset-only too rigid?
The honest objection is that a hard rule can't see the edge case - the peripheral that, in one environment, genuinely needs operational tracking. That's true.
And the standard handles it precisely because it isn't a ban; it's a gate. The edge case goes through the change gate with its evidence, gets tested against the two questions, and earns CI status or it doesn't. What you've taken away isn't flexibility. It's the reflex yes, and the reflex no.
A CMDB rarely loses the room over the records it's missing. It loses the room over the thousand records nobody believes - the low-confidence data the first article in this series warned about. Each record waved through by a reasonable request, because no one had written down the rule that would have stopped it.
Write the standard. Then the decision tests against a document, not a person - and you stop having the same argument twice.
The CMDB Maturity Series: Operational Trust: Measuring the Real Usability of the CMDB · CMDB Data Ownership Models · The CMDB as AI Infrastructure · The CI Eligibility Standard.