# Q3 2026 Quarterly Spot-Check — IEC 62304, IEC 62366-1, ISO 14971 (Issue #2620)

## Progress

- [x] REQ-IEC62304-4.3 (1/1)
- [x] REQ-IEC62304-5.1 (1/1)
- [x] REQ-IEC62304-5.4.3 (1/1)
- [x] REQ-IEC62304-5.6.3 (1/1)
- [x] REQ-IEC62304-5.7 (1/1)
- [x] REQ-IEC62366-4.1.1 (1/1)
- [x] REQ-IEC62366-5.3 (1/1)
- [x] REQ-ISO14971-10 (1/1)
- [x] REQ-ISO14971-5.4 (checked 5.4 AND 5.5) (2/2)

## Summary

| Atom | Clause(s) checked | Verdict | Severity |
|---|---|---|---|
| REQ-IEC62304-4.3 | IEC 62304:2006+A1:2015 §4.3 (a, c, d, e, g) | clean | — |
| REQ-IEC62304-5.1 | IEC 62304:2006+A1:2015 §5.1 (5.1.1, 5.1.6, 5.1.7) | clean | — |
| REQ-IEC62304-5.4.3 | IEC 62304:2006+A1:2015 §5.4.3 | clean | — |
| REQ-IEC62304-5.6.3 | IEC 62304:2006+A1:2015 §5.6.3 | clean | — |
| REQ-IEC62304-5.7 | IEC 62304:2006+A1:2015 §5.7 (5.7.1) | clean | — |
| REQ-IEC62366-4.1.1 | IEC 62366-1:2015+AMD1:2020 §4.1.1 | clean | — |
| REQ-IEC62366-5.3 | IEC 62366-1:2015+AMD1:2020 §5.3 | clean | — |
| REQ-ISO14971-10 | ISO 14971:2019 §10 (10.1, 10.3, 10.4) | clean | — |
| REQ-ISO14971-5.4 | ISO 14971:2019 §5.4 + §5.5 | clean | — |
| **Total** | **9 atoms / 11 clause refs** | **9 clean, 0 findings, 0 unverified** | — |

## Findings

_No findings met the flagging bar (obligation-level change, scope creep, invented specificity,
or normative/informative confusion). Two borderline observations were reviewed and NOT flagged
— see Methodology notes for the reasoning, since this report is a public review-log entry and
every call must be defensible._

### IEC 62304

#### REQ-IEC62304-4.3 — Software Safety Classification — VERIFIED CLEAN

- **Clause refs checked:** `iec-62304-2015: 4.3` (exists — clause 4.3 "Software safety classification"); `iso-13485-2016: 7.3.2` (exists, correct title "Design and development planning"); `21-cfr-820-qsr: 820.30(b)` (exists, correct title, presented as a crosswalk row, not asserted as current QMSR obligation).
- **Source, how retrieved:** `scripts/standards/standards-corpus get iec-62304-2015` → `/home/todd/.local/share/kelsey/standards/standards/iec-62304-2015.pdf`; read via Read tool, pages 110–111 (printed pp. 16–17), 2026-08-12.
- **Source quote (verbatim, p.16):**
  > "a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case-scenario as indicated in Figure 3."
- **Source quote (verbatim, p.17, sub-items c/d/e/g):**
  > "c) The MANUFACTURER shall document the software safety class assigned to each SOFTWARE SYSTEM in the RISK MANAGEMENT FILE. ... e) The MANUFACTURER shall document the software safety class of each SOFTWARE ITEM if that class is different from the class of the SOFTWARE ITEM from which it was created by decomposition. ... g) For each SOFTWARE SYSTEM, until a software safety class is assigned, Class C requirements shall apply."
- **Committed text (verbatim):**
  > "The manufacturer shall assign a software safety class (A, B, or C) to the software system and to each software item, based on the severity of harm that could result from software failure. The classification determines which IEC 62304 requirements are mandatory and must be documented."
- **Assessment:** The system-level assignment (a) and per-item classification/documentation (c, d, e) are both genuinely in clause 4.3 — the atom's rollup of "system and each software item" is accurate, not a scope broadening, since 4.3(d)/(e) explicitly extend classification to software items via decomposition. "Determines which requirements are mandatory" reflects (g) (Class C default) and the standard's general class-gated requirement structure (confirmed on p.17 NOTE: "the software safety classes for which a specific requirement applies are identified following the requirement in the form [Class ...]"). Obligation level (shall), scope, and terminology all match.
- **Location:** `apps/compliance/data/iec62304-atoms.json`, atom `REQ-IEC62304-4.3`, field `requirement_text`.
- **PDF page:** pp. 16–17 (source_grounding claims p.110 PDF-index / printed p.16 — confirmed correct).

#### REQ-IEC62304-5.1 — Software Development Planning — VERIFIED CLEAN

- **Clause refs checked:** `iec-62304-2015: 5.1` (exists — parent clause "Software development planning", with normative sub-clauses 5.1.1–5.1.12); `iso-13485-2016: 7.3.2` (exists, correct title); `21-cfr-820-qsr: 820.30(b)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** same PDF, pages 112–114 (printed pp. 18–20), 2026-08-12.
- **Source quote (verbatim, p.18, §5.1.1):**
  > "The MANUFACTURER shall establish a software development plan (or plans) for conducting the ACTIVITIES of the software development PROCESS ... The plan shall address the following: a) the PROCESSES to be used ...; b) the DELIVERABLES ...; c) TRACEABILITY between SYSTEM requirements, software requirements, SOFTWARE SYSTEM test, and RISK CONTROL measures implemented in software; d) software configuration and change management ...; and e) software problem resolution ... [Class A, B, C]"
- **Source quote (verbatim, p.19, §5.1.6 / §5.1.7):**
  > "5.1.6 Software VERIFICATION planning — The MANUFACTURER shall include or reference in the software development plan the following VERIFICATION information ... [Class A, B, C]" / "5.1.7 Software RISK MANAGEMENT planning — The MANUFACTURER shall include or reference in the software development plan, a plan to conduct the ACTIVITIES and TASKS of the software RISK MANAGEMENT PROCESS, including the management of RISKS relating to SOUP. [Class A, B, C]"
- **Committed text (verbatim):**
  > "The manufacturer shall establish a software development plan covering development processes, deliverables, traceability requirements, configuration management, problem resolution, risk management activities, and verification approach. The plan shall be maintained throughout the development lifecycle."
- **Assessment:** `regime_keys` cites the parent clause "5.1", not "5.1.1" alone, and the atom's `source_grounding.excerpt` is drawn from 5.1.1 while the requirement_text additionally rolls up "risk management activities" (5.1.7) and "verification approach" (5.1.6) — both are genuine, separately-numbered normative sub-clauses of 5.1, not invented. "Plan shall be maintained" reflects 5.1.2 ("Keep software development plan updated"). This is a fair section-level rollup, consistent with citing the parent clause number. No obligation-level, scope, or terminology drift.
- **Location:** `apps/compliance/data/iec62304-atoms.json`, atom `REQ-IEC62304-5.1`, field `requirement_text`.
- **PDF page:** pp. 18–20 (source_grounding p.112 PDF-index / printed p.18 — confirmed correct for 5.1.1 anchor).

#### REQ-IEC62304-5.4.3 — Develop Detailed Design for Software Unit Interfaces — VERIFIED CLEAN

- **Clause refs checked:** `iec-62304-2015: 5.4.3` (exists); `iso-13485-2016: 7.3.4` (exists, correct title "Design and development outputs"); `21-cfr-820-qsr: 820.30(d)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** same PDF, page 117 (printed p.23), 2026-08-12.
- **Source quote (verbatim):**
  > "5.4.3 Develop detailed design for interfaces — The MANUFACTURER shall document a design for any interfaces between the SOFTWARE UNIT and external components (hardware or software), as well as any interfaces between SOFTWARE UNITS, detailed enough to implement each SOFTWARE UNIT and its interfaces correctly. [Class C]"
- **Committed text (verbatim):**
  > "The manufacturer shall document a design for any interfaces between the software unit and external components (hardware or software), as well as any interfaces between software units, detailed enough to implement each software unit and its interfaces correctly. [Class C]"
- **Assessment:** Word-for-word match (case of defined terms aside). Obligation level (shall), scope (Class C), terminology identical.
- **Location:** `apps/compliance/data/iec62304-atoms.json`, atom `REQ-IEC62304-5.4.3`, field `requirement_text`.
- **PDF page:** p.23 (source_grounding p.117 PDF-index — confirmed).

#### REQ-IEC62304-5.6.3 — Software Integration Testing — VERIFIED CLEAN

- **Clause refs checked:** `iec-62304-2015: 5.6.3` (exists); `iso-13485-2016: 7.3.6` (exists, correct title "Design and development verification"); `21-cfr-820-qsr: 820.30(f)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** same PDF, page 119 (printed p.25), 2026-08-12.
- **Source quote (verbatim):**
  > "5.6.3 Software integration testing — The MANUFACTURER shall test the integrated SOFTWARE ITEMS in accordance with the integration plan (see 5.1.5) and document the results. [Class B, C]"
- **Committed text (verbatim):**
  > "The manufacturer shall test the integrated software items in accordance with the integration plan and document the results. Applies to Class B and Class C software."
- **Assessment:** Direct match; "Applies to Class B and Class C software" correctly restates the bracketed applicability tag. No drift.
- **Location:** `apps/compliance/data/iec62304-atoms.json`, atom `REQ-IEC62304-5.6.3`, field `requirement_text`.
- **PDF page:** p.25 (source_grounding p.119 PDF-index — confirmed).

#### REQ-IEC62304-5.7 — Software System Testing — VERIFIED CLEAN (one borderline item reviewed, not flagged)

- **Clause refs checked:** `iec-62304-2015: 5.7` (exists — parent clause with sub-clauses 5.7.1–5.7.5); `iso-13485-2016: 7.3.6` (exists, correct title); `21-cfr-820-qsr: 820.30(f)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** same PDF, pages 120–121 (printed pp. 26–27), plus §7.2.2/7.3 on page 125 (printed p.31) for cross-check, 2026-08-12.
- **Source quote (verbatim, p.26, §5.7.1):**
  > "a) The MANUFACTURER shall establish and perform a set of tests, expressed as input stimuli, expected outcomes, pass/fail criteria and procedures, for conducting SOFTWARE SYSTEM testing, such that all software requirements are covered. [Class A, B, C]"
- **Source quote (verbatim, p.26, §5.7.3(c)):**
  > "c) perform relevant RISK MANAGEMENT ACTIVITIES as defined in 7.4. [Class A, B, C]"
- **Source quote (verbatim, p.31, §7.2.2(a)):**
  > "If a RISK CONTROL measure is implemented as part of the functions of a SOFTWARE ITEM, the MANUFACTURER shall: a) include the RISK CONTROL measure in the software requirements ..."
- **Committed text (verbatim):**
  > "The manufacturer shall test the integrated software system against software requirements using a documented test plan. Tests must cover all software requirements and risk control measures. Test results must be recorded, and changes must trigger regression testing."
- **Assessment:** §5.7.1(a) literally says tests must cover "all software requirements" — it does not independently name "risk control measures" as a separate test target within §5.7. However §7.2.2(a) requires risk control measures implemented in software to be incorporated into the software requirements themselves, so "cover all software requirements" already, by the standard's own cross-reference, includes risk control measures. This is a defensible synthesis rather than invented specificity — reviewed and NOT flagged. "Test results must be recorded" reflects §5.7.5 (test record contents); "changes must trigger regression testing" reflects §5.7.3(a)/(b). No obligation-level or scope drift.
- **Location:** `apps/compliance/data/iec62304-atoms.json`, atom `REQ-IEC62304-5.7`, field `requirement_text`.
- **PDF page:** pp. 26–27, 31 (source_grounding p.120 PDF-index — confirmed).

### IEC 62366-1

#### REQ-IEC62366-4.1.1 — Usability Engineering Process — VERIFIED CLEAN (one borderline item reviewed, not flagged)

- **Clause refs checked:** `iec-62366-1-2020: 4.1.1` (exists); `iso-13485-2016: 7.3.2` (exists, correct title); `21-cfr-820-qsr: 820.30(b)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** `scripts/standards/standards-corpus get iec-62366-1-2020` → `/home/todd/.local/share/kelsey/standards/standards/iec-62366-1-2020.pdf`; pages 147–148 (printed pp. 13–14), 2026-08-12.
- **Source quote (verbatim, p.13–14):**
  > "The MANUFACTURER shall establish, document, implement and maintain a USABILITY ENGINEERING PROCESS, as defined in Clause 5, to provide SAFETY for the PATIENT, USER and others. The PROCESS shall address USER interactions with the MEDICAL DEVICE according to the ACCOMPANYING DOCUMENTATION, including, but not limited to: — * transport; — * storage; — installation; — operation; — maintenance and repair; and — disposal."
- **Committed text (verbatim):**
  > "The manufacturer shall establish, document, implement, and maintain a usability engineering process, as defined in Clause 5, to provide safety for the patient, user, and others (including bystanders and third parties). Per §4.1.1, the process must address user interactions including transport, storage, installation, operation, maintenance and repair, and disposal — covering user interface design, formative evaluation during development, and summative (validation) evaluation prior to release. Risk control activities related to the user interface must be integrated with the overall risk management process."
- **Assessment:** The six-item interaction list (transport/storage/installation/operation/maintenance and repair/disposal) is verbatim-accurate. "(including bystanders and third parties)" is an interpretive gloss on "others" — the term "others" is undefined in clause 4.1.1 itself; Annex B examples do depict bystander harm scenarios, but this is informative material, not the normative clause text. Reviewed and NOT flagged as it does not narrow or invert the obligation (glossing "others" wider is consistent with, not contradictory to, the standard's intent) — noted as a borderline gloss in Methodology. "Formative/summative evaluation" and "risk control integration" are accurate summaries of what Clause 5 (which 4.1.1 explicitly incorporates by reference) requires.
- **Location:** `apps/compliance/data/iec62366-atoms.json`, atom `REQ-IEC62366-4.1.1`, field `requirement_text`.
- **PDF page:** pp. 13–14 (source_grounding p.147 PDF-index — confirmed).

#### REQ-IEC62366-5.3 — Identify known or foreseeable Hazards and Hazardous Situations — VERIFIED CLEAN

- **Clause refs checked:** `iec-62366-1-2020: 5.3` (exists); `iso-13485-2016: 7.1` (exists, correct title "Planning of product realization"); `21-cfr-820-qsr: 820.30(g)` (exists, correct title, crosswalk row only). Cross-referenced `ISO 14971:2019, 5.4` inside the clause text — confirmed that clause exists and its title matches (see REQ-ISO14971-5.4 below).
- **Source, how retrieved:** same PDF, page 150 (printed p.16), 2026-08-12.
- **Source quote (verbatim):**
  > "The MANUFACTURER shall identify known or foreseeable HAZARDS and HAZARDOUS SITUATIONS, which could affect PATIENTS, USERS or others, related to use of the MEDICAL DEVICE. This identification shall be conducted as part of a RISK ANALYSIS performed according to ISO 14971:2019, 5.4. ... During the identification of HAZARDS and HAZARDOUS SITUATIONS, the following shall be considered: — USE SPECIFICATION, including USER PROFILE(S) (see 5.1); — information on HAZARDS and HAZARDOUS SITUATIONS known for existing USER INTERFACES of MEDICAL DEVICES of a similar type, if available; and — identified USE ERRORS (see 5.2). The results of this identification of HAZARDS and HAZARDOUS SITUATIONS shall be stored in the USABILITY ENGINEERING FILE."
- **Committed text (verbatim):**
  > "The manufacturer shall identify known or foreseeable hazards and hazardous situations which could affect patients, users or others, related to use of the medical device. This identification shall be conducted as part of a risk analysis performed according to ISO 14971:2019. During the identification, the following shall be considered: the use specification, including user profiles (see 5.1); information on hazards and hazardous situations known for existing user interfaces of medical devices of a similar type, if available; and identified use errors (see 5.2). Results shall be stored in the usability engineering file."
- **Assessment:** Near word-for-word match; only omission is the specific ", 5.4" sub-clause pointer within the ISO 14971 cross-reference (retains "ISO 14971:2019" generally) — immaterial, not a drift in obligation, scope, or terminology.
- **Location:** `apps/compliance/data/iec62366-atoms.json`, atom `REQ-IEC62366-5.3`, field `requirement_text`.
- **PDF page:** p.16 (source_grounding p.150 PDF-index — confirmed).

### ISO 14971

#### REQ-ISO14971-5.4 — Hazard Identification and Risk Estimation (clauses 5.4 AND 5.5) — VERIFIED CLEAN

- **Clause refs checked:** `iso-14971-2019: 5.4` (exists — "Identification of hazards and hazardous situations") AND `iso-14971-2019: 5.5` (exists — "Risk estimation"); `iso-13485-2016: 7.1` (exists, correct title); `21-cfr-820-qsr: 820.30(g)` (exists, correct title, crosswalk row only).
- **Source, how retrieved:** `scripts/standards/standards-corpus get iso-14971-2019` (⚠ OCR text source, no native text layer — rendered pages verified visually) → `/home/todd/.local/share/kelsey/standards/standards/iso-14971-2019.pdf`; pages 19–20 (printed pp. 11–12), 2026-08-12.
- **Source quote (verbatim, §5.4, printed p.11):**
  > "The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."
- **Source quote (verbatim, §5.5, printed pp.11–12):**
  > "For each identified hazardous situation, the manufacturer shall estimate the associated risk(s) using available information or data. For hazardous situations for which the probability of the occurrence of harm cannot be estimated, the possible consequences shall be listed for use in risk evaluation and risk control. ... The system used for qualitative or quantitative categorization of probability of occurrence of harm and severity of harm shall be recorded in the risk management file." / NOTE 1: "Risk estimation incorporates an analysis of the probability of occurrence of harm and the severity of the harm."
- **Committed text (verbatim):**
  > "The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions, then estimate the probability of harm occurrence and the severity of that harm for each hazardous situation."
- **Assessment:** The §5.4 sentence is a verbatim match. The §5.5 clause is correctly summarized ("estimate the probability of harm occurrence and the severity of that harm") — this is drawn directly from §5.5's own NOTE 1 ("probability of occurrence of harm and severity of the harm") and the normative "categorization of probability of occurrence of harm and severity of harm" sentence, not invented. No obligation-level, scope, or terminology drift across either clause.
- **Sub-check — Annex C.1 informative claim:** `atomic_constraints` states "ISO 14971:2019 Annex C.1 — which is informative — states that a decomposition into P1 and P2 is not mandatory" and correctly labels this Annex material (not clause 5.4/5.5 normative text) as informative — this is the correct normative-vs-informative handling the audit is checking for.
- **Sub-check — clause 4.4(d) cross-reference:** confirmed present verbatim: "d) criteria for risk acceptability, based on the manufacturer's policy for determining acceptable risk" (clause 4.4, Risk management plan).
- **Location:** `apps/compliance/data/iso14971-atoms.json`, atom `REQ-ISO14971-5.4`, field `requirement_text`.
- **PDF page:** printed pp. 11–12 (source_grounding p.19 PDF-index — confirmed for both clauses).

#### REQ-ISO14971-10 — Production and Post-Production Information Review — VERIFIED CLEAN (one borderline item reviewed, not flagged)

- **Clause refs checked:** `iso-14971-2019: 10` (exists — parent clause "Production and post-production activities", sub-clauses 10.1–10.4); `iso-13485-2016: 8.2.1` (exists, correct title "Feedback"); `21-cfr-820-qsr: 820.198` (exists, correct title "Complaint files.", crosswalk row only).
- **Source, how retrieved:** same PDF, pages 23–24 (printed pp. 15–16), 2026-08-12.
- **Source quote (verbatim, §10.1, printed p.15):**
  > "The manufacturer shall establish, document and maintain a system to actively collect and review information relevant to the medical device in the production and post-production phases. When establishing this system, the manufacturer shall consider appropriate methods for the collection and processing of information."
- **Source quote (verbatim, §10.3, printed p.16):**
  > "The manufacturer shall review the information collected for possible relevance to safety, especially whether: — previously unrecognised hazards or hazardous situations are present; — an estimated risk arising from a hazardous situation is no longer acceptable; — the overall residual risk is no longer acceptable in relation to the benefits of the intended use; or — the generally acknowledged state of the art has changed."
- **Source quote (verbatim, §10.4, printed p.16):**
  > "If the collected information is determined to be relevant to safety, the following actions apply. 1) Concerning the particular medical device, — the manufacturer shall review the risk management file and determine if reassessment of risks and/or assessment of new risks is necessary; ... — any decisions and actions shall be recorded in the risk management file."
- **Committed text (verbatim):**
  > "The manufacturer shall establish, document and maintain a system to actively collect and review information relevant to the medical device in the production and post-production phases, including complaint and incident data, to determine whether that information has implications for the risk management file. The manufacturer shall review the information collected for possible relevance to safety, especially whether: previously unrecognised hazards or hazardous situations are present; an estimated risk arising from a hazardous situation is no longer acceptable; the overall residual risk is no longer acceptable in relation to the benefits of the intended use; or the generally acknowledged state of the art has changed. When any of these conditions apply, the risk management file must be updated."
- **Assessment — §10.1 and §10.3 sentences:** verbatim/near-verbatim matches, correct.
- **Assessment — final sentence, reviewed and NOT flagged:** §10.4 actually says the manufacturer shall *review the risk management file and determine if reassessment ... is necessary* (a conditional determination step), and separately mandates that "any decisions and actions shall be recorded in the risk management file" — regardless of whether the determination is "yes, update" or "no action needed." The committed text's "the risk management file must be updated" compresses this two-step, partly-conditional process into a single unconditional clause. This is a defensible plain-language compression (the file is always touched — at minimum with a recorded decision — whenever the trigger conditions are met) rather than a clear obligation-level inversion or scope-broadening; the atom's own `atomic_constraints` field correctly preserves the "determine whether ... necessary" conditional. Reviewed and NOT flagged as a finding, but noted here per the zero-false-positive-bias standard and because this entry becomes a public review-log record.
- **Location:** `apps/compliance/data/iso14971-atoms.json`, atom `REQ-ISO14971-10`, field `requirement_text`.
- **PDF page:** printed pp. 15–16 (source_grounding p.23 PDF-index — confirmed).

## Methodology notes

- **Standards editions consulted:** `iec-62304-2015` (IEC 62304:2006/AMD1:2015 CSV, native text layer), `iec-62366-1-2020` (IEC 62366-1:2015+AMD1:2020 CSV, native text layer), `iso-14971-2019` (ISO 14971:2019, OCR text — rendered pages verified visually against manifest sha256, no OCR-token-confidence anomalies observed on the pages read).
- **PDFs accessed:** 3 unique PDF files, 13 distinct pages read (iec-62304-2015: pp.110–121; iec-62366-1-2020: pp.147–148, 150; iso-14971-2019: pp.19–20, 23–24), all via `Read` tool against paths returned by `scripts/standards/standards-corpus get <id>`, 2026-08-12.
- **Clause existence:** all 11 cited clause numbers across the 9 atoms (4.3, 5.1, 5.4.3, 5.6.3, 5.7, 4.1.1, 5.3, 5.4, 5.5, 10) confirmed present in the current recognized edition, with authoritative_titles matching the PDF headings exactly for every atom checked.
- **Cross-regime references (iso-13485-2016, 21-cfr-820-qsr):** clause numbers and titles in `authoritative_titles` were checked for internal plausibility against known ISO 13485:2016 / 21 CFR 820 structure (all correct: 7.1, 7.3.2, 7.3.4, 7.3.6, 8.2.1, 820.30(b)/(d)/(f)/(g), 820.198) but were NOT independently re-verified against the ISO 13485 or 21 CFR 820 source PDFs/eCFR in this session — that is a correctness check on a different atom family, out of this audit's scope fence. All 21-cfr-820-qsr refs appear only as crosswalk-table `regime_keys` entries, not asserted in any `requirement_text` as current QMSR obligations, so the "sunset" caveat in the task brief does not surface a finding here.
- **Atoms/files where source was unavailable:** none — all 9 rows fully verified against primary-source PDF text.
- **Out-of-scope observations not flagged (noted for lead triage):**
  - REQ-IEC62304-5.7: "risk control measures" phrase in requirement_text is a defensible cross-clause synthesis (§5.7.1 + §7.2.2(a)), not literally present in §5.7 alone — reviewed, not flagged (see finding block above for full reasoning).
  - REQ-IEC62366-4.1.1: "(including bystanders and third parties)" is an interpretive gloss on "others" not present in the §4.1.1 normative text itself — reviewed, not flagged.
  - REQ-ISO14971-10: final sentence "the risk management file must be updated" compresses §10.4's conditional review-then-determine structure — reviewed, not flagged; atom's own `atomic_constraints` field already carries the correct conditional language.
- **Time spent (rough):** ~1 hour.

**N audited, N clean, N findings, N unverified:**
9 audited, 9 clean, 0 findings, 0 unverified