ServiceMatch by SwipeLeft AI · Design Principles

Operational models are not discovered. They are engineered.

Every enterprise platform runs on operational models — CMDBs, service models, classifications, mappings, relationships. Trusted operational systems begin with governed decisions about those models: made from evidence, reviewed by experts, and kept on the record before anything reaches the instance. ServiceMatch exists because that engineering deserves its own governed software layer.

The principles below describe how we build that layer. Every one of them is enforced in the product, not aspired to.

01

Identity Before Import

Identity is resolved before import, with the confidence shown.

Duplicate CIs are not a cleanup problem — they are an identification problem that happened upstream, when several discovery tools each described the same estate with no shared notion of device identity.

We resolve identity across sources before anything reaches the instance. Every device carries an explicit 0–100 identity score built on weighted identifiers — serial, hostname, MAC — and the score is visible, not buried.

In ServiceMatch

  • Conflicting identities — one serial reporting many hostnames, one hostname claiming many serials — are flagged for human review. They are never silently merged.
  • Low-confidence records are blocked with a stated reason. Importing a record you cannot identify is not optimism; it is a duplicate you have scheduled for later.
02

Evidence Before Authority

The authoritative source owns each attribute — decided from evidence, and written down.

Without per-attribute source precedence, a CMDB degrades into last-writer-wins: whichever tool reported most recently owns the truth. Reconciliation rules fix this — but in most engagements they are hand-built, slowly, from tribal knowledge.

We author source precedence from the evidence in the data itself — which source actually carries reliable serials, whose OS field is trustworthy — and present those decisions for review before they take effect.

In ServiceMatch

  • Every golden record carries per-attribute provenance: which source won each field, and the conflicting values it beat.
  • Everything we produce arrives at the instance as conditioned input to identification and reconciliation. We never write around IRE — we make its job tractable.
03

Classification is Governed

Automatic classification targets deployable leaf classes. Class is evidence, not a guess.

A CI classified into an abstract parent class carries none of the attributes downstream processes need. Misclassification is worse than no classification, because it looks finished.

Classification rules target the most specific class the evidence supports, and generic parent classes are rejected — at rule-authoring time, at deployment, and again at runtime.

In ServiceMatch

  • Rule authoring requires corroborating conditions on rules that could collide — a substring match that catches more than intended — before they ship.
  • Records the rules cannot place with confidence are routed to review with the evidence attached, not forced into a default.
04

Relationships Before Deployment

One coverage number is always wrong. We report three.

The most common inflation in CMDB programs is the coverage claim: "98% of devices mapped to services" — where most of that number is a catch-all bucket doing no analytical work.

We report coverage as a three-way split: business-attributed (placed on evidence), management-service (honestly parked under the technology service that operates it), and unassigned. The single flattering percentage is banned vocabulary.

In ServiceMatch

  • End-user devices are not force-attributed to business services on weak signals like department or location. They park where operations actually manages them, with the context preserved for the day evidence arrives.
  • The service model stays minimal — no more objects than the operating workflows actually use. A model that mirrors the architecture diagram is documentation, not operations.
05

Expert Judgment is Explicit

Recommend, don’t assert. Confirm only on content evidence.

AI that asserts is a liability in a system of record. Every recommendation we make carries a confidence band, the evidence behind it, and a review status — and low-confidence inferences surface as questions for a human, never as silent facts.

Confirmation has a hard bar: a placement is confirmed only when evidence found on the device itself supports it. Corroborating context — mappings, naming, ownership — can support a confirmation, but can never anchor one.

In ServiceMatch

  • No engine release ships unless validation demonstrates zero false confirmations against the evaluation corpus — and across every validation run to date, synthetic and live, that bar has held. Everything below it stays pending, visible, and waiting for a person.
  • The system authors; your operator reviews. Overrides are first-class records that take precedence and stay attributable — reviewers judge outcomes; nobody retypes data.
06

Every Decision is Recorded

Every data decision is on the record — not just every data change.

Audit trails usually start at the instance: what changed, when. The decisions that shaped the data before import — why this rule, why this source, why this exclusion — live in a consultant’s notebook, if anywhere.

We keep the decision record itself: every classification rule, precedence choice, exclusion, and service placement lands in a governance log with its author, rationale, and evidence.

In ServiceMatch

  • Any record can be traced back to the decisions that shaped it — including what it would have looked like without them.
  • When someone asks, a year from now, why a CI is classified the way it is, the answer is a lookup, not an archaeology project.
07

Governance Never Ends

Data quality is an operating loop, not a project phase.

Cleanup projects produce clean snapshots. The estate keeps moving, and a year later the same engagement gets sold again. The long-term fix is governance that runs continuously — which only happens if it is cheap enough to run daily.

ServiceMatch is built as that loop: scheduled intake with schema validation and quarantine, drift detection between snapshots, and a standing review cadence measured in minutes, not workshops.

In ServiceMatch

  • Adoption is staged deliberately: what we capture is never gated, but what we emit grows with the maturity of the model — and promotion between stages is an operator decision, on the record like everything else.
  • It runs single-tenant, in the environment where the engagement lives. Discovery data never leaves it.

We would rather show the machinery than the slides.

Every position above maps to an enforcement point in the product — a gate, a validator, a review queue. On a live multi-source estate, AI-authored configuration has matched a hand-curated expert baseline within ±5%, with every decision on the record. A live run is the fastest way to check us.

See how ServiceMatch works