The Data That Doesn't Know What It Means

The Billion-Dollar Semantic Recovery Project

There is a quiet crisis at the heart of enterprise AI adoption, and almost nobody is naming it correctly.

Organizations are investing heavily in semantic layers, knowledge graphs, ontologies, and AI-powered data catalogues. The pitch is always some variation of the same idea: we will make our data understandable — to machines, to analysts, to the business. We will surface meaning from our data assets.

What is rarely said out loud is the uncomfortable premise underneath all of that investment: the data doesn't already know what it means.

That is not a technology problem. It is not something a better LLM will fix, or a richer graph schema, or a more expressive ontology language. It is a modeling problem — specifically, a problem that was baked in decades ago when organizations chose how to represent information, and what to keep and what to throw away.

This article is about what was thrown away, why it is so hard to get back, and why there is a family of modeling approaches that never threw it away in the first place.

The Trade Entity Modeling Made — and What It Cost

Entity-relationship modeling and its descendants — UML class diagrams, logical data models, enterprise data models — made a trade that felt reasonable at the time. Represent the world as things with properties, connected by relationships. Keep the notation compact and close to the structure of relational databases. Make it readable to a wide audience.

The trade worked. Entity modeling became the universal language of information architecture. It is taught in every university, embedded in every major modeling tool, and institutionalized in every enterprise data governance framework.

But the trade had a hidden cost: premature compression of meaning.

Consider a simple example.

In an entity model, and this is a imperfect diagram, — entities with attributes, and relationship lines. Done. Readable. Mappable to tables.

What the entity model does not preserve:

• The roles each participating object plays in the fact. The relationship line has a name, but the endpoints do not. The asymmetry of participation — who does what, in what capacity — is discarded or relegated to a comment field.

So, we can extend the model to include role playing columns to add more distuingishing features.

• The verbalization. The sentence that a business stakeholder would naturally speak to describe this fact is gone. What remains is a structural shorthand that requires interpretation.
• The elementary nature of the fact. An attribute bundles potentially many distinct truths into a single slot. Is this the residential address? The mailing address? The registered address? The entity model does not ask, because it cannot ask — the structure was decided before the question was raised.
• The constraints that emerge from the domain. Uniqueness, mandatory participation, exclusion — in entity modeling these are added after the structure is defined. In FBM they arise naturally from the fact populations themselves.

None of this was malicious. It was pragmatic. Entity modeling was designed for an era of constrained storage, limited tooling, and implementers who needed diagrams that mapped directly onto CREATE TABLE statements.

But that era is over. And the constraints that justified the trade no longer exist.

What Fact-Based Modeling Preserves

Fact-Based Modeling — the family of methods that includes ORM, CogNIAM, and FCO-IM — starts from a different premise entirely.

The sentence comes first.

Before any diagram is drawn, before any structure is defined, the modeler captures the elementary facts that domain experts naturally express in language. Person 123 is registered at an Address 900. Employee 777 holds a Function within a Department 987. Contract 400 is governed by Jurisdiction. These are not yet model elements — they are domain statements, verbalizable by anyone who understands the business.

The model is then derived from those statements, not the other way around. The structure serves the language. This means that the model, when complete, can be read back as natural language by any stakeholder — not because a documentation layer was added, but because the language was always the primary artifact.

To illustrate what earlier diagrams lost in semantics, we now depict an abstract diagram displaying missing verbiage.

Everything is a fact.

In FCO-IM in particular, there is no ontological distinction between an "entity" and a "relationship" or between an "object" and an "attribute." All information is expressed as elementary facts — irreducible statements that cannot be subdivided without losing meaning. This uniform treatment means that nothing gets promoted to first-class citizenship at the expense of something else being demoted to structural decoration.

The model is the semantic layer.

This point deserves emphasis. The entire project of adding semantic layers to existing data infrastructures is an attempt to reconstruct, after the fact, the meaning that was compressed away during modeling. In FBM, that meaning was never compressed. The semantic layer is not an add-on; it is the model itself.

The diagram below illustrates the semantics, the concrete examples, the type names, and constraints.

The Asymmetry Nobody Talks About

There is a useful thought experiment that reveals the structural difference between the two approaches.

You can write a transformation from an FBM model to an entity model. It is a compression function. You lose information — role identities, verbalizations, the elementary structure of facts — but you can mechanically produce an entity model from an FBM model. Tools and documents exist that describe exactly this transformation.

Now try to write the transformation in the other direction — from an entity model to an FBM model.

You cannot do it mechanically, because the information required to reconstruct the FBM model is not present in the entity model. You would need to go back to the domain. You would need to ask the business stakeholders the questions that the entity modeling process never asked. You would need to recover, through interviews and analysis, the elementary facts that were bundled into attributes and relationship lines.

This is not a minor technical inconvenience. It is the definition of lossy compression. And it is precisely the work that semantic layer projects, knowledge graph construction pipelines, and AI data understanding tools are performing today — at enormous cost, with incomplete results, on data assets that may be decades old.

Reverse engineering existing databases without proper documentation, modeling data from spreadsheets, and Data Warehousing efforts to harmonize source systems, all strugle with finding meaning in raw data.

The asymmetry also manifests in the documentation and tooling around standards. When an entity-based modeling framework adds FBM as a supported input notation, the documentation that gets written explains how FBM concepts map into the entity framework. FBM would be positioned as a notation — a way of drawing things — while the entity framework is positioned as the semantic target. There is never a companion document explaining what the entity framework fails to express that FBM captures natively, because writing that document would require naming the losses. Those losses are structural. They are features of the entity approach, not bugs in the transformation.

Graph Solutions and the Knowledge Mining Trap

Property graphs and RDF triplestores have attracted significant attention as solutions to the semantic recovery problem. They are more expressive than relational tables. They can represent facts as relationships. They support ontological reasoning. Surely they close the gap?

They do not, for a simple reason: most knowledge graph projects start from existing entity models or relational schemas, and inherit all of their semantic ambiguities in the process.

A node labeled Customer connected by an edge labeled hasAddress to a node labeled Address is not fundamentally more semantically precise than a Person table with an address foreign key. It is a different notation for the same compressed meaning. The role identities are still unnamed. The verbalization is still absent. The elementary fact structure is still bundled.

Dynamic diagram layout, and color coded filtering all look very fancy when mining for coherence, but it still skips the work of deeply understanding the semantics that were lost from the start.

The more important distinction is between two fundamentally different activities:

Knowledge mining is the extraction or inference of meaning from representations that were not designed to be semantically precise. It is what you do with entity-modeled data when you need semantics. It is the domain of data catalogues, automated ontology extraction, LLM-based schema interpretation, and semantic enrichment pipelines. It is inherently incomplete, because you are trying to recover information that was not captured.

Knowledge modeling is the capture of meaning at the source, before compression, in a form that preserves elementary facts, role identities, verbalizations, and domain constraints. It is what FBM does. It produces models that are ready for semantic processing without any recovery step.

These are not two approaches to the same problem. Knowledge mining is what you do when knowledge modeling wasn't done. The AI industry's enormous investment in knowledge mining is, in a real sense, the bill for decades of entity modeling.

The Question the Standards Bodies Are Not Asking

Enterprise data modeling frameworks — including the most thoughtfully constructed government information modeling standards — are largely built on entity foundations. Some of the more progressive ones have recognized the existence of FBM and have taken steps to accommodate it, often by providing transformation paths from FBM notation into their existing entity-based metamodels.

This is well-intentioned. But it places FBM in a subordinate position: a notation that feeds a framework whose core concepts remain entity-based. The semantic richness of FBM enters through the front door and is compressed on the way in. The framework gains FBM notation without gaining FBM ontology.

What these frameworks do not do — what would be genuinely revealing — is ask what their entity-based metamodel cannot express that FBM captures natively. That question would require them to document the losses, and the losses are significant enough that documenting them would amount to a critique of the framework's foundations.

If we were designing an information modeling standard from scratch today, given what we now know about the semantic requirements of AI systems, knowledge graphs, and interoperability at scale — would we choose entity modeling as the foundation?

The Advantage of Starting Right

The organizations that will navigate the AI-driven semantic layer challenge most effectively are not the ones that build the cleverest recovery pipelines. They are the ones that start with models where the meaning was never lost.

FBM models, and FCO-IM models in particular, are already in the form that knowledge graphs and semantic AI systems need. The verbalization is there. The role identities are there. The elementary fact structure is there. The constraints are there. The example data is there. The detailed metadata is there to support modeling governance. There is no semantic layer to add, because the model is already semantic.

This does not mean every organization should immediately abandon their existing entity models. Migration is a real cost, institutional inertia is real, and FBM requires a different modeling discipline that takes time to acquire. Those are legitimate practical considerations.

But for new modeling initiatives — for the domains where organizations are currently investing in semantic layers and AI knowledge extraction precisely because existing models are insufficient — the question of which paradigm to start with deserves a serious answer rather than a default one.

FCO-IM, and other FBM methods, have been around for decades and have been ignored as being too complex. To be honest, the work not put into this method, is the work we're paying for now. The cost never surfaced due to the entity based systems provided a quick solution to a problem in most cases. The challenge we're all facing now, requires us to do what we should've done from the start. This is an era of great opportunity, and it will be hard at the same time. Not because FBM is harder, but simply because not doing it is a delayed hardship. FBM shows the real cost from the start, and does not take easy entities for a sufficient answer.

Conclusion: Name the Problem Before Buying the Solution

The semantic recovery industry — the knowledge graphs, the ontology platforms, the AI data understanding tools — is not going away. The investment is too large, the institutional momentum is too strong, and for organizations sitting on decades of entity-modeled data, some form of recovery work is genuinely necessary.

But the framing of these tools as solutions obscures the more important question of what caused the problem. Meaning was not lost from enterprise data by accident. It was compressed away by a modeling paradigm that was reasonable for its time and has long since outlived the conditions that made it reasonable.

Fact-Based Modeling has existed for decades, waiting patiently for the moment when the question of semantic precision became unavoidable. That moment is now. The AI knowledge layer projects are — without knowing it — making the case for FBM every time they struggle to recover elementary facts from entity-modeled schemas.

The question is not whether FBM is more semantically precise than entity modeling. It demonstrably is. The question is whether the field is ready to acknowledge what was lost, and what it would mean to stop losing it.

Changes made: