Parallel Verification（简称 PV，并行验证）是一种“最后一公里”的集成验证实践，其目标是从外部确认一个系统确实做到了它所声称的事情。它之所以重要，是因为单元测试与验收测试都运行在系统自身的世界观内，它们信任代码的 mock、内存状态以及关于“发生了什么”的自我断言。资料指出，这种信任正是问题所在：提供者可以返回一个声称证书存在的状态文件，API 可以返回 201 Created，代码可以通过所有测试，而真实的存储后端里却什么都没有真正落地。
PV 的核心是“双观察者”原则：系统自我报告（其 API 响应、状态文件、返回值）与后端真实状态（独立 CLI 在真实记录系统中看到的内容）必须一致，两者的差异就是发现项。验证路径不得与受测对象共享代码、库或信任关系，这种独立性是 PV 的整个要点。资料强调，代码作者（人类或智能体）可以让代码撒谎，但无法让 psql、RACDCERT、AWS CLI 或 Vault CLI 对实际存储的内容撒谎。称为“并行”有两个原因：一是它作为单元/验收测试金字塔的平行轨道，完成后者无法完成的完整集成验证；二是其交付物是一个独立于编写代码上下文的独立装置，人类或 CI 任务可以冷启动重跑。
交付物始终为两件。第一是“可复用的测试装置”：通常是可执行脚本（bash），用于生成输入、驱动系统、执行最后一公里验证，并在任何不匹配时以非零退出。它位于独立的、自包含的目录中，任何人都可以隔离重跑；它不是一次性用品，而是保留的证据。第二是“发现报告”（FINDINGS.md），即人类可读的结论：验证了什么、证据是什么，以及超越通过/失败的任何发现（严重性、根因、修复建议）。
关于装置的位置，资料强调：在写任何东西之前先决定装置放在哪里，并且不要假设。应询问用户，默认使用 ./scratchpads/，建议 ./scratchpads/<feature>-pv/，让用户确认或改到其他位置。每个 PV 测试都是原子且自包含的，在选定位置下拥有自己的目录，包含自己需要的输入文件（如 main.tf、请求负载）、自己的运行脚本、日志和状态。测试必须能够隔离运行、以任意顺序运行，不依赖其他测试的搭建或残留，且其清理陷阱只能移除自己创建的内容。
PV 的核心循环适用于任何后端，后端只改变第五步的具体机制。步骤包括：一，识别契约，明确系统声称做什么、真相最终存在于哪里（Postgres 行、RACF 配置文件、Vault 路径、Okta 用户、S3 对象）；如果效果不落在任何可外部检查的地方，PV 可能不适用。二，生成真实输入，产生能覆盖真实表面积的负载/配置，而不只是快乐路径。三，将系统作为黑盒操作，通过其真实公开接口驱动（如 terraform apply、curl、CLI、SDK 公开 API），绝不深入其内部。四，捕获系统的自我报告作为“期望”，记录 API 响应体、terraform.tfstate、CLI 输出、返回的 ID/序列号等，并解析为结构化值。五，经独立路径对真实状态做最后一公里验证，得到“实际”，例如 REST API 落到 Postgres 用 psql SELECT，AWS 用 aws CLI 描述真实资源，IBM z/OS RACF 用 SSH + tsocmd "RACDCERT ... LIST"，Vault 用 vault CLI 读取路径，Okta 用 REST API 或 CLI 获取用户/组/应用。资料提醒，最后一公里方法往往不明显，不确定时应询问用户，而不是猜测。六，逐字段比较，对每个重要属性比对期望与实际，按 PASS / FAIL / WARN 输出。七，超越创建阶段探测，包括幂等性（无输入变化重跑，不应有漂移，Terraform 中 plan -detailed-exitcode 返回 2 表示漂移）、更新/续期、拆除（确认后端干净无孤儿或幽灵条目）、失败与回滚。八，报告，产出机器摘要（计数、退出码）与 FINDINGS.md 文字报告，不仅呈现通过/失败，还要呈现学到的任何东西。
选择最后一公里方法时，资料强调这是判断密集的一步：好的路径应是独立的（不复用受测系统自身代码来读回）、权威的（读取真实记录系统而非缓存或镜像）、可在字段级别检查的（能提取具体值做比较）。当路径确实不清楚（不寻常的后端、内部系统、模糊的“真相”或凭证缺失）时，应询问用户，提供可见选项让用户选择或纠正。资料警告，猜测最后一公里方法并向错误的真相来源验证比询问更糟，因为它会产生一个自信但没有意义的绿色结果。
装置约定方面，资料建议不要每次都重新发明脚手架，应先阅读 harness-conventions.md 中提炼的可复用 bash 模式，包括带计数器的彩色 PASS/FAIL/WARN 日志、参数解析、凭证解析顺序（标志 > 凭证文件 > 环境变量）、前置条件与连通性检查、基于 jq 的状态解析、分阶段运行器（--phase N）、跨阶段事实捕获、总会拆除的清理陷阱以及有意义的退出码。关键不变量包括：任何 FAIL 都要非零退出（退出码即裁决，CI 依赖它）；始终清理（用 trap 保证中途失败仍能拆除创建的资源，孤儿会污染下一次运行和真实环境）；捕获证据（记录实际比对的后端输出，让读者看到检查为何通过或失败）。
发现报告 FINDINGS.md 的结构应让审阅者五秒内得到结论、按需深入。资料给出示例结构：标题含功能与环境/主机，结果段为一句话结论；验证内容表含检查项、结果、证据；状态轨迹表（如涉及生命周期）；新发现章节按 FINDING N、标题、严重性、合并影响组织，含观察、根因与具体修复/行动项；建议部分给出 ship / ship-after-fix / block 及理由；复现部分给出重跑装置的精确命令与前置条件。证据列最重要，应引用真实看到的序列号、行或 CLI 输出。
资料还提供针对不同后端的配方文档：terraform-providers.md 覆盖任何 Terraform 提供者（dev overrides/本地提供者、apply、解析 terraform.tfstate、幂等性的 plan -detailed-exitcode、apply/plan/renew/destroy 阶段模式及按目标分支最后一公里）；rest-api-database.md 覆盖效果落到数据库的 REST/gRPC API（负载生成、curl 黑盒驱动、捕获响应、psql/mysql/mongosh 的 SELECT，包括反向检查：经 API 删除后确认 DB 中消失）；vault-and-secrets.md 覆盖 Vault 引擎与密钥存储；okta-and-saas-apis.md 覆盖 Okta 与 SaaS-API 后端；ibm-zos-racf.md 覆盖经 SSH + TSO 的 IBM z/OS RACF（tsocmd、RACDCERT），包括表示真实失败的消息码。若后端未被覆盖，则应用核心循环，使用 last-mile-catalog.md 选择路径（不确定时询问用户），并遵循 harness-conventions.md 搭建脚手架。