Part I — What learning changes
Behavior fitted from examples
An explicitly programmed rule gets its decision behavior from authored control flow. A learned predictor gets part of its behavior from parameters fitted to examples. For a request-duration predictor, an engineer might choose the inputs and model family, while fitting determines coefficients that connect request properties to a duration estimate. The resulting model is still a function that software can call.
| Question | Authored rule | Learned predictor |
|---|---|---|
| Where does behavior come from? | Conditions written by a programmer | Parameters fitted from examples |
| What varies per request? | Input values | Input values |
| What changes during training? | Nothing unless code is edited | Learned parameters |
| What happens during ordinary inference? | The rule executes | The fitted function executes |
| What establishes correctness? | Contract and behavioral tests | Contract checks plus statistical evidence on relevant new cases |
Determinism is a separate choice
Learning does not make execution inherently random. A fitted model can return the same output for the same input. Separate three choices: randomness used while fitting, optional sampling used to select a generated output, and nondeterministic numerical implementations. Seeding and deterministic-algorithm settings address different parts of that problem and may still vary across software versions or hardware.
A valid interface is also different from a valid prediction. JSON schema validation can establish that predicted_seconds is a number; it cannot establish that the number is close to the eventual duration. Software Engineering Fundamentals owns the fuller treatment of explicit contracts. Here the important point is that learned behavior adds an empirical correctness question to the usual software questions.
Examples, features, and targets
A learning problem begins by fixing the unit of prediction. One example is one unit about which the model should learn: a service request, an image, a document, or a customer session. Its features are observations available when the prediction must be made. Its label, or target, is the recorded answer training asks the model to predict. A collection used for fitting is the training set.
Choose the target before the algorithm
Predicting a numerical target, such as duration in seconds, is regression. Predicting one category from a set, such as completed, canceled, or timed_out, is classification. Encoding those categories as 0, 1, and 2 does not turn the task into regression; the numbers are identifiers unless their distances have a defined meaning.
Consider an invented request record. At submission time, the system knows the operation type, payload size, service version, and queue depth. Completion duration appears later. Duration can be the target, but using it as an input to predict itself would be leakage. Log-derived setup or execution durations pose the same timing problem: a field can be useful for diagnosis after completion yet invalid as a prediction-time feature.
A target appears after the prediction point
ExampleThe same request persists, but completion information is introduced only after the model had to predict.
The request identity persists; only submission-time fields are available as possible prediction inputs.
Read the diagram as text
- Request R-17. The stable request entity.
- Submission fields. Operation, payload size, service version, and queue depth recorded at prediction time.
- Duration prediction. A representation derived from the submission fields, not a property already stored on the request.
- Completion state. A later state of the same request.
- Observed duration. The target becomes available only after completion.
- Request R-17 → Submission fields: has recorded state.
- Submission fields → Duration prediction: data input.
- Request R-17 → Completion state: later state.
- Completion state → Observed duration: records target.
- At submission. The request identity persists; only submission-time fields are available as possible prediction inputs. Active: Request R-17, Submission fields. New: Request R-17, Submission fields.
- Make the prediction. The model derives a duration estimate from the available fields. Active: Request R-17, Submission fields, Duration prediction. New: Duration prediction.
- Observe the outcome. Completion adds the target while preserving the original request identity and fields. Active: Request R-17, Submission fields, Duration prediction, Completion state, Observed duration. New: Completion state, Observed duration.
| Field | Available at submission? | Role in duration prediction |
|---|---|---|
| request_id | Yes | Identity; usually not a predictive feature |
| payload_bytes | Yes | Possible feature |
| service_version | Yes | Possible feature |
| queue_depth | Yes | Possible feature if recorded at the prediction time |
| completion_duration | No | Target |
| post-run error trace | No | Later diagnostic evidence, not a submission-time feature |
Labels are measurements
A recorded target is not automatically the desired truth. It may arrive late, contain measurement error, encode an ambiguous policy choice, or exist only for cases selected by an earlier decision. If a dataset contains only completed requests, it may omit canceled and unfinished requests that future traffic includes. Likewise, an exact label match can be deterministic while the label itself remains disputable or depends on information withheld from the model. Collection, provenance, and labeling practice are developed in Data Quality and Curation.
Parameters and inductive assumptions
Suppose a duration predictor uses payload size :
Here changes with each request. The coefficient and intercept are learned parameters that remain fixed during ordinary prediction. An engineer may instead choose a regularization strength, tree depth, number of layers, or learning rate. Such a setting is a hyperparameter: it governs the candidate functions or the fitting procedure rather than being updated by the ordinary parameter-fitting loop.
Finite data leave choices open
A model family is the set of functions fitting may choose from. Linear regression can choose different lines. A decision tree can choose different feature thresholds and leaf values. A neural network composes parameterized transformations and may learn intermediate features rather than requiring every useful representation to be authored. Embeddings and Representation Learning develops that last idea. Two functions can fit the same observations yet disagree elsewhere. An inductive bias is the preference that makes one continuation easier to select than another.
Historical foundations of fitted behavior
1805Legendre publishes least squaresSelects unknown parameters by minimizing the sum of squared observational errors.
Contributors: Adrien-Marie Legendre
What changed: Made parameter selection from imperfect, overdetermined observations explicit. This is a publication milestone, not a sole-invention claim.
1958Rosenblatt’s perceptronStudies recognition and generalization in a network whose effective connections change through experience.
Contributors: Frank Rosenblatt, Cornell Aeronautical Laboratory
What changed: Made experience-dependent classification concrete through reinforcement dynamics that altered later responses.
1986Rumelhart, Hinton, and Williams on back-propagated errorsUses output errors to train intermediate representations in multilayer networks.
Contributors: David E. Rumelhart, Geoffrey E. Hinton, and Ronald J. Williams
What changed: Showed how the chain rule could efficiently provide weight sensitivities so hidden units could learn useful features from desired outputs.
Observed points do not determine one continuation
ExampleTwo functions fit every observed point yet disagree at an unobserved input.
Two sample-consistent functions
Both candidates agree at x=1, 2, and 4 but differ at the unobserved query x=3.
- 1. Linear candidate
- 2. Curved candidate
- 3. Unobserved query x=3
- 4. Observed examples
Read coordinates and regions as data
X: 0–4 dimensionless; Y: 0–8 dimensionless, increasing up. Axes scaled independently; screen angles and distances are not comparable.
(0, 0); (1, 2); (2, 4); (3, 6); (4, 8)
(0, 1); (1, 2); (2, 4); (3, 4.8); (4, 8)
(3, 0); (3, 6.6)
(1, 2); (2, 4); (4, 8)
x=3: unobserved: (3, 7.25)
6: (3.15, 6.2)
4.8: (3.15, 4.6)
Architecture, feature representation, regularization, and optimization all contribute to inductive bias. Finite observations do not uniquely determine behavior everywhere; the engineering question is whether the preference fits the intended setting.
The same observations can support different fitted representations. Increasing the range of candidate functions gives fitting more choices, but still leaves the engineer responsible for the objective and the conditions under which predictions will be judged.
How the developments connect
These approaches coexist with earlier statistical methods. Richer representations extend what can be fitted; they do not remove observational error or make the resulting predictor correct outside its assessed setting.
Part II — From signal to fitted model
Sources of supervision
A learning signal tells a fitting procedure how current behavior should change. In supervised learning, each example carries a supplied target: request fields paired with an observed duration, or an image paired with a class. The target need not be perfect, but it is explicitly treated as the answer for that training example.
Targets constructed from observations
In self-supervised learning, the data provide their own constructed targets. BERT, for example, corrupts selected positions in ordinary text and trains the model to recover the original content. The visible text becomes the input and the preserved original values become targets. No person must label every position, but the designer still chooses what to hide, what context is visible, and why recovering it should create reusable behavior.
This is distinct from using a large teacher model to generate labels. Teacher-generated labels are synthetic supervision and may reproduce teacher failures; they are not self-supervised merely because humans did not write them individually. Zeta2’s reported pipeline, for example, checked teacher edit predictions for task-specific violations and attempted repairs before using them as student targets.
Other learning signals encode different structures. Clustering can optimize compactness without supplied category labels. Reinforcement learning uses rewards from interaction rather than demonstrated actions. These signals are not interchangeable: each defines what information rewards a parameter change. Specialized corpus objectives belong in Pretraining and Midtraining; demonstrations, preferences, and rewards are developed in Post-training and Alignment.
Loss and the objective
A loss assigns a numerical penalty to a prediction relative to its target. A training objective aggregates losses across examples and may add weights, constraints, or regularization. The fitting procedure does not understand the prose description of your goal; it receives pressure from this computable quantity.
The penalty changes influence
Both objectives prefer small errors, but they apply different pressure. With absolute error, doubling an error doubles its contribution. With squared error, doubling an error quadruples its contribution. A single large duration miss therefore influences mean squared error much more strongly. That may be desirable when large misses dominate an operational budget, or undesirable when rare measurement failures should not control the fit. The objective encodes this choice; its name does not settle it.
How one residual changes the objective
For one duration prediction, the residual is observed duration minus predicted duration, in seconds. A negative residual means the prediction was too high.
Use the arrow keys to change the residual by half a second.
Residual 2 seconds: absolute penalty 2 seconds; squared penalty 4 seconds squared.
| Residual | Absolute penalty (s) | Squared penalty (s²) |
|---|---|---|
| Current: 2 s | 2 | 4 |
| Doubled: 4 s | 4 | 16 |
Doubling the residual magnitude multiplies the absolute penalty by 2 and the squared penalty by 4. Reversing its sign changes neither penalty.
These are terms for one example, before summing and dividing by the number of examples. MAE has duration units; MSE has squared-duration units. Their raw numeric sizes do not say which objective is better.
For binary classification, log loss rewards probability assigned to the recorded class and heavily penalizes confident mistakes. Weighting examples changes which cases dominate the aggregate. Adding favors smaller coefficients. These choices affect the selected predictor even when the examples are unchanged.
Optimization can succeed at the wrong task
Training loss remains a proxy. A model can reduce teacher disagreement without becoming more useful, optimize click labels without improving user welfare, or earn a learned preference score without becoming factually correct. Application metrics and decision consequences must therefore be evaluated separately from the quantity optimized during fitting.
Parameter updates
Gradient-based fitting repeats four operations: make predictions, compute the objective, calculate how locally sensitive that objective is to each parameter, and update the parameters. A gradient collects those local sensitivities. It does not identify a symbolic business rule to edit; it says how a small numerical parameter change would affect the current objective.
A minibatch is the subset of training examples used for one parameter update; in the equation, is its size. The parameter vector is , and is the learning rate controlling update scale. Small minibatches provide noisier gradient estimates but can make frequent updates; larger ones can use vectorized hardware efficiently. Changing batch size therefore changes both optimization behavior and execution.
Backpropagation computes; the optimizer updates
For composed differentiable operations, backpropagation applies the chain rule efficiently to compute parameter gradients. The optimizer then decides how to use those gradients. Plain stochastic gradient descent subtracts a scaled gradient; Adam and other optimizers transform or accumulate gradient information differently. Backpropagation is therefore not the optimizer and does not itself choose the learning rate.
Training adds a return path that inference omits
Backpropagation computes gradients; the optimizer uses them to create the next parameter state.
Read the diagram as text
- Features. Inputs available for the current examples.
- Parameters θₜ. The parameter values used by the current forward pass.
- Forward model. The authored parameterized computation.
- Predictions. Ordinary inference stops here. Training continues to the loss comparison.
- Targets. Recorded answers supplied during supervised training.
- Batch loss. The objective evaluated from predictions and targets.
- Backpropagation. Computes the gradient of the loss with respect to θₜ.
- Optimizer. Training only: combines θₜ and gradients with its update rule and learning rate to produce θₜ₊₁.
- Parameters θₜ₊₁. The distinct parameter state produced for the next training iteration.
- Features → Forward model: input.
- Parameters θₜ → Forward model: current values.
- Forward model → Predictions: forward computation.
- Predictions → Batch loss: training only: predicted values.
- Targets → Batch loss: recorded answers.
- Batch loss → Backpropagation: differentiate.
- Backpropagation → Optimizer: gradient.
- Parameters θₜ → Optimizer: previous state.
- Optimizer → Parameters θₜ₊₁: update.
Illustrative pseudocode
Python-like pseudocodeA large learning rate can cross a low-loss region and land on a worse point; a smaller rate can move toward it more cautiously. But lower training loss is only evidence about the fitted examples. Generalization remains a separate question. Also, not every learner uses gradients: decision trees greedily choose discrete feature splits according to an impurity or loss criterion.
Fitting is not inference
Robbins and Monro’s 1951 stochastic-approximation method established a recursive way to update an estimate from noisy observations under stated conditions. It is a useful historical foundation for noisy iterative updates, but it did not itself describe modern minibatches, neural networks, or backpropagation. During inference, fitted parameters normally remain unchanged. Examples placed in a prompt can still alter a response through the current input; that is the distinct mechanism developed in Prompting and In-Context Learning.
Part III — Evidence beyond the fitted sample
Generalization to new cases
Generalization is useful performance on new cases from the intended setting. Training error averages loss over observed examples. Population error is the expected loss over the underlying distribution of cases the system will encounter. The former is directly computable from the fitted sample; the latter is the quantity deployment usually cares about.
Minimizing is empirical risk minimization. It does not guarantee a small . Confidence comes from the combination of an appropriate inductive bias, sufficient coverage, representative sampling, and measurements on genuinely new cases. Interpolation within well-covered conditions and extrapolation beyond observed conditions make different demands on those assumptions.
What each score can support
| Evidence | What it measures | What it does not establish |
|---|---|---|
| Training error | Fit on examples used for learning | Performance on unseen cases |
| Random held-out rows | Performance on similar held-out records | Generalization to new entities if related records cross the split |
| Held-out projects | Performance on projects absent from fitting | Future performance after conditions change |
| Earlier-to-later split | Forecast performance across the represented time boundary | Stability beyond that period |
Rows are not always independent evidence
Random shuffling does not create independence. A thousand builds from one repository may contain less evidence about a new repository than a hundred builds from a hundred repositories. Group-aware splitting keeps dependent observations together when the claim concerns new entities; chronological splitting answers a different question about future observations.
Validation without leakage
Split names describe responsibilities. The training set fits model parameters and fitted preprocessing. The validation set guides choices such as model family, hyperparameters, features, and stopping point. The test set is held aside until those choices are frozen, then estimates the selected system’s performance.
Selection can overfit too
Repeatedly changing the system after reading test results makes the test set part of development, even when its rows never enter a gradient calculation. Adaptive selection depends on the reused data through the reported scores. Specialized reusable-holdout procedures exist under explicit query and sampling conditions, but ordinary final-test claims require fresh, independently sampled cases after adaptive development.
Data leakage occurs when fitting or selection uses information that would be unavailable in the intended prediction setting. Common paths include scaling features with statistics computed from all records, selecting features before splitting, placing records from the same entity on both sides of a split, or using observations from the future. A pipeline can ensure that fitted transformations are learned within each training fold, but it cannot prove that the raw fields were genuinely available at prediction time.
Three data boundaries, three responsibilities
The test estimate remains independent only when the complete system is frozen before test outcomes are read.
Read the diagram as text
- Training data. Contains only information permitted inside the fitting boundary.
- Fitted candidate. Preprocessing state and model parameters are learned from training data.
- Validation assessment. Evaluate the fitted candidate on validation data; results guide selection, not ordinary parameter fitting.
- Development choice. Validation results guide model family, features, hyperparameters, and stopping.
- Frozen pipeline. The selected preprocessing and predictor after development decisions are complete.
- Untouched test assessment. Evaluate the frozen pipeline on untouched test cases matching the final population or time claim.
- Final estimate. Performance of the frozen pipeline on the represented population or time boundary.
- Boundary rules. Fit preprocessing inside training; keep claim-relevant groups together; exclude future information; obtain fresh cases after test-driven revisions.
- Training data → Fitted candidate: fits state.
- Fitted candidate → Validation assessment: evaluated for selection.
- Validation assessment → Development choice: selection results.
- Development choice → Frozen pipeline: freezes complete system.
- Frozen pipeline → Untouched test assessment: one final assessment.
- Untouched test assessment → Final estimate: scored outcomes.
- Boundary rules → Training data: constrains fitting sample.
- Boundary rules → Untouched test assessment: constrains assessment sample.
Match the boundary to the claim
| Intended claim | Useful boundary | Reason |
|---|---|---|
| New independent cases from the same population | Random holdout or cross-validation | Estimates variation across independently sampled cases |
| New customers, repositories, or patients | Group-aware split | Prevents related records from appearing in fitting and evaluation |
| Future requests | Chronological split | Prevents later information from influencing earlier forecasts |
| Final performance after model selection | Untouched test set | Separates selection from assessment |
Baselines and uncertainty
Always compare against a simple baseline. A regression baseline might predict the training-set mean for every request; a classifier might always predict the most frequent training class. Beating it does not prove deployment value, but failing to beat it reveals that the learned features have not justified their complexity. Evaluation proportions also have sampling uncertainty, especially with small samples or rare failures. These foundations lead into the broader system-level methods in Evals and Benchmarks.
Underfitting, overfitting, and regularization
Underfitting means the fitted system has not captured useful structure available for the task. Overfitting means improving fit increasingly reflects sample-specific patterns that do not transfer. High training error can result from an unsuitable model family or unsuccessful optimization. Low training error combined with worse validation performance suggests a generalization gap, but only after leakage and validation mismatch have been ruled out.
Constrain the fit, not the evidence
Regularization changes which fitted solutions are favored. An L2 penalty discourages large coefficients; early stopping selects a training point using validation performance. These are different interventions, and neither repairs invalid labels, future leakage, or an evaluation population that does not match deployment.
| Observation | Plausible limitation | Next controlled comparison |
|---|---|---|
| Training and validation performance are both poor | Limited fit, weak features, or optimization failure | Try a more suitable representation, model family, or verified optimization change |
| Training improves while validation worsens | Possible overfitting or selection bias | Check leakage, then compare regularization, earlier stopping, or simpler choices |
| Validation improves as independent training examples increase | Evidence that representative data help | Collect more examples from the same intended population |
| Both curves remain poor as sample size grows | Persistent task, feature, label, or family limitation | Revisit the prediction contract rather than merely adding rows |
Training-step curves and sample-size learning curves answer different questions. The former vary continued optimization with a fixed dataset. The latter vary how many training examples are available. More parameters do not imply a universal U-shaped generalization curve, and more data from the same biased source may simply reinforce the same shortcut.
Part IV — Uncertainty, decisions, and change
Sources of predictive uncertainty
A point prediction gives one estimated outcome. A predictive distribution assigns probabilities across possible outcomes, while a prediction interval describes a range intended to contain a future observation at a stated long-run rate under its assumptions. These are richer claims than a single duration estimate.
Variation versus limited knowledge
Aleatoric uncertainty is unresolved outcome variation given the available information. Two requests with the same recorded features may still take different times because relevant causes were not observed or because outcomes genuinely vary. Epistemic uncertainty is limited knowledge about the predictive relationship, often exposed where examples are sparse or the model family is inadequate. The distinction is relative to the information and model: adding an informative feature can explain variation that previously looked irreducible.
More representative examples can reduce uncertainty about the fitted relationship without making each future outcome predictable. Conversely, richer observations may reduce outcome ambiguity while leaving the relationship poorly estimated in a new region. Some internal uncertainty decompositions are not uniquely identified by the same predictive distribution, so named components should not be treated as directly observed quantities in every model.
Different intervals answer different questions
| Output | Question |
|---|---|
| Point prediction | What single estimate does the model produce? |
| Prediction interval | Where might one new outcome fall? |
| Confidence interval for a mean | How uncertain is the estimated average response? |
A number between zero and one is not automatically a validated probability. Token log probabilities describe the model’s generation distribution, not calibrated factual confidence. A generated confidence statement and agreement among several similar models require their own evaluation. Calibration can also deteriorate under shift even when it looked acceptable on the original validation population.
From probabilities to actions
A probabilistic classifier is calibrated in an evaluated population when cases assigned probability near experience the outcome about a fraction of the time. Calibration is a frequency property across comparable cases, not a guarantee for one case. It also differs from discrimination, the ability to rank higher-risk cases above lower-risk ones. Predicting the population base rate for everyone can be calibrated while ranking nobody.
An action requires consequences as well as probabilities. If a false positive costs , a false negative costs , and correct decisions have zero cost, choosing the positive action minimizes expected cost when:
The same probability can justify different actions
| Predicted timeout probability | False alarm cost | Missed-timeout cost | Result |
|---|---|---|---|
| 0.30 | Low | High | Intervene at a relatively low threshold |
| 0.30 | High | Low | Do not intervene at that threshold |
| 0.30 | Moderate | Moderate, with useful human review available | Defer if the review path has acceptable capacity and delay |
Rare events produce surprising alert streams
Base rates matter. In a constructed set of 10,000 cases containing 100 real events, detecting 80% yields 80 true alerts. A 1% false-positive rate among 9,900 non-events adds 99 false alerts. Only 80 of 179 alerts are real even though 1% sounds small. This arithmetic is not a measured deployment result; it exposes why event prevalence and the denominator must accompany an alert rate.
Abstention adds a reject or defer action. Coverage is the fraction accepted automatically; selective risk is error among accepted cases. Raising a threshold helps only when the score meaningfully orders mistakes, and lower coverage transfers work elsewhere. Evaluate that downstream path rather than treating abstention as free safety. In bug-review systems, long lists of invalid reports illustrate the operational cost of a prediction stream whose report volume overwhelms human triage.
When deployment conditions shift
Distribution shift means that development or evaluation conditions differ from use conditions. The phrase is broad; diagnosing the changed relationship matters. Under covariate shift, input frequencies change while is assumed stable. Under label shift, outcome prevalence changes while is assumed stable. Under concept shift, the relationship itself changes.
Different changes require different evidence
Suppose large requests become more common but the duration relationship for each request size remains unchanged. That is compatible with covariate shift. If a service migration makes requests of the same size take different times, the conditional relationship has changed. The first problem may call for reweighting or evaluation on the new mix under strong assumptions; the second requires new labels and renewed validation of the predictive relationship.
A shortcut is a decision rule that works under ordinary development conditions but fails under a targeted change. Data, architecture, and training choices influence which shortcut a model finds. Held-out success drawn from the same shortcut-supporting conditions therefore does not prove that the intended rule was learned.
Detecting changed inputs and establishing degraded predictions are separate tasks. One study reported a controlled image shift that a detector noticed without harming the tested classifier. Conversely, an input-only test does not directly test a changed input–outcome relationship. Performance monitoring needs fresh outcomes, not merely feature drift alarms.
The model can change what it sees
Sequential systems add feedback. In imitation learning, a policy’s early mistake can move it into states absent from expert demonstrations; later decisions then face a new, policy-induced distribution. DAgger addresses this setting by executing the learned policy and collecting expert actions for states it actually encounters. The mechanism illustrates why deployment behavior can change future inputs. Longer-term update, retention, and forgetting strategies belong in Continual Learning.
Part V — Prediction is not intervention
Association, action, and causal effect
Prediction estimates an outcome under patterns represented in observed data. A causal effect compares outcomes under alternative interventions. The difference matters whenever a model output is used to choose an action: a variable can predict an outcome without being a useful lever for changing it.
A common cause can reverse the lesson
Imagine autoscaling records in which high load causes operators to add replicas and also increases latency. Replica count may therefore be positively associated with latency even if adding a replica under comparable load reduces latency. Load is a confounder because it influences both the observed action and the outcome. A predictor can learn the association accurately and still answer the intervention question incorrectly.
Load confounds the observed replica–latency relationship
ExampleOrdinary scaling records combine a load-driven association with the effect of changing replica count.
Read the diagram as text
- Operational load. A common cause of the scaling decision and latency.
- Replica count. The action whose effect is being studied.
- Latency. The outcome affected by load and potentially by replica count.
- Operational load → Replica count: ordinary scaling responds to load.
- Operational load → Latency: load affects outcome.
- Replica count → Latency: possible action effect.
Editing the replica-count feature and rescoring a predictive model is not automatically a causal experiment. Feature attribution assigns parts of a prediction to inputs under a reference construction; it does not establish the real-world effect of changing the corresponding quantity. Causal reasoning needs a specified intervention and assumptions about how outcomes would be generated under it.
What intervention evidence requires
Random assignment makes action selection independent of potential outcomes in expectation, allowing differences between assigned groups to estimate an average effect under the experiment’s conditions. It does not reveal both possible outcomes for one request. Observational adjustment instead needs assumptions such as consistency, conditional exchangeability, and positivity: the action must be well specified, measured covariates must remove action–outcome confounding, and each relevant group must have support for the actions being compared.
Prediction creates feedback
Acting on predictions can also change later data. Prices, traffic, reviewer decisions, and alerts can alter the inputs and labels collected for the next model. An interface that encourages reviewers to approve model suggestions can feed model-influenced decisions back as apparent truth; an independent judgment step can reveal disagreements, though it does not guarantee correct labels.
Four claims, four evidence burdens
| Claim | Evidence needed |
|---|---|
| The model forecasts accurately | Independent, representative outcomes scored with a defined metric |
| The forecast supports a useful decision | Validated probabilities or rankings plus consequences, capacity, and alternatives |
| The action changes the outcome | Randomized evidence or observational identification with defensible causal assumptions |
| The complete system helps in operation | End-to-end evaluation of outcomes, side effects, adoption, and changed conditions |
Open questions
How can useful epistemic uncertainty be estimated when several internal uncertainty representations produce the same predictive distribution? Progress would require methods whose uncertainty distinctions are identifiable, empirically connected to future errors, and validated after realistic distribution changes.
How should adaptive development reuse valuable failures without converting every benchmark into training data? The challenge is preserving regression tests while obtaining an honest estimate of performance on the intended population. Progress would combine versioned development sets, fresh independent cases, and reusable-holdout methods whose sampling and query-budget assumptions are actually enforced.
How can teams measure the causal benefit of model-guided actions when deployment changes who receives an action and which outcomes become observable? Progress would require explicit intervention definitions, support for credible comparisons, measurement of feedback effects, and evaluation beyond predictive accuracy.













































