Artifacts for Capturing Per-Customer Learning

Imagine a mid-sized logistics company that hires an AI-native startup to automate parts of its operations. Before a single model is trained, the startup's engineers sit in on meetings across the business and notice something awkward. The sales team calls the people who buy from them customers. The operations team calls the same people clients. Finance refers to them as billing entities, and the platform engineers store them as org IDs. Four departments, four words, one underlying group of people.

Stop and ask yourself a question before reading on. Whoever eventually settles which word the software uses, what does that settlement do to the customer over time? Your first instinct may be that it is only a naming decision, a small cleanup task for the engineers. This article argues that the answer is more serious. A small piece of unglamorous vocabulary work can turn into a strategic asset for the vendor and a constraint for the customer.

The definition has a second half that matters just as much. The vendor who settles disagreements over those terms shapes the customer's vocabulary. An ontology is not only a description of a business. It is also the point where someone must decide which word wins when two teams disagree.

Trace what happens to the logistics company's vocabulary as the startup works with it. The key move in the source is that the trace ends with a shift in who holds the definitions. Before resolution, the customer owns its own language, even if that language is messy. Four departments each have a word, and the company decides nothing as a whole. The meaning of the word customer lives inside each team.

After resolution, the customer's teams begin to reason in the vendor's terms, because the software, the reports, and the training materials all use them. Nobody has to be forced to adopt the vocabulary. It simply becomes the language the tools speak, and people learn to think in it. This is why the settlement of a word can matter more than the feature that word describes.

The source describes two routes that tie together. The first route runs through language. The vendor resolves the disputes over terms, the customer adopts those terms, and lock-in follows. Once the customer's teams speak the vendor's vocabulary, switching providers becomes a translation problem as well as a technical one. Moving to a competitor now means translating every report, every training manual, and every workflow out of one vocabulary and into another.

The source also gives a concrete illustration from the wider industry. Terms such as skills and MCP moved from being one vendor's vocabulary to becoming part of the industry's shared vocabulary. When a term crosses that boundary, the vendor who coined it has shaped how the whole field talks. The source describes this as a far stronger position than having a popular feature, because a feature can be copied while a shared vocabulary shapes how everyone describes the problem.

The second route runs through an artifact that extends the shared model. The second half of the source moves from the mechanism to the business consequence. Each engagement generates learning about the specific customer: how its approvals work, which exceptions recur, and which steps people actually take. The question is where that learning goes.

The answer to where the learning goes determines the outcome. If it stays in the consultant's head or in a folder of slides, every deployment starts close to zero. If it is captured in a durable form, the next deployment begins with a head start. The artifact is the component that carries learning from one deployment to the next, and the pipeline above traces that path.

Read the diagram as a loop rather than a line. The artifact carries learning forward, and each pass through the loop leaves it richer. The next customer's deployment becomes easier to run, and the existing customer's setup becomes harder to replace with a competitor's setup. The same mechanism that makes the next deployment cheaper also makes the current one harder to displace.

The source explains that the specific artifact depends on the domain. Examples it names include a skill library, an eval framework, a workflow registry, or a data model. The artifact changes from domain to domain, but the category stays the same: it is a durable structure that holds what the vendor has learned about a customer's way of working.

Notice that the worked example uses a data model because the logistics case involves org IDs and billing entities. In a different domain, the same reasoning might point to a workflow registry or an eval framework. The source does not claim one universal artifact. It claims that the category, a durable shared record of the customer's vocabulary and learning, is what matters.