When two teams disagree, ask which artifact settles it. An inferred definition never does.
Context management is the discipline of deciding what an AI system is allowed to treat as true about an organization, and keeping that true as the business changes. It is not the Kubernetes sense of context, switching between cluster configurations; not the CRM sense, the record a system keeps about a customer; and not the ITSM sense, the history attached to a ticket. Most of the context your systems run on today is inferred: derived from column names, query patterns, sample values and the statistical shape of how a field has been used.
Inferred context is a reading of the evidence. Nobody wrote it down as a decision; a system worked it out. A profiler notices that a column is always populated when another one is, and concludes the two are related. A model reads a schema and produces a description of cust_status that a domain expert would broadly endorse.
The quality is not the issue. Modern inference is good and getting better, and for most of your estate it is entirely sufficient, because most fields are not contested by anyone. The issue is narrower and it is structural: an inferred definition is a guess with good grammar. It can be excellent and bind nobody.
Apply the test. Two teams disagree. Which artifact settles it?
Not the inference, because the answer to an inference is always available and always reasonable: that is not how we use that field. The inference has no standing to argue back. It was never ratified, so there is nothing to appeal to and nobody to ask.
This is the shape of the most common disagreement in enterprise data, and practitioners describe it far better than vendors do. On r/BusinessIntelligence, a widely-read thread put it plainly:
The biggest data problem I keep running into isn't dirty data. It's teams defining the same metric differently.
The top reply took it one step further, to the place where the argument actually lives:
Our proverbial question is how many customers do we have? Then people get upset when I start asking questions about how they want to define a customer.
No amount of inference resolves that. Both definitions are correct about something. What is missing is not accuracy, it is a decision.
One thing, and only one: a person with the standing to decide has decided, and the decision is recorded where systems can reach it. That converts a reading into an authority, not because the human is more accurate than the inference, but because agreement creates accountability. Someone owns it. Someone approved the change. Someone can be asked why.
Which is also why this is not an argument against inference. The two are stages of the same path. Context is inferred, then promoted once someone signs it, then consumed by whatever asks. The practical rule is to be explicit where it counts and inferred everywhere else, and the part that counts is much smaller than the part that does not.
Because a person reading a report supplies the missing agreement from memory and experience. They know which definition their department uses and they argue when a number looks wrong. An agent has none of that. It receives the inference, treats it as true, and acts; it will do that confidently on behalf of both teams at once, giving each of them a different answer to the same question.
For the wider discipline, see context management. For the structure that carries agreed context, see what a context graph is. If you want the argument about whether a single agreed version is achievable at all, that question has its own piece.