Knowing the Norms: Regulatory-Readiness Engineering for a Physician-Governed Clinical AI System — Traceable Evidence and Declared Gaps

Abstract

Part III of Volume II (the outward extensions) of the H-DKPS series on physician-governed clinical AI (知衡八法). The redacted code package is included as a separate file. Clinical problem. A physician who builds clinical software for use in their own clinic will sooner or later be asked a question they are not equipped to answer alone: where does this stand against the rules? The honest answer is rarely "compliant" and rarely "not applicable". It is a list — of what the system already does that the rules ask for, of what it does differently, and of what it does not yet do at all. That list is hard to produce, easy to overstate, and usually written once and left to go stale. Engineering problem. Regulatory requirements for clinical decision support and AI-enabled medical software — the EU Artificial Intelligence Act, U.S. guidance on clinical decision support, premarket software documentation and predetermined change control, the international standards for software life cycle, risk management and usability, and Taiwanese guidance on medical software — are written for manufacturers with quality systems. A physician-governed system built incrementally has evidence of many kinds scattered across code, tests, logs and rulings, and no structure that connects any of it to a clause. Two failure modes follow: claims that outrun evidence (a system describing itself in certification language it has never earned), and evidence that never reaches the claim (properties that exist and are tested, but cannot be shown). Approach. We treat regulatory readiness as an engineering property with three parts. Claims calibration: every user-visible statement that implies certification or guarantee is removed or neutralised, and a guard keeps it so. Traceable evidence: a clause matrix maps requirements — each retrieved from its source on the day it was used — to evidence in code, tests and documents, and a traceability matrix linking requirement to code to test is regenerated automatically from the guard suites, with each test's ability to fail recorded. Declared gaps: what is missing is stated in the same tables, at the same level of detail, as what is present. The method was applied over two days to a deployed physician-governed system, and the gaps it found were then worked on: a production override process aligned with a published bounded-override design, hash-chained audit records, the traceability generator itself, a safety-classification planning document and a retirement procedure, and skeletons for instructions for use and a risk-management file. Evidence. This is an architecture study; no patient data were used. The claims guard scans the system's user-visible strings across 428 files for a fixed list of unsupported certification phrases. The clause matrix of 14 October recorded 31 statused rows: 7 present, 17 partial, 6 absent, 1 unknown; by 15 October, the work it prompted had changed several of them (Section 7.1). The traceability matrix covers 40 guard suites and 214 itemised requirements; 38 suites include mutation tests, and all 40 passed when executed. Every guard used as evidence in this paper turns red under at least one mutation that reintroduces the behaviour it forbids. The remaining gaps — a quality management system, instructions for use beyond a skeleton, a risk-management file with defined severity and probability scales, the full text of three paywalled standards, summative usability evaluation, clinical performance — are listed, not hidden. Contribution. Regulatory readiness can be engineered and kept current in the same way safety is: by stating requirements, connecting them to evidence that can fail, and declaring what is missing. A system that does this cannot claim more than it shows — and can show more than a narrative would. Not peer reviewed.