Can Virima Give Executives Explainable CI Truth for AI?
In February 2024, British Columbia’s Civil Resolution Tribunal ordered Air Canada to pay a customer $812.02 after the airline’s chatbot gave him a wrong answer about bereavement fares. Air Canada argued, in the tribunal’s words, that the chatbot was “a separate legal entity that is responsible for its own actions.” The tribunal rejected that. It found no reason the customer should have known which section of the airline’s webpage was accurate and which was not. It also wrote that it “makes no difference whether the information comes from a static page or a chatbot.”
The amount was small, but the principle reaches your office. IBM’s 2026 study of 2,000 senior technology executives found that two-thirds of surveyed CIOs and CTOs report being held accountable for AI systems they do not fully control. When two sources disagree, and an automated system acts on one of them, the organization answers for it, and “the system said so” is not an explanation.
You now run an ITSM platform, a CMDB, and an AI program, and nobody is asking you to replace any of them. The decision in front of you is narrower. Can one layer supply explained facts about assets and relationships to people and agents while the truth stays in one place?
Short answer: yes for the explanation and the reading path, with limits you should know before you commit. Virima records the source, freshness, and owner of each CI, resolves conflicts by attribute rules, maps relationships, and exposes the data through a REST API. Its published materials do not describe the Model Context Protocol, and discovery runs on a schedule, so ask about both.
What Can Virima Show an Executive About a Single CI?
An executive needs answers to six questions about any record that an agent, a dashboard, or an auditor relies on. The table maps each question to what Virima documents on its CMDB page.
| Question an executive asks | What Virima documents |
|---|---|
| Where did this record come from? | Each CI carries its discovery source |
| How current is it? | Each CI carries a freshness timestamp |
| Who is accountable for it? | Each CI carries an owner tag |
| What changed, and when? | Time-stamped history of what changed and from what state |
| Which source won a disagreement? | Attribute-level authority rules, with conflicts logged by source, timestamp, and rule applied |
| Is this record healthy? | Health scoring for accuracy, completeness, and staleness |
An Illustrative Example
Take a database server that supports a payments service. Its explanation record reads like this. The record came from agent-based discovery and was last observed yesterday. The ITSM platform listed one operating system version, and discovery observed a newer one. The authority rule for that attribute favors discovery, so the observed value stands and the conflict is logged. The owner tag names the payments platform team.
The relationships carry the same discipline. Discovery shows three services depending on this server, and the service owner has confirmed two of them and flagged the third for review. An agent asked to patch this server can read all of that before it acts. So can you, three months later, when someone asks why it did?
Virima’s Trusted Runtime Truth page also describes confidence scores on inventory records. The CMDB and use-case pages do not mention them, so ask to see a confidence score on your own data before you rely on one in a board conversation.
What Is Explainable CI and Relationship Truth?
Explainable CI truth means an executive can ask why a record says what it says and receive an answer from the record itself. The answer has three parts: which source reported it, when it was last observed, and which rule decided between sources. When any part is missing, a person has to reconstruct the answer by hand.
Relationship truth applies the same standard to connections. A relationship is a claim that one CI depends on another, and it carries a source and a timestamp like any other fact. Virima maps dependencies as part of discovery and ties them to business services when service definitions are provided. Service owners then confirm what a dependency means for the business, a judgment that only people can make.
The standards community treats this as a governance matter. NIST’s AI Risk Management Framework is voluntary guidance for organizations that design, deploy, or use AI systems. It lists explainability and interpretability among the characteristics of trustworthy AI, and a record an agent reads is part of what must be explained.
Why Do AI Agents Need Relationship Data, Not Just Records?
A record says what exists, and a relationship says what breaks if it changes. An agent that restarts, patches, or retires a CI without the second fact acts on half the picture, and it does so faster than a person would.
The stakes show up in analyst forecasts. Gartner predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear business value, and inadequate risk controls. Explainable records address the third reason directly.
The visibility problem sits upstream of all this. Flexera’s 2026 State of ITAM report found that complete IT asset visibility dropped to 36%, based on 512 technology professionals. Agents that read a CMDB built on that visibility will repeat its gaps quickly and consistently.
What “Without Another Silo” Means in Practice
A silo forms when a second copy of the truth appears and nobody decides which copy wins. Three tests show whether a truth layer will become one.
| Silo test | Question for your team | What Virima documents |
|---|---|---|
| Feeds the platforms you run | Does it work inside the platforms we already run? | Works alongside an existing CMDB; bi-directional CMDB sync with ServiceNow; integrations listed for Jira Service Management, Ivanti, Halo, Xurrent, Hornbill, and TeamDynamix |
| One authority per attribute | Is it written down which source wins each field? | Attribute-level authority rules, with reconciliation history retained for audit |
| An open read path | Can our agents and tools read it directly? | A REST API for CI records, dependency maps, CI health scores, and change history, with token-based authentication |
The full list of partner platforms sits on the integrations hub.
The second test is the one most programs skip. Without a written rule, the most recent write tends to win, and recency is a poor proxy for accuracy. A direct read from the source keeps one version of each record, while an agent platform that copies CI data into its own store creates a second version that ages.
Who Owns the Truth Layer
Ownership keeps a truth layer from drifting into a project that one team maintains, and nobody else trusts. Four assignments keep it a shared asset.
An executive sponsor, typically you or a direct report, decides which systems feed it and which consume it. A named steward for each domain, such as infrastructure, cloud, and applications, owns the authority rules for that domain. The ITSM owner controls how the data lands in the platform your service teams use. The security lead owns who and what may read it, including every agent.
Put the authority rules in writing and review them on a fixed schedule. Multi-source reconciliation explains how those rules decide what the CMDB holds. A rule that nobody reviews becomes the next source of disagreement, and a disagreement that nobody can trace is what the Air Canada tribunal declined to excuse.
Where the Truth Stops
A decision memo is more credible when it states limits. These are the ones to carry into your evaluation.
- Discovery runs on a schedule: Virima runs high-frequency scheduled discovery, so records are as current as your scan cadence. Ask for the cadence on your estate.
- Discovery has a defined scope: it covers network-connected infrastructure and cloud and SaaS accounts. Browser-side activity such as tracking scripts falls outside it.
- A CMDB maps infrastructure: Virima can show the network paths where sensitive data flows, and a separate data classification system identifies what the data is.
- A CMDB supports compliance work: it supplies the infrastructure record that your audit evidence and access controls rely on, and those two controls remain separate systems.
- Your platform sets agent permissions: your agent platform and access controls decide what an agent may do, and Virima makes the data under that decision explainable.
- The agent connection method needs confirming: the published materials describe a REST API and do not describe MCP. Ask how your agent platform will connect and what that connection can read.
A Six-Week Proof on One Business Service
Pick a service that a human, an automation, or an agent would plausibly act on. The proof tests whether the explanations hold up when you are not in the room.
- Choose one business service and name its owner. Pick one whose outage you would have to explain to the board.
- Pull the explanation record for a sample of CIs. Ask Virima for the source, freshness, owner, and conflict history of about ten CIs under that service. Have an executive read them without an analyst present.
- Have the service owner review the relationships. Count the dependencies the owner confirms, corrects, or says are missing.
- Connect one reader over the REST API, read-only. Use a workflow or an agent in a test environment. Confirm that it reads from Virima directly and that nothing is copied into a new store.
- Score the results against criteria you set in week one. Suggested measures are records with source and timestamp present, relationships confirmed by the owner, conflicts logged and resolved, and analyst hours spent explaining records. You decide the target numbers.
What a Pass and a Fail Look Like
Set the bar before the proof starts, so the result cannot be argued afterward. A pass means an executive can read an explanation record unaided and repeat the answer to a colleague. It also means the service owner confirms most of the mapped relationships. Every conflict in the sample appears in the log with its rule, and the agent reads directly from Virima without a second store.
A fail looks like this: records arrive without a source or timestamp, conflicts are resolved but not logged, or the vendor cannot state the scan cadence for your estate. Any one of these is a reason to pause, because each one forces a person to rebuild the explanation by hand. A partial pass still shows which authority rules to write first.
Put One Business Service in Front of Virima
If you are choosing a trust layer for your agents, decide from evidence on your own data. Book a Virima demo and name one business service. Ask to see the explanation record for its CIs, the relationships your service owner would confirm, and a read through the REST API on your data. If Virima cannot show all three, keep looking. If it can, you have your six-week proof.
Frequently Asked Questions
What is explainable CMDB data?
It is data where every record states which source reported it, when it was last observed, and which rule resolved any conflict between sources. An executive or auditor can read that answer without waiting for an analyst to reconstruct it.
Why do AI agents need relationship data?
A record shows what exists, and a relationship shows what depends on it. Agents that change a CI without dependency data cannot see the downstream impact, so they act quickly on an incomplete picture of the service.
How do you add a CMDB truth layer without creating another silo?
Write down which source wins each attribute, name an owner for each domain, and let agents read the data directly instead of copying it into a second store. One source then decides each field.
Does Virima create another silo next to our ITSM CMDB?
Virima works alongside your existing CMDB and ITSM platform, with documented bi-directional sync for ServiceNow. It resolves conflicts by attribute-level rules, so one source decides each field instead of two copies competing.
How can an AI agent read Virima data?
Virima publishes a REST API with token-based authentication that exposes CI records, dependency maps, health scores, and change history. Its materials do not describe the Model Context Protocol, so confirm the connection method for your agent platform.
