Where this chapter sits
The first three chapters were about control: where AI work is defined, who may let it act, and when the firm pays for a model. This chapter steps back to the reason most of that work exists at all. A large share of what operations teams do every day is carrying information from one place to another and changing its form on the way. That is translation, and it is the cost the rest of the series is trying to remove. The next chapter goes inside a single program, where a developer does the same translation in code.
The problem, as you would put it
Ask an operations team where their week goes and you will rarely hear the word “translation”. You will hear “re-keying”, “chasing”, “checking it matches”, “fixing the spreadsheet”, “sending it back because the number was in the wrong column”. Those are all the same activity. Information leaves one place in one form and has to arrive somewhere else in another, and a person stands in the middle doing the conversion.
Follow one routine piece of work from start to finish. A request arrives by email. Someone reads it and types the useful parts into a spreadsheet. Someone else takes the spreadsheet and copies its values into a portal. A third person downloads what the portal returns and files it. Four systems, three people, six hand-offs, and at every one of them the meaning of the work is carried across by hand.
Each of those hand-offs costs time. Few firms measure it, because it never appears as a line item. It is spread across salaries, overtime, the senior person who is the only one who knows how a particular report is assembled, and the correction that turns up a month later. In a regulated or paper-heavy firm, a large share of administrative cost is probably this work, and nobody has ever added it up.
The second cost is quieter and more expensive. Every translation is a chance to lose meaning. A date is read the wrong way round. An amount in cents is read as dollars because the field kept the same name. A rule that applied last quarter is applied again after it changed. The person doing the conversion is careful, but careful is not the same as checked, and nobody can see afterwards which version of the rule they used.
Why the usual fixes do not remove the cost
Firms usually try one of three things.
The first is more people, or better-trained people. That works until volume rises, someone leaves or the rules change. It also keeps the knowledge in heads rather than anywhere the firm can inspect. When the experienced coordinator is on holiday, the work slows down or the errors go up.
The second is a custom integration. A developer writes code that maps one system’s fields to another’s. This removes the re-keying for a while. The trouble is that the meaning now lives inside compiled code that only the developer can read. When a supplier changes a document or a department revises a rule, the business need is unchanged but the code must be rewritten. The translation has not gone away. It has moved somewhere harder to see and more expensive to change.
The third is to put an AI model on the problem. A model reads each incoming document and produces the output you want. This can look like the end of translation. In practice it repeats the translation on every record, for as long as the work runs. The cost rises with volume, and the same input can produce a different answer on a different day. In a regulated filing, “the model decided” is not an answer an auditor accepts. You need to be able to say which version of the work ran, on which inputs, and who approved it.
All three share a flaw. None of them gives the meaning of the work a home of its own, separate from the people and the code that carry it out.
The idea: give meaning a home outside the code
Our thesis starts its economic argument here, with the translation a firm already pays for: developers turning business meaning into application code, employees carrying information between applications, and businesses exchanging requests and records across their boundaries. “Each repetition consumes effort and creates another place where meaning can be lost.” (C2Consultants, Intelligent Software and Autonomous Organizations.)
The remedy is to keep the meaning in definitions that sit outside the code: what a field means, what units it is in, which rules apply, which substitutions are allowed. People can read those definitions. Software can execute against them. When a definition changes, it changes in one place, the change can be reviewed, and the firm can see when it took effect.
This does not make the work less exact. Arithmetic, transaction rules and permission checks keep exact implementations. Interpretation is reserved for the cases that genuinely need it, such as an ambiguous description on an incoming document, and even then it is bounded and checked. Recurring conversions run through a definition that has been reviewed and adopted, not through fresh guesswork on each record. That is also why the model, where one is used, is called when the definition is written or when a source changes shape, rather than on every record, as chapter 3 set out.
Nor does it remove responsibility. The thesis is direct about this: “Moving a rule outside a compiled method does not remove the responsibility to define it correctly.” (C2Consultants, Intelligent Software and Autonomous Organizations.) What it creates is a place where the rule can be inspected, revised and tied to the conditions under which it is valid. That is what your auditor, your controller and your next hire all need.
The second half of the idea is about who does what. Software carries the routine coordination: moving the information, applying the definitions, noticing what is missing. People keep the authority: approving the consequential step, deciding the exception, owning the outcome. The record of what happened belongs to the firm, not to a conversation window or a model provider.
The same pattern holds at every scale where translation happens. Inside a program, developers translate business rules into code. Between applications, employees carry values from one screen to the next. Between companies, a supplier’s document and a regulator’s form each expect their own fields. The question is the same each time: what does this value mean, and who decided?
What it looks like in a firm like yours
Take a mid-sized firm that submits a recurring government portal filing for each of its sites or clients. Today the work goes like this. Data arrives from two internal systems and a spreadsheet kept by the field team. A coordinator copies each value into the portal, checks it against last period, fixes the mismatches and files. When the portal changes a field, someone notices by getting an error.
With the meaning kept in definitions, the same work looks different. The fields the portal expects are written down once, along with which internal source supplies each one and what units it uses. The rules are written down too: which values must match last period, which records are out of season. A workflow reads the sources, applies the definitions, fills the portal, and stops at an approval step where a named person sees what is about to be submitted. Every run leaves a trace: which version of the workflow ran, on which inputs, who approved it, and what the portal returned.
When the portal changes a field, the change is made to the definition, reviewed and published as a new version. The coordinator’s job moves from typing every value to supervising many filings and handling the exceptions.
On one installation of this kind the automated filing takes 112 seconds (Measured, median of the last 18 runs), against 10 to 20 minutes by hand (the customer’s estimate), at about 100 filings a week. It is one measurement, not a promise. The point is less the minutes than where the remaining time goes: into decisions a person should make, rather than conversions a person should never have had to do.
What to do first, before you buy anything
1. Count one hand-off. Pick a single recurring task that crosses at least two systems. For two weeks, have the people who do it note each time they copy, re-key or reconcile a value, and roughly how long it takes. Most firms are surprised by the total, and more surprised by how often the same value is converted twice.
2. Write the definitions down. For the fields that cross in that task, write a one-page glossary: the name in each system, what it means, its units or format, and the rule that governs it. Where two people give different answers, you have found a place where meaning is already being lost.
3. Name the authority. For each step in the task, write down who may approve it and what they need to see before they do. Separate the steps that are routine coordination from the steps that carry consequence. That list is the boundary between what software can carry and what people must keep.
At the end of those three steps you will have a measured cost, a set of definitions and a map of authority. That is most of the design work for any automation, whoever builds it.
How C2Consultants does this
C2Empowered is the operations platform we build for this work. In Workflow Studio, the co-author drafts a workflow from a plain description of the task; the field mappings and rules are kept as definitions you can read and version, rather than buried in code; Fleet Agents run the work across your existing applications, from email and spreadsheets to web portals, SQL Server and Windows desktop applications; and the steps that send, write to a system of record or act in an application stop at approval gates set by risk level for a named approver, with a trace of each run kept as the firm’s own record. The model is used when the work is designed and again when a source changes shape, not on every record. One honest limit: driving an application through its own screens works for Windows applications only, not mainframe screens or Citrix sessions, and a definition is only as good as the agreement your people reach on what each field means. The way to start is a pilot: discovery of the hand-offs that cost you most ($2,000), installation ($1,750), and building and testing your first workflows ($175 per hour), run side by side with how you work today before you decide anything more.
Next chapter: Typed, checked AI calls for .NET. How a developer keeps the same translation out of application code and still trusts what a model returns.