是责任归属，不是作者署名
归属回答的是现在时的问题：今天谁对这个服务负责？作者署名属于历史。这个区别很重要，因为代码会易手、团队会合并，写下一个模块的人可能早已离开。归属元数据指明的是接收告警、批准变更、在故障中对外负责的团队。
放在哪里
归属应写在代码旁的服务描述文件里，字段要能解析到真实团队：用标识符而不是显示名称。服务目录、告警系统和权限评审都应读取同一个字段。在三个系统里各存一份归属，必然有两个是错的。
不只是一个团队名
一次呼叫需要一条路径：负责团队、升级路径和值班轮换。值班表每周变化，而归属很少变化，因此两者应分开存储但保持关联。例如，告警规则可以先由服务解析到团队，再由团队解析到当前值班，无需为每次排班调整而修改告警。
保持最新
归属会在组织调整中腐烂。增加定期检查，确认每个服务都能解析到现存团队，并在描述文件指向已解散团队时让构建失败。把归属评审放进季度规划，因为那时本来就要讨论团队转手和新服务。
与散文化文档的对比
wiki 页面可以描述归属，但任何告警路由都无法读取它。机器可读的元数据才能驱动自动化：路由、权限申请、漏洞派单和成本分摊。元数据并不取代关于责任的沟通，它只是让沟通的结论能被系统使用。