Machine learning with contracts
Concrete Problems in AI Safety — refined
A perspective, drawn from software engineering analogy, of building ML systems that satisfy well-defined behavioral contracts rather than the brittle implicit contract that training and test distributions are identical.
Software engineers write contracts: explicit promises about what a component will do, checkable at its interface. Carried into machine learning, the idea exposes an uncomfortable fact, that most ML systems rest on the brittle, unwritten promise that training and test data look alike.
The first section unpacks the borrowing from design-by-contract; the second shows how the reframing organizes several other ideas on this wiki, model repair among them.
Borrowing design-by-contract from software engineering
Machine learning with contracts adapts a software-engineering idea — design by contract, the practice of specifying a component's guaranteed behavior as an explicit, checkable interface — to machine learning systems. Concrete Problems introduces the perspective directly: "one would like to construct machine learning systems that satisfy a well-defined contract on their behavior in analogy with the design of software systems" (concrete-problems, §"A unifying view: counterfactual reasoning and machine learning with contracts.", p. 19). The paper's central diagnosis is that most deployed ML systems implicitly promise only one thing — that training and test distributions will be identical — and that this promise is, in the paper's own words, "extremely brittle": difficult to check and rare to hold exactly in practice. Unlike most of the concepts in its immediate neighborhood, this framing is the paper's own refinement of a borrowed analogy rather than a technique lifted wholesale from prior literature.
A reframing that organizes three other concepts
The contracts perspective does real organizing work across Robustness to distributional shift. The edge Machine learning with contracts — reframes as a specification failure → Robustness to distributional shift recasts the whole problem: distributional shift is not fundamentally a statistical estimation difficulty but a specification failure, and the fix is not a better estimator but a system built against a weaker, explicit, checkable contract. Paired against Counterfactual reasoning in Counterfactual reasoning — is the descriptive counterpart to → Machine learning with contracts, the two concepts split the problem along a diagnosis/prescription line — counterfactual reasoning explains what shift is, contracts specify what a fix must guarantee. Partially specified models is offered as one route to a weaker, checkable contract, requiring distributions to match only on the pieces of the model that are explicitly specified rather than everywhere; Reachability analysis and Model repair supply two more, and the edge Machine learning with contracts — is restored post hoc by → Model repair singles out model repair as the only one of these that operates after training, restoring a violated contract on an already-trained model rather than constraining the search that produced the violation. All four edges sit in the Before the fact or after: when a safety property gets enforced connective theme. The concept is a child of Robustness to distributional shift and parent of Model repair, anchoring the Reframing distributional shift as broken contracts and causal structure theme within the Distributional shift: relax the statistics, or rewrite the contract supertheme.