Which facts in your AI's memory has anyone checked?

Last week one of our working files described a credential as belonging to one AI provider. It belonged to a different service altogether. The label was simply wrong. Had a session trusted the label and wired it up as described, the result would have been a configuration that could never work, failing in a way that pointed everyone at the wrong supplier.

Nobody had lied. The label had been written at some point and never checked, and it sat there looking exactly as authoritative as every true line around it.

That is the problem with most of what businesses feed their AI tools. Every fact arrives with the same weight. The price list from 2024 and the price list from last Tuesday look identical to a model. So does the client contact who left in March.

Why models do not push back

OpenAI published a paper in September 2025 on why language models hallucinate. One of its arguments is that the way models are trained and scored rewards guessing over admitting uncertainty. A model that says "I don't know" scores worse on many tests than one that guesses and is sometimes right.

Apply that to your business. When the model has a fact, it uses it. When it has two conflicting facts, it picks one. When it has none, it often fills the gap with something plausible. It has no way of knowing which of your facts someone actually checked, because nobody told it.

What a fact needs to carry

In a company memory, the useful unit is a fact with a status attached. An example:

Fact:      Standard call-out window is 4 working hours in the city
Source:    Signed service terms, version 3
Owner:     Operations
Checked:   12 Aug 2026
Status:    Verified

Five lines. The source says where it came from. The owner says who answers for it. The date says how stale it might be. The status says whether anyone has checked it, and it has more than two values: verified, unverified, and retired, for facts that were true once and must not be used again.

With that in place, rules become possible. Only verified facts go into anything a client sees. Unverified facts can be used internally with a flag. Retired facts are kept, so nobody re-adds them by accident, and never used. Anything checked more than six months ago goes on a review list.

What we changed after the mislabelled credential

The lesson went into our memory as a rule with its reason attached: check the thing, not the label. Before wiring any key, confirm what it actually is and that it works. Before using a model name, confirm it exists in the provider's current list. It sits in the memory our AI sessions read before they start.

It is a small rule. It exists because a label looked like a fact.

What a status field does not do

It does not make the facts true. A tired person can mark something verified without checking it, and then the status is worse than useless, because it is trusted. The status is only as good as the habit behind it.

It does not stop a model from inventing facts about the outside world. A verified internal price list does nothing for a question about a competitor's pricing or a change in tax law. Those still need a source and a person.

And it takes work. Someone has to own the review list and actually review it. In a firm of twenty people we would guess a few hours a month, and it will be the first thing dropped in a busy week unless it is on someone's calendar.

Start with ten

List the ten facts your AI tools are most likely to state to a customer: prices, lead times, service areas, warranty terms, payment terms, contact details. For each one, add a source, an owner and the date someone last checked it. If you cannot fill in the date, mark it unverified. Do not be surprised if one or two turn out to be out of date.

The AI readiness check looks at data quality alongside the rest of your setup. Book 20 minutes at pgco.world/book.