The Core Model

Every enterprise already has a model of its business. It has several, in fact: the warehouse has one, the CRM has one, the content platform has one, the API contracts have one, the industry standard the compliance team follows has one. Each was settled by people who had good reasons, and each is expert in something the others cannot hold. The warehouse cannot hold what the content model knows about audience and sequence. The taxonomy cannot hold what the transformation code knows about lineage. The translation memory knows a term in twelve languages and nothing about which system is allowed to change it.

A core model does not replace any of them. It holds each model as it is and keeps the mappings between them alive — which sense of a term applies at which seam, which system the business considers true for a given entity, and who is allowed to change each. It is not a fifth place where the definition lives, slightly differently again. It is the place where the correspondences are written down once and read every time.

In CoreModels, one core model is a project: one governed model and everything in it — types, elements, taxonomies, mappings, versions, and the connectors that feed it. Most teams run one per domain or per source system, and map between them.

It is not a warehouse, a catalog, a metrics layer, a master-data system or a vector index. A catalog knows its tables. A metrics layer holds measures. 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 each stays in place. A core model sits below the catalog and across the systems, and it is written where a machine can read it — in the schema, not in prose about the schema.

CoreModels grew out of the Core Content Model®, a methodology developed by Cruce Saunders and the [A] senior content engineering team. It was developed initially to serve the needs of the Mayo Clinic, and expanded over many implementations with some of the largest enterprise publishers in the world.

The problem it was built for predates language models by a long way. A large enterprise already holds its knowledge in many representations at once — a content model here, a data model there, a schema for each system, a format for each channel, a standard the industry expects it to conform to — and each was settled by different people for good reasons. The work at the Mayo Clinic was not, for the most part, designing a new content model. It was organizing what they already had, across all of those representations, into a core model: an abstraction layer that holds the existing models and the mappings between them. That is the whole point. Not a new model to maintain beside the others, but the layer that contains them — so a component means the same thing on the website, in the app, in the document a regulator receives, and in every format and standard it has to travel through.

The methodology maps more than channels and systems. It maps formats, representational states and standards — the same entity as a FHIR resource, a warehouse table, a JSON Schema, a schema.org type and a taxonomy term, held together by typed correspondences rather than by anyone’s memory. Language models multiplied the handoffs and sped them up. The discipline that held meaning steady across channels now has to hold it across models, agents, warehouses, and everything they touch. CoreModels is that discipline turned into a platform: the methodology as a hosted modeling workspace where models are authored, governed, versioned and exported, and — since the arrival of agents — served at runtime to the systems that need to look a term up before they act.

Here is a failure that did not look like one. An account manager asks an assistant for a renewal summary. The assistant reads the CRM, where the account’s customer record carries a segment: mid-market. It reads billing, where customer is a contract tier: enterprise, because of a legacy bundle. It reads the help center, where customer is an audience tag on the articles that account gets shown. It writes “Enterprise customer, mid-market segment, renewing in Q4” — fluent, blended, and nobody in the room can tell which sense of the word carried the pricing. The renewal email goes out with enterprise language. The summary is stored. Next week another agent builds the quarterly deck from that memory, and “enterprise” is now a fact about the account that no system ever asserted.

Notice what the failure was not. It was not that billing and the CRM disagree; those are real meanings, each settled by people with good reasons, and neither is wrong. The failure is that at the moment of the request nothing could say which sense was in force for this handoff, so the assistant blended them, and three hops later the blend looked like knowledge.

Agents run on leverage, and leverage is symmetric. A good harness propagates a wrong term exactly as faithfully as a right one, and faster the better it gets — into tool calls, into memory, into the next agent’s input, into the summary written back as fact. The industry has not ignored this. Grounding, citations, evaluation suites and data contracts all help, and all of them stand on the same floor: a definition pasted into a system prompt does not survive the next agent or last week’s memory write; retrieval by similarity finds language that sounds like the term and cannot record that it guessed; evaluations grade the answer, not the binding the answer was made from.

The same answer serves the harder seam. No estate is alone: a supplier’s system hands you a purchase order whose unit is a case where yours is a pallet; a partner’s agent reads your catalog with its own sense of available. Two agents that share a protocol but not meaning — what we call the Stranger Problem — need something to check against before they act. Coherence between estates is built on coherence within them, and a core model is the within.

Dropping a person into a loop to approve what a machine already did sets them up to rubber-stamp, or to fail. The workable division is older and simpler: humans set direction, encode meaning and own the judgment and the exceptions; machines do the volume and the assembly. In a core model, people settle the calls that carry consequence once, in the model, and are nowhere near the request path afterwards. Every agent reads what they settled. The people who structure knowledge — the content practitioners, the data modelers, the taxonomists and ontologists — are not being written out of the story by agents. They are becoming its authors again.

Read on for why coherence is a capability, or go straight to why CoreModels rather than the stack you already run.