Data, ethics and review

Your colleague does not need a clever prototype. They need the next research brief, evidence summary or analysis result, and a way to tell whether they may use it. The difficult moment comes when your component works on invented examples but the next input contains information about real people. A small test is still a transfer. A polished result is still capable of harming someone.

Continue the project you have already chosen. In this book you will make its AI component inspectable and handover-ready: what goes in, what comes out, who may use it, which decisions are still missing, and what your colleague does when the safe answer is to stop. The review section supports that working component; it is not a replacement project.

1. The analysis works, but the approval is older than the tool

Imagine an analysis that groups free-text recovery comments into themes. It performs well on synthetic records. The real research dataset replaces names with participant codes, so the team calls it pseudonymised. The proposed model is reached through a US-hosted API, but the study's ethics approval predates that service and describes analysis inside the institution's controlled environment.

A colleague suggests sending ten coded rows as a small test. You stop before uploading them. Codes can be reconnected to people, comments may contain health details and indirect identifiers, and neither the provider's subprocessors nor retention terms appear in the existing review record. Enterprise, pseudonymised, and already approved do not answer whether this specific transfer and output use are permitted.

Stopping the transfer need not stop useful work. You can build the input boundary, rehearse the output review on invented material, preserve the existing manual route, and prepare the decisions that would allow the component to progress. Your colleague should be able to open the rehearsal, understand the proposed result and see why it is not yet a live research finding.

The next deliverable combines that bounded component with a decision-ready description of its data, purpose, service, account, locations, agreements, retention, affected people, safeguards and output use. Until the required accountable reviewers record their decisions and their conditions are implemented, the proposed new live-data route remains STOP. That does not revoke a separate, already approved workflow; keep it available rather than quietly replacing it with the prototype.

The recovery-comment story is optional. Your project might instead produce a recurring public-literature briefing, a checked methods digest, an aggregate survey report or another useful result. Choose the smallest component a real colleague could depend on. Public material still needs source, licence and output checks, but do not invent participant-data risks or an ethics application where the responsible local route determines they do not apply.

2. After this you can

• Build a usable boundary around one recurring result: permitted input, candidate output, human acceptance and a stopped path your colleague can follow.
• Classify and map proposed inputs and outputs from source to deletion without treating a data label as permission.
• Compare a new AI use with the recorded purpose, consent or notice, ethics approval, data-protection assessment, contracts and security decision that already exist.
• Prepare the facts reviewers need: necessity, data fields, processor location, agreement, retention, access, re-identification capability, output use and safeguards.
• Route a proposal to ethics, privacy or data protection, information governance, security, procurement, clinical safety or another accountable owner instead of deciding alone.
• Recognise when health data, minors, vulnerable groups, free text, international processing or an output affecting treatment or opportunity demands a different or additional approval path.

3. Open the project, not a new assignment

You need the component or bounded AI-assisted step you have been building, an approved text editor, the file manager or document workspace your team already uses, and the current review route for the project. An approved model interface is needed only if you will run the optional synthetic rehearsal through a model. There is no reason to buy a new service for this book.

The neighbouring Reproducibility with AI in the loop supplies the model, prompt, version, settings, input and output record. This book asks a different question: even if a colleague can repeat the procedure, is this data flow and use permitted, and can they keep it inside its conditions? For an unattended component, Rules for things that run without you supplies the execution limits and stop controls. Here those controls must agree with the research and data-review decisions.

Gather the applicable current protocol, ethics decision, consent materials or participant information, privacy notice, data-management plan, information-classification rule, retention schedule and contracts. Locate the organisation's routes for ethics, privacy or data protection, information governance, security, procurement, records, incident response and, where relevant, clinical safety. Identify the service owner or principal investigator and the roles authorised to decide whether the proposal may proceed. A small public-source project may need fewer routes; record who confirmed that scope, not your guess.

In your approved project workspace, open the existing component instructions in the text editor. Add a section named AI component: review and handover, or create ai-review-and-handover.md alongside the instructions if there is no suitable section. Do not replace the approved protocol. If your organisation requires a form, use its corresponding fields as the authoritative review record and link to it from the component instructions. Do not create a competing approval record in Markdown.

Begin with four concrete lines:

Recurring result: [what the colleague needs, and when]
Consumer and next action: [role, result location, permitted use]
Component version and review record: [existing version/locator]
Proposed live-data route: STOP pending required decisions

For example, an entirely synthetic rehearsal could say: "A weekly themes brief for a research coordinator planning the next coding meeting; not a diagnosis, participant contact list or treatment recommendation." This identifies the dependency. A component that produces themes but gives nobody a permitted next action is not ready for handover.

Use invented, public or explicitly approved material within its authorised boundary. Do not paste participant or patient records, study free text, employee comments, customer cases, identifiers, linkage keys, unpublished results, credentials, contracts or review documents into an unapproved AI service. You can describe the real project's fields and proposed flow in its protected review system without uploading those records to a model. Keep identifying details out of the learning artifact; field names and risk descriptions usually explain the proposal better than a real row.

This book is workflow guidance, not legal, clinical or ethics advice. Terms such as personal data, health data, anonymisation, controller, processor, consent, amendment and impact assessment can have specific meanings under the rules that apply to your project. Use the language and decision process required by your institution, organisation, review body, contract, profession and jurisdiction.

4. Make the proposed processing visible

A label is not a permission

Start with what would actually enter the component, not the vendor's security page or the model's usefulness.

Removing a code column may leave a rare diagnosis, date, job, site or quotation that singles someone out. Do not ask a destination model to anonymise material it was not permitted to receive. Minimise rows, fields, precision, text, outputs, recipients and retention.

Pseudonymisation is useful precisely because it can separate routine analysis from direct identity. It does not make every recipient harmless. Ask who holds the key, who can combine the released fields with other information, and what the output might reveal without any key at all. The ICO's UK guidance distinguishes pseudonymisation from anonymisation; it also currently warns that the guidance is under review following legislative changes. Treat it as contextual guidance, not a universal clearance certificate.

Draw the route, including the copies nobody sees

A model call is not simply dataset -> answer. Draw content and recoverable representations through deletion:

approved source -> minimisation/pseudonymisation -> application or connector
       -> API gateway -> model provider -> named subprocessors/regions
       -> output, safety logs, caches, backups and monitoring
       -> approved reviewer -> accepted result or rejection -> deletion/archive

separate linkage key ------------------------X never sent to the model route

At each stage, record system, location, fields, purpose, access, retention, deletion and evidence owner. Distinguish headquarters, processing region, support, subprocessors and backups. Write unknown - owner to confirm when evidence is absent. A setting in an application may describe one copy, while a governing agreement describes another; neither should be silently extended to every stage in the diagram.

In the component's existing input configuration, select the allowed fields explicitly. In the review document, explain why each is needed. These are different jobs: the input selection constrains what the component can receive; the document explains why the constraint is justified. A prompt can describe the expected fields, but cannot prevent a transfer that has already happened. A sentence saying "do not use identifiers" is not a technical restriction if the connector still exports every column. If the present tool cannot exclude the prohibited fields, keep that route disabled and use a separately prepared, authorised input instead.

Compare the change, not just the project title

Compare the flow with the actual protocol, consent or notice, ethics decision, privacy assessment, security decision, contract and retention plan. Summarise the delta:

Previously approved: [data, purpose, systems, recipients, locations, outputs].
Proposed change: [new AI component and every changed fact].
Unchanged: [facts that genuinely remain fixed].
Decision requested from: [named review route and accountable role].
Live-data status: STOP until required decisions and conditions are recorded.

The locally authorised route determines whether the delta needs an amendment or modification, impact assessment, contract, security or information review. Do not assume this is always a decision for an ethics committee alone. For example, the UK Health Research Authority's current project-change guidance assigns modification categorisation to the sponsor and points to IRAS for notification and submission instructions. That example does not determine the route for another jurisdiction or project. Consent alone does not replace the other applicable decisions.

Escalate health or clinical use; minors or vulnerable groups; biometrics, genetics, linkage or covert inference; uncertain external processing; unattended scale; and output affecting treatment, employment, finance, safety, publication or opportunity. Human review requires a qualified person with source evidence, rejection criteria, time and stop authority.

Give reviewers the owner and requested decision; purpose; affected people and fields; minimisation; complete flow and processor evidence; retention and reuse; model and prompt record; prohibited uses and controls; alternatives and unresolved questions. Use the official decision fields where they exist. In a working summary, APPROVE, REVISE and STOP can distinguish states, but only the authorised decision-maker supplies the decision. Copying an approval into your instructions must retain its scope, version and conditions.

Turn a condition into an action your colleague can perform

"A human checks the output" is too vague to build. Name the person or qualified role, what they open, what they compare, what they reject and where accepted work goes. The colleague consuming an aggregate report need not be the person authorised to read its row-level source. Keep those permissions separate.

For a manually operated component, a small release boundary may be enough: the model writes a candidate in a restricted working location; the authorised checker compares it with the permitted source; only the accepted version goes to the colleague's normal result location. Use your existing folders, document states or review features. Do not add a second tracking application merely to name these states. If the tool publishes automatically, the human boundary is not real until automatic delivery is disabled or an actual approval gate is configured and checked.

Keep the previous accepted result unchanged while checking a new candidate. Label the new result with its source/run version, checker and date, limitations and permitted use. If the new run fails, say that the current result is unavailable. A previous result may be offered only where its age and continued suitability are explicit; silently presenting last week's report as this week's is a new error, not recovery.

5. The worked example: one review pattern, two settings

The two cases below are optional, entirely synthetic practice. Course Model API, its regions, agreements and retention settings are fictional; they do not describe a real provider. Both teams have a useful prototype and an older approval. Both submit the same fields and keep live data out while decisions are pending. Adapt the pattern to your own project rather than adopting either dataset as a required assignment.

Lab framing: coded recovery comments

Project LANTERN-LAB studies how fictional adult participants describe recovery after a routine procedure. Its existing protocol permits coded survey analysis in the university research environment. The proposed component would assign themes to one optional free-text response. The source table has 120 rows. Names and contact details are held in a separate recruitment system, but the research team can reconnect the study code. Comments can mention symptoms, a clinic, dates, relatives, work and rare events. The material is therefore treated as pseudonymised participant health data with risky free text, not anonymous text.

The prototype used twelve invented comments and made no care or eligibility decision. The proposed service is Course Model API through an institution-managed account. Its fictional primary processing region is the United States; subprocessor and support-access evidence is not yet attached. The old ethics decision names local statistical analysis and does not describe this provider. The principal investigator therefore asks the responsible institutional route whether an amendment or other determination is required, while privacy, information governance, security and procurement review the route. The team does not send one "test" participant row while waiting.

The design is narrowed before review. A local approved preprocessing step removes study code, exact dates, clinic names, names, contact details, relatives' details and unnecessary quotations. It converts each approved comment into controlled phrase categories where the research question allows. The linkage key never enters the analysis workspace or model call. Output contains a row number generated for the run, proposed theme, supporting source span, uncertainty flag and HUMAN_REVIEW; it cannot write to a clinical record, contact a participant, determine treatment or change study inclusion. A trained researcher compares every theme with the minimised source, rejects unsupported inferences and reports only approved aggregate findings.

Minimisation can change what the analysis can honestly claim. If dates and context have been removed, the model must not reconstruct a recovery timeline. If controlled categories replace the prose, the supporting evidence is the retained category or phrase, not an invented quotation from the original. The human checker must be able to reject a plausible theme whose support was lost during preprocessing. Removing sensitive detail is not a licence to fill it back in by inference.

The intended recurring result is an aggregate themes brief for the next research coding meeting. The coordinator opens that brief, sees the accepted themes and unresolved coding questions, and decides what the researchers should inspect next. They receive no linkage key and no permission to contact participants. If the AI component is stopped, the team uses its already approved manual coding route, or records that the brief is delayed if no suitable fallback exists.

Even with those controls, the proposed live route remains STOP. The reviewer may require a different processor, local model, revised information, further minimisation, deletion evidence, a new risk assessment or no AI use. The team has reduced the proposal; it has not approved it.

Company framing: coded employee-support comments

Project LANTERN-COMPANY seeks aggregate themes in a fictional voluntary employee-support survey. The existing notice covers collection and internal reporting, but the proposed AI processor and individual-level inference were not specified. The export replaces names with staff codes, while HR retains the mapping. Comments can reveal mental health, disability, caring responsibilities, location, team, grievances and manager identity. Managers could often recognise a writer from combinations. The dataset is treated as pseudonymised personal data containing sensitive free text.

The prototype again uses twelve invented comments. The same fictional US API and managed account are proposed, and the same processor evidence is missing. The fictional builder, Jonas, routes the design to the company's privacy or data-protection owner, information security, procurement or vendor management, HR data owner, employee-relations or worker-representation route where applicable, and the AI review group. These are not decorative sign-offs: each route answers a different question about expectations, necessity, contracts, access, impact, security and worker safeguards.

The narrowed design excludes staff code, names, contact details, exact dates, team names, precise locations, manager names, case references and raw quotations. It reports only broad themes above a minimum aggregation threshold chosen by the accountable reviewers. No row-level score is exposed to a manager. Output cannot influence performance, promotion, discipline, absence management, access to support, redundancy or recruitment. An authorised analyst checks themes against the approved minimised source, searches for small-group disclosure and suppresses unsafe aggregates. Employees retain the organisation's existing contact, correction, objection, complaint and incident routes as applicable; the review determines whether further notice or participation safeguards are needed.

The recurring result is a restricted aggregate service-improvement brief, not a dashboard for identifying unhappy employees. Its recipient can discuss broad support needs, not drill into individual comments. If a requested breakdown would expose a small group, the analyst withholds that breakdown and records why. A threshold is a control to assess, not a magic number: several apparently safe tables can still reveal a small group when compared.

Again, these safeguards do not produce permission. The current state is STOP until the named reviewers record decisions and every condition is reflected in the system.

The shared submission section

Each team completes one section in its own approved review system. This filled example shows the level of specificity expected while keeping the cases synthetic. Read each project column as a complete submission if the table is easier to follow one case at a time.

The strength of the section is not that it promises perfect anonymisation or perfect model accuracy. It tells reviewers what is known, what is missing, how people could be affected and exactly where the system is prevented from acting.

Rehearse the handoff without pretending it is live

Use your own component's format. If a tiny themes example helps, the following three lines are invented from scratch, not disguised participant records:

SYNTHETIC REHEARSAL - NOT RESEARCH FINDINGS
demo-01: The printed instructions were easy to follow.
demo-02: I could not find the number for asking a question.
demo-03: I have nothing to add.

In the approved file manager, create a new rehearsal location separate from live inputs and accepted outputs. In the text editor, save these lines as synthetic-input.txt, or use a permitted fixture already matching your component. Keep live connectors and automatic distribution disabled; if you cannot establish that separation, rehearse the review manually instead of running the component.

If an approved assistant is available, open a new conversation in its actual approved account. Do not attach the project folder. Paste only the invented lines and the following bounded request, adapting the output shape to your existing component:

This is synthetic rehearsal material, not research data.
For each demo ID, propose a descriptive theme supported by its text.
Return: demo ID | theme or NO_THEME | exact supporting words | HUMAN_REVIEW.
Do not infer a diagnosis, identity, demographic attribute or cause.
If no substantive theme is supported, return NO_THEME.
Do not aggregate, publish or recommend an action about a person.

Save the returned text unchanged as candidate-output.txt in the rehearsal location and record the exposed model, date and prompt under your existing T15-L02 run record. The expected shape is three inspectable proposals, not a promise of exact model wording. demo-03 should not acquire a diagnosis or dissatisfaction score from "nothing to add." If no model is available, write a clearly labelled simulated candidate and rehearse the human boundary; record that model behaviour remains untested.

Open synthetic-input.txt and candidate-output.txt side by side in the editor. Compare each theme with its supporting words. Reject invented support, unsupported inferences and missing rows. Create a separate checked-result.md only for the accepted rehearsal result, with the synthetic label, source locator and remaining limitations. Do not overwrite the raw candidate to make the run look cleaner. These filenames are a concrete optional path, not a required architecture for your project.

Now make a separate candidate copy with one deliberately unsupported theme, labelled deliberate rehearsal error. Give the checker the safe source and candidate, not the answer in advance. The desired observation is that the candidate is withheld and the previous accepted rehearsal result remains unchanged. Do not plant test errors in a live shared result. A failed rehearsal is useful evidence of a boundary that still needs work; it is not an embarrassment to erase.

6. What goes wrong

Pseudonymised is treated as unrestricted

Symptom: the team replaces names with codes and sends the table through any convenient account.

Fix: classify it accurately as linkable, protect the key separately, test indirect identification, minimise fields and require approval for the exact service and purpose. Do not put the key in prompts, logs, filenames or output.

Free text bypasses the column review

Symptom: the structured fields look clean, but comments contain names, dates, diagnoses, workplaces, relatives or distinctive events.

Fix: treat the complete free-text field as sensitive until locally inspected and minimised. Prefer controlled categories or synthetic text. If meaning cannot be retained without disclosure risk, keep it out of the model route.

A consumer tool has no reviewed agreement

Symptom: a builder relies on a paid subscription, privacy toggle or vendor marketing page but cannot show the organisation-managed account, governing terms, processor role, locations, subprocessors, retention, deletion or reuse conditions.

Fix: stop. Give vendor management, privacy, security and procurement the exact service and architecture. Use synthetic fixtures while they assess an appropriate arrangement or reject the route. A screenshot of a toggle cannot establish terms it does not describe.

The old approval is stretched around the new tool

Symptom: the project title and research question are unchanged, so the team assumes external AI processing is covered.

Fix: compare the old approved flow with the proposed one and submit the delta. Let the authorised route determine amendment, new review, updated information or another outcome before live processing.

Review happens after a "small test"

Symptom: ten live rows are sent to obtain performance evidence for the review.

Fix: use synthetic data or an explicitly approved evaluation route. Review must cover the transfer that the test itself would perform. Small volume can reduce impact; it does not create permission.

Human review is only a label

Symptom: one analyst approves hundreds of opaque scores, cannot open the source and has no authority to stop delivery.

Fix: define the evidence, workload, competence, rejection criteria, escalation route and stop control. Remove the model from consequential decisions if meaningful review cannot be provided. If the checker lacks source access, do not solve that by broadly sharing protected records: use an authorised checker or stop the release.

Output risk is ignored

Symptom: the input flow is secured, but inferred health themes or staff-risk scores are shared more widely than the source data.

Fix: classify output and logs, restrict recipients, prohibit unapproved individual decisions, test subgroup and disclosure harms, and retain only what the approved purpose needs.

The builder decides alone

Symptom: the submission ends with "low risk; proceed," signed only by the person who built the prototype.

Fix: separate preparation from decision. Name the service owner and every applicable independent review route. Keep status at STOP until authorised decisions, conditions and owners are recorded.

The colleague can stop it but cannot recover

Symptom: a rejected run leaves a half-written result, and the instructions say only "try again."

Fix: prevent further delivery first. Retain the minimum permitted evidence of the failed run in the restricted workspace; preserve the previous accepted version without relabelling it as current. Tell the recipient what is unavailable and use the documented approved fallback if it remains suitable. Fix the cause before rerunning into a new candidate. If protected data may have reached an unauthorised destination, use the incident route rather than attempting to erase the event yourself. Deleting a local file does not establish deletion from a provider, logs or backups.

7. Build and hand over your project's reviewed boundary

Keep working on the same useful component. The sequence below is not a promise that institutional review fits into a timed exercise. You can finish a safe rehearsal and a decision-ready submission while the proposed live route correctly remains stopped.

1. Name the dependency and current state

In the component instructions, complete the four opening lines from Section 4. Name the accountable owner, affected people, intended output and decisions the output must never make. Identify the actual recipient and the next action they need to take. Write STOP pending review for an unapproved live route. If approval already exists, cite its exact scope and version; do not expand it to cover a new account or use.

2. Inventory what the component really touches

In the protected review location, inventory inputs field by field. Mark synthetic, public, anonymous, pseudonymised, identifying, sensitive, free text and linkage capability. Include attachments, metadata, prompts, retrieval content, output, embeddings, logs, caches and error traces. State where any linkage key exists and confirm that it is excluded from the proposed model route. Use descriptions and authorised counts, not identifying example records.

Draw the complete flow from source through preprocessing, connector, API, provider and subprocessors to output, review, retention, archive and deletion. Add location or region, access role, encryption boundary and owner at every stage. Mark facts not supported by evidence as unknown. Check the actual input selection and output destination in the component's existing configuration; do not infer them from the diagram you hoped to build.

3. Prepare the decisions, with evidence attached

Compare the flow with the existing protocol, approval, consent or participant information, notice, data-management plan, privacy assessment, security decision and contract. Write previously approved, proposed change and unchanged. Form the exact questions authorised reviewers must answer; do not answer them on their behalf.

Document the provider arrangement: exact service and account, provider role as locally defined, named subprocessors, processing and support regions, governing agreement, transfer assessment where applicable, content retention, backups, deletion, model-training or improvement use, support access and incident notification. Cite current evidence in the protected system. Record which evidence applies to the actual account and service. If it is absent, assign an owner and retain STOP; do not turn a requested setting into an observed guarantee.

Minimise the proposal. Remove fields, rows, precision, text, retrieval access, output detail, recipients and retention that the purpose does not need. Describe a synthetic-first evaluation and at least one non-AI or local alternative. Explain why any remaining personal or sensitive field is necessary rather than convenient. An alternative is meaningful when it can supply the needed result within its own approved conditions, not merely when it is labelled "local."

4. Make safeguards visible in the working path

Name who verifies outputs, the source they see, rejection criteria, prohibited inferences and decisions, aggregation or small-group controls, withdrawal/correction/complaint routes, incident handling and the stop control. If output could influence treatment, study eligibility, employment, education, finance, insurance, benefits, access or safety, route that use separately and prohibit it in the current unapproved design.

In the component instructions, identify the exact stop action available in your tool: for example, not initiating a manual call, or disabling the existing schedule through its documented control. Record the real control label and location after inspecting your own interface. There is no universal "safe mode" button. If you cannot establish how to stop automatic calls and distribution, do not enable them. Stopping new work does not necessarily cancel work already queued or revoke an output already shared; name who handles those cases.

Keep candidate output separate from accepted output, and make the fallback and its limits readable without contacting you. Use text labels for state, not colour alone. Use document headings and descriptive source links so the colleague can navigate the handover with their normal accessibility tools.

5. Rehearse a usable result and a refusal

Use a permitted fixture in the component's existing format, or the optional synthetic path in Section 6. Produce and inspect one candidate. Save the unchanged raw output and a separately checked result. Rehearse one failure at the relevant boundary: unsupported theme, prohibited field, missing source or a requested recipient outside the allowed scope. Use only safe invented material for a prohibited-field rehearsal; do not test the restriction by sending a real identifier.

Verify that the rejected candidate cannot become the accepted deliverable through the path you built. For a manual path, observe the person's withholding action; for an automated path, observe the configured block using safe data. A manual rehearsal does not prove an automated gate works. Record what was actually tried and leave untested behaviour explicit.

6. Let the colleague use the handover

Share the permitted result and instructions through the approved workspace with the intended colleague, using their authorised access rather than your credentials. Ask them to find the current state, identify the allowed next action, locate the supporting evidence they are permitted to see, and follow the stopped path. Where source inspection requires a separate authorised checker, make that handoff explicit instead of granting the recipient new access.

For the optional themes example, the recipient should be able to prepare a coding-meeting agenda from the labelled rehearsal brief and explain why it cannot be reported as a research finding. In your project, choose the equivalent useful action. Record their actual difficulty and repair the instructions or boundary that caused it. If no colleague is available, record handoff not yet observed; your own read-through is preparation, not independent use.

7. Submit and preserve the conditions

Combine the review material into the official submission section and link it to the component version. Record the prompt and model fields from T15-L02; name changes that trigger re-review, including provider, account, model, region, subprocessor, retention, purpose, population, fields, scale, recipients, automation and output use. Do not promise identical model output.

Read it as a reviewer: can you locate every unknown, owner, evidence source, safeguard, prohibited use and requested decision? Remove unnecessary identifiers. Submit only through the approved review route. Once decisions arrive, keep their conditions with the component instructions and implement them before enabling the approved live route. A submitted form, a successful rehearsal and an approval with unmet conditions are three different states.

8. Exit check

Deliver one handover-ready project component, with its linked review section, permitted demonstration result and instructions for use, stop and recovery. This may be a manually operated component; unattended automation is not required. The lab and company fixtures are optional. A synthetic rehearsal can demonstrate the boundary and handover, but must remain labelled and cannot establish live-data permission or scientific validity.

The review section must contain the owner and requested decisions; purpose and necessity; affected people; data categories and linkage capability; field-level minimisation; complete data flow; provider, account, locations and subprocessors; governing agreement and evidence status; retention, deletion and provider-reuse terms; model and prompt record; output use; applicable safeguards; human review; incident and stop route; alternatives; unresolved questions with owners; re-review triggers; and current decision state. Where a field is not applicable, give the reason and the accountable route that established the scope rather than inventing an answer.

It passes the component learning check when the colleague can use the permitted result for the agreed next step, distinguish candidate from accepted work, find the decision state and follow a demonstrated safe stop without relying on your memory. The review material must let an authorised reviewer distinguish fact from assumption, compare old and proposed flows, see why pseudonymised or free-text data remains protected, identify who can re-identify, trace input and output to deletion, understand how people could be affected, and make an informed decision through the applicable process. The learner does not fill the approval field on the reviewer's behalf.

A complete component rehearsal with unresolved review questions can pass this learning check while the live route remains stopped. If the colleague handoff or a required boundary demonstration has not happened, report it as prepared but unfinished. Do not confuse the learning result with permission to process real data.

It fails if unapproved live processing was used to prepare it; if a provider claim lacks evidence but is stated as fact; if "anonymous," "consented," "enterprise" or "human reviewed" substitutes for analysis; if consequential output use is hidden; if rejected work reaches the recipient as accepted; or if the builder treats submission as approval.

9. Rule to remember

The approval covered the study, not the tool you added later. Build the boundary your colleague must be able to keep.

10. Further reading & tools

• Taught: T15-L02 - Reproducibility with AI in the loop - records model, prompt, settings, input, output, rerun and limitations for the component described in review.
• Taught: T12-L02 - Privacy and labelling in everyday work - distinguishes anonymisation from pseudonymisation and checks free text, hidden surfaces, linkage, rights and impact before upload.
• Taught: T12-L03 - Rules for things that run without you - defines permitted actions, approvals, limits, accountability and a kill switch for unattended processing.
• Catalogued: NIST Privacy Framework (opens in a new tab) - voluntary privacy-risk guidance; it does not approve a dataset, model, transfer or purpose.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) and Generative AI Profile (opens in a new tab) - lifecycle risk-management references for mapping, measuring, managing and governing AI risks.
• Catalogued: WHO guidance on ethics and governance of artificial intelligence for health (opens in a new tab) - international health-focused principles and governance considerations; local clinical, ethics, professional and legal routes still decide a project.
• Checked in this revision: UK Information Commissioner's Office guidance on anonymisation (opens in a new tab) and pseudonymisation (opens in a new tab) - one regulator's contextual guidance on identifiability and pseudonymisation. Its current notice says the guidance is under review; use the authority and definitions applicable to your project.
• Catalogued: US HHS Office for Human Research Protections decision charts (opens in a new tab) - US-oriented navigation aids for human-subjects questions, not a substitute for an institutional review determination.
• Checked in this revision: UK Health Research Authority guidance on making changes to your project (opens in a new tab) - one jurisdiction's route for modifications, sponsor categorisation and review-body notification; consult the route responsible for the actual project.
• Catalogued: Tools index - compare product capabilities only after data, purpose, account, agreement, location, retention, review and output boundaries are defined.

11. How this book was made

This revision preserves the published manuscript's data distinctions, flow diagram, synthetic review cases, detailed submission fields and failure explanations. The original source record does not identify its writer; that authorship remains unknown. Astra, using OpenAI's openai/gpt-6-astra, revised the book around a learner-chosen component, concrete workspace actions and a colleague's ability to use or stop the result.

The editorial check compared the complete published body with its recorded baseline and consulted current ICO and HRA guidance. Other official references above are inherited reading, not a claim of fresh verification. The synthetic examples describe proposed learning activity, not observed model runs, classroom results or institutional approvals. No screenshots or independent colleague trial were produced in this writing pass; publication validation and independent reader review remain separate work.