要证明什么
验证管理回答：某一资产在某一版本上，是否按需求完成挑战，证据与批准是否齐全。正式 Word/PDF 交付物走 QualityDocs 生命周期。
分层对象
| 对象 | 用途 |
|---|---|
| 验证实体家族 | 相同/等价资产的分组，共用强制需求 |
| 验证实体 | 被验证的资产（如一条 MES、一条产线） |
| 验证实体版本 | 资产在某时点的版本；需求、活动、交付物挂在版本上 |
| 验证需求 | 要挑战的 URS/FRS/规格条目 |
| 验证活动 | 一次项目：范围、起止、参与人、交付物包 |
| 验证交付物 | 活动中的占位；正文在文档或测试记录上 |
不要只对笼统「资产」挂需求——挂在被挑战的 实体版本 上。
验证团队 vs 脚本角色
| 层 | 作用 |
|---|---|
| Validation Team（实体分配） | 谁能看见该实体下需求、脚本、交付物 |
| 脚本生命周期角色 | 编写、执行、独立复核、批准 — 通过 Sharing 与字段 + 工作流任务 |
两层不要混用：团队分配不派发执行任务。
活动生命周期（摘要）
- 创建活动，挂到实体版本。
- 维护交付物清单（计划、测试协议等）。
- 送审 → 工作流任务批准（见 测试执行）。
- 完成活动 前检查：交付物状态、脚本结论是否齐；不齐则不能完成。
与 QMS / 变更的交叉
工艺或系统变更（QMS 变更控制）可能要求新的 验证活动 或回归 OQ。需求描述里可引用变更号与受控 SOP（DOC-*）。
常见问题
| 现象 | 建议 |
|---|---|
| 需求挂错层 | 改挂到 实体版本 |
| 看不见脚本 | Validation Team 分配或 DAC |
| 活动完不成 | 跑完交付物与脚本终态检查 |