What ServiceMatch is, and where it sits

ServiceMatch is a governed conditioning layer for CMDB discovery data. It sits between your discovery tooling and ServiceNow: multi-source discovery data goes in; identity-resolved, deduplicated, classified, and CSDM-attributed records come out—as conditioned input to Identification and Reconciliation, never as direct table writes.

Discovery sources (Intune · SCCM · Nexthink · ScienceLogic · Tanium · …)
        ↓
ServiceMatch   normalize → identify → classify → govern
        ↓
Identification & Reconciliation Engine (IRE)
        ↓
CMDB

What goes in

The input is the discovery data your existing tools already produce—exported, not re-scanned. ServiceMatch installs no agents and touches no endpoints; it conditions the exports your endpoint-management, monitoring, and directory platforms already generate. A real estate arrives described several times over: the same laptop turns up in Intune, Nexthink, and SCCM, each with its own spelling of the truth.

Every source is role-typed by what its evidence can support, not by its brand. Discovery sources establish that a device exists and can anchor its identity; enrichment feeds add fields but never create devices; corroborating feeds confirm existence without being trusted to author records; and application feeders carry the attribution evidence that maps devices to services. The full catalog—each source's role and identity notes—is in Discovery sources; what each contributes field-by-field is in Field coverage & gaps.

• →Device records — one row per thing a source saw, carrying identity fields (serial number, hostname, MAC), hardware and OS attributes, and whatever context that source happens to hold.
• →Overlap and disagreement, by design — the same device seen by three tools is three records with three opinions. Reconciling them is the job, not a defect to apologize for.
• →Per-source provenance, kept from the first read — every value remembers the source it came from, so nothing turns anonymous once records are merged.

What it produces

• →Golden records — one identity-resolved record per real device, with per-field source provenance and every conflict resolved during reconciliation.
• →Disposition reports — what is new, what updates an existing CI, what was blocked and exactly why.
• →ServiceNow-ready import artifacts — the conditioned data as import sets, plus a ServiceNow update set XML(the platform's unload format) that stands up the loading machinery in your instance: the import set tables, transform maps with coalesce rules, and onBefore transform scripts, all wired to route through IRE rather than write around it. A CSDM 5.0 workbook, generated from the governed service model, ships alongside.
• →The decision record — every configuration decision that shaped the data, with author, rationale, evidence, and review status.

How these docs are organized

• →Concepts — golden records and identity, source precedence, classification, evidence and reasoning, uncertainty and failure modes, field coverage, and staged adoption.
• →CSDM — the 5.0 model, attribution and coverage, and quality and scope.
• →The AI layer — Conductor and Pro: governed authoring, what they generate, and the guardrails they run under.
• →Governance — decision types and lifecycle, the decision record, and review and overrides.
• →Reference — the deliverables catalog, the glossary, the policy listing, the discovery source catalog, and the deployment model.

Prefer the reasoning before the implementation? Start with Design Principles. The docs explain how; Design Principles explain why.