Which discovery fields actually matter for CMDB quality

The usual answer to this is a list of recommended fields, which is why the usual answer does not help. Every estate has different consumers, so the fields that matter differ. What transfers is the test.

A field earns its place if some decision changes when it is wrong.

Not “if someone might want it”. Not “if the schema has it”. If you cannot name the decision, the report or the automation that would behave differently, the field is storage.

Run that test honestly across a CI class and two things usually fall out. Most estates are collecting far more than anything consumes — and are missing three or four fields that would unlock a great deal, which nobody noticed because nothing is obviously broken.

The ones that nearly always earn it

Not because they are universally important, but because so much hangs off them:

• →Something stable to identify on. Serial, UUID, anything that survives a rebuild. If identity is weak, nothing downstream is trustworthy, because you are not sure the records are about distinct things.
• →Ownership, of the kind a human can act on. A support group that is paged, not a name that left in 2024. This is the field that decides whether an incident routes.
• →Operational status and lifecycle. The difference between “we do not have it” and “we retired it” governs every count you will ever publish.
• →Environment. The cheapest field that separates a real outage from a non-event, and very often empty.
• →Last seen, from a source you trust. Without it you cannot tell a stale record from a current one, and a confidently wrong record outranks a missing one for damage done.

The question people skip

What fraction of this class has the field populated — and populated by a source that is allowed to speak for it?

Those are different numbers. A field can be 95% populated and still useless if most of the values came from the source with the worst view of that attribute. Coverage reports almost never separate the two, which is how an estate ends up with high completeness and low reliability at the same time.

And the inverse, which is where the savings are

Look for fields with near-total coverage that nothing reads. They cost collection time, review time and schema complexity, and they inflate the health score that is supposed to tell you how you are doing. Every one you retire makes the remaining numbers mean more.

More data is not the goal. The right data is.

How coverage is measured per class against the target schema, and where estates quietly fail on it, is in the field coverage documentation.