Operations
For Both Executive and Technical ReadersAn executive asks a question in plain English. An answer comes back with its reasoning attached. This is what happens in between, and why every step leaves a record.
01 From Question to Answer
An executive asks a question in plain English. Some time later, an answer comes back with reasoning attached. This column is what happens in between.
It matters more than it sounds. The steps are what separate a system whose answers can be checked from one that simply produces confident text. Every step leaves a record, and the record is what makes the answer defensible months later when someone asks how you arrived at it.
02 The Eight Steps
The pipeline runs in a fixed order. Each step hands a checked result to the next. The first page covers two steps, which is why the count runs to eight across seven pages.
Parse & Formalize, turn the plain-English question into a precise one. Most of the ambiguity in business questions gets resolved here, in the open, rather than silently later.
Route, work out which kind of question this is and which model can answer it.
Identify, check whether the question can be answered at all from what is known. Sometimes the answer is no, and it is far better to learn that here than after the analysis.
Compose, assemble the pieces needed for this particular question.
Execute, run the calculation. This part is arithmetic, not judgment, and it gives the same answer every time.
Audit, check the result and record how it was reached.
Narrate, put the answer back into plain English for the person who asked.
03 The One Rule
One design decision shapes the whole system, and it is worth understanding even if you read nothing else here.
The language model touches only the two ends. It helps turn your question into a precise one at the start, and it puts the answer back into readable English at the finish. Everything in between runs on fixed rules and arithmetic.
The reason is straightforward. Language models are good at language and unreliable at arithmetic and consistency. So they are used where they are strong and kept away from the part where a wrong answer would be both invisible and consequential. Ask the same question twice and the middle gives the same result both times.
Pipeline sets this out in full.
04 The Architecture Underneath
Below the pipeline sits a set of twelve capabilities that the steps draw on, how the model gets built, how it takes in hedged real-world information, what you can ask it to do, and how you know whether to trust the result.
Three of them come up in nearly every serious conversation. Discovery covers where the model comes from, since it is built from expert knowledge rather than learned from data alone. Robustness asks how fragile an answer is if an expert estimate was wrong. Validation separates “the math is correct” from “this matches reality,” and reports both.
The full set, grouped by purpose, is in the Architecture overview.
05 What You Get at the End
An answer, in plain English, with the reasoning attached: which factors drove it, what was assumed, how confident the system is, and what would change the conclusion.
That last part is the one executives use most. Knowing what would change the answer tells you where to spend the next hour of attention, and it is the difference between a number you accept and a number you can act on.
The steps are what separate a system whose answers can be checked from one that simply produces confident text.