Before AI Can Reason About Your Business, It Needs a Model of It

The first thing digital electronics taught me is that a computer never sees a signal. It sees samples. A voltage moves continuously, and a digital system checks it at intervals and writes down a number each time. Check often enough and the numbers trace the signal faithfully. Check too rarely and you do not just lose detail. Something stranger happens.

You have seen it in old Westerns. A stagecoach picks up speed, and its wheels appear to slow down, stop, and turn backwards. The wheel never reversed. The camera took twenty-four pictures a second, and between two pictures each spoke traveled almost all the way to where the next spoke had been. Your eye matches each spoke to the nearest one in the next frame, which sits slightly behind, so the wheel seems to creep the wrong way. Engineers call this aliasing. Sample too slowly and you do not get a blurry version of the truth. You get a sharp picture of something that is not happening.

Companies sample themselves too, and mostly they sample slowly. Revenue gets read monthly, churn quarterly, strategy once a year at an offsite. Some of those numbers are snapshots, and snapshots alias. Count active customers on the last day of each month. If a promotion lands in the final week of every month, that count might read 12,412 while a typical mid-month day sits closer to 11,000. Every month-end chart will describe a healthier business than the one you run for the other three weeks. It will be clear, steady, and wrong.

That is the first lesson, and it is a humbling one: we never work with the business itself, only with a representation of it, and a representation can be wrong in ways that look exactly like being right. The second lesson came from physics, and it was about what you do with the samples once you have them.

A record of the sky is not an explanation of it

For about twenty years, Tycho Brahe wrote down where the planets were. He built an observatory on an island, made his own instruments, and logged positions to within about two arcminutes, better than anyone had managed without a telescope. When he died in 1601, he left behind the best record of the sky in the world.

It did not explain anything. The record said where Mars had been, not why it went there or where it would be next year. Johannes Kepler, Tycho's assistant, spent years fitting circles to that data, and the best circle he could find still missed by eight arcminutes, about a quarter of the width of the full moon. That was four times Tycho's margin of error, too large to be noise. Astronomers had trusted circles for two thousand years. Kepler trusted the measurements instead, and the orbit turned out to be an ellipse. Newton later found the reason: one force behind the ellipses, the tides, and the comets.

Most companies are sitting on Tycho's notebooks. The warehouse knows every order, every click, every cancelled subscription, recorded more precisely than any company could have managed a generation ago. It is a superb record of where the planets were. Dashboards get a company as far as Kepler: the shape of what happened. What almost nobody holds is the model: what drives what, which relationships are definitions and which are guesses, and what should happen if we change something. We are now handing those notebooks to AI and asking it to be Newton.

What physics really contributed was a habit: find the few variables that matter for the question, and the relationships between them. To predict where a thrown ball lands, you do not need every atom in it. You need how fast it left the hand, at what angle, and how hard gravity pulls: three quantities and one relationship. You do not even need its mass. Companies do the same thing when they reason well. Revenue is down 10 percent. Revenue is customers times revenue per customer, so either we lost customers or they spent less. New customers are traffic times conversion, so either fewer people came or fewer of them bought. Keep going, and "revenue is down" becomes "mobile conversion among first-time customers from paid search fell after the checkout release." The company did not get any simpler on the way down. The representation of the problem got better. (We walked through a fuller version of this breakdown in our guide to the Decision Context Graph.)

How far down to go depends on the question. "Are we healthy?" needs the top of that chain. "Why did Android checkout conversion fall last Tuesday?" needs the bottom. Same company, different resolution, and a useful model has to serve both without pretending to be the whole company at either level.

Where a company stops looking like physics

Newton's laws hold on Tuesday and on Friday. A company's relationships are messier, and the mess has a structure worth naming. They come in kinds, and each kind gets checked a different way.

Each row fails differently. A definition can be checked with arithmetic, which makes it the easiest kind to keep honest and the most embarrassing to get wrong. Suppose New Revenue plus Returning Revenue comes to $11.8M against a total of $12.4M. The $600K gap is a kind of revenue nobody drew on the tree, in this case expansion revenue from upsells. Definitions also break in quieter ways. We once caught a Trial-to-Paid Conversion Rate in our own system being computed as a raw count. It ran, it rendered, and it was not a rate.

A statistical relationship fails more quietly still. Customers who log in less do churn more, but maybe unhappy customers simply log in less, and no amount of nudging them to log in will keep them. A hypothesis cannot fail at all until someone writes it down before the result arrives, which is the argument of our KPI tree essay.

This is the part that matters most once AI is involved. Nothing in the data tells an AI which kind a relationship is. "Onboarding drives retention" and "revenue equals price times quantity" look exactly alike in a slide, a wiki, or a prompt. One of those is arithmetic. The other is a bet the company made at an offsite. Giving a model access to all your data does not tell it which is which. The data has no column for it.

That is why we split the work the way we do. In our own system, a deterministic engine runs every query against the warehouse, and no language model writes SQL. The meaning of a definition belongs to the person who owns it, not to the machine that found it. The machine should check what arithmetic can check. People should rule on what only people know.

What a model is for

Sampling taught me that a measurement can mislead. Physics taught me what a model is. Control theory came later, put the two together, and asked the question that made them useful: what do you do with a model and a measurement?

The simplest answer is the difference between a toaster and a thermostat. A toaster runs on a timer. It never checks the bread, and if the timer is wrong, you get charcoal. A thermostat has a target, measures the room, compares the two, acts, and measures again. Engineers call the first open loop and the second closed loop. Almost every system we trust with something important is closed loop.

Most companies make strategic decisions open loop. The plan gets set at the offsite, the work runs for a quarter, and someone checks the toast at the quarterly review. Control theory has three more ideas that describe what goes wrong in between, and they translate almost word for word.

Observability. Can you tell what is happening inside a system from what you are able to measure? Revenue flat at $8.4M a month is consistent with a stable business. It is also consistent with $500K of new revenue arriving every month while $500K of existing revenue walks out the door. Those are two very different companies, and revenue alone cannot tell them apart. A company that watches only its top-line numbers comes close to what an engineer would call unobservable.

Delay. Feedback that arrives late makes you overreact. Everyone has done this in a hotel shower. The water is cold, so you turn it hotter. Nothing happens, so you turn it further. Ten seconds later you are scalded. Companies do the same thing with budgets: acquisition cost spikes, marketing gets cut, the pipeline dries up a quarter later, and money floods back in. The swings belong to the loop, not to the people in it. Nobody fixes a hotel shower by turning the tap faster. You learn that it takes ten seconds, make a small turn, and wait. That is a model of the delay, and control engineers have a name for building one into the controller: dead-time compensation. A company that knows a marketing cut takes a quarter to reach the pipeline can make a small cut and wait for the quarter.

Model plus measurement. In the early 1960s, engineers at NASA's Ames Research Center turned a new method from the electrical engineer Rudolf Kalman into a way to navigate Apollo to the moon (NASA's own account). The Kalman filter trusts neither its model nor its sensors on their own. It predicts where the spacecraft should be, takes a noisy measurement, and blends the two, weighting each by how much it can be trusted right now. The model keeps the measurements honest, and the measurements keep the model honest. Kepler made the same call by hand, when he trusted Tycho's eight arcminutes over two thousand years of circles.

A company is not a spacecraft, and it is worth being plain about where the comparison strains. Customers and competitors react to what you do. Numbers arrive weeks late. A decision can take two quarters to show up in anything you measure. So the lesson is not that a company can be steered precisely. It is close to the opposite: steering on late numbers, with a model nobody wrote down, is how capable teams end up correcting in every direction at once. What control theory offers is the loop itself. Write down what you expect, measure what happened, and let the difference correct the model.

A company is many loops

A thermostat runs one loop. A company runs hundreds, roughly one for every number somebody owns. Each has the same parts: a target, a reading, some levers, an owner who pulls them, and a delay before the reading moves. And the loops are not separate. They are nested, and they are tangled.

Nested first. Revenue is an outer loop. It rarely pulls a lever itself. It sets targets for the loops inside it: so many new customers for the growth team, so much churn for customer success. Engineers call this cascade control, and it comes with one firm rule: the inner loop has to settle faster than the outer loop changes its target. Break the rule and the system thrashes. A monthly revenue review that resets the onboarding team's target every month, for a change that takes two quarters to show up in retention, never lets that loop finish a single cycle.

Then tangled. The loops act on the same customers, so one loop's lever is another loop's disturbance. Growth hits its new-customer target with discounts. The discounted customers churn faster. Customer success sees churn rise and fights it with save offers and outreach. Each team can show that its own loop is working. Every dashboard is green except revenue's, because the problem lives between the loops, where nobody owns it. Control engineers learned long ago that you cannot tune coupled loops one at a time and expect them to behave. You need a model of how they push on each other.

In effect, a KPI tree is a drawing of the company's loops. Every node is a reading, every owner is a controller, every initiative is a lever being pulled. What the drawing leaves out is what control theory says matters most: how long each loop takes to respond, and which other loops each one disturbs.

Where decision intelligence comes in

Picture a very smart person locked in a room. Once a month, someone slides three pieces of paper under the door: revenue $8.4M, churn 3.8%, customers 12,412. Then they ask what the company should do.

Their intelligence is not the problem. That customer count is the month-end snapshot from the start of this essay, so one of the three numbers is already aliased. They are reading a misleading sample of an unobservable system, through a long delay, open loop. Sliding the whole warehouse under the door instead does not fix it. That is Tycho's notebooks again, only heavier.

So we tried it. We gave Claude Sonnet 4.6 exactly what the person in the room gets: revenue of $8.4M, down 10 percent, churn of 3.8%, 12,412 customers, and the question of what to do. We expected it to guess. It did not. Three times out of three, its first sentence was some version of "I can't actually tell you what's driving the decline from these numbers alone." Then it asked for what was missing: "Did you lose customers, or did existing customers downgrade?" "Any pricing changes or discount activity?" "Is 3.8% normal for you, or a spike?" Those questions are a model of the business, requested one row at a time.

Then we slid a model under the door too: seven lines about how this made-up company works, each labelled as a definition, a correlation, a bet, a dated fact, a constraint, or an owner. The answers changed completely. All three runs split revenue into customers and revenue per customer, put the September pricing change first, treated the new onboarding flow as a bet to test, and left the locked enterprise contracts alone. Two of three raised a risk nobody had asked about: most of that enterprise revenue renews in the first quarter. One run explained its ordering in a sentence: "You have a hypothesis about onboarding and a correlation about login frequency, and it's tempting to connect them into a story. But the pricing change is the only known event with a known date in the right window."

With owners on the page, the answers also started reasoning across loops. "The ownership structure means you need both teams in the room," one run said.

Then we took the labels off and stated the same seven beliefs the way a slide or a wiki usually states them. The model was more careful than we expected, but not entirely. One unlabelled run saw the coupling plainly: "growth owns new customers, CS owns churn, but the pricing change was likely a leadership/product decision that affected both." One decision, two loops, spotted without being asked. The same run was also the one of three that slipped. From "if login frequency predicts churn," it went straight to in-app prompts for low-engagement customers, with no test of whether logging in is what keeps them.

Same model, same numbers. What changed the answer was the model of the business. (One model, Claude Sonnet 4.6, with no system prompt; one made-up company; one question; three runs of each version, in October 2026. We added the unlabelled version after seeing the first two results. Quotes are word for word, with formatting marks removed.)

The AI in the room was already smart enough to know what it was missing. What it lacked were the three things a controller needs:

1. A model. The variables that matter, the relationships between them, what kind each relationship is, and who owns each one.
2. Measurements at the right resolution for the question being asked.
3. The loops. Decisions recorded with what they were expected to do, outcomes that come back to correct the model, and a map of which other loops each decision touches.

That is how we think about the Living Map: the shared model a company's loops run on. Not a dashboard, and not a static KPI tree. The base exists today. It is a persistent, versioned tree whose nodes are bound to the warehouse measures that compute them, each carrying its formula, its owner, and the history of who changed it and why (more on how that works). Underneath it sits the Decision Context Graph, the graph of tables, metrics, and owners that our Cartographer builds by scanning the warehouse. The graph is the part a machine can reason over. The Living Map is the part a person can argue with. What neither holds yet is the part this essay keeps arriving at: how fast each loop responds, and which loops push on which.

Here is where it has to go, and to be clear, this is the destination, not the demo. Today an AI can tell you that conversion fell 8 percent. Inside a closed loop, it should be able to say more. Conversion fell mostly among first-time mobile customers after the checkout change. That segment brings in about 40 percent of new-customer revenue, and the drop there accounts for most of this month's miss. Here is the evidence, how confident we are in each link, and which links are hypotheses rather than definitions. And eventually: if you change this, here is what we expect to move, which other teams' numbers it will push on, and the number that will tell us we were wrong.

The map is not the company

None of this makes the model the company. Newton's equations are not the sky, and a Living Map will never be the business. It will be incomplete, and parts of it will be wrong. The statistician George Box put it in one line: all models are wrong, but some are useful. The useful ones are built to be corrected.

Go back to the stagecoach. On the screen its wheels turn backwards, sharply and convincingly. But if you know the coach is moving forward at speed, you know that cannot be true. The samples alone fooled you. The samples plus a model of how the wheel should be turning would not have.

For decades, companies have gotten very good at recording what happens to them. Every order, click, and support ticket leaves a trace. The next layer of enterprise AI is probably not another place to store what happened. It is decision intelligence, the control system the company never wrote down: a model of its loops that says which links are definitions and which are bets, and that reality can correct when it is wrong.

We digitized the observations before we digitized the model.