Reconciliation and apply

Once a run has staged its observations, Discovery works out which CI each observation is about, which attributes the source is allowed to set, and whether a change is written to the CMDB or held for a person. All of this happens in the Discovery apply sweep, which runs hourly at minute 47.

Current scope. Reconciliation, the precedence defaults and apply or review are available and run for scanner sources in the hourly sweep. Intune observations are staged but not yet linked to CIs by the sweep. See Availability.

The CMDB's own side of this — source identifiers, the duplicate-candidate queue and bulk registration — is described in Reconciliation and import. This page covers what Discovery adds in front of it.

Matching observations to CIs

Discovery matches each observation to a CI by its strong identifiers — serial, MAC, FQDN, cloud resource id, external id — never by name similarity. Each source's manifest declares which identity attributes it uses, in precedence order, and marks each one strong or weak; at least one must be strong. There are four outcomes:

A few rules keep matching honest:

• Identifiers are canonicalised before comparison, so AA:BB:CC and aabbcc match. Unknown identifier keys are namespaced by key name, so two systems using the same value never collide.
• Placeholder serial numbers such as To Be Filled By O.E.M. are filtered, so that many virtual machines are not collapsed into one CI. If you meet a new filler value, report it so it can be added.
• Every CI carries an immutable CI origin stamp naming the source that first created it, or cmdb_manual for CIs that pre-date discovery.

Duplicate handling

Discovery never merges CIs automatically. When two or more CIs claim the same identity, the candidate pair goes to Assets & Risk → Configuration Items → Reconciliation, where candidates raised by discovery carry the matching identifiers in Match basis. A person then chooses:

• Merge — both are the same asset. The merge keeps one CI, unions the source identifiers and retires the other. Merging is audited and cannot be undone.
• Mark distinct — they are different assets. The decision is remembered: discovery reports later observations as blocked by split instead of raising the same question again.
• Dismiss — dismiss the candidate.

The procedure is in Guides for CMDB reviewers and auditors.

Per-attribute source precedence

Linking an observation to a CI does not mean the source may change it. For each attribute, a precedence policy decides whether this source may set the value.

• Platform defaults. The platform ships a default policy — for example Intune wins for the OS build, vCenter for vCPU and RAM, the endpoint scan for installed software.
• Staleness. The authoritative source wins until its data is older than the rule's staleness limit. After that, a fresher source that disagrees produces a review, never a silent overwrite.
• Unranked sources. A source that is not ranked for an attribute never wins, even when nobody disagrees; the value goes to review.
• Governance attributes. Owner, technical owner, criticality tier and supports critical function are manual-only for every source. They are refused in the precedence engine and again at apply time.
• Tenant overrides of the default for a CI class, attribute and source kind are planned — not yet available. The service exists, but there is no screen or API yet.

Apply or review

The apply router is the only path from Discovery into the CMDB. It creates at most one new CI version per observation, and only when a winning attribute actually changed. The version is written through the CMDB services, so it appears in the CI's version history like any other change.

Everything the router may not apply becomes an append-only review item that records why the attribute was not applied. The reasons are:

• governance attribute,
• ambiguous or split identity,
• class mismatch,
• stale authority,
• unranked source,
• no observations,
• production apply not activated.

Where a review item is drift — the CMDB and the observation disagree — the sweep promotes it to a deviation with an owner, severity and due date. Deviations are covered in Deviations and attestation.

Retrying the same record never duplicates versions, review items or audit rows.

Bounded production apply

Partially available. The service and API exist for activate, preview, commit and compensate; there is no screen yet.

Reaching the active state lets a source observe; it does not let it write. Writing to production CIs needs a separate activation that names a corroborating origin system:

• Activation (discovery.apply.activate) is refused unless another origin system has independently confirmed at least one CI. Activating production apply and running batches are separate permissions.
• Preview (discovery.apply.execute) stores the before-and-after plan and a digest.
• Commit re-checks that digest and applies exactly the previewed plan. The change cap is checked before the first write.
• Compensate reverses a committed batch: it restores every changed attribute and keeps the provenance and audit history.

Activation can also be withdrawn with discovery.apply.activate.

Note that independent confirmations are not yet written by the sweep (see Verification and attestation), which the activation precondition depends on.

What Discovery never does

• It never merges CIs, retires a CI or closes a deviation on its own.
• It never sets owner, technical owner, criticality tier or supports critical function.
• It never lets a scanner create a CI.
• It never deletes a CI: retiring sets the lifecycle state and keeps the record, its history and its provenance.