The situation
A professional-services firm wanted its staff to ask the business a question in plain language: is this engagement on track, what is this client’s outstanding balance, is a particular resource available next week. A language model answered all of these instantly and fluently, and a proportion of those answers were wrong in ways that read exactly like the right ones. For a firm that bills by the hour and reports balances to clients, confident and wrong was the one failure mode that could not be allowed through.
The model itself was not the problem. Left to draw on whatever it had absorbed in training and on the shape of the question, it produced a number that looked like a balance whether or not it was the client’s actual balance. The failure was invisible at the point of use: the answer arrived phrased with the same fluency as a correct one, with no marker to say which part had been retrieved and which part had been guessed. Over the firm’s own mix of engagement and billing data, spread across a CRM, an ERP and ad hoc spreadsheets, the guessing only got worse, because even a model that tried to look things up could not tell which of several conflicting figures was the one that counted.
What we built
We bound the assistant to governed data and let it speak only from there, which meant building three things underneath it before the assistant itself.
A semantic layer defined what engagement, balance, available and billed each meant, so the assistant was never left to infer a definition on the fly. Retrieval was bound to that governed data platform: before it answered, the assistant fetched the relevant records and answered from those rather than from memory, so the generated text was constrained to what the retrieved data actually said.
Diagram: a plain-language question, such as what is our margin, passes into a semantic layer that defines what terms like margin and active customer mean. The semantic layer reads governed data, one trusted copy, and returns an answer. Both the data and the answer trace down to the underlying source rows, so every figure can be checked. The assistant answers from governed data or says it cannot, and it never invents a number.
Every answer carried a path back to the source records behind it, so a staff member could check it, and when the data could not support an answer, the assistant said so rather than filling the gap. A plain “I cannot tell you that from the data” turned out to matter more to the firm than a confident guess ever would have.
The pattern only worked because the governed layer beneath it already existed by the time we built the assistant. Where the firm’s data had not yet been conformed and defined, we did that work first; grounding an assistant on ungoverned data would only have given the confusion a more convincing voice.
The outcome
Routine questions, where is this engagement up to, what does this client owe, who is available next week, started getting answered without a person in the loop, and the ones the data genuinely could not answer were escalated rather than guessed at. Staff trusted the assistant’s silence as much as its answers, because both tracked the underlying data rather than the phrasing of the question. The firm’s own team maintains the semantic layer today as the definitions evolve.