An answer is only as good as its denominator.

The dangerous answer is not always the obviously wrong one. It can be a correct count attached to the wrong population, or two valid numbers combined into a claim neither supports.

That distinction became central while building the customer-insights platform, a conversational analytics backend for customer-experience work. The easy part was letting someone ask a question. The difficult part was preserving the meaning of the answer all the way from the data to the prose.

Put meaning where it can be enforced

A percentage needs more than a numerator. It needs a named denominator, exclusions, and a clear relationship between the row and the population being described.

In the customer-insights platform, curated views carry those rules. Test and abandoned noise is excluded before a request reaches the analytics layer. Ranking exclusions are explicit. Percentage columns identify the population they describe. A row outside a population does not receive a plausible-looking percentage of it.

These are application contracts. They should not depend on the model remembering a paragraph of instructions every time.

Let the model explain; make the system account

On the normal query path, typed tools and validated query builders retrieve the facts. The tool payload includes the rows, SQL, denominator, and exclusions. A verification step then checks significant figures in the answer against that payload.

That check is useful, but its limits matter. A figure appearing in a tool result does not prove that every sentence around it is correct. Verification findings are logged so the system can be investigated and improved. It is a layer of accountability, not a declaration of infallibility.

The interface is only the last step

This is why I keep returning to system design when working on AI. The model sits inside boundaries someone still has to define: what it can read, what a metric means, what happens when configuration is incomplete, and what evidence remains after a response.

The same reasoning connects analytics semantics, API contracts, and security. In each case, the interesting question is where an assumption becomes something the system can enforce.

A conversational interface can make a system approachable. The work underneath makes it worth approaching.