Problem framing, requirements and metrics

Before any data is collected or model trained, a project must be framed: what exactly is being predicted, generated or decided, for whom, under what constraints, and how success will be measured. Framing determines everything downstream. The same business need, such as reducing invoice fraud, can be framed as binary classification, anomaly detection, ranking for human review or rule extraction, and each framing implies different data, models and metrics. A poor framing can produce a model with excellent test scores that nobody can use. This lesson covers understanding users and the decision context, translating needs into a machine learning task, functional and non-functional requirements, choosing metrics that reflect real costs, setting targets, and deciding whether machine learning is the right tool at all.

Start with the decision

AI systems are useful when they improve a decision or task. Begin by describing the current process: who does the task now, what information they use, how long it takes, how often it goes wrong, what errors cost, and what would change if the task were faster, cheaper or more accurate. Interview prospective users and observe the work where possible. Users often describe what they want in terms of solutions ("we need a dashboard"), and the team's job is to understand the underlying need ("we need to know which shipments will be late in time to reroute them"). A clear statement of the decision, the person making it, the timing and the consequences of mistakes is the foundation for every later choice.

Translating needs into a learning task

Once the decision is clear, choose a task formulation. Common formulations include classification (assigning one of a set of labels), regression (predicting a number), ranking (ordering items for attention), detection and segmentation (locating objects in images), sequence labelling and extraction (finding fields in text), generation (producing text, images or code), retrieval (finding relevant documents), clustering and anomaly detection (finding structure or unusual cases without labels), and forecasting (predicting future values). Each formulation needs a precise definition of inputs, outputs and the moment of prediction: what information is available at the time the prediction is made. Using information that would not be available at that moment is a form of leakage (Lesson 4).

Requirements

Requirements describe what the system must do and under what constraints. Functional requirements describe behaviour: inputs accepted, outputs produced, and how users interact with the system. Non-functional requirements describe qualities: accuracy targets, latency (how quickly a response is needed), throughput (how many requests per second or per day), cost per prediction, availability, privacy and security, explainability (whether users need reasons for outputs), fairness across groups, and compatibility with existing systems. Non-functional requirements often rule out approaches: a model that must run on a phone without a network connection cannot be a 70-billion-parameter language model, and a decision that affects people's access to services may require explanations and human review.

Choosing metrics

A metric turns the vague notion of "good" into a number. The choice of metric is one of the most consequential decisions in a project, because teams optimize what they measure. Considerations include:

• Class imbalance: when positives are rare, accuracy is misleading, because a model that always predicts the majority class scores highly. Precision, recall, the F1 score, the precision–recall curve and its area are more informative.
• Asymmetric costs: when false negatives and false positives have different costs, as in fraud, medical screening or content moderation, the metric should reflect them, for example by choosing a threshold that minimizes expected cost.
• Capacity constraints: when only a fixed number of cases can be reviewed, precision at k or recall at k matches the real use.
• Ranking and retrieval quality: mean reciprocal rank, normalized discounted cumulative gain and recall at k measure ordered results.
• Generation quality: automatic metrics such as BLEU or ROUGE correlate weakly with human judgement for open-ended generation; task-specific checks, human ratings and model-based judges are often needed (Lesson 7).
• Business or user outcomes: the ultimate measure is often the effect on the decision, such as time saved or losses avoided, measured in a pilot or A/B test (Lesson 12).

import numpy as np
# Choosing a decision threshold from costs instead of accuracy
rng = np.random.default_rng(0)
n = 5000
y = rng.random(n) < 0.08                          # 8 % of invoices are fraudulent
score = np.where(y, rng.beta(5, 2, n), rng.beta(2, 5, n))
cost_fn, cost_fp = 500.0, 20.0                    # missing fraud costs 500, a false alarm costs 20 to review
best = None
for t in np.linspace(0.05, 0.95, 19):
    pred = score >= t
    fn = np.sum(y & ~pred); fp = np.sum(~y & pred)
    acc = np.mean(pred == y); cost = fn * cost_fn + fp * cost_fp
    if best is None or cost < best[1]:
        best = (t, cost, acc, fn, fp)
    if abs(t - 0.5) < 1e-9:
        print(f"threshold 0.50: accuracy {acc:.3f}, missed fraud {fn}, false alarms {fp}, cost {cost:,.0f}")
t, cost, acc, fn, fp = best
print(f"cost-optimal threshold {t:.2f}: accuracy {acc:.3f}, missed fraud {fn}, false alarms {fp}, cost {cost:,.0f}")
print(f"always predicting not fraud: accuracy {np.mean(~y):.3f}, cost {np.sum(y) * cost_fn:,.0f}")

threshold 0.50: accuracy 0.887, missed fraud 48, false alarms 517, cost 34,340
cost-optimal threshold 0.40: accuracy 0.776, missed fraud 17, false alarms 1101, cost 30,520
always predicting not fraud: accuracy 0.918, cost 204,000

The output shows why accuracy can mislead. Always predicting "not fraud" achieves the highest accuracy of all, about 92 %, while missing every fraud and incurring the largest cost. The model at the conventional 0.5 threshold is more accurate than at the cost-optimal threshold, but the cost-optimal threshold catches far more fraud and reduces total cost, at the price of more false alarms for reviewers. Whether reviewers can handle those false alarms is itself a requirement to check with users.

Primary and guardrail metrics

Most projects need one primary metric that defines success and several guardrail metrics that must not get worse. For an invoice extraction system, the primary metric might be the share of invoices with all fields correct, with guardrails for latency, cost per invoice and accuracy on invoices from small suppliers. For a question-answering assistant, the primary metric might be the share of answers rated correct and complete, with guardrails for the rate of unsupported claims, refusals of answerable questions and response time. Guardrails prevent a team from improving the headline number by making the system worse in ways that matter.

Setting targets

Targets should be ambitious but grounded. Useful references include the performance of the current process, such as human accuracy or an existing rule-based system; simple baselines (Lesson 5); published results on similar tasks; and the minimum performance at which the system would be useful, which only users can tell you. A target such as "recall of 0.90 at a precision of at least 0.50" is better than "high accuracy", and a target expressed relative to the current process, such as "halve the time to process an invoice without increasing errors", connects the model to value.

Is machine learning the right tool?

Not every problem needs machine learning. Simple rules, lookups, optimization or better user interfaces may solve the problem more reliably and cheaply. Machine learning is most appropriate when the task involves patterns that are hard to specify by hand, enough representative data exists, some errors are tolerable, and the environment is stable enough for patterns learned from past data to hold. It is least appropriate when decisions must be fully explainable by law, errors are catastrophic and cannot be caught, data is scarce or biased beyond repair, or the problem changes faster than data can be collected. A capstone that concludes, with evidence, that a simple rule-based system outperforms a learned model is a legitimate and valuable result.

Interviewing users

User interviews are a skill. Prepare a short guide of open questions, such as "walk me through the last time you did this task" and "what goes wrong most often?", rather than asking users whether they would like a particular feature, since people readily agree to hypothetical features they would never use. Ask for examples and, where appropriate, observe the work directly. Interview several users with different roles, such as frontline staff, supervisors and people affected by the decisions, because their needs and concerns differ. Summarize findings in a short document that the whole team reads, and confirm key points with the partner. Interviews with people outside the program may require ethics approval if the results will be published.

Defining the label precisely

A frequent source of trouble is a label that sounds clear but is not. "Fraudulent invoice" might mean an invoice later confirmed as fraud, one flagged by auditors, or one that was rejected for any reason. "Customer churn" might mean cancelling, not renewing, or becoming inactive for 90 days. Each definition produces different training data and a different model. Write the exact operational definition of the target, including the time window and data source, agree it with the partner, and record it in the proposal and datasheet.

Thinking about errors in context

Every model makes errors, and the framing should anticipate how they will be handled. Will a human review every output, only uncertain ones, or none? Can errors be detected and corrected later, or are they final? Who bears the cost of each type of error, the organization, its staff or the people the decisions are about? Answering these questions shapes both the metric and the design: a system whose errors fall on vulnerable people, and cannot easily be corrected, needs a much higher bar and stronger safeguards than one whose errors are caught by a reviewer before any action is taken.

Documenting the framing

The framing decisions belong in the proposal and later in the report: the decision supported, the users, the task formulation and label definition, the moment of prediction, the requirements, the primary and guardrail metrics with targets, and the alternatives considered and rejected. Reviewers use this section to judge whether the rest of the project answers the right question, and partners use it to confirm that the team understood their need.