# Guide-Prose Content Re-Review — #2620
## Progress
- [x] iso-14971-risk-management/page.tsx (1/1)
- [x] iec-62304-software-lifecycle/page.tsx (1/1)
- [x] iec-62366-usability-engineering/page.tsx (1/1)
- [x] iec-81001-cybersecurity/page.tsx (1/1)
## Summary
| File / scope | Audited | Drift found | Severity |
|---|---|---|---|
| iso-14971-risk-management | 1 | 3 | high:1, medium:1, low:1 |
| iec-62304-software-lifecycle | 1 | 2 | medium:1, low:1 |
| iec-62366-usability-engineering | 1 | 2 | high:1, medium:1 |
| iec-81001-cybersecurity | 1 | 6 | high:2, medium:3, low:1 |
| **Total** | **4** | **13** | critical:0, high:4, medium:6, low:3 |
## Findings
### iso-14971-risk-management/page.tsx — verdict: findings
Reviewed against ISO 14971:2019 (`standards-corpus get iso-14971-2019`) and ISO/TR 24971:2020
cross-references. Verified verbatim against the OCR text layer for: Clause 1 (Scope), Clause 3.15
(reasonably foreseeable misuse), Clause 3.2 (benefit), Clause 4.1 (risk management process), Clause
4.2 NOTE 1 (ALARP/AFAP/as-far-as-possible), Clause 4.4 (risk management plan, items a–g), Clause 4.5
(risk management file, NOTE 1), Clause 5.4/5.5 language, Clause 6 (risk evaluation), Clause 7.1–7.5,
Clause 8 (evaluation of overall residual risk), Clause 9 (risk management review), Clause 10.1–10.4
(production and post-production, restructured into four sub-clauses). All of these matched the
source byte-for-byte or as a faithful paraphrase. This guide is the most accurate of the four audited.
Two lower-severity items and one cross-reference staleness item are flagged below.
#### Line 486 (Clause 4.4 plan contents) — invented specificity inside a quoted clause enumeration
- **Drift type:** invented-specificity
- **Severity:** medium
- **Standard clause / source:** ISO 14971:2019 Clause 4.4(d)
- **Source quote (verbatim from PDF):**
> d) criteria for risk acceptability, based on the manufacturer's policy for determining acceptable
> risk, including criteria for accepting risks when the probability of occurrence of harm cannot be
> estimated;
- **Committed text (verbatim from repo):**
> "Clause 4.4 requires the plan to include at minimum: (a) the scope of planned risk management
> activities, identifying the device and the lifecycle phases covered; (b) assignment of
> responsibilities and authorities; (c) requirements for review of risk management activities; (d)
> criteria for risk acceptability, including severity categories, probability categories, and the
> risk acceptability matrix — and criteria for accepting risks when probability of harm cannot be
> estimated; ..."
- **Location:** `src/app/(marketing)/guides/iso-14971-risk-management/page.tsx:486-491`
- **PDF page:** p. 9 (ISO 14971:2019, Clause 4.4)
- **Recommended revision:**
> Drop "including severity categories, probability categories, and the risk acceptability matrix"
> from the enumeration of what Clause 4.4(d) requires, or explicitly separate it as "in practice,
> this is commonly implemented as..." — the clause itself only requires criteria for risk
> acceptability (with a carve-out for unknown-probability risks); it does not name severity/probability
> categories or a matrix as content elements.
- **Notes:** This is presented inline as part of an enumerated list introduced by "Clause 4.4 requires
the plan to include at minimum," which reads as a direct paraphrase of normative text. The added
detail is common practice, not a documented drift customers would be misled by in a harmful way, but
it does put words in the clause's mouth.
#### Lines 92, 105, 403-404 — sibling-standard clause citations use a superseded edition label
- **Drift type:** non-standard-terminology (edition label)
- **Severity:** low
- **Standard clause / source:** IEC 62366-1 — manifest `iec-62366-1-2020` (current edition:
IEC 62366-1:2015+AMD1:2020 CSV)
- **Source quote:** manifest note (`data/corpus/reference/manifest.yaml`, `iec-62366-1-2020` entry):
> "Edition 1.1 2020-06 CONSOLIDATED VERSION — merges the 2015 base with Amendment 1 (2020-06)...
> AMD1 adds new §5.10 (UOUP...) and Annex C..., plus scattered edits through Clauses 1–5."
- **Committed text (verbatim from repo):**
> "IEC 62366-1:2015 Clause 5.1 (Prepare Use Specification)" (line 92); "IEC 62366-1:2015 Clause 5.5
> (Usability evaluation)" (line 105); "IEC 62366-1:2015 Clause 5.1 requires an intended use
> specification..." (line 403-404)
- **Location:** `src/app/(marketing)/guides/iso-14971-risk-management/page.tsx:92,105,403-404`
- **Recommended revision:**
> Cite as "IEC 62366-1:2015+AMD1:2020" for consistency with the guide's own IEC 62304 citation
> style (`IEC 62304:2006+AMD1:2015`) and with the sibling IEC 62366 guide, which correctly cites
> "IEC 62366-1:2015+AMD1:2020 CSV" throughout.
- **Notes:** AMD1:2020 made "scattered edits through Clauses 1–5" per the manifest, so this is a
labeling-consistency issue rather than a confirmed substantive drift in Clause 5.1/5.5 content.
#### Line 1447-1448 — stale link text names the superseded 2023 cybersecurity guidance edition
- **Drift type:** invented/stale dated claim
- **Severity:** high
- **Standard clause / source:** FDA Cybersecurity in Medical Devices guidance — current edition
Feb 3, 2026 (`fda-cybersecurity-guidance-2026-02`)
- **Committed text (verbatim from repo):**
> `IEC 81001-5-1 + FDA 2023 Cybersecurity: What you
> need to ship`
- **Location:** `src/app/(marketing)/guides/iso-14971-risk-management/page.tsx:1447-1448`
- **Recommended revision:**
> "IEC 81001-5-1 + FDA Cybersecurity Guidance (Updated 2026): What you need to ship" — matching the
> target guide's own `` metadata, which was correctly updated for the Feb 3, 2026 edition.
- **Notes:** Same pattern recurs in the IEC 62366 guide (see below) and inside the IEC 81001-5-1 guide
itself (see below) — a systemic leftover from before the guide set was updated for the Feb 2026 FDA
guidance revision.
---
### iec-62304-software-lifecycle/page.tsx — verdict: findings
Reviewed against IEC 62304:2006+AMD1:2015 CSV (`standards-corpus get iec-62304-2015`, native text
layer, `pdftotext -layout`). Verified verbatim/near-verbatim: Clause 4.3 (Class A/B/C definitions,
including the AMD1:2015 "external to the SOFTWARE SYSTEM" / NOTE 1 "hardware, an independent SOFTWARE
SYSTEM, health care procedures" language — the guide's "software probability of failure is assumed to
be 1" / external-control framing matches the current text), Clause 5.4.1 vs. 5.4.2-5.4.4 class
applicability (Table A.1), Clause 5.2.2 disciplines, Clause 6.1 maintenance-plan procedures, Clause
7.1.3, Clause 8.1.2 SOUP identification fields, Table A.1 class-applicability matrix for 5.1-9. This
guide's technical content is accurate; the SOUP/classification core claims (its stated differentiator)
hold up well against the source. Two lower-severity precision gaps below.
#### FAQ item — "Does Class A software require almost no documentation?" (line 131) — overgeneralized clause-applicability claim
- **Drift type:** scope-narrowing (omitted-conditional)
- **Severity:** medium
- **Standard clause / source:** IEC 62304:2006+AMD1:2015, Annex A, Table A.1 (Summary of requirements
by software safety class), row "7.4 / 7.4.1"
- **Source quote (verbatim from PDF, Table A.1):**
> "7.4 7.4.1 X X X
> 7.4.2, 7.4.3 X X"
(7.4.1 "Analyse changes to MEDICAL DEVICE SOFTWARE with respect to SAFETY" is tagged `[Class A, B,
C]` in the normative clause text at 7.4.1; only 7.4.2/7.4.3 are Class B/C-only.)
- **Committed text (verbatim from repo):**
> "No — and this is one of the most dangerous misstatements circulating in guides from QMS platform
> vendors. Clause 7 (software risk management) does not apply to Class A software, and the detailed
> design requirements of Clauses 5.4.2–5.4.4 apply to Class C only..."
- **Location:** `src/app/(marketing)/guides/iec-62304-software-lifecycle/page.tsx:131`
- **Recommended revision:**
> "Clauses 7.1–7.3 (identify software items that could contribute to a hazard, analyze causes,
> evaluate risk control measures) do not apply to Class A software; nor do 7.4.2-7.4.3. Clause 7.4.1
> — analyze whether a change affects safety — applies to all three classes, including A."
- **Notes:** The FAQ item is itself warning readers against exactly this style of over-broad
simplification from "QMS platform vendors" ("ask them to point to the clause that says so") — the
guide's own blanket "Clause 7 ... does not apply to Class A" claim has the same shape of imprecision,
just far less consequential (one subclause out of seven in Clause 7, and it doesn't reduce required
rigor).
#### Line 656-659 — Clause 6.1 "verb" is paraphrased more narrowly than the clause's actual list
- **Drift type:** non-standard-terminology
- **Severity:** low
- **Standard clause / source:** IEC 62304:2006+AMD1:2015, Clause 6.1(a)
- **Source quote (verbatim from PDF):**
> "a) procedures for: — receiving, — documenting, — evaluating, — resolving and — tracking feedback
> arising after release of the MEDICAL DEVICE SOFTWARE;"
- **Committed text (verbatim from repo):**
> "Clause 6.1 specifically requires a process to receive and review post-market field feedback...
> 'Monitor' is not the §6.1 verb: the requirement is to receive and review, which implies a defined
> intake path, a reviewer, and a documented decision, not merely passive observation."
- **Location:** `src/app/(marketing)/guides/iec-62304-software-lifecycle/page.tsx:655-660`
- **Recommended revision:**
> "'Monitor' is not a §6.1 verb: the clause requires receiving, documenting, evaluating, resolving,
> and tracking feedback — a defined intake-and-disposition path, not passive observation."
- **Notes:** The guide's underlying point (documented, active intake beats passive "monitoring") is
directionally correct; only the specific two-verb gloss ("receive and review") is narrower than the
clause's five-verb list, and "review" does not appear in Clause 6.1 at all ("evaluating" is the
nearest term).
---
### iec-62366-usability-engineering/page.tsx — verdict: findings
Reviewed against IEC 62366-1:2015+AMD1:2020 CSV (`standards-corpus get iec-62366-1-2020`, native text
layer). Verified verbatim/near-verbatim: Clause 4.1.1, 4.2 (Usability Engineering File), 5.1-5.9 clause
titles and numbering (Use Specification, Hazard identification, Hazard-Related Use Scenarios, Select
HRUS for summative evaluation, User Interface Specification, UI Evaluation Plan incl. 5.7.2/5.7.3,
Formative/Summative evaluation), 5.7.3(e) summative-planning sub-requirements, §3.29 USER PROFILE,
Amendment 1:2020 introduction text (22 issues, no fundamental changes to the process). This is a
technically strong guide. Two findings below — one is an edition-attribution error on the UOUP
section, the other is the same stale-cybersecurity-guidance-edition link seen in the ISO 14971 guide.
#### Lines 852-901 (section "User Interface of Unknown Provenance") — Clause 5.10 and Annex C attributed to the wrong (pre-amendment) edition
- **Drift type:** edition drift (misattribution)
- **Severity:** high
- **Standard clause / source:** IEC 62366-1 manifest (`iec-62366-1-2020`) note; corroborated by the
PDF's own "INTRODUCTION to Amendment 1" section
- **Source quote (verbatim, manifest note for `iec-62366-1-2020`):**
> "AMD1 adds new §5.10 (UOUP — User Interface of Unknown Provenance) and Annex C (UOUP evaluation
> methodology), plus scattered edits through Clauses 1–5."
- **Source quote (verbatim from PDF, p. 8, "INTRODUCTION to Amendment 1"):**
> "The first edition of IEC 62366-1 was published in 2015. Since its publication, experts working in
> the field have identified several inaccuracies that warrant correction. In total, 22 issues were
> identified..."
- **Committed text (verbatim from repo):**
> "Clause 5.10 of IEC 62366-1:2015 addresses User Interfaces of Unknown Provenance..." (line 857);
> "...the streamlined evaluation path described in normative Annex C." / "Normative Annex C of IEC
> 62366-1:2015 defines a focused five-requirement evaluation path for UOUP" (line 901)
- **Location:** `src/app/(marketing)/guides/iec-62366-usability-engineering/page.tsx:857,901`
- **Recommended revision:**
> "Clause 5.10 of IEC 62366-1:2015+AMD1:2020 addresses User Interfaces of Unknown Provenance..." and
> "Normative Annex C of IEC 62366-1:2015+AMD1:2020 defines a focused five-requirement evaluation path
> for UOUP" — both §5.10 and Annex C were introduced by Amendment 1 (2020); they do not exist in the
> unamended 2015 base edition.
- **Notes:** The substantive UOUP requirement content the guide describes (Use Specification,
post-production review, hazards, risk control, residual risk) is accurate to the standard; only the
edition attribution is wrong. Elsewhere in the same guide (metadata, review banner, opening
paragraphs) the edition is correctly stated as "IEC 62366-1:2015+AMD1:2020 CSV," which makes this
section's bare "...IEC 62366-1:2015" citations a localized regression rather than a guide-wide
edition error.
#### Line 1067-1069 — stale link text names the superseded 2023 cybersecurity guidance edition
- **Drift type:** invented/stale dated claim
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity in Medical Devices guidance — current edition
Feb 3, 2026 (`fda-cybersecurity-guidance-2026-02`)
- **Committed text (verbatim from repo):**
> `<Link href="/guides/iec-81001-cybersecurity" ...>IEC 81001-5-1 + FDA 2023 Cybersecurity
> Guide</Link>`
- **Location:** `src/app/(marketing)/guides/iec-62366-usability-engineering/page.tsx:1067-1069`
- **Recommended revision:** "IEC 81001-5-1 + FDA Cybersecurity Guidance (Updated 2026)" — matching the
target guide's own current title.
- **Notes:** Same recurring pattern as the ISO 14971 guide finding above; graded medium here rather
than high because it is a "further reading" cross-link rather than inline in the main narrative.
---
### iec-81001-cybersecurity/page.tsx — verdict: findings
Reviewed against IEC 81001-5-1:2021 (`standards-corpus get iec-81001-5-1-2021`, native text,
`pdftotext -layout`) and FDA Cybersecurity in Medical Devices guidance, current edition Feb 3, 2026
(`standards-corpus get fda-cybersecurity-guidance-2026-02`, TOC read directly from the PDF). Verified
verbatim/near-verbatim: §3.21/3.25/3.36 (Maintained/Required/Supported software definitions), §4.1.4,
§4.2, §4.3, §5.1.3, §5.2.2 (four quality criteria + four reviewer disciplines, both verbatim), §5.3,
§5.5.1, §5.7.2-5.7.4, §5.8, §6.1.1, §6.2, §6.3, §7.2, and the full FDA-2026 crosswalk table's Roman-
numeral section references (IV.A, IV.A.1, V.B/V.B.1/V.B.2, V.C, Appendix 1.D/1.H, Appendix 4, VI.B,
VII.C.1/C.2, VII.D) — all confirmed against the 2026 guidance's own table of contents. The review
banner's edition claim (current Feb 3, 2026, supersedes June 27 2025 and Sept 27 2023) is correct, and
the crosswalk table itself is internally consistent and accurate. The findings below are (a) a clause-
citation error, (b) a cluster of stale "FDA 2023" labels on content that verifiably matches 2026-edition
section numbers, and (c) one unsupported annex citation.
#### Line 661 — Clause 5.6 miscited as "security validation"; actual Clause 5.6 is unrelated
- **Drift type:** clause-reference error
- **Severity:** high
- **Standard clause / source:** IEC 81001-5-1:2021, Clause 5.6 vs. Clause 5.7
- **Source quote (verbatim from PDF):**
> "5.6 Software integration testing / The MANUFACTURER can perform some of the software system
> testing as a part of software integration testing (see 5.7). As a part of HEALTH SOFTWARE
> integration testing, the MANUFACTURER should consider SECURITY policy differences across TRUST
> BOUNDARIES."
> "5.7.2 THREAT mitigation testing / The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES)
> for testing the effectiveness of the mitigation for the THREATS identified and assessed in the
> THREAT MODEL."
- **Committed text (verbatim from repo):**
> "This is a requirements quality gate — not a security testing activity. Whether the implemented
> security controls are effective is a separate question, answered by security validation under
> Clause 5.6."
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:657-663`
- **Recommended revision:**
> "...answered by security validation under Clause 5.7 (Software system testing), specifically
> §5.7.2 (Threat mitigation testing)." Clause 5.6 is "Software integration testing" and does not
> address control-effectiveness validation.
- **Notes:** The guide correctly cites §5.7.2 as "Threat mitigation testing" elsewhere in the same
document (crosswalk table row, line 92-95), which makes this a localized citation slip rather than a
guide-wide misunderstanding — but it directly misdirects a reader looking up "security validation" to
the wrong clause.
#### Line 49 vs. line 876 — TOC label cites the superseded 2023 guidance; the table it introduces is explicitly labeled 2026
- **Drift type:** invented/stale dated claim (internal self-contradiction)
- **Severity:** high
- **Standard clause / source:** FDA Cybersecurity guidance, current edition Feb 3, 2026
- **Committed text (verbatim from repo, line 49):**
> `{ id: "mapping-iec-81001-to-fda", label: "Mapping IEC 81001-5-1 to FDA 2023" }`
- **Committed text (verbatim from repo, line 876, the crosswalk table the TOC entry links to):**
> `col3Header="FDA 2026 GUIDANCE SECTION"`
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:49` (TOC) and `:876`
(table header it points to)
- **Recommended revision:** `label: "Mapping IEC 81001-5-1 to FDA 2026"` — matching the table's own
column header and the review banner's stated current edition.
- **Notes:** This is the clearest instance of the pattern: the TOC entry and the section it links to
disagree about which edition is being mapped, within the same file.
#### Line 972 — auditor-callout caption cites "FDA 2023 guidance" for content matching the 2026 TOC
- **Drift type:** invented/stale dated claim
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity guidance, current edition Feb 3, 2026 — TOC:
"V.A.4 Third-Party Software Components" (p. 15), "Appendix 4. General Premarket Submission
Documentation Elements and Scaling with Risk" (p. 51)
- **Committed text (verbatim from repo):**
> "FDA 2023 guidance Section V.A.4 (Third-Party Software Components) and Appendix 4 (Premarket
> Submission Documentation) together require you to explain how you manage those vulnerabilities,
> not merely list components."
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:969-973`
- **Recommended revision:** "FDA 2026 guidance Section V.A.4 ... and Appendix 4 ..." — matching this
guide's own established convention (`col3Header="FDA 2026 GUIDANCE SECTION"`; multiple `GuideRTACitation`
captions elsewhere correctly say "FDA 2026 guidance").
- **Notes:** The section numbers themselves (V.A.4, Appendix 4) are correct for the current 2026 TOC —
only the edition label is stale.
#### Line 1060 — post-market vigilance section cites "FDA 2023 guidance" for content matching the 2026 TOC
- **Drift type:** invented/stale dated claim
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity guidance, current edition Feb 3, 2026 — TOC:
"6. TPLC Security Risk Management" (V.A.6, p. 18), "B. Cybersecurity Management Plans" (VI.B, p. 30)
- **Committed text (verbatim from repo):**
> "The FDA 2023 guidance places significant emphasis on post-market cybersecurity management.
> Section V.A.6 (TPLC Security Risk Management — Total Product Life Cycle) and Section VI.B
> (Cybersecurity Management Plans) together require a plan..."
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:1059-1063`
- **Recommended revision:** "The FDA 2026 guidance places significant emphasis on post-market
cybersecurity management..." — the section numbers are correct for the current edition; only the
edition label is stale.
#### Line 1113 — pitfall-3 caption cites "The September 2023 guidance" as the operative source
- **Drift type:** invented/stale dated claim
- **Severity:** low
- **Standard clause / source:** FDA Cybersecurity guidance, current edition Feb 3, 2026
- **Committed text (verbatim from repo):**
> "Designing a 'point-in-time' security state that cannot be updated or monitored. The September
> 2023 guidance places heavy emphasis on the Secure Product Lifecycle."
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:1110-1114`
- **Recommended revision:** "The current FDA guidance (Feb 2026) places heavy emphasis on the Secure
Product Lifecycle." Graded lower severity than the other three because it carries no specific section
number that could send a reader to a wrong document version — it's a general framing statement.
#### Line 1034 — SBOM annotation practice attributed to Annex A.3, which does not discuss SBOMs
- **Drift type:** invented-specificity (unsupported citation)
- **Severity:** medium
- **Standard clause / source:** IEC 81001-5-1:2021, Annex A.3 ("Risk transfer" — informative rationale
for the Maintained/Supported/Required Software categories)
- **Source quote (verbatim from PDF, full text of Annex A.3.1-A.3.4):** confirms A.3 explains why the
three risk-transfer categories exist and gives examples of each (e.g., "Examples for MAINTAINED
SOFTWARE include • software from third party... • embedded off-the-shelf software..."); the annex
contains no reference to SBOM, submission documentation, or where the classification should be
recorded.
- **Committed text (verbatim from repo):**
> "The classification is annotated directly on the SBOM, per Annex A.3 of the standard. Each
> component entry in your SBOM should carry the §4.3 classification alongside the component name,
> version, license, and end-of-support date."
- **Location:** `src/app/(marketing)/guides/iec-81001-cybersecurity/page.tsx:1033-1039`
- **Recommended revision:**
> "The classification is a practical annotation to carry on the SBOM (the standard's §4.3 defines the
> classification and Annex A.3 explains the risk-transfer rationale behind it, but neither section
> specifies SBOM formatting)." — separate the normative classification requirement from the
> recommended SBOM-annotation practice, which is this guide's own practical advice, not a standard
> requirement.
- **Notes:** The underlying advice (annotate the SBOM with the §4.3 classification) is reasonable
practice, but citing it "per Annex A.3 of the standard" implies the annex directs this, which it does
not.
## Methodology notes
- Standards editions consulted: `iso-14971-2019` (OCR text layer, verified per-clause), `iec-62304-2015`
(native text, `pdftotext -layout`), `iec-62366-1-2020` (native text, `pdftotext -layout`),
`iec-81001-5-1-2021` (native text, `pdftotext -layout`), `fda-cybersecurity-guidance-2026-02` (native
PDF, TOC + preface pages read directly via the Read tool).
- PDFs / URLs accessed: 5 (all four standards + the FDA guidance PDF); no live eCFR/USC/fda.gov fetches
were needed for this audit (no 21 CFR or FD&C Act text was in scope beyond section-number
cross-references already anchored to atoms/manifest).
- Unverifiable claim, not flagged as a finding per the "never invent a clause number" / "note it in
Methodology" rule: `iec-81001-cybersecurity/page.tsx:997-998,1043` claims "A December 2025
Interpretation Sheet (ISH1:2025) clarified the three [software risk-transfer] categories." No
`ISH1:2025` entry exists in the standards manifest (`standards-corpus search "ISH1"` and
`"interpretation sheet"` both returned no match for this document). Cannot confirm or deny; the
underlying §4.3/Annex A.3 category descriptions the guide attributes to it are independently correct
against the base 2021 standard, so this is a provenance gap, not a contradicted claim.
- Out-of-scope observations not flagged (noted for lead triage):
- `iec-81001-cybersecurity/page.tsx:434` ("The FDA 2023 cybersecurity guidance explicitly references
IEC 81001-5-1 as a viable Secure Product Development Framework (SPDF)") reads as a historical
statement about when this reference was first made (2023), which remains true; not flagged since
it is not being used to source a still-open compliance obligation, unlike the four instances that
were flagged.
- Crosswalk-table clause-to-guidance mappings across all four guides were spot-checked but not
exhaustively re-derived row-by-row; the sampled rows (roughly 20 across the four guides) all
resolved correctly against the source TOCs/clause text.
- Statute-subsection citations (e.g., "§524B(b)(3)(A)") were treated as plausible based on general
domain knowledge but not independently verified against 21 U.S.C. §360n-2 text in this session —
scope was standards/guidance-PDF verification per the task brief, not USC verification.
- Numeric/dated claims that were spot-checked and found consistent with reality as of 2026-08-12:
QMSR effective date (Feb 2, 2026), FDA cybersecurity guidance edition history (Sept 2023 → June
2025 → Feb 2026), 180-day RTA response window, 15-participants-per-user-group FDA HF benchmark.
- Time spent (rough): ~2 hours (four guides, cross-referenced against five source PDFs with targeted
clause-by-clause verification rather than full linear reads of every paragraph).
## Per-guide counts
- iso-14971-risk-management: 3 findings
- iec-62304-software-lifecycle: 2 findings
- iec-62366-usability-engineering: 2 findings
- iec-81001-cybersecurity: 6 findings