Reference

The import package

The import package is the deliverable an engagement hands over — the conditioned discovery data plus everything ServiceNow needs to load it correctly. It is not a database write. It is a bundle of import-set files and the transform configuration that loads them, so every record enters through ServiceNow's own import and transform layer, matched on the same identifiers your Identification and Reconciliation Engine (IRE) already uses — never written straight into a CMDB table. The full catalog of what an engagement produces is in Deliverables; this page is the detail on the load package itself.

What's in the bundle

The package is a single ZIP, organized into folders by purpose. The data files are plain CSVs; the setup files stand up the load; the workbook and governance files carry the service model and the evidence behind it.

Path	What it is
`import_template/sn_transform_input.csv`	The load file — one row per CI, carrying every record that is new to the CMDB or an update to an existing one, across all CI classes.
`import_template/stale_*.csv`	CMDB records that no current discovery source corroborates — retirement candidates, surfaced for review and never silently deleted.
`servicenow_setup/`	The load configuration: a step-by-step `SETUP_GUIDE.txt`, the per-class transform-map spec, the onBefore transform scripts, a list of reference values to pre-seed, and — optionally — a one-click update-set XML.
`relationships/cmdb_rel_ci.csv`	Device-to-service relationships, loaded once the CIs exist.
`governance/full_records_with_metadata.csv`	Every record with its identity score, status, and per-field provenance — for review, never imported.
`workbook/CSDM_50_Workbook_*.xlsx`	The governed service model as a conformant CSDM 5.0 workbook — a generated view, never a hand-edited source.
`README.txt + manifest.json`	The audit companion: the file inventory, the load order, the coalesce keys and IRE rules per class, field- and reference-validation results, and the coverage split.

The load configuration

ServiceMatch does not just hand over data; it hands over the configuration that loads the data correctly. For each CI class in scope, the package defines an import-set table, a transform map, and an onBefore script. You can build these by hand from the setup guide, or import a single update-set XML that stands the whole thing up in one step.

Coalesce keys aligned to your IRE. The transform map matches each incoming record against existing CIs on the identifiers your instance already trusts — read from your ServiceNow identifier rules when a schema extract is provided, and falling back to sensible per-class defaults (servers on name and IP, endpoints on serial). Matching behaves the way your IRE would identify the same device.
onBefore logic, per row. Each script filters rows to its class, honors the disposition (a matched record with no drift is skipped; a retirement candidate is never re-asserted), decides insert versus update, and refuses any row with no usable identifier.
A reference-value pre-seed list. Models, users, locations, and departments that will not resolve in your instance are listed up front, so they can be seeded before the load rather than failing quietly during it.

Scope of the one-click XML

The update-set XML stands up CI loading — the import-set tables, transform maps, and onBefore scripts for every device class. Relationship loading (device-to-service, CI-to-CI) is a guided manual step in the setup guide, because those scripts resolve references live in your instance and are safer built with a human watching. The relationship data ships either way.

How it loads

Stand up the load. Import the update-set XML — or follow the setup guide — to create the import-set tables, transform maps, and onBefore scripts.
Load the conditioned data. Load sn_transform_input.csv into the staging tables and run the transform.
The transform conditions each row. onBefore applies the class filter, the disposition, and the identifier guard; then the map coalesces on your IRE-aligned keys — matching an existing CI or inserting a new one.
Relationships and retirements follow. Load the relationship files once the CIs exist, and work the stale list as a retirement review.

At no point does anything write directly to a CMDB table. Every record arrives through the import-set and transform layer, matched on the identifiers your instance uses to reconcile — which is exactly what reconciliation-ready input means in practice.

Every record arrives with a disposition

The load file is not a dump of everything discovered. Each record has already been judged against your current CMDB and carries a disposition and a reason, so the import changes only what should change.

Disposition	Meaning	On import
NEW	No CMDB record matched — the device is missing from the CMDB.	Insert a new CI.
UPDATE	One match, and a trusted discovery source reports drift.	Update the changed fields.
MATCH	One match, no drift.	No action — shipped for review, not import.
CONFLICT	Identifiers match more than one CMDB record.	Held for human review before import.
STALE	In the CMDB, but absent from every current discovery source.	Surfaced as a retirement candidate.

The gate before it ships

An export is not allowed to ship if the data behind it fails the quality gate: too many blocked records, any unresolved identity conflict, or too much left unclassified will stop the bundle from generating until the underlying data is fixed — or the gate is explicitly overridden, on the record, with a stated reason. The exact rules the gate enforces are listed in Policies.

The through-line

The package is three things at once: the conditioned data, the configuration that loads it the way your instance reconciles, and the record of the judgment that produced it. Nothing in it writes around ServiceNow's own import layer — the whole point is to make that layer's job tractable, not to bypass it.