"Use AI" is too broad to specify a system. A useful requirement names what the system must do with its inputs. Does it need to identify a field, find a source, estimate a future outcome, create a draft, or change something in another application?
Several capabilities can be combined in one workflow. They do not need to come from the same model, and some may be better implemented with ordinary software.
This chapter names eight capabilities, explains how each is checked and how each fails, and shows how the guide's workflows combine them. The taxonomy is an editorial tool for writing requirements, not a scientific classification.
The capability map
| Capability | Question it answers | Example |
|---|---|---|
| Extract | What information is present? | Quantity on a purchase order |
| Classify | Which defined category applies? | Route a support request |
| Retrieve | Where is relevant information? | Find an approved setup guide |
| Generate | What output should be composed? | Draft an explanation |
| Predict | What outcome is likely? | Demand over a replenishment period |
| Optimize | Which feasible choice best serves an objective? | Proposed production schedule |
| Perceive | What is in a signal? | Defect in an image or speech in audio |
| Act | What authorized change should be executed? | Create an approved order |
These are functional categories, not mutually exclusive scientific definitions. Speech transcription can also be treated as extraction. An image model can classify defects. The taxonomy is useful when it clarifies requirements; it should not force one label onto a mixed system.
How far each capability sits from a consequential action
Informs
Output is information a person reads
- RetrieveFind an approved setup guide
- ExtractQuantity on a purchase order
- PerceiveDefect in an image or speech in audio
Proposes
Output suggests a decision a person or rule takes
- ClassifyRoute a support request
- GenerateDraft an explanation
- PredictDemand over a replenishment period
- OptimizeProposed production schedule
Acts
Output changes something outside the system
- ActCreate an approved order
Authority boundary: crossing it requires an authorized, permission-checked, recoverable action.
Closer to action →
Each capability: output, check, and failure
The table below adds what each capability produces, how a person or rule can check it, and a characteristic failure. The failures are the ones the guide's chapters design against; they are illustrations, not measured frequencies.
| Capability | Output | How it can be checked | Characteristic failure | Where the guide shows it |
|---|---|---|---|---|
| Extract | A value with its location in the source | Compare the value with the cited span | A plausible value where the source is silent | Catalog enrichment, order intake |
| Classify | A label from a fixed set | Confusion between categories, weighted by consequence | A confident label for a case that belongs to no category | Support replies scope check |
| Retrieve | A ranked set of permitted passages | Whether required sources are found; whether restricted ones are excluded | The right document missed, or a restricted one shaping the answer | Knowledge retrieval |
| Generate | Composed text or structure | Each material claim against permitted evidence | Fluent prose that states something no source supports | Support replies, proposals |
| Predict | An estimate, ideally with a range | Error on periods unseen at prediction time | A good average that hides bias or damaging item-level misses | Inventory forecasting |
| Optimize | A choice among feasible options | Feasibility under every hard constraint, then the objective | An "optimal" choice that breaks a constraint the model never saw | Replenishment policy in forecasting |
| Perceive | A reading of an image, audio, or other signal | Errors under the real capture conditions and speaker range | Accuracy that varies by speaker, lighting, or device | Transcription in meeting follow-up |
| Act | A change in another system | The change happened once, as authorized, and can be reconciled | A duplicate write after a timeout; an action no one authorized | Order creation in order intake |
Two patterns in this table matter for requirements:
- The check differs by capability. Extraction is checked against a span, prediction against the future, action against a system's record of what happened. A single "accuracy" figure across a mixed system hides which capability failed.
- The failure that matters may be a confident wrong answer, not an error message. Extraction that invents a missing value, classification that forces an odd case into a category, and generation that states an unsupported fact all look like success at a glance. That is why the workflow chapters ask for source spans, an explicit "none of these" category, and claim-by-claim review.
Perception depends on conditions
Perception depends heavily on how the signal was captured. A peer-reviewed study of five commercial speech-recognition systems, tested before 2020 on interview recordings, reported an average word error rate of 0.35 for Black speakers against 0.19 for white speakers. Koenecke et al., PNAS 2020 The study concerns older systems and a specific audio collection, not current products or business meetings. It supports a narrow design point: evaluate perception on the range of voices, accents, devices, and conditions the workflow will actually see, and do not assume errors fall evenly.
Prediction is different from explanation
A forecasting model produces an estimate of future demand. A language system can describe that estimate and its assumptions. A convincing description does not validate the forecast. Evaluate the prediction against outcomes that were unavailable when it was made, and evaluate the explanation for fidelity to the actual calculation.
Similarly, a model can summarize why an order was flagged without being the best mechanism for flagging it. Compare explicit rules with model-based checks for missing fields and invalid quantities; do not assume which approach performs better.
Two further points from forecasting practice apply to any prediction:
- Compare with a simple benchmark. The forecasting textbook the guide relies on describes simple methods (the mean, the last value, the same period last season, and a drift line) and notes that one of them is sometimes the best method available, while in other cases they serve as benchmarks. FPP3, section 5.2 A prediction that does not beat a naive forecast on unseen data has not earned a place in the workflow.
- A point estimate without a range can mislead. The same source states that point forecasts can be of almost no value without accompanying prediction intervals. FPP3, section 5.5 In the forecasting chapter, the intermittent item shows the problem: a forecast of one case a week describes an item that sold nothing in most weeks.
Generation is different from retrieval
Retrieval selects information from a collection. Generation composes an output. In a knowledge assistant, the system may retrieve approved documents and use them as context for a draft. The two stages can fail separately: the right document may not be found, or the draft may misrepresent a document that was found.
Decide whether a generated answer is needed. Sometimes the right result is a short list of documents, an exact passage, or a structured field with a source reference. Adding prose can increase review work without improving the decision.
Retrieval itself is not one technique. Microsoft's documentation for its search service, a vendor source, describes keyword retrieval as serving exact identifiers while vector retrieval can find conceptually similar material without matching terms. Microsoft hybrid search In the knowledge retrieval chapter, a question about "pricing redesign" needs to reach a document about "tariff restructuring", which is a conceptual match; a question about engagement ENG-2231 needs the exact identifier. The retrieval chapter covers the trade-offs.
A misreading to avoid
"The model knows our products" can mean two different things: the model was given approved documents to retrieve from, or it is answering from what it absorbed in training. The first can be checked passage by passage and kept current by maintaining the documents. The second cannot be checked against a source and does not update when the product changes. The support chapter's worked ticket fails precisely when an archived version-3 rule reaches the draft; a requirement written as "retrieve from approved, current documents and cite them" prevents that, where "answer product questions" does not.
Optimization needs an objective and constraints
A distributor might predict demand, then use a purchasing policy or optimizer to determine order quantities. The chosen action depends on stock, lead times, order minimums, service targets, and cost assumptions. Improving a forecast does not specify those choices by itself.
Be explicit about what "best" means. Minimizing inventory and minimizing stockouts are different objectives. A generated recommendation that ignores a hard supplier constraint is not feasible even if its explanation sounds reasonable.
Writing an optimization requirement
As a proposed template, an optimization requirement has three parts:
- The objective, in one sentence. "Minimize average inventory value" or "minimize expected stockouts of critical items". If two objectives compete, say which wins or how they trade.
- Hard constraints. Pack sizes, order minimums, supplier lead times, budget limits. A result that breaks one is infeasible, not merely worse.
- The comparison. The current rule, run under the same constraints. In the forecasting chapter, the same order-up-to policy is applied to every forecasting method, so a better result can be attributed to the forecast rather than to a changed rule.
The forecasting chapter also notes that fixing the policy layer (confirmed lead times, explicit buffers, correct pack sizes) may be the cheaper improvement. An optimizer working on wrong constraints will produce confidently wrong choices.
Action requires application design
For your technical lead
An action-taking system connects model output to tools or software interfaces. The model may propose parameters, but application controls should determine whether the action is allowed. The system needs a way to handle invalid inputs, retries, partial failure, and uncertain outcomes.
A customer email containing "ignore the usual rules" is not authority to change those rules. Treat information supplied to the system separately from permissions granted by the organization. The retrieval chapter covers this prompt-injection risk; it is a reason to keep permissions in the application, not in instructions to the model.
Uncertain outcomes are part of the design
An action can succeed while the confirmation is lost. Writes need idempotent submission; the order-intake chapter cites the engineering source and works through the consequence: a retry sent as a new request after a timeout creates a second order, while a retry that carries the same operation identifier, or a status lookup by that identifier, finds the first one. This is application design, not model behavior, and it belongs in the requirement for any capability that acts.
Choose the simplest useful combination
For order intake, a sensible candidate might combine document extraction, a fixed schema, deterministic unit checks, proposed product matching, and human-approved execution. A conversational agent is not required just because several steps are involved.
For forecasting, start with a simple comparison method and a meaningful evaluation period. For proposals, start with a maintained template and approved source library. Google's engineering guidance recommends establishing metrics and a simple initial system before adding complexity. That principle supports a comparison baseline; it does not determine which implementation will win your evaluation. Rules of Machine Learning
Worked combinations from the guide
These summarize designs the workflow chapters propose; they are not observed deployments.
| Workflow | Capabilities used | Done by ordinary software instead | Who acts |
|---|---|---|---|
| Support replies | Classify (scope), retrieve, generate | Version filtering of articles; permission filtering | Agent sends |
| Proposals | Extract (requirements), retrieve (approved material), generate (draft) | Requirements tracking; reuse-permission checks on credentials | Partner and delivery lead approve; a person submits |
| Order intake | Extract, classify (mapping proposals) | Unit conversion, required-field and duplicate rules, idempotent order creation | Specialist approves; integration writes once |
| Incident triage | Retrieve, generate (brief) | Alert grouping and counts, time-windowed queries | Commander authorizes mitigation |
| Onboarding | Retrieve, generate (plan) | Checking plan steps against the structured entitlement record | Specialist approves and sends |
| Knowledge retrieval | Retrieve, generate (answer package) | Permission filtering before ranking | Consultant verifies before use |
| Meeting follow-up | Perceive (speech), extract, generate | Excluding off-record segments; task identifiers | Recap owner approves send and each task |
| Forecasting | Predict, optimize (policy) | Pack rounding, exception flags | Planner approves; buyer places |
| Catalog enrichment | Extract, generate (copy) | Unit conversion with NIST factors, vocabulary checks | Steward approves publication |
The pattern is consistent: deterministic steps (conversions, permissions, duplicates, counts) stay in ordinary code, where they can be tested exactly, and the model handles the parts that need interpretation. Action stays with a named person or a controlled integration.
When the simplest combination is no model at all
Some requirements dissolve on inspection. If customers can send structured orders, extraction is unnecessary. If documentation is owned and searchable, a search interface may answer most questions without generation. If a planner's main problem is wrong lead times, better data beats better prediction. Each workflow chapter compares its design against such an alternative; the comparison belongs in the requirement, so the team measures whether the model adds anything.
Write requirements with capability verbs
Write requirements using capability verbs, then assign an evaluation method to each. This prevents a product label or model brand from standing in for a clear description of the work.
A proposed format, one line per step:
[Capability] [what] from [permitted input], checked by [method], with [failure that matters] handled by [control]. Output goes to [person or system], who [decides or acts].
For example: "Extract quantity and unit from the customer's purchase order, checked against the source span and the item master's pack size, with a pack-size conflict handled by blocking the line for buyer confirmation. Output goes to the order specialist, who approves the order."
Requirements written this way make model selection a comparison of configurations against named checks, which is how the model-selection chapter proceeds. They also make clear which steps need a model and which do not.
Related chapters: workflow change, authority, model selection, retrieval, document extraction, inventory forecasting.