Scope
The standard is a creation-time process for considering bias in an algorithmic system, not a live audit or a certificate.
What clause 1.1 asks
The document is written for the people who build algorithms and models. It covers systems that use symbolic methods, subsymbolic methods or both. Three pieces of work are named: choosing the data sets, setting out the limits within which the system was designed and validated and telling users about those limits, and helping users read an output correctly so that a mistaken reading, such as treating a correlation as a cause, does not become a source of unfair treatment. The focus is creation. Examining a system that is already running, to find a bad algorithm, is not what this document does.
Why it matters
The scope tells a reader what kind of document this is. It is a design and development process standard. It assumes the organization can still change the system, its data or its boundaries. That is why the process is organised around the life cycle and around a record that is built as the work proceeds. A team that arrives after deployment with a request to certify a running model is outside the intended use, even if some of the clauses still help.
What good looks like
Write a scope note for each system before any clause work. Name the system, the decisions it supports, the people it affects and the boundary conditions under which it was validated. Then map the three scope elements to owners: data selection criteria, boundary communication, and user expectation material. If the organization cannot name the person who owns each of the three, the scope note is not finished.
Evidence an assessor asks for
An assessor will start with the system boundary. If the boundary statement is missing, the assessor cannot tell whether the evidence that follows is in scope, and every later clause becomes arguable.
- Scope note A dated note for each system naming its decisions, affected parties and validated boundary
- Data selection criteria The written criteria used to accept or reject a data set, with the owner
- Boundary statement The application boundaries the system was designed and validated for, in language a user can act on
- Expectation material The user-facing explanation of what an output does and does not mean
Where it commonly fails
- The scope is read as machine learning only, so a rules engine that ranks people is left out
- The boundary statement exists in a design document but was never communicated to users
- User expectation material is a disclaimer rather than an explanation of what the output means
What to do before publication
Draft the scope note and the boundary statement first. Both are inputs to clause 4.2 and both are needed before the data work can be judged against a purpose.