Outcomes
The team knows the contents of the bias profile and the boundaries of acceptability for the system.
What clause 4.5 asks
The step ends when the team can explain the profile and the limits without reading from the file. The document is not the outcome; understanding is. That understanding is what lets later steps make judgement calls about data, stakeholders and risk.
Why it matters
An outcome is not the same as a deliverable. A team can hold a profile document and still not know what is in it. The clause asks for understanding, which is tested by whether the team can explain the requirements and boundaries without reading the file. That understanding is what lets the later clauses make judgement calls, for example when a data set is representative enough or when a risk is acceptable.
What good looks like
Hold a short read-back at the end of the clause 4 work. Each role explains the requirement or boundary it owns, in its own words. Record the questions that could not be answered and send them back to the action that should have answered them. Then baseline the profile and start clause 5 with a known version.
Evidence an assessor asks for
The assessor will ask a team member to explain a boundary. A team that can only point to the document has a document, not an outcome.
- Read-back record The date, the participants and the requirements each role explained
- Open questions The questions the read-back could not answer, with the action they return to
- Baseline The profile version that the team confirmed it understands
- Briefing pack The short explanation a new team member receives
Where it commonly fails
- The read-back is skipped and the profile is filed
- Only the author can explain the boundaries
- Open questions are closed without an answer
What to do before publication
Run the read-back before the baseline. It is cheaper than discovering the misunderstanding at the clause 8 assessment.