svc.payment按角色做决策
一个Service模型。 不同的问题需要回答。
选择你负责的决策。每个角色都可以测试同一个Service，而不把已声明模型当作实时运行证据。
Tech Lead / Architect
Service说明、图表、架构决策和运维说明可能在不同时间发生变化。
跨有权阅读的不可变制品版本检查Service身份和已声明的依赖关系。
Head of Engineering
跨团队的负责人决策需要看清谁声明了负责人，以及哪些知识依赖于这项决策。
结合来源和版本上下文，审查负责人、依赖、Runbook和SLO的覆盖范围。
CTO
共享模型可以减少重复工作，但设置、审查和发布规则同样需要时间。
比较在现有工具和Topoloom中更新、审查一个Service的工作量；在不阻塞草稿的前提下测试内置发布规则。
CIO
采用决策既需要权限感知、可移植的知识模型，也需要明确运行条件。
检查选定Service的访问、来源和导出，并记录所评估环境的条件。
SRE / Platform
交接期间，已声明的负责人和恢复步骤需要易于查找和核实。
在实时状态仍由监控工具负责时，结合阅读Service负责人、关联Runbook和SLO。
选择第一个用例
选择一项团队 能够验证的变更。
如果你负责Service、维护平台或响应事故，可从一次负责人变更或缺失的恢复步骤开始。选择一项可共同验证的工作。
- 01Service 负责人对象ID · 语义差异 · 已授权版本引用
审查一次负责人变更。
选择一个Service和一个Team，找到其引用，修改已声明负责人，再比较保存的版本。
- 02架构 / ADR 审查类型化边 · 来源 · 源导航
追踪一次依赖决策。
声明重要关系，并在更新后检查其源、目标和Decision状态。
- 03可靠性覆盖Runbook/SLO 链接 · 已授权源 · 监控检查
检查一条交接路径。
找到Service已声明的Runbook和SLO链接，再在运维工具中确认实时状态。
- 04外部差异审查提供方身份和时间 · 分离的人工编写状态
比较一项提供方发现。
配置兼容提供方后，在接受任何人工编写变更前检查其带归属的上下文。
- 05AI-ready 知识稳定ID · 版本 · 权限与来源
测试一条检索回答。
检查回答是否指向已授权版本并显示其来源，然后与源内容比较。
范围明确的评估
用小测试和 书面记录做决策。
在扩大范围前，约定基线、执行者、可投入时间以及何种结果算有用。
- 01记录基线
选择一个Service、两份文档、一张图，以及一次负责人或依赖变更，记录当前步骤和耗时。
- 02执行同一次变更
创建并复用一个对象，记录设置工作量、手工整理以及仍在模型外的副本。
- 03测试审查和故障
检查语义变更和发布检查。在Topoloom可用时，让上下文提供方不可用后重复测试。
- 04作出决策
打开导出和遗漏报告，将第二次更新与基线比较，记录缺口、负责人和下一次审查日期。