A Configuration Management Process Owner is preparing solution options for presentation to the technical governance...

Data Foundations emphasizes that “ingest” must produce CMDB data that is standardized, supportable, and upgrade-safe. When introducing custom CIs, the best practice is to reuse the most appropriate existing CI class (or an approved industry-aligned model) and only add what is necessary—this keeps the data model aligned with platform expectations and reduces downstream rework.

Option B supports this directly: the CMDB CI Class Models application is intended to help teams select a suitable existing class rather than inventing new classes unnecessarily. Reusing existing classes improves consistency across integrations, Discovery/Service Mapping patterns, reporting, and CMDB Health rules—reducing technical debt and making future platform upgrades smoother.

Option A is also aligned with best practice when used correctly: once you have the right CI class, extending that class to add additional attributes (new fields) is a standard, upgrade-safe customization approach. It preserves the underlying platform data structures and avoids breaking out-of-box behaviors, identification/reconciliation practices, and CMDB Health evaluations.

Option C is not appropriate because Asset tables serve a different purpose (financial/lifecycle tracking) than CI tables (operational/service context). Mixing CI attributes into Asset classes creates confusion and process misalignment. Option D is strongly discouraged because repurposing and renaming base attributes creates long-term ambiguity, breaks shared semantics, and increases upgrade and maintenance risk.