The page an AI supplier is not supposed to write, and the one a sceptical operator usually finds most useful.
A language model is a high-variance component with remarkable range. Put it where range is worth more than certainty and it earns its place. Put it where the answer must be exactly right every time and you have built something that works impressively until the day it does not, in a place where nobody was checking.
The interesting thing about a frontier model is not that it is sometimes wrong. Every component is sometimes wrong. It is that its errors are fluent, plausible, and distributed unpredictably across inputs that look identical to the person reading them. A rules engine that fails, fails the same way twice. A model that fails produces a confident sentence, and confident sentences are the hardest kind of error to catch downstream.
So the design question is never "can a model do this". It is "what happens the one time in two hundred that it does this differently, and who would notice". Where the honest answer is nobody, that work does not belong to inference, however good the demonstration looked.
The goal is not more AI activity. It is greater organizational velocity.The measure that decides what gets built
This is the test we actually apply, in the order we apply it. It is not sophisticated, which is the point: it can be run in a room with the people who own the process, in an hour, without anybody having to learn what an evaluation harness is.
| What the work involves | What should run it | What we build |
|---|---|---|
| Language, ambiguity, synthesis. Many acceptable answers | ✓A model | Drafting, summarizing, classifying a request, answering from cited documents |
| It must be exactly right every time. One acceptable answer | ✕Deterministic software | Rules, calculations, validation, state transitions, records |
| Both, in one process | △A deterministic core with a model at the edges | The model prepares and explains; the core computes and enforces; a person accepts |
| A figure somebody will act on or publish | ✕Computed, never generated | Deterministic tools that compute and reconcile, carrying how the answer was reached |
| A decision about a person, or a regulated obligation | ✕A named human decides | The system may prepare the material. It does not make the call |
| Nobody downstream would notice a wrong answer | ✕Nothing, yet | Fix the missing check before automating the step. Automation makes an unnoticed error faster |
Row six is the one that saves the most money and is the least popular. A process with no downstream check is not a candidate for automation of any kind; it is a control gap wearing a productivity costume.
This is easy to say and awkward to demonstrate, because the evidence is a list of things a supplier could have sold and did not. Three examples from the platform we actually ship.
Secure file intake, a forecasting tool over an organization's own records, scheduling with public listings, a roster and KPI tool with encrypted columns and an audited reveal path. What organizations use day to day is governed business software running inside an environment they own. AI is one capability among several, and often not the one doing the work.
In the module path, the component that runs without a person watching is the validator, and it is ordinary software: it refuses an undeclared host, a route without verification, a scope beyond what was admitted, a changed artifact hash. It approves nothing. Every judgment call in that path is made by a named administrator.
Retrieval finds the passage. It does not total the column. Figures come from deterministic tools that compute and reconcile, and every answer carries how it was computed and how to reproduce it. A model that is good at prose is not thereby good at addition, and treating those as the same capability is how defensible numbers stop being defensible.
A supplier whose revenue depends on inference has a reason to find inference-shaped problems everywhere. Ours does not: the deployment, the managed service and the per-deliverable engineering are priced the same whether a capability calls a model or not, and your compute bill goes to you either way. Inference is not always the answer, and nothing in our commercial model pushes against saying so.
A model that helps write deterministic software is not sitting in the critical path when that software runs. The output is code, and code is reviewed, tested and versioned by machinery that has existed for decades. A model that answers a question live is in the path every time somebody asks.
An assessment that can only conclude "deploy the platform" is not an assessment. Ours regularly recommends that a process be fixed before it is automated, that a step stay manual because the check that would catch a bad answer does not exist yet, or that the first capability be ordinary software with no model in it. That is not modesty. It is what makes the recommendations that do involve inference worth something.
Prioritization runs on outcomes you define, not on a universal "hours saved" figure. One executive is optimizing delivery time, another errors, another risk, another the frustration of a team that keeps redoing work. A supplier who arrives with a single metric is measuring their own story rather than your business, and the baseline has to be yours or the number afterwards means nothing.
A governed environment you own, and capabilities that run inside it with the same identity, roles, quotas, isolation and records whether or not they call a model. The environment is the durable part. Modules on it get their own origin, short-lived credentials tagged to a named person, and an access record written before the credential is issued. Nothing about that is less valuable because a given capability is deterministic. What is in a deployment.
It means we will automate them with software that behaves the same way every time, and use a model for the parts that are genuinely about language or ambiguity. Most critical processes turn out to be a deterministic core with messy edges. Automating the core properly and putting a model on the edges is usually both safer and cheaper than the fashionable alternative.
We do not offer unattended agents operating inside a client environment. The rule on this page is the reason: anything consequential completes because a named person accepted a result the deterministic core computed, and an agent acting on its own removes exactly that step. What we do not claim.
You do, with the process owner in the room. We bring the test on this page, the failure modes we have seen, and a strong view. The decision about what your organization is willing to have a model touch is a risk decision, and risk decisions belong to the people who carry them. Shared responsibility.
Inference does not belong in a zero-error critical path. Knowing which of the two you are looking at is most of the judgment in this work, and it is the part no product page can do for you.
Bring the process you were told to put a model into. The assessment is a good place to find out whether that is the right instrument.