跳至正文
一个稳定身份 默认由人工编写 为可移植性而设计
Topoloom by Relia1

平台

从自然书写到 相互连接的系统模型。

Topoloom 让文档和图表保持易于阅读,同时明确呈现重要对象、关系、版本与变更。

架构概览草稿

结账流程将已授权请求路由至 Payment Service。

可复用对象 · ServicePayment Servicesvc.payment

人工编写声明

图表节点svc.payment引用 · 并非复制
自然正文稳定身份类型化模型

日常编写

熟悉的工作界面就是基础。 并非妥协。

在人能直接阅读的文档和图表中完成编写、绘制、审查、搜索、浏览、导入和导出。形式化结构只在能改善复用或治理的地方出现。

  1. 01技术文档
  2. 02结构化图表
  3. 03实时协作
  4. 04语义变更审查
  5. 05权限感知搜索
  6. 06历史与恢复
  7. 07文档导入
  8. 08不可变发布与导出
Topoloom Library 显示 Engineering、Operations 和 Team Handbook 等 Collection,以及文档和图表条目
Payment Service Overview 和支付授权图表位于同一个 Library 中,成果物类型和状态清晰可见。 产品UI以英语显示查看图片详情

可实际验证的流程

跟随一个Service,从编写到导出。

Service是系统的一部分,例如支付处理。六项检查都使用同一个Service,并记录在评估中实际可用的行为。

  1. 01
    尝试操作

    写下说明

    在文档中描述Payment Service,并请同一Workspace中的另一位成员与你共同编辑。

    检查什么

    编辑器截图显示已保存的文字和另一位编辑者;它并不能证明后续所有步骤。

    查看产品截图
  2. 02
    尝试操作

    为Service赋予一个身份

    将Service确认为可复用对象,即一份可由文档和图表指向的共享记录。

    检查什么

    对象截图显示负责人和版本历史。该裁切未显示Used in列表,因此复用仍需另行测试。

    查看产品截图
  3. 03
    尝试操作

    在两份文档和一张图中复用

    插入指向同一对象的引用。按需添加Runbook(恢复步骤)和SLO(可靠性目标)。

    检查什么

    打开每个引用并比较对象ID;同名并不足够。分别测试跟随最新版本的引用和固定到某个版本的引用。

    在演示中测试
  4. 04
    尝试操作

    审查一次变更

    修改负责人或依赖关系,比较保存的版本,以查看被称为semantic change的含义变更。

    检查什么

    图表对比截图显示引用变更和新增项目。请测试自己的负责人变更,以及谁能批准它。

    查看产品截图
  5. 05
    尝试操作

    工作准备好后再发布

    尝试内置Service Overview Contract。这套规则会在受治理发布前检查Service名称和所属Team。

    检查什么

    未完成的草稿仍必须能保存。确认启用的审查规则,以及选择哪个已保存版本进行发布。

    在演示中测试
  6. 06
    尝试操作

    在Topoloom外打开导出

    导出选定内容,打开可读文件、共享记录以及列出遗漏或变更信息的报告。

    检查什么

    截图显示导出完成。请检查实际归档以确认内容,并在提供方不可用时重复测试。

    查看产品截图

这些真实截图于2026年9月提供,各自展示一个独立的产品状态,而非一场完整评估的连续记录。请在演示中确认版本和已启用功能。

产品证据

Map说明文档中的关系。

当前文档模式是Content和Map。这里的STORES_IN表示Payment Service将数据存入Payment PostgreSQL。

文档关系视图显示带类型的文档项;Payment Service 到 Payment PostgreSQL 的 stores in 关系已选中,旁边显示检查器
关系具有明确含义:Payment Service 将数据存储在 Payment PostgreSQL 中。节点是文档中的项目。 产品UI以英语显示查看图片详情

检查共享记录

打开引用背后的对象。

将其ID、负责人和版本与你插入的引用比较。选择让引用跟随最新对象版本,或固定在某个版本。

Used in列出你有权阅读的固定文档或图表版本中的引用。这些版本不可变,内容不会改变;不包括实时草稿。该裁切未显示列表。

Payment Service 对象详情显示负责人 Payments Team、当前 Version 2,以及不可变的 Versions 1 和 2
查看 Service 的负责人和当前对象版本,再打开不可变版本中记录的属性。 产品UI以英语显示查看图片详情

能力边界

了解每一步覆盖什么。
在你的环境中验证。

上面的工作流提供六项检查。这些边界说明应检查什么、哪些状态保持分离,以及现有环境在何处影响结果。

01 / 引用范围

检查哪些版本使用该对象。

Used in会列出你有权阅读的不可变制品版本中的引用,包括未发布版本;不包括正在编辑的草稿。

02 / 图表含义

区分已声明边和视觉连线。

类型化节点和已声明边携带来源。仅用于视觉说明的连接线不主张同一关系。

03 / 变更审查

在编辑之外检查含义。

通过稳定身份检查负责人、依赖、目标和Decision变更;确认Workspace中启用的审查规则。

04 / 发布规则

测试内置 Contract。

Service Overview会检查受治理的发布,却不会阻塞普通草稿保存。自定义Contract创作属于后续能力。

05 / 外部上下文

确认需要的提供方。

已配置提供方的上下文会保留归属,并与人工编写知识分开。参考工作流使用模拟提供方;真实连接器需要另行确认。

06 / 导出范围

打开包及其报告。

检查可读内容、ID、版本、关系、来源、审查、权限映射和遗漏。带源引用的Diagram导出使用topoloom.package/4。

AI-ready,无需依赖 AI

对机器有用。 仍由人掌控。

配置后,搜索、RAG和GraphRAG等检索管线以及Agent都可以使用这些知识。Topoloom提供结构化、带版本、遵循权限的输入,同时让AI置身于权限、审查批准和发布决策之外。当前版本中,Knowledge Review背后的建议引擎是一套确定性的离线规则:没有模型参与。

01 / 身份

稳定身份

检索可以跨文档、图表、版本和导出引用同一个对象。

02 / 权限

权限上下文

搜索、引用、事件、导出和生成视图在展示任何内容前都会再次检查你的权限。

03 / 来源

来源与生命周期

来源说明一项陈述从何而来;生命周期说明哪个版本是当前版本。读者可以区分声明与建议、已发布版本与被替代版本,以及它们与外部上下文的区别。

04 / 独立性

不依赖提供方

AI或上下文提供方故障时,编写、协作、审查、历史和本地导出仍会继续。Knowledge Review建议也会继续:当前分析既不需要模型,也不需要网络调用。

聚焦的产品演示

带来团队每天都在 说明的工作流。

查看同一个Service如何贯穿正文、系统图、Runbook、SLO和语义审查。

申请演示 探索可信设计

产品截图