The Data Contract: Ambiguity Used to Be Self-Detecting
Ambiguity in a field definition used to detect itself: two people read it differently, disagreed in a meeting, and the argument was the instrument. An…
Most CRMs carry fields whose definitions were never written down, and until agents started writing to them that was survivable. The definition lived in people's heads, it varied between them, and the variance surfaced the way variance between humans always surfaces. Somebody typed a value, somebody else read it, and one of them said that is not what that field means. Nobody designed this. The side effect of a record passing through two people with different jobs was the only quality control most of those fields ever received. The old failure mode was slow, loud, and self-limiting. A wrong value stayed local: one record, one reading, one person's interpretation, corrected socially in a forecast review or a renewal handoff. Mostly nobody looked. The mechanism was weak, intermittent, and dependent on somebody caring on a Tuesday afternoon. It was the only one there was. The new failure mode is fast, silent, and compounding. An agent reading the same undefined field holds no interpretation in tension with anyone else's. It resolves the ambiguity once, at configuration or at the first inferred pattern, and applies that resolution to every record it touches. Nothing objects. Consistency is the property the system was bought for, and consistency is not correctness. It is the absence of the signal that used to stand in for correctness. An agent has three sources for what a field means: the label, the instruction it was given, and the values already in the column. The label produced the ambiguity. The instruction came from whoever configured the automation, so the field means what that team thought it meant. The existing values encode the reading of whichever team writes the most rows. All three select for volume or proximity. None selects for correctness, and none can represent that a second reading exists. The agent does not adopt the sales reading because it is correct. It adopts it because sales wrote most of the rows. Close date sits on every opportunity record in every CRM we have worked in, and it carries two definitions in active use inside the same company. To a sales team it is the date the deal is expected to sign. To a finance team it is the date revenue starts. Those are different dates on most contracts, sometimes by a week and sometimes by a quarter. Both readings are defensible. Neither has been written down. The two readings coexisted because a human sat at every boundary between them. The controller pulling a revenue schedule knew the sales dates ran early and adjusted. The adjustment was never documented, and it never had to be, because it was the same controller each time. This is what an undefined field looks like when it is working: a value that is wrong in a known direction, read by somebody who knows the direction. Put an automation on that field and the adjuster disappears. Give an agent authority to maintain close date from call transcripts and email and it settles the definition once, in favor of the sales reading. A conversation about a deal talks about signing, not revenue recognition. Finance pulls the revenue schedule from the same column a month later, and every deal that straddles a period boundary lands in the wrong period. The schedule does not look wrong. It looks better than usual, because every date in it was produced by the same rule and the familiar scatter is gone. One misdated deal is a correction. The exposure is the rate. Take a book of four thousand accounts. The number is illustrative. The rule writes four thousand values in an afternoon, none of them flagged, because every one followed the rule. Error volume is no longer bounded by attention. Throughput bounds it instead. Consistency is the easier failure to repair. Records written under one reading can be fixed with one query, and records typed by a whole department under as many private readings cannot be fixed at all. The argument holds on one condition: somebody wrote the reading down before the agent started. When nobody did, nothing records which definition the system settled on, and the system cannot be asked. The remedy is smaller than a governance program, and it is written in prose. The first sentence is the definition, stated in business language rather than in schema. Close date is the date on which the customer is expected to countersign, which is not the date revenue recognition begins and not the date the subscription term starts. A definition only a data team can read has already failed. Write it so an account executive in their second week could read it and know which date to type. The second sentence names the owner, one person who may change the definition, not a team and not a committee. The person who owns an automation decides whether it runs. The person who owns a field definition decides what a value means, which is upstream of every automation reading it. The third sentence names every actor permitted to write to the field, and the list is longer than anyone can recite. A form, two integrations, an enrichment vendor, a cleanup script somebody wrote three years ago, and now an agent. The writers people name first are the ones a human touches. The ones that matter run unattended, because their reading of the field has never had occasion to be stated out loud. An actor list that cannot be completed is itself the finding. The fourth sentence is new. It exists because non-human actors now write. It states the condition under which an agent may write to the field at all: what it must observe, what confidence it must clear, and what it does instead when it cannot. An agent that cannot determine whether a countersignature date exists should leave the field empty and escalate. It should not infer a plausible one. This is a confidence threshold pointed at a write instead of at a decision. It makes the definition enforceable. The other three are documentation. Data governance programs are where enthusiasm goes to die: a catalog of every field in every system, maintained by nobody, obsolete before it was finished. This is not that catalog. The scope is the fields an agent writes to and the fields an agent reads in order to decide. The count is knowable in an afternoon by reading the automations already running, and it runs to dozens, not thousands. Each field costs a conversation. The work gets skipped because it does not look like engineering. What it produces is the ability to answer one question later, and the question is which reading produced which value. Answering it requires the system to record who wrote what. The Client Portal we run our own engagements in attributes every write to a named actor, and the audit trail is a table, not a promise. An agent and a human writing to the same field are two actors with two possibly different readings. Without attribution they are one. We write the data contracts before the automations in Strategy engagements, and the sequence matters more than the artifact. A contract is cheap to write before an agent has formed an opinion about the field and expensive afterward, because afterward it is not a definition. It is a reconciliation. Engagements run 8 to 16 weeks and end with the system operating inside the business, which means somebody on the client team has to be able to say what every field the agent touches means, and say it without calling us.