The Decisions IRE Can't Make for You

1. Where the industry already agrees

Ask the best CMDB practitioners in the ServiceNow ecosystem how discovery data should enter the platform and you will get, with remarkable consistency, the same answer.

One consulting firm states it plainly: "Data should never be put directly into a CMDB data table without being passed through the IRE to help reconcile and correlate the data to existing CMDB records."¹ And again, on multi-source estates: nearly every source "can (and should) flow through IRE so records are uniquely identified and the right source "owns" the right fields."²

Another firm makes the same case for Service Graph Connectors, which "leverage the Identification and Reconciliation Engine (IRE), so you know you can trust the data is being inserted correctly into the CMDB."³ Practitioner after practitioner — boutique and Elite partner alike — has converged on the rule: everything flows through identification and reconciliation; nothing writes around it.

This consensus is correct. It was hard-won, over a decade of duplicate storms and last-writer-wins chaos, and we endorse it without reservation. Everything described in this paper arrives at the ServiceNow instance as conditioned input to identification and reconciliation — never as a bypass.

This is not another paper about IRE. It is about the question the consensus leaves open.

2. The question the consensus leaves open

IRE is a gatekeeper, not a judge.

It enforces rules with perfect consistency — identification rules, reconciliation rules, source precedence. What it cannot do is author them. Every IRE deployment, however well tuned, presupposes that someone has already decided:

• Which identifiers establish identity, and with what weight. Is a hostname match sufficient? A serial number? What combination clears the bar, and what happens to a record that clears none of them?
• Which source owns which attribute. When the endpoint-management tool and the network scanner disagree about an operating system, who wins — and does the same source win for serial number, for location, for owner?
• What class a device belongs to, and how specific "classified" must be. Is a record classified when it lands in a generic parent class, or only when it reaches a class specific enough to deploy against?
• What happens to the records that don't clear the bar. Imported and flagged? Held back? Silently defaulted?

None of these are technical questions. They are judgment calls — about trust, about evidence, about risk tolerance — and every functioning CMDB embodies hundreds of them. IRE with unauthored rules is a gate standing open.

So where do the answers come from?

Anyone who has lived through a CMDB engagement knows: they accumulate. A precedence rule gets set during source onboarding because two feeds collided that week. An identification threshold gets loosened to unblock an import the night before a milestone. A classification mapping gets chosen because it matched the last engagement's pattern. Each of these was a decision — a real one, made by a capable person for a reason that was probably good.

The problem is not who made them. The problem is that there was nowhere to put them. Not because some table is missing from a platform — because the industry has no standard governance object for a judgment call. The decision lived for exactly as long as its moment, and then survived — if it survived at all — in a workshop deck, an email thread, or the memory of whoever was in the room. The people did their jobs. The tooling had no place to record the most consequential thing they produced.

Someone had to decide. Nothing was built to remember that they did.

3. Your CMDB has an audit trail. Its configuration doesn't.

The instance is meticulous about one kind of history. Every data change is logged: which field, which value, which source, what time. Sys audit tables, history sets, update sets — the platform can tell you what changed with forensic precision.

Call these change records: the who/what/when of a value being written.

Now try the other question. A year from now, an auditor — or an incident commander, or a new platform owner — asks why a CI is classified the way it is. Why this source owns the serial-number field. Why that batch of records was accepted at a confidence level the current team would reject. Is the answer a lookup — or an archaeology project?

For nearly every estate, it is archaeology, because the industry's audit discipline starts at the write and stops there. What is missing is a second kind of artifact.

A decision record captures a judgment call as a first-class object:

• what was decided (the rule, the threshold, the precedence, the classification),
• by whom — a named person, or a named automated author,
• on what evidence — the observed data that motivated it,
• when, and against which alternatives,
• and how it can be revisited — because a decision that cannot be reversed on the record isn't governed, it's fossilized.

The distinction matters because the two records answer different questions. Change records answer what happened to the data. Decision records answer why the data is shaped the way it is. A CMDB program with only the first kind can prove its data moved; it cannot explain its data. And an estate that cannot explain its data cannot defend it — not to an auditor, not to a skeptical application owner, not to the next consultant who inherits it.

Name the gap precisely. The industry long ago standardized change governance: approval boards, update sets, history sets, audit tables — mature, universal, unquestioned. There is no equivalent standard for decision governance: the discipline of treating judgment calls as governed objects — authored on evidence, recorded, reviewable, revisable. That asymmetry — rigorous governance for what the data does, none for why the data is shaped that way — is the gap this paper is about, and it is bigger than any one platform or product.

From decisions to policy

Watch a decision record accumulate entries and a pattern emerges: the same decision keeps getting made. Low-confidence identities get blocked — every time. Devices never get classified into abstract parent classes — every time. A placement is never confirmed without evidence found on the device itself — every time.

A decision that recurs is not really a decision anymore. It is a policy: a standing rule that constrains future decisions, with its own rationale and its own provenance. Policies are where an organization's data-quality doctrine actually lives — and they deserve the same first-class treatment. A policy worth having is a policy you can name, state in one sentence, trace to the incident or principle that motivated it, and point to where it is enforced.

That completes a governance stack with three layers and three distinct verbs:

IRE enforces the writes.
Decisions author the rules IRE enforces.
Policies constrain the decisions.

The industry has thoroughly built the first layer. This paper's argument is that the second and third layers deserve the same rigor — and that today, in most estates, they have none. Nothing in this model requires any particular product. A team could adopt it tomorrow with a wiki and discipline. The rest of this paper is about what follows once you take it seriously.

4. Decisions must be made while they are still decisions

Here is the uncomfortable consequence of the decision-record model: a decision that is made implicitly was never made at all — it was defaulted.

Consider the low-confidence record: a device with no serial number, a generic hostname, no MAC address. If it is imported anyway, no one decided to trust it. The import decided, by not deciding. The record is now in the estate — indistinguishable, at a glance, from its trustworthy neighbors — and the judgment call that should have been made about it has been converted into future cleanup work. Importing a record you cannot identify is not optimism; it is a duplicate you have scheduled for later.

The same is true of precedence. If two sources disagree about an attribute and the estate has no recorded ownership decision, then the decision is being made anyway — by write order. "Last writer wins" is not the absence of a precedence policy; it is the worst one, adopted silently.

This is why the timing of a decision is not an implementation detail. Before data crosses the write boundary, a judgment call is still a judgment call: it can be made explicitly, on evidence, recorded, reviewed, and — crucially — declined, at zero cleanup cost. After the boundary, the same call has been silently embedded in the estate, and unwinding it means remediation: dedup jobs, reclassification sweeps, the familiar machinery of cleanup.

To be precise about what is being claimed here: the argument is not "therefore, preprocess your data." Transformation without a decision record just relocates the tribal knowledge — the judgment calls end up embedded in ETL scripts instead of instance configuration, no more explained than before. The argument is: make the judgments while they are still judgments, and write them down. Explicit decisions, made on evidence, before the boundary, on a record. Whatever data conditioning follows from those decisions is a consequence of the discipline, not the discipline itself.

Prevention at the write boundary — IRE, properly configured — is necessary. It is not sufficient, because by the time a payload reaches the gate, the judgment calls that shaped it are already inside it. Decision governance begins before the write boundary.

5. The lens applies more widely: two demonstrations

Decision governance extends well beyond identity and reconciliation. Two examples illustrate the pattern — one about a number every CMDB program reports, one about a new kind of author every CMDB program is about to meet. Both are, at bottom, the same argument.

5a. A coverage percentage is an unrecorded decision

Every service-mapping program eventually produces the slide: N% of devices mapped to services. The number is rarely a lie. It is something more corrosive: a judgment call about what counts as "mapped," made invisibly and reported as a fact.

Does a device parked in a catch-all bucket count? Does attachment to a management service — "all workstations," "all network gear" — count the same as attribution to a business service that an owner would vouch for? The single percentage answers these questions without ever asking them. Even practitioners who teach ServiceNow's health dashboards warn that an unconfigured rollup reads far healthier than the estate it describes; the aggregate number flatters by construction, because the definitional decisions underneath it are invisible.

The decision-record discipline forces the question into the open, and the honest answer is a decomposition. Report coverage as three numbers, split by one recorded predicate: business-attributed (placed on content evidence a reviewer can inspect), management-service (parked honestly under operational groupings), and unassigned (the truth about the remainder). The three-way split is a policy — a standing rule about what may be claimed — and once it is on the record, the flattering single percentage stops being reportable, because everyone can see which decision it was hiding.

5b. AI is a new author, not a new problem

Agentic AI is arriving in CMDB work, and the instinctive question — should AI write configuration? — is the wrong one. The industry is already answering it in practice; automation increasingly authors rules, mappings, and remediations. The right question is the governance question: when a new author starts making judgment calls, do its decisions land on the same record as everyone else's?

Decision governance answers cleanly, because it never depended on the author being human:

• Recommend, don't assert. An AI author proposes; its proposal is a decision record awaiting review, with evidence attached — not a silent write.
• Confirmation has an evidence bar. A placement is confirmed only on content evidence found on the device itself; context can corroborate, never anchor. The bar is a policy, applied identically to human and machine judgment.
• Review is a release gate, not a ceremony. Human confirm/reject outcomes are themselves recorded decisions, and they feed calibration: an authoring engine ships only when validation demonstrates zero false confirmations against its evaluation corpus.
• Overrides are first-class records. When the operator disagrees, the override is not an edit — it is a recorded decision that takes precedence and survives re-runs. Nobody retypes data; the record keeps both authors honest.

Notice that nothing in this list is AI-specific. It is the same stack — policies constraining decisions, decisions on a record — applied to a faster author. Organizations that already govern decisions will absorb AI authorship as an incremental change. Organizations that govern only writes will discover that they have added a prolific new author to an estate that cannot explain itself.

6. One implementation

One implementation of decision governance is ServiceMatch, and it can serve here as an existence proof that the model runs in practice rather than as the point of the paper.

ServiceMatch is a governed conditioning layer for CMDB discovery data. It sits between discovery tooling and ServiceNow, and it is built so that every judgment call in this paper is an explicit, recorded, reviewable object before data reaches the instance:

The policies constraining these decisions are maintained the same way: a registry, one row per named policy, mapping each rule to its provenance and to the exact point in the system that enforces it — so the published doctrine and the running code cannot silently diverge.

Because the authoring is AI-assisted, the claims in section 5b are load-bearing here. What matters to this paper: every decision the system authors is attributable, evidence-anchored, and overridable on the record — "why is this CI shaped this way?" is a lookup. And the quality holds where we have measured it: on a reference estate, AI-authored configuration matched a hand-curated expert baseline within ±5%.

Deployment: ServiceMatch runs single-tenant in the environment where the engagement lives — discovery data never leaves the organization's control. And everything it produces is designed to enter the instance as conditioned input to identification and reconciliation, not as a direct table load. The paper ends where it began, inside the consensus.

7. The operating loop

Decisions do not stay made. Estates move: sources are added, feeds change shape, precedence that was right in March is wrong by November. A decision record that is written once and shelved is a slightly better archaeology site.

Which is why decision governance is an operating loop, not a project phase. The record has to be cheap enough to maintain daily — every new conflict a decision, every override a record, every recurring judgment promoted to policy — or it will be maintained annually, which is to say, re-sold annually as cleanup.

The industry already agrees that IRE should govern the writes. That consensus took a decade, and it was worth it.

The next discipline is governing the decisions that produce those writes.

Until those decisions become governable objects, CMDB governance will remain incomplete.

ServiceMatch, by SwipeLeft AI, is a governed conditioning layer for CMDB discovery data. The positions summarized here are published in full — with the policies behind them — at swipeleft.ai/servicematch/positions.