第三部分 — 信任层的九项原则

原则五 — 验证即交付物

问一家供应商他们的临床工具是否经过验证，你听到的会是 工具的验证——安装时执行过一次的测试脚本、架子上的一本活页夹、一份带签名的证书。这个模型在软件被当作电器买回来的年代是说得通的。把它套在一条流水线上，就像给汽车钉马掌。

这条原则是：验证属于产品，随产品一起交付，并由产品自身的机制来行使。 它不是针对某个版本举行的一次性仪式，而是一个活的工件——每次发布都携带它，每次执行都强化它。

那么，交付的是什么

一个验证就绪的产品携带四类证据，按说服力递增排列：

一份验证计划，诚实地陈述范围：系统声称做什么、明确不做什么、以哪些标准为框架、以及哪些风险被评估为不相关及其理由。
一份可追溯性矩阵，把每一项声称的能力与证明它的测试连接起来。当某项需求没有测试时，矩阵必须用红色明说，而不是让那一行含糊地保持绿色。任何此类矩阵中最有价值的单元格，是一句诚实的"尚未验证"。
针对现实执行的运行确认——真实的引擎、真实的渲染路径、真实的比对——而不是打了桩的演示。一个只在带模拟依赖的沙箱里通过的确认，确认的只是那个沙箱。
可复现的运行：带清单的已记录执行，使第三方可以重新运行确认并进行比对。你无法复现的验证，只是一则带签名的轶事。

诚实地基于风险

每次发布都对一切做全量再验证，正是验证沦为团队绕行之物的原因。可行的替代方案是基于风险的范围划定，并且不带虚荣地执行：失效会污染交付数字的组件，承受最重的制度；只负责渲染或展示的组件，承受较轻的制度；而风险评估本身——可能性、影响、缓解措施——是一份经过评审的文档，因为所有的判断力都住在那里。

有一个微妙却关键的做法：公开维护一份偏差日志。当确认发现真实缺陷时——它一定会发现——关于发现、修复和重跑的记录，对任何认真的审计员而言都比一份一尘不染的历史更有说服力，因为一尘不染的历史与从未被检查过的历史无法区分。

经济账

这里是商业上的点睛之笔。在大多数组织里，验证是一个成本中心，其中的员工巴不得自己在干别的任何事。而一旦验证随产品交付，局面就翻转了：验证包成了买方无法廉价自造的东西。一家 CRO 可以在一个下午下载一个制表引擎；但它下载不到一套针对所声称能力、可追溯地执行过的确认套件——附可复现的运行和维护中的可追溯性矩阵。这个包——乏味、一丝不苟、随产品附赠——是一条用纸面工作筑成的护城河，而且没有人需要假装享受写它的过程，因为其中的大部分是系统自身运行的副产品。

检验。 问任何一家供应商："把我今天将要运行的那个确切版本的验证包交给我，并让我亲自重跑一次确认。" 如果这个包过时了、超范围了、缺货了——或者重跑需要用供应商自己的笔记本——那这份验证属于他们的销售流程，而不属于产品。