Concepts
Source precedence

When four tools report the same device, they disagree — about the OS string, the model, sometimes the hostname itself. Without attribute-level precedence, the CMDB degrades into last-writer-wins. ServiceMatch treats "which source owns which attribute" as a first-class, reviewable decision.
Authored from evidence
Precedence is authored during onboarding from the data itself: which source actually carries reliable serials, whose OS field is normalized, which feed is enrichment-grade rather than discovery-grade. The proposed precedence set is presented for operator review before it takes effect — and it lands on the decision record like every other configuration choice.
Recorded, field by field
- Every golden record carries per-attribute provenance: the winning source for each field.
- Beaten values are retained alongside the winner — a conflict is evidence, not noise.
- Precedence application never swaps device identities as a side effect; identity-conflict groups are protected from cross-assignment.
Source roles
Not every feed is a discovery source. ServiceMatch distinguishes discovery sources (trusted to establish that a device exists), enrichment feeds (add fields, never create devices), and application feeders (software and service inventories that carry attribution evidence but must never mint device records). Only trusted discovery sources can create new CIs.
Design Principle
Everything arrives at your instance as conditioned input to Identification and Reconciliation. ServiceMatch never writes around IRE — it delivers payloads where the identification chaos is already resolved and the source-ownership decisions are already made, recorded, and reviewable.
All docs