If you accept that AI should be sold as defined jobs rather than as access to a model, the next question is the practical one. What does a defined job actually contain? What has to be written down, and by whom, before anyone can be charged for it?
This is less glamorous than the argument that precedes it, and it is where most attempts fall over. Publishing a price is easy. Publishing a price you can defend when the output is wrong takes a specific set of artefacts, and most teams discover halfway through that they do not have them.
The five artefacts
A job that can be sold has five pieces. Miss any one and you are back to selling access with a price tag stapled on.
1. The input contract
What will you accept, in what format, at what size, and what happens when something arrives outside those bounds. This sounds trivial until you try to write it. A job that takes “a document” is not specified. A job that takes a PDF up to forty pages, text-layer or scanned at 200 DPI or better, in English or German, under 20MB, is specified.
The important part is the second half: what happens outside the bounds. A specified job rejects out-of-scope input clearly and immediately, before payment, rather than accepting it and producing something plausible and wrong.
2. The output contract
Precisely what comes back. Not “a summary” but a structured object with named fields, each with a type and a definition. Where the output is prose rather than data, the contract is a rubric: length, register, what must be included, what must never appear.
Writing the rubric is where domain expertise earns its keep. It is the difference between “professional tone” and “second person, present tense, no superlatives, no claims not present in the source, between 90 and 140 words.”
3. The evaluation set
A held-out collection of inputs with known-correct outputs, produced by a person who knows the domain. This is the acceptance criterion made concrete, and it is the artefact teams most often skip because it is expensive and boring.
It needs to be big enough to be meaningful and adversarial enough to be honest. A set of forty easy cases tells you nothing. The useful sets are the ones that include the awkward document, the ambiguous phrasing, the case where two fields could plausibly hold the same value.
4. The confidence and escalation rule
Probabilistic systems are sometimes wrong. A job that pretends otherwise is not a job, it is a gamble. So the contract has to say what happens on low confidence: does it return a partial result, refuse, or route to a human, and does the buyer pay in that case.
Our default is that the system refuses rather than guesses, and a refusal is not billed. That single rule does more for trust than any accuracy figure, because it converts an unknown risk into a known one.
5. The remedy
What the buyer gets when the output is wrong despite everything above. A rerun, a refund, a human doing it manually, or credit. Published before purchase, not negotiated afterwards.
Vendors resist this hardest, and it is the part that makes everything else believable. Anyone can claim 99 percent accuracy. Only someone who means it will write down what happens in the other one percent.
Who writes these
Not the model, and not the engineer alone. The input and output contracts need someone who does the work today, because they know which edge cases are common and which are theoretical. The evaluation set needs the same person, plus the discipline to hold it back rather than let it leak into development.
The engineer’s job is to build the harness that runs the evaluation, the confidence machinery, and the refusal path. The commercial person’s job is to price it knowing the error rate and the remedy cost.
On our engagements this is roughly a week of combined effort for a job of moderate complexity, before any production code exists. Clients occasionally push back on that week. It is the week that decides whether the thing can be sold at a fixed price, so we hold the line on it.
A worked specification
Here is one, compressed, from a job we built for a logistics client. The task was reading proof-of-delivery documents.
Input: a single-page image or PDF, minimum 150 DPI, containing a signed delivery note from one of eleven named carriers. Anything else is rejected with a reason code before billing.
Output: consignment reference, delivery date, recipient name as printed, signature present true or false, damage noted true or false, and free-text exception if the damage flag is set. Each field carries a confidence between zero and one.
Evaluation: 800 documents keyed by two people independently, with disagreements resolved by a third. Field-level accuracy measured per carrier, because carriers differ enormously and an aggregate figure hides the bad ones.
Confidence rule: any field below 0.92 routes the whole document to a human queue. Documents routed to the queue are not billed.
Remedy: a field proven wrong by the client’s own audit is refunded at ten times the unit price, which is roughly what it costs them to unwind downstream.
That last number was the hardest conversation in the project and the reason the client signed. It priced our confidence in a way they could check.
The cost of getting the specification wrong
It is worth being concrete about what happens when one of the five artefacts is weak, because the failure modes are distinct and each has a smell.
Weak input contract. The system accepts things it should not and produces confident nonsense. You find out through customer complaints rather than through monitoring, because from the system’s point of view nothing went wrong. The tell is a support queue full of cases where the answer is technically a valid response to a document nobody should have submitted.
Weak output contract. Two buyers get results that are both defensible and inconsistent with each other. Downstream systems break intermittently on fields that are usually a date and occasionally a sentence describing a date. The tell is integration code full of defensive parsing.
Weak evaluation set. Accuracy looks excellent in development and disappointing in production, and nobody can explain the gap. Usually the set was drawn from convenient examples rather than representative ones, or it leaked into development and the system learned the answers. The tell is a number everyone quotes and nobody trusts.
Weak confidence rule. The system guesses when it should refuse, so the error rate is real but invisible. This is the most expensive failure because it destroys trust retroactively. Once a buyer finds one confident wrong answer they reasonably assume there are others, and they are right.
Weak remedy. Nothing breaks technically. The commercial relationship just never deepens, because the buyer keeps the job at low volume as a hedge. The tell is a customer who has been running a pilot for eleven months.
How this changes the sales conversation
Selling a specified job is a different conversation from selling a platform, and it is a shorter one.
The buyer reads the input contract and knows immediately whether their documents qualify. They read the output contract and know whether it plugs into what they have. They read the accuracy figure and the confidence rule together, which is the only way either number means anything. Then they read the remedy and decide whether they believe you.
There is no discovery phase, no workshop, no proof of concept that quietly becomes the project. Either the specification matches their problem or it does not. We lose deals faster this way, which is a feature: the deals we lose are the ones that would have gone badly.
What this does to the engineering
Specifying a job like this changes what you build. A chat-shaped product optimises for breadth. A job optimises for a measured pass rate on a known set, which pushes you toward things that are unglamorous and effective.
You spend more time on retrieval and input normalisation than on prompting, because most errors turn out to be the system not seeing the right thing rather than reasoning badly about it. You build a confidence signal you actually trust, which usually means comparing several passes rather than believing a single self-reported score. You build the refusal path early, because it is the thing that keeps the accuracy figure honest.
You also stop chasing the frontier. Once the target is a pass rate on a defined set, the question becomes which model clears the bar most cheaply, and the answer is frequently not the largest one. We have moved production jobs to smaller models several times after the evaluation showed no measurable difference on the task that mattered.
The objection about rigidity
A defined job cannot do the thing next to it. Ask the delivery-note reader to handle an invoice and it refuses. To someone used to a general assistant this feels like a downgrade.
It is a downgrade in flexibility and an upgrade in everything else: price, accountability, measurability and trust. The right response is not to widen the job until it becomes an assistant again. It is to define the second job.
Buyers understand this instinctively in every other market. Nobody complains that a dishwasher will not wash clothes. The complaint only appears in software, because software has spent thirty years promising that one tool can do everything, and mostly getting away with it.
What we would not sell as a job
Being honest about the limits matters, so here is where we would decline.
Anything where correct cannot be defined without a person exercising judgement in the moment. Strategic advice, clinical diagnosis, hiring decisions, anything with a legal consequence attached to the specific output. These are not jobs, they are decisions, and they need an accountable human whose name is on them.
Anything where the evaluation set cannot be built because the ground truth does not exist. If nobody can say what the right answer was, you cannot measure whether you produced it, and you certainly cannot sell it with a remedy attached.
Anything so rare that the specification costs more than the work it replaces. A job that runs eleven times a year should probably stay manual, and we have told clients so.
Where this is going
The pattern we expect over the next few years is a slow migration of tasks from the open interface to defined jobs, in roughly the order that specifications become writable. Document handling first, because the contracts are easy and the volume is enormous. Then routine correspondence, categorisation and enrichment. Then narrow analytical work where a rubric can be agreed.
What stays in the chat window is genuine exploration and everything where the buyer is also the expert. That is a real and permanent market. It is just considerably smaller than the market for finished work.
BotUp is our attempt to build the marketplace for the second thing: jobs with a published spec, a price and refund terms, rather than access sold by the token. If you have a task you think is specifiable, tell us about it and we will tell you honestly whether it is.
