可复用对象
Payment Servicesvc.payment已声明 · 已发布 v8
稳定身份一个对象在正文、图表和运维知识中统一引用。
明确关系类型化连接每条已声明链接都说明连接的具体含义。
可审查变更影响清晰可见重要变更在发布前接受审查。
协作难题
知识会碎片化 就在系统连接之处。
Service 描述、图表、Runbook 和负责人信息往往演变成彼此独立的副本。它们看似相关，却不再共享身份、来源或审查上下文。
被复制的含义丢失的上下文
Payment Service 负责授权与结算...
负责人：Core PlatformCheckout → Payment
无类型连接线将故障升级至 Payments Team...
负责人：Payments Team负责人已变更。下游影响未知。
3 个副本 · 2 位负责人为什么是现在
AI 技术栈的可靠程度，取决于 它能信任的知识。
缺少身份、权限和来源时，搜索、RAG 与 Agent 只会放大技术知识原有的歧义。
不同副本对负责人给出不同答案。
负责人变化写进 Wiki，却没有同步到图、Runbook 或审查上下文。
关系只是文字或箭头时，很难评估影响。
审查者必须先重建依赖图，才能理解变更范围。
Runbook 和 SLO 与其服务失去联系。
覆盖缺口往往到事故或跨团队审查时才被手工发现。
搜索、RAG 与 Agent 使用权威不明的内容。
没有来源、权限和生命周期，答案会显得比证据更确定。
Topoloom 方法
书写自然。 需要时足够精确。
当一个概念值得被识别、复用、发布或治理时，再逐步引入结构。
在易读文档中工作
先在协作文档和图表中说明系统，再将关键内容正式化。
文档 · 区块 · 评论提升重要概念
将选定概念转化为可复用对象，并赋予关系明确含义。
对象 · 类型 · 关系复用一个稳定身份
在 Document Graph 中贯穿引用、来源与语义影响。
引用 · 版本 · 审查相互连接的知识闭环
一个 Service。五个人工编写界面。
沿着同一个稳定身份，查看工程团队如何说明、建模、运维和变更它。外部上下文始终位于闭环之外，默认不会进入其中。
Checkout 将已授权请求路由至 Payment Service。
区块 14 · 人工编写Checkout APIDEPENDS_ON →svc.payment
类型化节点 · 稳定引用支付恢复
OPERATES → svc.payment结账目标
MEASURES → svc.paymentCore PlatformPayments Team
svc.payment已声明 · 已发布 v8
01正文
清晰可见的信任边界
在此声明。在别处验证。绝不混淆。
Service · svc.paymentPayment Service
负责人 · Payments Team
观察到的部署负责人不一致
建议 — 尚未声明
Topoloom 记录经授权人员所声明的内容。由外部系统决定哪些内容已通过验证。
可衡量的结果
衡量知识闭环， 而不是页面数量。
用有限工作流比较连接身份引入前后的维护、审查、覆盖与可移植性。
减少修改同一事实的位置。
跟踪对象复用率与尚未解决的副本。
更快理解负责人和依赖变更。
衡量审查者看清含义、来源和影响范围所需的时间。
提高负责人、Runbook 和 SLO 覆盖。
把隐藏缺口变成按服务可见的清单。
让全部知识可导出、可检查。
核验内容、结构、版本、来源、审查和权限映射。