明确职责，再规划采用方式

选择有用且范围明确的服务

从真实需要和组织能理解的范围开始。不要只选择演示效果最好的服务，或最关键的系统。

一家虚构公司选择制作内部报告，用于规划团队工作量。设置期间使用获准的合成记录。初始结果很具体：获授权的经理可以生成并检查一份报告，且计算过程可以追溯。

范围不包括员工绩效决策、生产环境中的真实人事记录，以及对其他系统的自动修改。这些排除项界定了当前授权。后续扩大范围，需要重新评估。

一个人可以承担多个角色。不要因为团队小，就默认某个角色已经有人承担。对于可能阻碍持续工作的决定，记录替代负责人。

使用运行模式练习识别缺失的负责人和证据。输出是一份行动清单，不是认证或就绪分数。

报告的验收要求包括计算正确、未获授权角色的访问被拒绝，以及部署可重现。运维负责人还需要经过测试的恢复流程和事件响应路径。

记录当前工作的基线。衡量取得已验证结果所需的时间、审查投入、返工和运维成本。不要把生成代码行数当作业务价值。

在首次出现问题前，定义停止条件。例如，未经批准的数据传输、原因不明的权限变化，或必要发布决定缺少证据。说明谁停止受影响工作，以及谁可以授权继续。

根据最初标准复核实际情况。决定继续、缩小范围、修正缺口，还是停止。记录原因和证据。

成功的报告工作流，不能证明面向客户的支付服务已经就绪。新的数据类别、用户、权限和故障后果会改变评估。可以复用运行模式，但仍需检查新要求。

启用 Taiga 时，将这些职责关联到实际的组织、工厂、产品、代码仓库和环境。区分合同状态与运行状态。产品完成配置，并不代表合同已经签署或生产使用已经获准。

继续编写决策记录，明确假设和下一次复核。