Four of the five steps have nothing to do with language models, and everything to do with whether the answer can be trusted.
Five Steps, Four of Them Invisible
Step one: entity resolution. "Database & Middleware" has to resolve to something: specifically, a sub-tower within the Resource Tower layer of the TBM Taxonomy, with a defined boundary. Which licenses, which instances, which supporting infrastructure are in, and which belong to an adjacent tower? That boundary lives in an ontology: the structured definition of what things mean and how they relate. If two source systems draw the boundary differently, the question is ambiguous before any AI touches it.
Step two: scope resolution. "Our" and "this quarter" both carry assumptions. Which environments count: production only, or dev and test too? Does the quarter follow the fiscal calendar the ERP uses or the calendar quarter the billing feed uses? A comparison question doubles the exposure, because categorization has to have been consistent at both points in time. A sub-tower that was redefined mid-year makes the comparison quietly meaningless, and the tool will not mention it.
Step three: source arbitration. The cost figure could come from the ERP, the billing feed, or an allocation already computed in the TBM model. The count of database instances could come from the CMDB or from a monitoring platform. Something has to decide which system is authoritative for which fact, and that precedence is an ontology property, not a model capability. An NLQ tool without it does not choose wrongly so much as choose arbitrarily.
Step four: deduplication. A CMDB configuration item and a monitoring agent's device record frequently describe the same physical server. If the ontology holds that relationship, they are one asset. If it does not, they are two, and every count, along with every unit cost divided by that count, inflates by an amount nobody has measured.
Step five, the only step most people picture when they hear "AI," is assembly: turning the resolved, arbitrated, deduplicated data into a sentence and a chart. It is the least fragile step in the chain; modern language models are genuinely good at it. Which is exactly the problem: fluency at step five conceals failures at steps one through four.
This is why FogLifter® puts the ontology, not the interface, at the center of its NLQ. The ontology serves as the source of truth for tower definitions, relationships, and source precedence, and it is built on Count, Caliber, and Cost data reconciled against the CMDB, ERP, billing, and ITAM systems before a question ever arrives. An internal line from our product team captures the design philosophy better than any spec sheet: AI doesn't need to be smarter; it needs better data.
The next time an NLQ demo impresses you, ask the vendor to walk through steps one through four for a question of your choosing. The demos that survive that request are the ones worth piloting.
The whitepaper behind this blog
For a deeper look at the validation framework and a step-by-step pre-launch checklist, read the full whitepaper: The AI Readiness Assessment for TBM Programs.
Frequently Asked Questions
The structured definition of what entities mean and how they relate: tower and sub-tower boundaries, which system is authoritative for which fact, and how records across systems map to the same real-world asset. NLQ tools depend on this structure to interpret questions correctly.
Because the failure happens before generation. If entity boundaries, scope, source precedence, or deduplication are wrong, the model is fluently summarizing the wrong data, and fluency makes the error harder to spot, not easier.
The ontology is continuously reconciled against systems of record through the Count, Caliber, and Cost framework, with discrepancies routed to data owners for resolution as they emerge, so the definitions NLQ relies on reflect the environment as it is, not as it was at implementation.
Related Resources
Continue reading on connected topics from FogLifter®.