Field of application
Scope follows the outcome, not the technology, and five life cycle events bring a system into the process.
What clause 1.4 asks
The document does not care which computational method a system uses. Rules, statistics, learned models and other approaches are treated the same way. What brings a system into the document is its effect: if it takes part in choosing, allocating, ordering or deciding, or in another process that can leave some parties with a different result from others, it is covered. Five moments call for the work to be done again: a new build, a move to data unlike the training data, use in a setting that is new, a change to the system, and retirement. The document does not say that every difference is wrong. Some differences are deliberate and necessary, and the work is to separate those from the differences that cause harm and to make the separation visible. Because the setting shapes what counts as harm, the document offers a method that can be adjusted rather than a closed list of banned criteria.
Why it matters
This clause is the scope engine for the whole product. It stops two common errors. The first is treating bias as a machine learning problem, which lets a rules-based eligibility engine escape review. The second is treating the work as a one-off approval, which lets a model drift or move into a new country without a new review. The clause also protects wanted bias: a search ranking that matches the query is biased on purpose, and a fraud rule that treats high-risk transactions differently is doing its job.
What good looks like
Build the inventory from outcomes, not from model names. For each system, record the parties who can receive different outcomes and the five trigger events. Then write a short justification for each wanted bias and the boundary within which it is acceptable. Review the inventory whenever a trigger event occurs, not only at the annual cycle. A system in decommissioning still needs a bias record, because the retirement decision can affect the people who relied on it.
Evidence an assessor asks for
The assessor will ask why a system is in or out of the inventory. A list built from the model register alone will usually miss a vendor rules engine and an inherited spreadsheet scorecard.
- System inventory One row per algorithmic system, with the decisions it makes and the parties affected
- Trigger log A dated entry for each of the five events, including decommissioning
- Wanted bias rationale The operational reason for each intended differential treatment, with its limit
- Context note The social and societal context that makes a difference wanted or unwanted
Where it commonly fails
- Only machine learning models are inventoried
- A system moved to a new country without a new context review
- Wanted bias is never written down, so every difference looks like a defect
What to do before publication
Run the inventory against the five triggers before the clause 4 work. A system with no trigger event and no differential outcome can be recorded as out of scope with the reason.