One page per clause
The requirement in our words, the evidence an assessor asks for, the common gaps and what to do before publication.
Open the registerAll 61 clauses, from scope to ongoing evaluation
Every page is written from the published IEEE edition behind the joint ISO/IEC/IEEE project. Each one states the requirement in our words, the evidence an assessor asks for, the common failures and the work to do before publication. Start where the system is, not where the page numbers are.
61 clause records269 evidence lines201 failure lines23,923 authored words
1. Overview and scope
| Clause | Record | The answer in one line |
|---|---|---|
| 1.1 | Scope | The standard is a creation-time process for considering bias in an algorithmic system, not a live audit or a certificate. |
| 1.2 | Purpose | The purpose is to let a creator define, measure and communicate how bias is used in the system, and to show the practices behind that claim. |
| 1.3 | Word usage | Only shall creates a requirement. Should is a recommendation, may is a permission and can is a capability. |
| 1.4 | Field of application | Scope follows the outcome, not the technology, and five life cycle events bring a system into the process. |
| 1.5 | Limitations | The standard covers creation. It does not detect or evaluate a problematic algorithm in live use, and it does not track or certify. |
| 1.6 | Organization of the standard | Six normative clauses run around one record, the bias profile, and every clause is revisited as the system changes. |
| 1.7 | Audience | The standard is written for suppliers, procurers, developers, maintainers, auditors, operators, users and managers, including in-house teams. |
| 1.8 | Conformance | A project or organization can claim conformance, use the standard in a contract, or adopt it in-house. None of these is a certificate. |
| 1.9 | Disclaimer | The standard sets minimum criteria. It does not guarantee that the system meets its mission or that no harm will occur, and it does not replace legal or ethical duties. |
2. Normative references
| Clause | Record | The answer in one line |
|---|---|---|
| 2 | Normative references | There are no normative references. Nothing else has to be read for the standard to apply. |
3. Definitions
| Clause | Record | The answer in one line |
|---|---|---|
| 3.1 | Definitions | The clause defines the algorithm, the system, bias, the bias profile, the stakeholder types, protected and sensitive attributes, and the three drift terms. |
| 3.2 | Acronyms and abbreviations | The clause fixes the short forms, principally AIS, and keeps the rest of the document readable without a decoder. |
4. Requirements for bias consideration
| Clause | Record | The answer in one line |
|---|---|---|
| 4.1 | Purpose | Clause 4 starts the bias work by fixing the system's bias requirements and boundaries before any data or model work. |
| 4.2 | Inputs | Clause 4 needs the business requirements and the case for the system, the design documentation, and the governance material that frames the work. |
| 4.3 | Outputs | Clause 4 produces the bias profile with its requirements and boundaries, and a values statement that carries the bias considerations. |
| 4.4 | Actions | Eight actions turn the inputs into the profile: collect records, represent sensitive attributes, set accountability, list life cycle requirements, build the profile, write values, set boundaries, and establish procedures. |
| 4.5 | Outcomes | The team knows the contents of the bias profile and the boundaries of acceptability for the system. |
5. The bias profile
| Clause | Record | The answer in one line |
|---|---|---|
| 5.1 | Purpose | The bias profile is the through-life record of the bias work, built from data, model and code and kept across every iteration. |
| 5.2 | The bias profile and the system life cycle | The profile keeps the initial, intermediate and most recent versions of every task document, and every clause reads and updates it. |
| 5.2.1 | Requirements for bias consideration | The clause 4 requirements enter the profile as the first entry and are revisited at every iteration. |
| 5.2.2 | Stakeholder identification in the life cycle | Stakeholder identification has two goals, and it depends on resourcing, representation and the system's relation to systemic and cultural bias. |
| 5.2.3 | Data representation in the life cycle | The data work maps the system's data to the identified stakeholders and records provenance, governance, collection and the biases the data can cause. |
| 5.2.4 | Risk and impact assessment in the life cycle | The risk and impact assessment is resourced for the full life cycle and takes the stakeholder and data work as inputs. |
| 5.2.5 | Evaluation in the life cycle | Evaluation is resourced across the life cycle and begins with how the system uses data and whether it is a solution in its context of use. |
6. Stakeholder identification
| Clause | Record | The answer in one line |
|---|---|---|
| 6.1 | Purpose | Clause 6 identifies every stakeholder and their attributes so the later steps can define the groups for which bias is examined. |
| 6.2 | Inputs | The inputs are the business case with its first stakeholder record, the technical requirements, the context of use, other necessary information and the bias profile. |
| 6.3 | Outputs | The output is an updated profile with five entries: the reference set, the order of importance, the type, the attributes, and the protected attributes with their rationale. |
| 6.4 | Actions | Ten actions record the method, apply diverse perspectives, identify both stakeholder types and their attributes, find protected attributes, test for bias, update clause 4, measure influence and feed clause 8. |
| 6.5 | Outcomes | The team has a stakeholder reference set that is used across the life cycle, with types, attributes and protected attributes identified. |
7. Data representation
| Clause | Record | The answer in one line |
|---|---|---|
| 7.1 | Purpose | Clause 7 records the types and sources of the data and shows how fully the data represents the identified stakeholders. |
| 7.2 | Inputs | The inputs are the business case, the data and metadata, and the stakeholder section of the profile. |
| 7.3 | Outputs | The outputs are the data map, the metadata and an updated bias profile. |
| 7.4 | Actions | The actions decide what data to include, record the reasons, describe the collection conditions, explore the data for bias and map it to the stakeholders. |
| 7.4.1 | Decisions about data | Every decision to include, remove or leave out data or attributes is recorded with its reason, concern and limitation. |
| 7.4.2 | Metadata | The metadata records the type of each feature and the conditions under which each data set was collected or created, with the reasons for each choice. |
| 7.4.2.1 | Collection and creation conditions | The record covers the source, jurisdiction, reason, first use, collection method, consent, opt-out, timing, anonymization and relation to other data, plus proxies, synthetic generation, fitness and quality. |
| 7.4.2.2 | Data exploration | The data is examined for bias before the system is implemented, including sensitive and non-sensitive attributes and the correlation or causation between them. |
| 7.4.2.3 | Data map | The map connects data attributes to the impacted stakeholders, is repeated after retraining, and records every imbalance. |
| 7.5 | Outcomes | The team knows how the data represents the stakeholders, and that knowledge feeds the risk assessment, the evaluation and the mitigation work. |
8. Risk and impact assessment
| Clause | Record | The answer in one line |
|---|---|---|
| 8.1 | Purpose | The risk and impact assessment starts at the business case, runs across the life cycle and is updated at every change. |
| 8.2 | Inputs | The inputs are the current versions of the profile, values statement, stakeholder work, data representation and evaluation, plus the business case, design, deployment strategy and retirement plan. |
| 8.3 | Outputs | The outputs are an updated bias profile and an initial or updated risk and impact assessment. |
| 8.4 | Actions | The actions start the assessment at the business case, update it at changes, build two inventories, assign accountability and record the signature. |
| 8.5 | Outcomes | The team identifies risk levels and treatment tasks, uses them continuously, and the owner formally accepts the assessment. |
9. Evaluation
| Clause | Record | The answer in one line |
|---|---|---|
| 9.1 | Purpose | Clause 9 evaluates the system as a whole for bias through a design and output evaluation and an ongoing evaluation. |
| 9.2.1 | Evaluation of design and outputs: purpose | The design and output evaluation is part of design and development, and more than one evaluation is permitted as the product matures. |
| 9.2.2 | Evaluation of design and outputs: inputs | The inputs are the requirements and design documentation, the stakeholder, data and risk sections of the profile, the test data sets and the UI and UX design documentation. |
| 9.2.3 | Evaluation of design and outputs: outputs | The outputs are an updated profile and an evaluation document with nine required items, from metrics and scenarios to mitigation and optimization results. |
| 9.2.4 | Evaluation of design and outputs: actions | The actions examine the records, the data pre-processing, the testing, the mitigation and optimization effects and the UI and UX design. |
| 9.2.4.1 | Examine the records | The evaluation begins by examining the requirements, the data documentation and the design documentation. |
| 9.2.4.2 | Examine data pre-processing | Every pre-processing step is examined for bias in the method and for bias it adds to the data set, and the effect on outcomes is recorded. |
| 9.2.4.3 | Testing | Testing selects scenarios where bias is a risk, sets granularity, chooses a metric with reference values, records each test and justifies the method and its interpretation. |
| 9.2.4.4 | End of the evaluation | The end review compares human and system decisions, tests bias added by mitigation and optimization, and checks the UI and UX against every stakeholder attribute. |
| 9.2.5 | Evaluation of design and outputs: outcomes | The team knows how to evaluate bias in the design and outputs, and the evidence is in the profile and the evaluation document. |
| 9.3.1 | Ongoing evaluation: purpose | Ongoing evaluation looks for drift and for changes that affect bias during operation and decommissioning. |
| 9.3.2 | Ongoing evaluation: inputs | The inputs are the requirements and design documentation, the stakeholder, data and risk sections of the profile, and the records of the design and output evaluation. |
| 9.3.3 | Ongoing evaluation: outputs | The outputs are an updated profile and an updated evaluation document with the monitoring list, the procedure, the recurrence rationale and the drift plans. |
| 9.3.4.1 | Set up the ongoing procedure | The procedure lists what to monitor, how each item is evaluated, the rationale for recurrence, a post-mitigation cycle and stakeholder feedback. |
| 9.3.4.2 | Each iteration of the ongoing evaluation | Each iteration checks data drift, concept drift and other drift, records the plan for each and watches for reinforcement of external bias. |
| 9.3.4.3 | End of each iteration | At the end of each iteration, the team revisits the requirements, stakeholders, data representation, risk assessment and evaluation procedure. |
| 9.3.5 | Ongoing evaluation: outcomes | The team knows how to run the ongoing evaluation for bias and has the record to show it. |
Reading the verbs. Only "shall" creates a requirement. "Should" is a recommendation, "may" is a permission and "can" is a capability. The register keeps the verb visible so a finding and a suggestion are not confused. Clause 1.3.
THE RULES THIS IS BUILT FROM
The rules this is built from
Read from the real rules, not invented. Every clause answer on this site points to the official rule behind it, so you can check any line yourself. The register holds 67 records, 269 evidence lines and 201 common failure lines. The dates come from the ISO record. The substance comes from the published IEEE edition behind the joint project.
61 CLAUSES
6 ANNEXES
Guidance, clearly labelled
Annexes A to F are informative. Each page says so, because a finding cannot rest on guidance alone.
Open the annexesONE STAGE RECORD
No invented date
Stage 40.99 is recorded on 16 September 2026. The planning date is an estimate and is labelled wherever it appears.
Read the recordThe ISO draft text is not public and is not reproduced. Each record cites the published clause it comes from. Where the public record is silent, the page says so.