What IS_ACTIVE Actually Meant
Say a customer table has a column called IS_ACTIVE. Just from the name, you’d assume it means “is this customer currently active.” At this particular company, though, it actually meant “is this customer flagged for contract renewal next quarter.” Even a dormant customer with an expired contract and zero activity would show IS_ACTIVE = 1 if they were in renewal negotiations.
How would a new hire at this company ever learn that? It’s not written down anywhere. Most people find out by asking the person at the next desk, “what does this column mean?” That’s tacit knowledge — it never gets documented, it only passes between people.
AI Doesn’t Have a Colleague to Ask
The problem is AI has no one at the next desk. It looks at the column name IS_ACTIVE and sample values (0, 1) and infers “active customer status.” That guess is completely plausible — and wrong.
Ask it “how many active customers do we have?” and AI will count rows where IS_ACTIVE = 1. You get a number, but that number counts renewal candidates, not active customers. Because it runs without an error and produces a plausible-looking figure, nobody notices the mistake for a while.
AI Sees Patterns, Not Meaning
This keeps happening because of how LLMs work. They infer meaning from column names and sample values. A name like IS_ACTIVE paired with values of 0 and 1 statistically matches “active status” across huge numbers of databases on the internet, so the model follows that pattern. This company’s IS_ACTIVE was the exception that broke the pattern. AI never sees the column’s actual meaning — only the shape of its name.
Relationships Hide Even Deeper Than Values
A confusing column is bad enough. Relationships between tables are worse.
To answer “who’s the account rep for customers that churned last month,” you need to join the customer table, the churn history table, and the rep-assignment table. Often that join isn’t defined as a foreign key in the database at all — it’s hardcoded in application logic, or it exists only as “a rule everyone just knows.”
AI can’t see a rule like that. So it picks fields with similar-looking names and joins them arbitrarily. Again, no error. You get an answer. It’s just the wrong one.
The Fix Isn’t a Smarter Model — It’s a Documented Map
Would upgrading to GPT-5 or whatever comes next solve this? No. A smarter model just produces wrong answers that sound more convincing. The bottleneck was never the model’s reasoning — it’s that nothing anywhere documents what this column means or how these tables connect in the first place.
That documentation is exactly what an Ontology provides.
| Database view | Ontology view |
|---|---|
Table CUSTOMER |
Object “Customer” |
IS_ACTIVE = 1 |
Property value “Renewal Candidate” (labeled by actual meaning, not the column name) |
| A join that only existed tacitly | An explicit Link “Customer → Account Rep” |
Tables become Objects, confusing values get renamed to what they actually mean, and join rules that used to live only in someone’s head become visible Links.
What Changes Once You Have the Map
Imagine this company’s IS_ACTIVE story after it’s been mapped into an Ontology.
- A new hire — or a newly connected AI agent — can look up the definition directly instead of asking around.
- “Active customer count” and “renewal-candidate count” now return two different, correct answers. Until now, both questions may have returned the same wrong one.
- Instead of AI guessing a different join path every time someone asks about churned customers and their reps, it follows the defined Link.
- You can go a step further and design an Action like “automatically notify renewal candidates who haven’t been contacted in three months.”
None of this is free. Drawing the map the first time takes real time and people, and it needs upkeep as the company grows. But skip that investment, and the same confusion repeats every time a new column like IS_ACTIVE gets created.
Summary
AI doesn’t fail to understand company data because it isn’t capable enough. It’s because meaning that only ever passed verbally between people was never documented anywhere AI could reference. IS_ACTIVE isn’t the real problem — the real problem is that every company has hundreds or thousands of columns and relationships like it hiding in plain sight.
Frequently Asked Questions
Q. Do we need to document every single column and table in an Ontology?
No. It’s more efficient to work backward from the questions AI or people actually ask often, and document only the tables and relationships those questions need. Prioritize columns like IS_ACTIVE that carry a high risk of being misread.
Q. Where do we start if this confusion is already deeply entrenched? Collect cases from the last three months where a wrong report or a bad decision actually happened. The columns and tables behind those cases give you a natural priority order.