The Record

Every company that runs on software already keeps a detailed record of how it actually operates. Orders arrive and get written down. Items move between locations and each move leaves a row. A routing engine picks a path and stores the decision. A sensor reports a reading every few seconds. A person catches a mistake and enters a correction. None of this is kept for the sake of a future AI project. It accumulates because the software needs it to run. But taken together it is the most accurate description of the business that exists anywhere.

It is more accurate than the process documents. A process document describes the intended business: the way work is supposed to flow, the rules people are supposed to follow, the exceptions someone thought to write down. The record describes the real business: the way work actually flowed last Tuesday, the rule that gets broken twice a week because following it would stall a shipment, the exception nobody documented because it only shows up in the data. When the two disagree, and they always disagree somewhere, the record is right. It has no incentive to flatter anyone and no reason to simplify.

This matters because the common story about AI integration puts the hard part in the wrong place. The story says the work is collecting data and choosing a model. In practice a company that has been running for years is not short of data. It is drowning in it. The data sits in an order system, a warehouse system, a scheduling tool, a spreadsheet a manager maintains by hand, and three databases that were meant to be retired but never were. The model is also rarely the constraint. Capable models are available and largely interchangeable for most business decisions.

The hard part is connection and reading. The order system calls a thing a "customer." The billing system calls a related but not identical thing an "account." The warehouse system tracks a "ship-to," which is sometimes the customer, sometimes the account, and sometimes neither. A person who has worked there for a decade knows how these line up and reconciles them without thinking. The software does not know, because nothing ever wrote the correspondence down. Before any model can reason across these systems, something has to establish that these three words point at the same underlying thing, or explain exactly how they differ.

The same problem repeats at every level. A status field in one system has eight possible values; the equivalent field in another has five, and the mapping between them is not one to one. A timestamp is stored in local time in one place and in a shared standard time in another, and no column says which. A product code was reformatted during a migration four years ago, so records before and after that date look like they describe different products when they do not. None of these are exotic. They are the ordinary residue of software built by different teams at different times to solve different problems. Each one is a small wall between a system and the meaning of what it stores.

This is why the gap is connection and reading, not collection. Collection is mostly finished before the project starts. The record already exists and already describes the business in fine detail. What is missing is a reliable way to move across the pieces of it and be sure that a term means the same thing on both sides of every join. That work is unglamorous. It is closer to reconciliation than to modeling, and it rewards patience and knowledge of the specific business more than it rewards any general technique.

The payoff is that once the terms are aligned, the record can be read as the single description it always implicitly was. Questions that used to require a person who held the whole map in their head become answerable directly. The business that the software has been quietly recording all along becomes legible. Nothing new had to be collected. What was already there had to be connected, and the words had to be made to mean the same thing everywhere.