Multisource Data Arbitration: The Hidden Engine Powering an AI-Trusted Configuration Database

Foundation: How priority, ordered source conflict resolution, Data Refresh Rules, and CMDB 360 turn your configuration data into the authoritative foundation every AI workflow demands.

The Data Quality Problem AI Cannot Solve for You

AI is only as trustworthy as the data it reasons over. That sentence sounds obvious. Its operational consequences are not. Every AIOps workflow, every predictive impact analysis, every autonomous remediation agent traces its assumptions back to a CI record. Configuration data is the structural backbone of AI-driven IT operations — not as a convenience, but as a hard dependency. If a natural language agent is asked which services are affected when a server goes down, it traverses the CMDB's relationship graph to answer. If an anomaly detection model correlates incident volume to a deployment event, it reads CI attributes to identify the change surface. The intelligence is only as reliable as the data underneath it. Most configuration databases are not reliable. Not in the catastrophic, obviously wrong sense — the dangerous kind is subtler. Data looks consistent, passes format validation, and would fool a casual reader. But it was written by the wrong source. This is the core problem: production CMDBs are populated by multiple competing discovery tools, each with a different view of the same infrastructure. ServiceNow Discovery sees a Windows Server at the protocol level. SCCM sees it through WMI. Altis sees it through its own agent. They do not always agree. Without a formal arbitration mechanism, the loudest source wins — not the most accurate one. Whichever tool ran most recently writes its values, and every competing observation is silently overwritten.

The result is attribute thrashing: the same field flipping between values as competing sources write and overwrite without coordination. Consider a concrete example — a Windows Server CI with three sources: ServiceNow Discovery (priority 100), Altis (priority 200), SCCM (priority 300). A lower number means higher authority. Without reconciliation rules enforcing this hierarchy, all three sources write freely. SCCM runs on Thursday and sets os_version = "Windows Server 2022 Standard". ServiceNow Discovery runs Tuesday and corrects it to "Windows Server 2022 Datacenter". SCCM runs Thursday again. The field is a pendulum. The CI becomes an averaging artefact of whoever ran last, and no AI system can rely on it. No AI model fixes this. Better prompts do not fix it. More sophisticated inference does not fix it. The problem lives in the data layer, and it requires a data layer solution. That solution is a formal data arbitration layer baked into the platform itself — not bolted on after the fact, not managed by governance meetings, but encoded as executable platform policy. The mechanism is the Identification and Reconciliation Engine (IRE), extended by Data Refresh Rules and CMDB 360. Understanding how they work together is the prerequisite to building a configuration database that AI can actually trust.

How Priority-Ordered Source Arbitration Works

The IRE is a two-phase arbitration pipeline with a clean separation of concerns. Phase 1 establishes identity. Phase 2 establishes trust. They answer fundamentally different questions, and conflating them is one of the most common architectural mistakes in CMDB design.

Phase 1 — Identification

Before any data lands in a CI record, the platform must determine whether the incoming payload refers to an existing CI or represents something new. The Identification Phase applies a sequential identifier-matching cascade. For a Windows Server, the sequence might proceed through CI Number first, then MAC address, then FQDN and IP address combination, then serial number. Each rule in the sequence is evaluated in order; the first successful match terminates the cascade. If a match is found, the payload carries the matched CI's sys_id forward to the Reconciliation Phase. If no match is found, a new CI record is created with the incoming values written directly. The architectural boundary here is significant: reconciliation does not occur on initial CI creation. The very first source to discover a CI sets the baseline values unconditionally. If SCCM discovers a server before ServiceNow Discovery does, SCCM writes the initial state. When ServiceNow Discovery arrives later, it has higher priority and will overwrite correctly — but during the window between SCCM's creation and Discovery's first run, the CI's data is only as good as SCCM's data. For AI pipelines consuming CIs in real time, this initial-state window is a known vulnerability.

The other risk: if identification rules cannot reliably match a source's payload to the existing CI — because the source uses different identifier attributes — the source creates a second CI record rather than triggering reconciliation. Duplicate CIs are always an identification failure, never a reconciliation failure. Reconciliation rules cannot protect you from duplicates.

Phase 2 — Reconciliation

Every subsequent write from any source is evaluated against the active reconciliation rules. Each rule carries an order number — a positive integer where lower means higher authority. The canonical example: ServiceNow Discovery at order 100 holds the highest authority; Altis at 200 is secondary; SCCM at 300 is tertiary. At reconciliation time, the platform compares the incoming source's order number against the order number of the source that last authoritatively updated the CI. If the incoming order is lower (higher authority), the update is permitted. If the incoming order is higher (lower authority), the platform blocks the write. The value set by the higher-authority source is preserved. When SCCM (order 300) attempts to overwrite a field set by ServiceNow Discovery (order 100): 300 > 100 — blocked. The incorrect RAM value that SCCM's WMI query returned does not reach the CI record. Every AI system consuming that CI's attributes inherits the correct value from the authoritative source, not the noise from the lower-confidence one. Each reconciliation rule carries three governing elements:

• Applies to: the CI class (cmdb_ci_win_server, cmdb_ci_linux_server, etc.) and, optionally, specific attribute fields within that class
• Order: the priority integer — gaps between values (100, 200, 300 rather than 1, 2, 3) are intentional, preserving space to insert a new source at order 150 without renumbering everything downstream
• Discovery source: which integration tool this rule governs, matched against the sys_import_source metadata in the incoming payload

One detail practitioners frequently miss: ServiceNow ships no baseline reconciliation rules. Out of the box, every CI class is last-write-wins. The platform's position is reasonable — source authority is an organisational trust question, not a universal one. Whether ServiceNow Discovery or SCCM should be authoritative for RAM on a Windows Server depends on your environment. But the consequence is that a newly enabled CI class is ungoverned until someone configures its rules. Source integration and rule configuration must happen together.

The Staleness Problem — Data Refresh Rules as a Circuit Breaker

Priority ordering solves the conflict problem. It creates a new one: what happens when the highest-priority source goes silent?

If ServiceNow Discovery stops running — agent failure, network partition, credential rotation, a firewall rule change that pushes a server outside its scan range — its last-written values remain locked in the CI. SCCM may have fresher, more accurate data. Altis may have updated its view just yesterday. But the reconciliation rules will continue to block every write from both, because the authority ranking does not account for recency. The order number comparison reads 200 > 100 and fires the block, regardless of whether Discovery ran this morning or three weeks ago. This is the staleness trap: the most trusted source becomes a stale lock. The CI record confidently displays discovery_source = "ServiceNow Discovery" while silently degrading in accuracy, and no downstream system receives any signal that something is wrong. The solution is the Data Refresh Rule. Configured within a reconciliation rule, it adds a temporal dimension to static priority ordering. The mechanics:

• The rule is configured with a time interval — in the worked example, 14 days
• When a higher-priority source has not updated a given field within that interval, its priority hold expires
• The next lower-priority source in the ranking is then permitted to write for that field
• The cmdb_datasource_last_update table tracks last-update timestamps per source per CI class — this is the clock the Data Refresh Rule reads

The distributed systems analogy is precise: Data Refresh Rules implement a circuit-breaker pattern. In distributed systems, a circuit breaker detects when a downstream service has become unresponsive and automatically routes traffic to a fallback, without requiring human intervention to open the switch. The Data Refresh Rule does the same thing: when the authoritative source goes dark beyond the configured threshold, the circuit opens, and the next trusted source takes over automatically. The 14-day example in practice: if ServiceNow Discovery has not updated a Windows Server attribute in 14 days, AMIS — the next-priority source — is permitted to write. AMIS's data is less authoritative than Discovery's agent-based scan, but it is more current than a 14-day-old stale record. Once ServiceNow Discovery recovers and runs again, it re-asserts authority on the next cycle. discovery_source shifts back. The circuit closes. Calibrating the threshold requires real data, not round numbers. Query cmdb_datasource_last_update for the source's actual historical cadence. A Discovery cycle that runs weekly with low variance should carry a threshold of approximately two weeks — one missed cycle as expected operational tolerance, two missed cycles as the trigger. Set it shorter than the discovery interval, and fallback activates during normal operation. Set it longer than necessary, and staleness accumulates to the point where lower-priority source data may itself be stale before the circuit opens.

CMDB 360 — Every Truth, Not Just the Winning Truth

Priority-ordered arbitration decides which value wins. That decision is correct and necessary. But it discards something valuable in the process. In standard reconciliation mode, rejected proposals are gone. When Altis reports os_version = "Windows Server 2022 Standard" and ServiceNow Discovery's higher priority blocks it, Altis's proposed value is not stored in a pending state or logged in a conflict register. It is discarded. The CI record reflects one truth — the winning truth. Every other source's view of that attribute is invisible. This creates a class of questions that standard reconciliation cannot answer: What did every source propose for this IP address? What would the CI look like if you reprioritised sources? If a high-priority source misconfigured for three weeks and corrupted 500 CI records, can you roll it back? Can inter-source disagreement be treated as a confidence signal?

CMDB 360 answers all of these by retaining every value that was ever proposed — winners and losers alike. The storage mechanism is the cmdb_multisource_data table, which captures every source proposal flowing through the IRE regardless of whether it was accepted or rejected.

This is not a debugging log. It is a secondary data product with three distinct operational capabilities.

Track. Audit the full provenance of any attribute on any CI. "When did Altis last report a value for os_version on this server? What did it say?" This is answerable without querying the discovery tool directly, without mining sys_audit records, and without access to historical snapshots. The evidence is in the table, continuously built by every discovery cycle.

Revert. If a reconciliation rule is misconfigured and the wrong source wins for a period, the platform can revert affected CIs to the values that would have been written under the correct configuration. The rejected proposals from the correct source are already stored. A targeted rollback replaces a CMDB data recovery crisis. Recompute. When rules change — new source added, priority reordered, new attribute added to scope — the platform can replay historical proposals against the new rule set and update CIs to the corrected state. This is a backwards-compatible migration without re-running discovery. It means improving reconciliation governance does not just improve future data quality; it retroactively improves historical data. The AI angle is the most strategically important capability: rejected source proposals are weak signals. If ServiceNow Discovery reports 16 GB RAM and SCCM consistently reports 32 GB across 90 days — but SCCM is lower priority — cmdb_multisource_data captures all 90 days of SCCM proposals. An anomaly-detection model reading this table can flag the sustained disagreement as a sensor accuracy issue, a capacity change that has not been reflected in the authoritative source, or a potential discovery misconfiguration. The rejected data is not noise. It is a confidence signal. Source disagreement on an attribute over time is precisely the kind of weak evidence that distinguishes a trustworthy AI feature from an unreliable one. A CI attribute where all sources agree carries high confidence. A CI attribute with sustained inter-source disagreement carries low confidence, and downstream AI systems should treat it accordingly.

One operational note: cmdb_multisource_data is only populated after reconciliation rules are configured for the CI class and data has flowed through the IRE. Historical pre-configuration data is not retroactively captured. Enable CMDB 360 and configure reconciliation rules together, early. Every discovery cycle that runs before you enable these features is historical evidence permanently unrecoverable.

Practical Configuration Prescriptions for AI-Readiness

Seven concrete prescriptions for CMDB practitioners building toward an AI-trusted configuration database:

1. Design the priority taxonomy before touching the platform. Map every data source your organisation uses. Assign tier ranges: Tier 1 = 100–199 (network-discovery grade), Tier 2 = 200–299 (agent-based or ITSM-grade), Tier 3 = 300–399 (manual, vulnerability scanners, CMDBs of record for specific domains). Reserve gaps for future sources. Write this taxonomy in a shared governance document before configuring any rules. Every rule written thereafter simply asks: which tier does this source belong in? The order number follows from the taxonomy.
2. Never assign the same order number to two sources. Ties produce undefined behaviour. The platform does not guarantee which source wins when order numbers collide. Gaps between numbers are free — use them.
3. Scope reconciliation rules to specific attributes, not entire classes. A vulnerability scanner (Qualys, Rapid7) should own the last_scanned, vulnerability_count, and patch_level fields — but should never be permitted to overwrite hostname or ip_address. Field-level scoping enforces attribute ownership rather than all-or-nothing source authority. Different sources have different observational competencies; reconciliation rules should encode that precisely.
4. Set Data Refresh Rules conservatively. A 14-day interval is a reasonable starting point for a weekly discovery cycle. Set the threshold too short and lower-priority sources overwrite unnecessarily during normal operation. Set it too long and staleness accumulates. Align the interval to the actual discovery cadence of your highest-priority source — query cmdb_datasource_last_update for historical cadence data — plus a safety buffer equivalent to one additional cycle.
5. Build CMDB Health dashboards that surface source disagreement rate. The cmdb_multisource_data table lets you compute — per CI class, per attribute — the percentage of proposals that were rejected. A high rejection rate for a normally-authoritative source signals discovery failure. Surface this as a leading indicator. A source that has stopped winning reconciliation contests is a source that has stopped running, is misconfigured, or has lost access. Detect it before it propagates into AI decisions.
6. Treat cmdb_multisource_data as a feature store input, not a log. Feed source disagreement signals, staleness duration, and proposal frequency into AIOps models. These signals encode reliability context that no single CI attribute captures. A CI attribute with 90 days of single-source agreement is a different quality of input than one with 90 days of three-way disagreement. Make that difference visible to the models that consume it.
7. Run recompute after every rule change. When you add a new source, reorder priorities, or change attribute scope, trigger a recompute across affected CI classes. Do not assume historical data is correct under the new rules — it is not, until recomputed. This is the difference between a governance change that improves the CMDB going forward and one that corrects the full historical record.

Three Key Takeaways

1. Priority Numbers Are a Contract, Not a Setting

The order number on a reconciliation rule is the single arbiter of truth for every attribute write that flows through the IRE. Getting the taxonomy wrong corrupts data at ingestion — and the mistake surfaces downstream, in an AI model that produces unreliable outputs, not in the platform where the misconfiguration lives. Design the taxonomy deliberately, document it formally, and review it whenever sources change. An undocumented priority taxonomy is a governance liability.

2. Rejected Data in CMDB 360 Is an Asset, Not Waste

The cmdb_multisource_data table retains every proposed value — the ones that won and the ones that lost. Source disagreement over time is a confidence signal with direct operational value: it surfaces discovery sensor failures, flags sustained attribute uncertainty, and provides the raw material for AI models to reason about data reliability rather than treating all CMDB attributes as equally trustworthy. Feed it to AIOps models. Surface it in CMDB Health dashboards. Use it to detect discovery failures before they propagate into AI decisions.

3. Data Refresh Rules Protect Completeness When Sources Fail

Stale locks from silent authoritative sources corrupt data as surely as bad writes do — they just do it quietly, without error logs or alerts. A properly configured Data Refresh Rule acts as an automatic circuit breaker: when the highest-priority source goes dark, the next trusted source takes over without human escalation. Design Data Refresh Rules with the same rigour as the priority taxonomy itself. They are not fallback accommodations; they are the mechanism that keeps the configuration database current when the infrastructure it observes does not cooperate.\

Conclusion

The configuration database has always been the hardest data problem in enterprise IT. Not because discovery is technically difficult — it is not. The difficulty is arbitration at scale: hundreds of sources, thousands of CIs, millions of attribute proposals, all competing to define the same reality. For decades, the solution was governance meetings and manual reconciliation scripts. That era is over. Multisource data arbitration — implemented through priority-ordered reconciliation rules, Data Refresh Rule circuit breakers, and CMDB 360's full-provenance audit layer — is the engineering answer to a problem that governance alone could never solve. It does not eliminate source disagreement. It turns disagreement into a governed, auditable, reversible decision with a clear chain of custody. Every accepted value has an authoritative source. Every rejected value is retained. Every priority decision is encoded as executable policy that the platform enforces consistently, at scale, on every discovery cycle.

This matters most precisely because AI is arriving. Every AI workflow that touches operational data — AIOps anomaly detection, autonomous remediation, predictive impact analysis, natural language querying of infrastructure — must trust the data it reasons over. That trust is not built in the AI layer. It is built in the data layer, long before the model ever runs. The configuration database is either the most reliable input an AI system has, or it is the reason that AI system fails in production. There is no middle ground. A CMDB with unreconciled sources feeding into an AIOps model is not a slightly degraded input — it is a systematically poisoned one. The model learns patterns from data that reflects whoever ran last rather than whoever is most authoritative. Its outputs are confidently wrong in ways that are difficult to trace back to their source.

For tinyloop.com.au readers: the path forward starts with the audit. Review your current reconciliation rule configuration — query cmdb_datasource_last_update, cross-reference against configured rules, identify ungoverned classes. Audit your Data Refresh Rule intervals against the actual cadence data for your discovery sources. Then look at your cmdb_multisource_data table: if it is not being actively queried for source disagreement signals, you are sitting on an operational asset you have not yet opened.

The technology is in place. The configuration is the work.