Concepts

Evidence & reasoning

Every automated conclusion in ServiceMatch has to survive the question "why?" — at the level of the individual record, on demand. Open the evidence view on any device and the full reasoning chain is there: not a confidence number asking to be trusted, but the actual case.

What the evidence view shows

Identity — the identifiers that resolved this device, the score they produced, and any conflicts that were surfaced along the way.
Classification — which rule placed it in its CI class and the evidence the rule matched on.
Field provenance — which source won each attribute and the conflicting values it beat (see Source precedence).
Service placement — the signals behind any CSDM attribution, what anchored a confirmation or why the record is still pending, and any stakeholder declaration involved.
Status and next action — where the record stands and what would move it: the missing field, the unreviewed conflict, the evidence that would confirm a placement.

How confidence works

Confidence is banded, and the band decides behavior: high-confidence conclusions are applied and stay reviewable; mid-band conclusions are presented as recommendations; low-band inferences become questions for a person, never silent facts. For service placements the bar is stricter still: only device-content evidence (installed applications, registered services) can anchor a confirmation — context signals like naming, mappings, or department can corroborate a placement but can never confirm one on their own, and structural defaults can never confirm anything.

Worked example (illustrative)

A server, srv-erp-db-02, is proposed for the ERP platform's database offering:

＋ Database software for the declared ERP product is installed on the device — a content signal; this is what anchors. ＋The hostname pattern and a stakeholder-declared server mapping agree — context; corroborates, can't anchor. − One installed agent is also associated with a different service — a contradiction; it lowers the score rather than being averaged away.

Net: above the confirmation bar with a content anchor → the placement is confirmed, carrying all three signals and the contradiction in its evidence trail. Had the content signal been absent, the same context evidence would have left it pending— visible, with "what would confirm it" stated. And if the architect knows better, an override moves it, on the record, and survives re-runs.

Deterministic, not narrated

The plain-language explanation is generated deterministically from the decision data itself — the same rules, scores, and provenance the pipeline actually used. It is not an after-the-fact summary of what probably happened; it is the record's processing history, rendered readable. Run the pipeline again on the same inputs and configuration, and the explanation is the same.

Reasoning connects to the record of decisions

Every element of a record's rationale traces to a governance decision — the rule that classified it, the precedence that shaped its fields, the claim that placed it. Record-level "why" and estate-level "who decided" are the same trail, walked from different ends.

Design Principle

A classification that can't explain itself is a guess with a confidence score. Explanation is not a reporting feature bolted on afterward — it is what makes automated judgment reviewable, and reviewable is what makes it usable in a system of record.