Calogero Bonasia

Four Ways of Saying “Customer” (3/5): Content, Context and Who Answers for Meaning

Part 3 of 5. Part 2 discussed similarity search and Eco's dictionary.

If meaning must be written down, the first practical question concerns the texts one starts from. Helyx Horwitz, in an infographic from August 2026, locates the hidden risk of investing in artificial intelligence in content more than in technology. Her argument starts from a difference in how people and machines work. People infer context from a network of knowledge that keeps growing; artificial systems require explicit structure and declared relations.

Anyone who reads the customer disputed the March invoice knows what an invoice is, knows that a dispute opens a case and, if they have worked there for some years, also knows which customer is meant. Eco observed that every text leaves much work to the reader and counts on the reader doing it (Eco 1979). Company documents push this economy to the extreme, because they presuppose years of corridor talk. For a machine, what is not written simply is not there. Horwitz draws from this a rule of method I share: content readiness is assessed before signing the contract for the tool.

Emily Crockett and Holly Maykow, in a document from October 2026, start from a commonplace, the one according to which results are only as good as the input data. They note that technical teams usually stop at the question of whether the data are accurate and neglect the next, more important one: whether the system receives enough context to constrain the interpretation of those data. When context is missing, the system produces an answer anyway, and the work has to be redone.

Answering requires a broader category than data and content. Enterprise Knowledge calls it a knowledge asset and defines it with an operational criterion taken from the firm's earlier texts: a knowledge asset is any object that can be tagged and linked to others. The definition covers the minutes of a technical committee, a supplier's data sheet, the test procedure kept in a spreadsheet on someone's desktop. It even covers the person who knows how to configure a certain machine, because a person too can be tagged by skill and linked to a project. It is the archivist's criterion in front of a newly acquired fonds. The importance of an item is settled later; first, it must be describable and placeable in a series.

Once the assets are identified, the decisive step for Crockett and Maykow is to structure them. Assets without structure remain isolated, like the volumes of a library without a catalogue, all preserved and consulted by no one. The current records of Italian public administrations have long known the remedy and call it the titolario: the classification scheme through which every file receives its place.

The tool the authors propose is a business metadata model, that is, an ordered set of attributes that describe assets in the words the company uses for itself. Italian regulations on electronic documents define metadata as data associated with a document to identify it and describe its context, content and structure (AgID, Annex 5). In a manufacturing company every document might carry seven attributes: product family, market, applicable standard, lifecycle phase, owner, start and end of validity. None requires IT skills, and an experienced colleague could recite them all in a few seconds. Written down, they become readable by a machine too.

Crockett and Maykow's document carries in its title the phrase context engineering. I will try to pin down its meaning by comparison with a better-known phrase. Prompt engineering works on how a request is worded. It is a real skill, which acts on a single exchange and depends on whoever writes. Context engineering works on what surrounds the model when the request arrives: definitions, relations, provenance. The difference resembles that between teaching a new hire to ask sharper questions and handing them the org chart, the glossary and an orderly archive. The first intervention improves one case; the second improves many, including some no one had foreseen. An organizational consequence follows as well: individual skill leaves the company with the person, while written context stays.

Back to the customer. The contract sits in the document repository, the order in the ERP, the ticket in the support system, the discussion that led to the decision in a messaging channel, the technical drawing in the product lifecycle management system. These are five enclosures, and in each the word has its own sense. A person crosses them from memory; an agent, at the edge of the enclosure, returns an error or an invented value.

Software engineering has had a name for this problem for some time. In 2003 Eric Evans published Domain-Driven Design and called bounded context the scope within which a word has a single meaning (Evans 2003). Within each context, developers and domain experts use the same vocabulary. Correspondences between one context and another are written down one by one. The four senses of customer from the beginning belong to four contexts that no one has ever drawn. William Kent had seen the problem as early as 1978. In Data and Reality he asked when two records describe the same thing, and concluded that the answer depends largely on the purpose of whoever does the recording (Kent 1978). Evans teaches how to draw boundaries. Kent reminds us that every boundary is a decision, and that someone makes it.

Crockett and Maykow conclude that connecting and harmonizing assets through semantic models breaks down the barriers between systems. The semantic model leaves the data where they are and builds passages between the enclosures. It states, for example, that the customer in the contract repository and the one in support coincide in one case and diverge in another. The work is notarial in nature: someone must put in writing what is equivalent to what, and answer for what they have written.

Enterprise Knowledge's texts say little about who that should be. Italian regulation offers a precedent. The guidelines of AgID, the Italian digital agency, on electronic documents provide for two named roles: the records management officer and the preservation officer (AgID 2021). The first is mandatory in public administrations. The second also concerns companies that keep documents in digital form, starting with electronic invoices. Both ensure that documents written by others are classified and retrievable, and both answer for the classification scheme. The meaning of words needs a similar figure. It sits between domain experts, who know the distinctions, and technical staff, who translate them for the machine. The role often goes by the name data steward. Whatever its name, it must appear on the org chart, with written duties and allotted hours.

Work of this kind must also be paid for, and this is where trust comes in. In a conversation with Lulit Tesfaye, Wael Taha, Vice President of Enterprise Architecture at Brown Brothers Harriman, retraces his path from business analysis to managing data as an enterprise asset. He explains how to build trust in the bank's data and how to turn the semantic layer into value. The theme concerns anyone who has to pitch a project of this kind internally. An exact number that no one trusts is as useful as a wrong one. For this reason accuracy must be made visible: whoever uses a number must know where it comes from and who answers for it.

I draw a conclusion of my own. The semantic layer is justified even without artificial intelligence, because it serves regulatory reporting, security, data governance and the quality of reports. Artificial intelligence makes it urgent. Whoever bases a budget request on artificial intelligence alone ties years of work to a hype cycle that may run out first. Whoever bases it on compliance and trust, and presents artificial intelligence as an added benefit, builds on firmer ground.

Next: part 4, RDF or LPG.

Sources for this part

#artificial intelligence #english #organizational intelligence #semantic layer