多数集成页面数的是徽标，Tajo 数的是真正在运行的内容，并让你看清两者的差别。
“支持 199 项集成”这句话几乎可以指代任何情况，而且往往如此。Tajo 将这一说法拆分为若干层级，并给出严格、可验证的定义：哪些仅仅是被收录，哪些已接入受治理运行时，哪些可以安全写入，哪些已通过端到端认证。下表中的数字是平台当前的真实状态。这些数字变化时，本页面也会随之更新。
| 层级 | 当前 | 实际含义 |
|---|---|---|
| 已认证目的地 Brevo，拥有 7 个类型化写入目标。HubSpot 是正在成型的第二个目的地。 | 1 (+1 in progress) | 完整的受治理生命周期已通过端到端验证：类型化写入目标、审批关卡、验证证明与审计一应俱全，这是一项你今天就可以发布并在生产环境中运行的集成。 |
| 可写入 至少支持一项写入操作的运行时集成。 | ~19 | 这些集成可以通过运行时的关卡执行写入操作，包括一次性、输入绑定的审批与预算上限，但尚未在所有目标上获得认证标签。 |
| 已接入运行时 已接入实时运行时的集成。 | 53 | 已完成身份验证并在治理下运行。许多集成以读取为主：适合发现、抽样与草拟；写入能力会在通过审批关卡后逐步开放。 |
| 发现语料库 代理起草时所依据的、有文档记录的 API 操作。 | 27 vendors / 10,345 operations | 这并非连接，而是起草素材。当你的技术栈中包含这些供应商之一时，代理会依据其真实、有文档记录的 API 操作进行起草，而不是猜测接口端点。 |
| 已收录目录 集成目录中的条目。 | 199 | 路线图的呈现层：Tajo 已识别并界定范围的系统。仅有目录条目并不会移动任何数据，这一点我们不会讳言。 |
各层级按验证程度从高到低排列，覆盖范围逐层扩大。无论处于哪个层级，每一项集成都在同一套治理体系下运行：摘要绑定审批、默认拒绝的同意规则、预算上限，以及防篡改审计日志。完整生命周期请参阅 工作原理 页面。
每往上一层，门槛都会严格提高。收录一个系统很容易；将其接入受治理运行时需要投入；证明写入操作的安全性需要投入更多；而对每个目标进行端到端认证，则是投入最大的一步。这一层级体系准确展示了这些工作目前进展到了哪一步。
已认证目的地意味着每一个类型化目标都完整走过了整个生命周期：起草、验证、摘要绑定审批、经验证的执行，以及审计。我们采取的方式是逐一、严谨地认证每个目的地，而不是把这个标签批量贴到整个目录上。
晋级顺序由早期访问合作伙伴决定。如果你的技术栈需要接入某个语料库供应商，或需要将某个已接入的集成升级为可写入，这正是 Tajo 的代理与我们团队存在的意义：为你完成这类前线部署式的工作。
因为另一种做法正是行业惯例：一面徽标墙，过时的目录条目与久经考验的目的地看起来毫无二致，直到你的项目真正依赖这份差异的那一刻才现出原形。Tajo 的整个立足点在于可验证性：可核查的审批、能证明实际执行内容的运行记录，以及无法被悄悄篡改的审计轨迹。如果一份就绪度页面夸大了自己的数字，那会是这套产品一个奇怪的门面。而这一页，没有这样做。
早期访问合作伙伴决定接下来接入和认证哪些系统。告诉我们你需要连接哪些系统，我们会与你一起朝着这个方向构建。