Bias requirements and the bias profile

This page covers the footing the rest of the standard stands on: the bias-consideration setup (Clause 4) and the bias profile (Clause 5). It maps the per-system requirements MRF-440 (setup and boundaries of acceptability) and MRF-441 (the bias profile).

The order matters. The setup activity establishes how this system will consider bias and what "acceptable" means for its context; the bias profile is the record everything else writes into. Stakeholder identification, data representation, risk assessment, and evaluation all consume and update these two artifacts.

Bias-consideration setup (Clause 4)

During requirements setting, the team establishes how the AI system will consider bias within its specific context of use, and it revisits that as circumstances warrant across the lifecycle. The activity is where the standard's central distinction is drawn for the first time: wanted bias, which helps the system meet its objectives, is separated from unwanted bias, which impedes them or harms stakeholders.

The setup produces three auditable outputs:

• An initial bias profile — the first version of the through-life record described below.
• A values statement — a combination of organizational values with the system's early bias considerations. It is per system, and it draws on organization-level inputs (see Organizational values and bias policies on the org side).
• Proposed boundaries of acceptability — the context-specific limits for what bias is acceptable, taking into account factors the standard names such as inclusion, accessibility, disability, and culture.

Producing those outputs requires several inputs and decisions, all recorded:

• Gathering business requirements, design documentation, and governance materials as the starting evidence base.
• Naming the sensitive attributes the system must represent and advocate for, and sourcing external advocates where those perspectives are absent from the team.
• Settling an accountability structure with a defined interface to the organization's governance framework.
• Identifying further requirements across the lifecycle, up to and including decommissioning.
• Establishing clear processes and methods for considering bias, suited to that context.

The point of the setup is not to fix thresholds. It is to make explicit, and to justify, how this particular system will handle bias — so that every later activity has a documented footing to work from.

Wanted versus unwanted bias

The setup is where teams first commit the wanted/unwanted distinction to the record. Treating all bias as something to remove misreads the standard: a recommender biased toward a user's interests is functioning as intended. What the standard demands is that the intended (wanted) bias is stated and justified, and that unwanted differential impacts are identified and worked against.

In Modulos, MRF-440 carries this activity. Its outputs are captured through the new control MCF-660 (bias requirements, values statement, and boundaries of acceptability, with each element independently falsifiable), alongside reused controls for requirements and design documentation (MCF-213, MCF-232).

The bias profile (Clause 5)

The bias profile is the enduring repository of a system's bias considerations, and it is the piece most worth understanding early because everything else writes into it.

The profile holds every version — from first draft to current — of the documents each bias-consideration activity produces: requirements setting, stakeholder identification, data representation, risk assessment, and evaluation. Crucially, it also captures the level of bias risk judged acceptable under the circumstances prevailing when each decision was made, so a later reader can see not just what was decided but the context and accepted risk at the time.

Two properties make it a living dossier rather than a report:

• It is fed both forward and backward. Outputs from one activity inform later stages, and findings from later stages propagate back into earlier records.
• It is revisited on triggers, not on a fixed cadence. The activities are revisited at appropriate points in the lifecycle, and whenever feedback or changed circumstances warrant, so bias risk and stakeholder effects are reassessed as the system and its context evolve.

The profile also carries the wanted/unwanted distinction explicitly, so the record always shows which bias is intended for the system to achieve its objectives and which is being worked against.

The test of a good bias profile is the auditor's question: why did you conclude this system is fair enough to deploy? A profile that answers that question with linked, versioned evidence is doing its job.

In Modulos, MRF-441 carries the profile, and it is the flagship control MCF-661: a version-preserving, through-life repository with immutable version history, the accepted-risk context at each decision, update triggers, and links to each underlying artifact — never a narrative summary that stands in for the evidence.

Cross-framework fit

Preview

• ISO/IEC 42001 — the values statement and accountability structure align with the management system's policy and roles-and-responsibilities machinery; the bias profile aligns with the documented-information and impact-assessment record.
• EU AI Act — the boundaries of acceptability and the bias profile give a documented footing for the Article 10 duty to examine datasets for possible biases in high-risk systems, and for the record-keeping expectations around it.
• NIST AI RMF — the setup activity corresponds to the Govern and Map functions; the bias profile is the traceability artifact the Manage function relies on.

Related pages

IEEE 7003 overview

What the standard is, wanted-versus-unwanted bias, and the MFF-25 / OFF-25 split

Stakeholders and data representation

The next stages: who is affected, and how the data represents them — MRF-442–444

Risk, evaluation, and monitoring

Risk and impact assessment, design and output evaluation, and drift monitoring — MRF-445–447

Operationalizing in Modulos

The OFF-25 / MFF-25 rollout, control library, and evidence model

Source attribution

The authoritative source is IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations, published by IEEE. This page paraphrases Clauses 4 and 5 and references them by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes are Modulos template identifiers, not IEEE references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024.