Coherence: meaning survives many handoffs

Someone asks an assistant for something the company should already be able to produce — who the customer is on this account, what the policy says, a first draft of the release notes. A prompt fires. A window is assembled from last week’s tickets, a CRM record, a help-center article. Tools are called. Something clean comes back and is stored for the next turn. That is the request: built from nothing each time, leaving only its product behind. It fails in an afternoon, and somebody on the platform team sees it fail, because a request failing is loud.

Everything the request touched was already there before it started. The account object, the billing plan, the article, the topic in the component content system, the policy with a version number on it. None of it was created for this request, and all of it sits whether or not anyone opens an assistant today. That standing material is the estate. It fails slowly, over years, and nothing looks broken while it does. Underneath the estate is the ground: what the terms mean, who says so, and whether that still holds when work crosses a seam.

Organizations don’t adopt AI. They grow capabilities. Each wave of the last three years arrived as a question, and each question, once an organization learned to ask it well, grew into a practice with a team and a budget line. What should the model do: prompt engineering. What should it see: context engineering. How should the whole system behave: harness engineering — the tools, memory, guardrails and loop around the model, which is where agent work became systems work and stopped fitting inside one job description.

Each question contains the one before it, and the reason to keep widening is leverage. Which is the thing the sequence hides: leverage is symmetric. Think of a relay race where the baton is a word. Every runner is fast, every handoff is clean, nobody drops anything — and if the first runner was handed the wrong baton, the team still finishes first, in perfect form, carrying the wrong thing across the line. Do, see, behave: the last three years optimized behavior, and were right to. Not one of those questions decides who is allowed to say what a term means.

Authority over meaning has capabilities too, and they predate this conversation by decades. Data engineering asks: what records do we have, and do they survive the trip? Pipelines, contracts, lineage, types — mature, well tooled, respected, and present nearly everywhere. Content engineering asks a three-part question the others don’t: what did we actually say, what shape does it live in, and how does it move? Model, metadata, schema, taxonomy — the authored structure. A structured component carries what a record carries, plus audience, sequence, variant conditions, the reason a sentence sits where it sits, and unlike a record it never stops moving. Treating content as data alone isn’t wrong. It’s thin.

These two are peers. Neither contains the other. Both already live in most large organizations, and they usually report to people who don’t attend each other’s meetings.

Inside a request, nesting means scope: harness contains context contains prompt, and moving outward widens your view of the same work. The relationship between the request and the estate is a different kind of nesting. The request sits on top of the estate, and the estate sits on the ground. Everything above inherits whatever is settled, or unsettled, below. That is why a very good harness over an unsettled customer does not give a slightly worse answer. It gives a confident, fast, well-formatted wrong answer, every time.

So the missing thing is semantic engineering. Not another practice added to the list, and not a fourth ring drawn further out. It is the ground the other practices stand on, and it asks a plain question: what do the terms mean, and who says so?

Most of the answer is written down. The CRM has a definition of an account. The ERP has an order object with fields somebody fought over for a quarter. The content platform has a content type with a required audience field. A hospital has HL7 and FHIR. The data contracts already say what a customer is — in four places, differently. Decades of settled argument, written into data models, content models and standards. Two things are missing, small to say and hard to do: those definitions are not reachable at the moment the request needs them, and they have never been mapped to each other.

Reconciling them means connecting the models, not merging them. Each is a place a definition lives, and each is expert in something the others cannot hold. Every attempt to collapse them into one master model has produced a very expensive fifth place where the definition lives, slightly differently again. Which is also the answer to “we have this.” A metrics layer holds measures. A catalog holds lineage. A master-data system holds identity. A component content system holds components. A knowledge graph holds whatever someone loaded into it. Each is real, and none of them holds the mappings between the rooms: which sense applies at which seam, and who may change it.

A lot of large organizations already hold most of the practices in that table. What they don’t have is composition. The practices live as silos with their own vocabularies and their own meetings, and a term changes meaning every time it crosses a seam. Agents make this worse before they make it better: every department can now run its own self-improving loop tuned to its own metric, and a silo that optimizes itself faster does not become more coherent with its neighbors. It becomes more confidently different. The correction isn’t a merger. It’s a grammar between disciplines — shared reference structures that let each practice stay expert in its lane while meaning survives the handoffs. Maintained by people, consulted by machines.

Here is what a week of that looks like. Pick customer. Write the four definitions side by side — the CRM’s, billing’s, the help center’s, the warehouse’s — each in the words its own system uses. Name who may change each one. Publish the mapping somewhere a machine can read it, in the schema, not in prose about the schema. Point the harness at it. Then watch the next twenty retrievals. Some will resolve cleanly. Some will hit a seam where two authorities disagree, and the right behavior there is not to pick or to blend but to record the contest and hand it to the owner. Two of the twenty will be surprises: a distinction discovered in a bug fix that deserves to outlive the bug, or a mapping that has to be republished because billing renamed a tier on Tuesday. That is the job.

Not a big-bang ontology program, not a merged master model, and not a platform purchase that counts as the capability. Not a new department either: centers of excellence fail when they are nobody’s job. The ones that work are funded and chartered, centralize the pattern-making, and leave implementation where it already lives. Coherence needs a practice of that shape, crossing the rooms that already exist — a shared reference structure both can point at, and a named owner for each seam where meaning is known to leak. Not an owner of the CRM and an owner of the help center. An owner of customer, wherever it travels.

The change moves at the pace of the estate, not the pace of a request. Start with what you have. Reconcile the settled definitions first. Name the authorities. Tend the seams. Let the harness look things up instead of guessing, and let the retrieval logs tell you which terms are still contested. Mining produces candidates. Governance gives them status.

We’ve spent three years making the request smarter. The estate is where the meaning was the whole time. The ground is where it gets settled. And coherence — meaning surviving its own handoffs — is a capability. Capability is the thing that compounds, and coherence compounds unusually well, because meaning is shared infrastructure: one team’s investment in it lowers the cost of every other team’s data and AI work.

Where CoreModels sits in this picture: on the ground, holding the mappings. Why CoreModels →