Quality makes sure every verification protocol is reviewed and approved, with pass and fail criteria fixed, before anyone runs it. During execution, quality records who ran each test, on which software version and on what date. Every failed test or deviation gets a written disposition, and any code change it causes gets a regression analysis. The exact build that passed is then archived so it can be rebuilt and inspected later.
On the map: Protocols approved before execution. Deviations dispositioned. Archive the verified build.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Approve protocols before engineering, cybersecurity and clinical run them, and disposition every deviation the same week. Archive the verified build so later questions can be answered from records.
Check that each protocol traces to a requirement, names the software version under test, and states acceptance criteria that a second person could judge without asking the author. Approve it only then, so the criteria cannot drift toward whatever result the test produced.
Record it as a deviation and decide between a test error, a protocol error and a product defect. A product defect goes to problem resolution and change control. The report then states the intentional changes made in response to failures and which tests were re-run.
Base it on what the change touched and on the risk analysis. A change to a risk control or to the model pipeline usually means re-running the full system suite. A labeling-only fix may need only the affected protocols, with the rationale written down.
The build identified in every executed protocol, with its container image, dependency hashes and model weights archived under document control. If the released version differs from the tested version, the difference needs a written assessment of its effect on safety and effectiveness.
See the open positions and apply.