Plausibly Correct, Evidently Wrong: Why Enterprise Meaning Needs a Living Ontology
Plausibly Correct, Evidently Wrong: Why AI Needs a Living Ontology, Not a Data Catalog
Enterprise meaning has to become a living framework - auditable, and updated because it must be, because it’s a runtime component of machine and analyst use and decision-making, if it’s going to be governed and actionable by machines or people.
So today I’m reading different thought leaders and reconciling their proposed solutions against what I know about entropy, organizations, data, and every prior attempt to solve this.
I agree with this: "While data catalogs focus on documenting datasets, schemas, lineage, and ownership, pragmatic ontology defines domain objects and relationships that are directly usable by both humans and AI agents at runtime." — Emmanuel Klinger
Throwing gold-layer metadata into a repository, graph, or vector won't cut it.
The models are already showing us the gap.
They guess for you: plausibly correct, evidently wrong, and it’s what your analysts have been telling you for years, it's what is discovered after using dashboards for a few months.
You just weren’t listening until a machine said it: by producing reasonably deduced but wrong outputs.
Outputs you are now authorizing it to act on, unsupervised.
Nobody Reads Anyone Else's Code — And Now Nobody Reads AI's Either
“the cost of pulling the casino lever to regenerate something new seems cheap, at the beginning.”
That’s not something that started with AI.
In a world of AI, having a unique voice and clear, personal vision will be the differentiator.
16m •
I enjoyed reading the post by Andreas Horn yesterday, and I just want to point out how many of the comments were developers stating that they aren't even reading the code before shipping it lol.
That dovetails with another comment I made about how developers and project teams are reluctant to re-leverage what has been built, and to refactor or extend existing codebases. In practical terms, I've almost never witnessed a developer reuse another developer's or team's code.
The argument is always about risk (risk of dependencies intra-project) and cost (it takes time to read another's code). They'd always rather write it from scratch, even if it is largely replicating existing functionality in another set of code.
This introduces the same problem that duplicated data produces: different and contradictory logic in different places and the overhead of resolving discrepancies between the codebases or data stores.
And the cost of pulling the casino lever to regenerate something new seems cheap, at the beginning.
I don't think these two problems get any better when AI is writing the code, and am reminded of it after reading the comments.
Do you?