The Agreement That Erases the Meaning

Why harmonized definitions are the problem dressed as the solution — and why agreeing to disagree is the better answer

The Definition Was Agreed. The Problem Got Worse.

There is a moment in almost every enterprise data governance initiative that feels like progress but isn't.

The working group has been convened. The stakeholders from HR, Finance, Legal, and Operations are in the room. The term on the table is "Employee." Everyone agrees that the inconsistency is a problem. Everyone agrees that a shared definition is the solution. After several sessions, a definition is ratified. It is entered into the business glossary. The initiative is declared a success.

Six months later, the systems are still inconsistent. The reports still don't reconcile. The data team is still getting contradictory answers to the same query depending on which source they use.

What went wrong?

Nothing went wrong. The process worked exactly as designed. That is the problem.

Harmonization Destroys Precision by Design

When two departments use the same term differently, the instinct is to find common ground. This is politically sensible and semantically catastrophic.

HR's "Employee" and Finance's "Employee" are not the same thing using the same word. They are genuinely different things that happen to share a label because the same person appears in both departments' worlds. HR cares about the employment relationship: the role, the reporting line, the contract type, the date the relationship began. Finance cares about the cost center allocation, the payroll jurisdiction, the budget headcount, the liability category.

These are not the same facts. They do not always hold for the same people at the same time. A director who is also a shareholder may be an Employee in HR's sense and not in Finance's. A contractor on a long-term exclusive engagement may be an Employee in Finance's headcount model and not in HR's contractual records. A person on secondment from another organization exists in one but not the other.

The harmonization process looks at these two legitimate, context-specific usages and asks: what can both departments agree on? The answer is always the intersection — the part of each usage that the other can accept. What remains after that negotiation is a definition general enough that neither department is wrong, and specific enough for neither department's actual purpose.

The sharp boundary that made the term useful within each context has been deliberately removed to achieve the appearance of agreement. The word is shared. The precision is gone.

This is not a failure of governance. It is governance working as intended, optimizing for organizational harmony at the cost of semantic accuracy. The definition was always going to end up too broad, because too broad was the only definition both sides could sign.

The Invisible Homonym

Data management has a well-established concept of the homonym: the same word carrying different meanings in different organizations or different systems. The standard advice is to identify homonyms, flag them, and resolve them through — definition harmonization. The cure, in other words, is the same as the disease.

But there is a more insidious variant that receives far less attention: the internal homonym, where the same word carries different, context-legitimate meanings within the same organization. Both meanings are correct. Both are in active use. Both are supported by real data in real systems.

The external homonym can sometimes be resolved by choosing a winner or by renaming one variant. The internal homonym cannot, because both variants belong to the same organization and serve real purposes. Choosing a winner means one department loses the precision it needs. Renaming requires political capital that governance processes rarely have.

The result is that internal homonyms are almost never resolved. They are covered: a harmonized definition is written that is vague enough to encompass both usages without explicitly acknowledging their differences. The homonym goes underground. The data remains inconsistent. The definition is invoked as evidence that the problem has been solved.

The term is used in a context, and needs a context-specific definition. This is often overlooked.

It is overlooked because acknowledging it undermines the premise of the harmonization project. If context-specific definitions are valid — and they are — then the goal of a single agreed definition is not just difficult but wrong. And admitting that is a harder conversation than most governance initiatives are prepared to have.

Facts Carry Context by Construction

Here is the property of Fact-Oriented Modeling that addresses this directly: facts don't need a single definition, because facts carry their context in their structure.

Consider how FCO-IM handles the Employee problem. Rather than asking HR and Finance to agree on a definition of "Employee," it asks each department to tell it true sentences:

HR tells you:

A Person [p] has an employment contract with Organization [o] from Date [d1]
A Person [p] holds Function [f] within Department [d]
A Person [p] reports to Manager [m]

Finance tells you:

A Person [p] is allocated to CostCenter [c] in fiscal period [fp]
A Person [p] is subject to PayrollJurisdiction [j]
A Person [p] is counted as headcount of type [t] in BudgetPeriod [bp]

These are different facts. They are about the same people, but they express different things. They have different participants, different constraints, different temporal boundaries. Neither set contradicts the other. Neither set needs to be merged with the other to be modeled correctly.

The word "Employee" can still appear in this model — as the name of a role, or as the label for an objectified fact type that captures the specific combination of HR facts. Finance may use the same word for a different objectified fact type. The model accommodates both without forcing them to agree, because the agreement it requires is not about terms — it is about sentences. And each department can verify its own sentences independently.

The facts make context very clear, especially when the verbiage is different and the data is different, while the departments still share the same definitions.

This is the insight that conventional semantic modeling misses. Shared definitions hide contextual differences. Shared facts reveal them. A glossary has one row per term. A fact-based model has as many contextually distinct representations of a concept as the domain actually contains — and each one is grounded in verified, natural-language sentences rather than negotiated prose.

What "Agreed" Should Mean

The failure mode of definition harmonization is that it treats agreement as a terminal state. Once a definition is ratified, the work is done. The definition is the answer.

In a fact-based approach, agreement is a different thing entirely — more granular, more concrete, and more durable.

Agreement is reached sentence by sentence. Is this sentence true in your department? When HR says yes and Finance says yes, the sentence is confirmed. When HR says yes and Finance says no, the difference is visible and specific — not a vague disagreement about what "Employee" means in general, but a precise disagreement about whether a particular fact holds. That disagreement can be investigated, understood, and either resolved or legitimately preserved as a contextual distinction.

This is agreement that actually changes behavior, because it is grounded in the specific facts that systems will be built on. It is not agreement about an abstract term that each department will continue to interpret differently the moment they return to their desks.

The process also surfaces something that harmonization conceals: the cases where the difference is not a misunderstanding but a genuine distinction that the business legitimately maintains. HR and Finance don't disagree about what "Employee" means because one of them is wrong. They maintain different facts about the same people because they have different responsibilities, different regulatory obligations, and different operational needs. A model that respects those differences is a more accurate model of the business than one that erases them.

Agree to Disagree — But Model the Disagreement

In conventional governance, "agree to disagree" is a failure state. The working group couldn't reach consensus. The initiative stalled. The definition never got written. Everyone goes home frustrated and the problem remains open.

In Fact-Oriented Modeling, "agree to disagree" is a feature.

HR and Finance don't need to agree on what "Employee" means. They need to agree on which sentences are true in their context. The disagreement between their definitions is not a problem to be resolved — it is information about the domain that the model should preserve. The model says: here is what HR means by it, expressed as these facts; here is what Finance means by it, expressed as these other facts; here are the people who satisfy both; here are the ones who satisfy only one. That is a more accurate picture of the business than any harmonized definition could produce.

The disagreement, once modeled, becomes navigable. An AI system, a data integration pipeline, or a reporting tool can work with explicit, documented contextual differences. What it cannot work with — what consistently produces errors, inconsistencies, and confident wrong answers — is a harmonized definition that silently contains unresolved differences its consumers don't know are there.

"FCO-IM doesn't ask departments to agree on what a term means. It asks them to agree on what is true — and lets them disagree on everything else."

The disagreement doesn't disappear. It gets promoted from a hidden inconsistency in the data to an explicit, named distinction in the model. That is not a compromise. That is the correct representation of a business that is genuinely more complex than a single definition can describe.

When the goal shifts from forcing agreement to modeling reality, two things happen. First, the governance conversation becomes faster — people stop fighting over definitions and start confirming facts, which is a task they can actually complete. Second, the model produced is honest about the domain in a way that a glossary never is. The contextual differences are visible, traversable, and available for downstream systems to reason over.

Agree to disagree. But model the disagreement, and suddenly the disagreement becomes an asset.

The Governance Process That Would Actually Work

None of this means that governance is unnecessary. It means the governance process needs a different input.

Instead of convening stakeholders to agree on definitions, convene them to verify sentences. Present them with the fact types the model has collected and ask: are these true? Are there cases where they don't hold? Are there facts we've captured incorrectly? Are there facts about your domain that are missing?

The conversation that follows is more productive than any definition workshop, because it is grounded in specifics. Disagreements are immediately locatable — they appear as rejected sentences, as proposed modifications to role names, as constraints that one department insists on and another considers optional. These are resolvable discussions, or at minimum, they are discussions where the precise nature of the disagreement can be documented and preserved.

The governance artifact that results is not a glossary. It is a verified fact model — a set of elementary sentences about the business that every relevant stakeholder has reviewed and either confirmed or explicitly contested. That model is the Business Semantic Model that the data team, the AI systems, and the interoperability projects all need. It was built by the business, verified against real examples, and structured with explicit grammar. It does not need a semantic layer added afterward.

Three Articles, One Argument

This series has been building toward a single claim from three directions:

From the technical side: Entity modeling compresses meaning. The semantic layer projects trying to recover that meaning are paying for a trade that was made decades ago and didn't need to be made. Fact-Oriented Modeling never made the trade.
From the business communication side: Definitions alone are not sufficient. Verifiability, information grammar, and example data are required. These three requirements describe, precisely, what FCO-IM's elicitation methodology produces.
From the organizational side: Harmonized definitions don't resolve contextual differences — they hide them. Facts carry context by construction. The granular, sentence-by-sentence agreement that FBM requires is the kind of agreement that actually works.

The organizations that will build reliable AI systems, interoperable knowledge graphs, and genuinely shared semantic models are not the ones that write the most careful definitions. They are the ones that ask the right questions — and then build models from the answers.