Why Discovery Tools Miss Business Context

Industries frequently stop at solving the most solvable parts of a problem, then declare the entire problem finished. Discovery tools successfully identify IT assets but often fail to assign them meaningful business context. This distinction creates a gap between a CMDB that is merely 'complete' in terms of asset count and one that is truly 'trustworthy,' which requires an ongoing understanding of business relevance that is never fully completed.

Discovery tools primarily rely on network signals, such as server and database responses, to identify components. While this method effectively captures factual data about system existence and connections, it inherently misses business-critical context. Servers, for instance, cannot report on their impact on human users or the broader business services they support.

Mapping infrastructure components to specific business services remains a significant failure point in many systems. Discovery tools can identify connections between two systems but cannot discern the ultimate customer-facing capabilities these systems enable. For example, TTC's 'WheelTrans' service critically depends on background scripts that traditional discovery tools often overlook, as these tools prioritize visible servers over the actual workload-carrying scripts.

Ownership data within Configuration Management Databases (CMDBs) is frequently set only at the initial build phase of a system and then rarely updated. A major internal reorganization at the Toronto Transit Commission (TTC) led to incorrect ownership records, with one team splitting into three. This resulted in service tickets being assigned to teams that no longer held responsibility for the work, making CMDB records appear complete but fundamentally inaccurate.

Criticality fields, which dictate the urgency of system failures, are often left blank in CMDBs, particularly for tiers 3 and 4. When an AI agent encounters an empty field, it is programmed to interpret this absence as a 'low' priority, equivalent to an explicit low rating. This default interpretation can critically mislead AI agents, causing them to undervalue the urgency of significant system issues.

While discovery tools can identify that two systems are connected, they cannot ascertain the cascading impact when one of those systems fails. For mission-critical systems, understanding the propagation of failures is paramount. The TTC's 'Vision' system illustrates this challenge, where architectural failovers can obscure the true underlying dependency behavior from automated discovery, making it difficult to predict real-world consequences.

Discovery tools meticulously record individual physical servers, but CMDBs typically lack the mechanisms to document complex failover relationships. This systemic blind spot leads to dependencies being incorrectly labeled as critical when a robust failover mechanism is actually in place. Consequently, the data suggests a critical outage, even though the system continues to function uninterrupted due to the failover.

Human intervention is often required to ensure the accuracy of CMDB data, but there is no automated enforcement mechanism to compel these updates. Unlike scheduled discovery processes for asset existence, contextual data like ownership or business criticality lacks regular, mandated checks. This absence allows systems to 'drift' quietly, with maps becoming outdated, assignment groups becoming incorrect, or criticality ratings remaining unset, without any alerts being triggered. CMDBs remain accurate about the mere existence of assets but become increasingly unreliable regarding their business meaning.

Engineers routinely compensate for inaccuracies in formal records by applying 'tacit knowledge,' which encompasses information not explicitly documented anywhere. This assessment, such as mentally overriding outdated assignment groups or interpreting empty criticality fields, often occurs in about four seconds within a person's head. This crucial knowledge is rarely written down because engineers perceive it as simply 'knowing how things work' rather than explicit data. Consequently, engineers believe they are adhering to CMDB protocols, often unaware they are effectively bypassing its inaccuracies through their personal expertise.

Past manual systems, like those using Microsoft Access, achieved greater data accuracy not because of the tools themselves, but due to their stringent data input processes. Information only entered the database if it originated from an approved change record. By the time a change reached the data entry point, critical decisions regarding system identity, ownership, and connections had already been made and formally agreed upon. This institutional process effectively captured existing human consensus and decisions, ensuring that the 'meaning' of the data was embedded before automation replaced this crucial human oversight.

AI agents, unlike human analysts, interpret empty fields literally as low priority rather than 'unknown,' and treat all dependencies as critical due to their lack of knowledge about failover mechanisms. The agent accurately follows its programmed logic, providing clear explanations of its decisions and the records it processed. However, these decisions are often incorrect because the crucial contextual knowledge an analyst possesses was never formally documented. Without this unwritten institutional context, AI agents, despite flawless logic, cannot 'know' the inherent limitations or gaps in the data they are given.

Analysts provide vital, undocumented information during every interaction, which is not stored in the CMDB. This intelligence is derived from their accumulated experience and understanding, not from written instructions. When the task of ticket handling is automated and transferred to an AI agent, not only is the work removed from the analyst, but their essential, unwritten knowledge is also removed simultaneously. This is because only the procedural 'work' itself was ever documented, never the underlying 'reasoning' or 'tribal knowledge' required to perform it correctly. Automating such tasks therefore carries the hidden risk of eliminating the crucial informal intelligence necessary for accurate problem-solving.