MODULE 1 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolNon-Determinism as a Product Property
The specification does not exist
Conventional software has a property you stop noticing until it is gone: you can say what it will do. Given this input, that output. A test asserts it. A defect is a deviation from the stated behaviour, and everyone agrees what a defect is.
An AI feature has no such statement. You cannot write "given this support email, the system produces this reply". You can say what kind of reply, within what constraints, acceptable how often.
This is not a gap to be closed by better engineering. It is the nature of the technology, and it propagates into every part of the product discipline:
The last row is the one product teams are least prepared for. A customer does not experience your 94% accuracy. They experience the one answer they got, and if it was wrong, your aggregate number is not an answer to their complaint — it is an insult dressed as one.
What replaces the specification
Three things, together:
A described behaviour. What the system is for, what it will attempt, and — stated as prominently — what it will not attempt. The boundary is part of the product.
An acceptance range. "At least 90% of replies require no edit before sending, measured on a fixed evaluation set of 500 real tickets." This is the closest thing to a specification you will get, and module 3 is about building it.
A defined behaviour at the edges. What happens when the system is unsure, when the input is out of scope, when a dependency is unavailable. In conventional software these are error states; in an AI product they are a substantial part of what you are actually selling.
Which parts should be probabilistic
The most consequential architectural decision in an AI product, and it is a product decision rather than an engineering one:
Probabilistic is right where variation is acceptable or valuable — drafting, summarising, suggesting, ranking, explaining, generating options.
Probabilistic is wrong where the answer has a single correct value — prices, balances, availability, entitlements, dates, legal terms, medical dosages. These come from systems of record.
The frequent mistake is not using AI where it does not belong. It is building a product where the two are blended so the user cannot tell which is which. An assistant that says "your balance is £412 and you might want to consider switching plans" has stated one fact and one opinion in one sentence, in the same voice, with the same apparent confidence. If the balance came from a database and the suggestion from a model, the user has no way to know that one is reliable and the other is a guess.
Separate them visibly. It is a design obligation, not a nicety.
Consider one capability — generating a plain-English summary of a legal contract — shipped two ways.
Product A: a summary tool for lawyers. The summary appears beside the contract. Every claim links to the clause it came from. The user is a professional who will verify anything that matters. The interface says "draft summary — check against source". Errors are caught by exactly the person best equipped to catch them, at almost no cost, and the tool saves them the first read.
Product B: a summary shown to consumers before they sign. Same model, same accuracy. The user cannot verify anything — they have no legal training and no reason to distrust a confident summary. An error does not get caught; it gets acted on. And it may be acted on in a way that later becomes a regulatory matter, because the product effectively gave advice.
Identical technology. One is a good product; the other is a liability.
The difference is entirely in who the user is and whether the surface positions the output as a draft to verify or an answer to rely on. That is a product management decision, made before any engineering, and it is the decision that most often determines whether an AI product succeeds or causes harm.
The generalisable test: can the person receiving this output detect it if it is wrong, and what happens if they cannot? If the answer is "they cannot detect it and they will act on it", you are not building a drafting tool — you are building an authority, and you should hold it to a completely different standard or not ship it.
An assistant replies "your balance is £412 and you might want to consider switching plans." What is the product design problem?
The missing specification
Click to flipAn AI feature cannot be specified as "given this input, that output". You can state what kind of output, within what constraints, acceptable how often — and that is the closest thing to a specification available.
Click to flip backAn AI product cannot be specified the way software can, and that propagates into acceptance criteria, defect definitions, testing, release and support. What replaces the specification is a described behaviour with explicit limits, a measured acceptance range, and defined edge behaviour — which is a real part of the product rather than an error state. Decide deliberately which parts are probabilistic, never blend generated content with facts from systems of record, and judge every surface by whether the user could detect a wrong answer.