In One Document Apples are Vegetables. In Another, Fruits.

Two weeks ago, we asked who decides what AI gets to see. This week we are going a step further: how does AI decide whether what it sees is true?

The short version is: it doesn't. It does the best it can with what it has been given, and what it has been given is rarely as clean as anyone selling the model would like to admit.

The Confluence page last updated by someone who no longer works at the company. The policy doc you wrote three years ago sitting two folders away from the one that replaced it. Whether the answer the AI surfaces is right or wrong depends on which version it finds first.

So we asked Yaroslav, our director of engineering, to walk through how we actually think about this from the build side. Starting with a metaphor about fruit.

Here is how I explain it. When LLMs are trained, big providers scrape the internet. They pull from niche forums, mainstream forums, every kind of source.

So let's say in one forum, people say apples are vegetables and in another, apples are fruits. The model has both facts. In some situations, it operates with the one and in others, with the other. That is what you are seeing when an AI tool gives a confident answer that turns out to be wrong.

Inside a company, the same dynamic plays out, just with a smaller dataset. The model is not reading the public internet. It is reading your Confluence, your Google Drive, your shared documentation. If your documentation is conflicting, outdated, or has guidance that should have been removed years ago, the AI will surface whichever version it finds. It will sound confident either way.

We think about this from two sides with building Leebry. The first is that the user should always be able to verify the answer. Citation-backed answers with a one-click path to the source are the minimum bar.

The second is that the documentation problem belongs to the customer, not the vendor. We can highlight conflicts and surface outdated pages, but we are not editing your documentation and we don't think a vendor should be.

Your AI is Reading AI.

Last month, EY retracted a cybersecurity study on loyalty rewards programs after researchers at GPTZero found it cited a McKinsey report that does not exist, used mixed-up figures, and contained more than half a dozen footnotes pointing to pages that did not support the claims.

The report had been used by EY consultants in Canada to market their cybersecurity services.

That is the part most coverage missed. EY is not just a Big Four firm that got caught publishing AI-generated content. EY is now a source of AI-generated content, sitting on the internet, getting scraped by training pipelines and retrieved by the next generation of AI tools as if it were authoritative.

The apples-and-fruits problem started with strangers on a forum, but it now lives in the footnotes of corporate reports. The model is still confidently wrong and the source material just got more credible looking.

One practical takeaway from all of this. Run a knowledge source audit on your top documentation systems this week.

The goal is not to fix everything. It is to find out which sources your AI tools are reading, and which of those sources you can actually trust. That answer is what you give your CEO the next time they ask whether the AI tool is trustworthy.

That's Issue #2.

If you have an example of bad documentation that broke an AI workflow (no need to name names), reply and tell us. The next issue is about personalization, and we are working through where the line is between an AI that knows enough about you to be useful and one that knows too much.

See you in two weeks.

— The Leebry Team