第二部分 — 文献：领域现状

文献综述三：平台与生态版图

验证总是发生在某个东西之内。本章勘察这些"东西"：商业化的已验证 平台、开源组件生态，以及填充两者之间地带的实践者报告。

在位者层级

对"受监管的分析应当在哪里运行"这个问题，默认答案仍是商业化的已验证 平台——在许多大型组织中历来是 SAS 的 Life Science Analytics Framework；在 R 一侧，则是 Posit 的企业级组合：Workbench、Package Manager 与 Connect。这个层级出售的产品，主要不是软件，而是厂商的 担责：他们的验证包、他们对审计的应答、他们的支持渠道。订阅费买的就是 这个，这既解释了这一层级的耐久，也解释了它的价格。

其诚实的局限是结构性的：封闭平台是一场单一谈判。如果它的路线图、定价 或托管模式与你的需求分道扬镳，你的选项只有迁移或迁就。对大型组织而言， 这笔交换往往是对的。对小型组织，那是一份为别人的问题量身定做的订阅。

开放组件层级

在另一极，是本书已经引用过的那些生态。pharmaverse 网络精选了约五十个 软件包，横跨整条链路——admiral 负责 ADaM 衍生，metacore 与 metatools 负责元数据驱动的开发，rtables、tern、rlistings、Tplyr 与 tfrmt 负责 表格，teal、siera 与 autoslider 负责交互式审阅，cards 与 cardx 负责 分析结果数据，logrx、covtracer 与 riskmetric 家族负责与验证相邻的 需求，pharmaverseadam 与 pharmaversesdtm 提供合成数据，pkglite 与 xportr 负责递交打包，whirl 负责带日志验证的流水线执行。Insights Engineering 的 NEST 家族贡献了 rtables/tern/rlistings/teal/formatters 技术栈、scda 合成数据包，以及——对后面章节尤为重要的——作为独立产品 的 TLG Catalog。

关于这个层级，有两个事实比任何功能清单都重要。其一，它自身的治理是 坦诚的：pharmaverse FAQ 对 GxP 保障那句干脆的"No"(第 5 章)。其二， 是它的时间线：NEST 项目的公开历史，从 2017 年的概念验证，到 2020 年 为一个监管计算环境所做的内部验证，再到 2022 年支撑首个基于 R 的 FDA 递交——这提醒我们：即便是资金最充裕的开源技术栈，从想法到受监管使用 也走了半个十年，而环绕它的那座工厂从未开源。

实践者层级

在两极之间，有一层单薄但正在生长的实践者报告文献，记录着小型组织实际 建造的东西。本书取材(也有所贡献)的最详尽的近期例子，是一篇 PHUSE 报告：用一个组合的 Docker 平台替换厂商托管的单一 Shiny 服务器——一台 主机上跑二十一个服务：十四个 Shiny 审阅应用、一个 R API、五个 Python 服务、一个反向代理——仅有一个加密入口，一个共享认证模块在本地核验合 作方的签名令牌，一切数据访问经由同一个 API，仅限流水线的部署方式，配 十三项健康检查与一条命令的回滚，每一个重要决定都有一页纸的决策记录。 论文对自己的边界毫不含糊——内部探索性审阅，而非已验证系统——并提炼 了"自建还是购买"的规则，本书将在第四部分将其一般化。

空着的格子

把三个层级放到一张能力对担责的网格上：在位者有担责而无组合性； 生态有组合性而无担责；实践者报告展示了组合可行，却自觉地停在 GxP 线 外。没有人占据第四个格子——一个自己生成担责的组合系统：开源部件 被信任层包裹，每一份输出都随附证据。这个空格子，以市场观察的形式 说出来，就是本书的论题。

检验。 当某个厂商或生态的推销找到你时，用一句话把它放上那张 网格："这东西出故障时谁担责，他们拿什么作为证明交到我手上？" 需要一通销售电话才能解读的答案，属于前两个层级。第四个格子在你 开口之前，就用工件作答。