开始使用

curl -s http://uiax.org/wp-json/uaix/v1/catalog
curl -s http://uiax.org/wp-json/uaix/v1/schemas/uai.intent.request.v1
curl -s http://uiax.org/wp-json/uaix/v1/adoption-kit
curl -s -X POST http://uiax.org/wp-json/uaix/v1/validate -H "Content-Type: application/json" -d @validate-request.json
curl -s -X POST http://uiax.org/wp-json/uaix/v1/mock-exchange -H "Content-Type: application/json" -d @mock-exchange-request.json

这是给谁的#

如果您正在实施、评估、管理或引用需要声明、可审查结构的 AI 系统交换，请使用 UAIX。 UAIX 是公共标准与发布站点，UAI 是标准系列，UAI-1 是当前的规范版本。

按角色划分的读者路径#

• 实施者： 开始于 UAI-1，然后依次阅读 模式, 注册表, 示例，验证器， 和 实施轨道。
• 工具制造商： 开始于 模式, 注册表, 示例，验证器，以及已发布的发现表面，以便自动化可以干净地解析当前路线。
• 研究人员和标准读者： 开始于 UAI-1，然后使用 变更日志, 新闻， 和 参考资料与贡献者 当您需要公开修订轨迹和引用上下文时。
• 编辑、审阅者和贡献者： 开始于 参考资料与贡献者，变更日志, 新闻，以及 验证器 因此，提案将保留在公共记录中，而不是私人附注中。
• 公众读者和媒体： 从 新闻 开始了解公开发布路径，然后使用 媒体资料 和 参考资料与贡献者 用于面向外的语言和持久的链接。

UAI-1 解决什么问题#

UAI-1 为实施者提供了一个稳定的公共信封，用于身份、配置文件声明、意图、上下文、出处、有效负载传输、输出和错误。目标是使可互操作的机器通信比私有运行时方言更容易验证、审核和发展。

今天的公共工作是如何组织的#

UAIX 目前通过记录系列和实施轨道来组织其公共工作，而不是通过单独的活动日历、会员计划或广泛的社区门户。

• 使用 UAI-1, 模式, 注册表, 示例, 验证器， 和 实施轨道 作为技术采用的实用方案图。
• 使用 变更日志, 新闻, 参考资料与贡献者， 和 媒体资料 作为该地图周围的发布、引用和面向公众的支持层。

快速评估清单#

1. 确认当前公共记录存在于稳定的规范路由上： UAI-1, 模式, 注册表, 示例，验证器, 实施轨道，变更日志， 和 参考资料与贡献者。
2. 决定您是否需要当前发布的实施轨道或仅可移植基线。今天的公共轨道是 WordPress 发布轨道 和.NET 桥接轨道，如下所述 实施轨道。
3. 检查发布轨迹是否可见并且是最新的：使用 变更日志 和 新闻 查看更改的日期、解释以及如何链接回受影响的记录。
4. 检查贡献者和引文移交是否足以满足您的用例： 参考资料与贡献者 应该让另一个审阅者在没有私人注释的情况下解决相同的公共记录。
5. 将更广泛的公共联系渠道、指定的多利益相关者治理角色、单独的独立政策页面和其他运行时跟踪视为未来的工作，除非它们明确发布在网站上。使用 治理 和 参考资料与贡献者 了解当前发布的隐私、可访问性和公开表面上的分析状况。

首先要读什么#

1. 开始于 UAI-1 了解当前的规范消息模型。
2. 读 模式 和 注册表 在一起，以便字段规则、配置文件标识符和兼容性句柄保持一致。
3. 审查 示例 并运行 验证器 在将实现视为一致之前。
4. 使用 实施轨道 选择适合您环境的发布或运行时轨道。

采用清单#

1. 选择一个 UAI-1 配置文件并确认该配置文件为何与您想要支持的交换相匹配。
2. 使用显式版本、配置文件、源、目标、正文、出处和完整性字段构建或映射一条候选消息。
3. 在将消息连接到发布路径之前验证消息并保存结果。
4. 决定接下来的工作由哪个公共轨道进行：WordPress 发布、.NET 桥接集成或与公共记录相关的其他实施路径。
5. 在下游用户依赖该行为之前，在变更日志或发行说明中记录任何兼容性假设。

接下来您需要什么记录#

• 规范记录为 UAI-1。
• 机器验证目标 模式。
• 稳定的配置文件和标识符引用 注册表。
• 可复用示例位于 示例。
• 验证证据来自 验证器。
• 部署方向来自 实施轨道。

目前公开实施范围#

该公共网站目前记录了两个实施轨道 实施轨道： WordPress 发布路径和.NET 桥接路径。

• 除非已发布公共实施记录，否则请勿假设 Python、JavaScript、SDK、CLI 或其他运行时支持。
• 如果您正在评估另一个环境，请将 UAI-1、模式、注册表项、示例和验证器证据视为可移植基线，直到存在公共轨道。

最小首次成功路径#

1. 选择一个已发布的配置文件并构建与其声明的目的相匹配的消息。
2. 根据已发布的架构和注册表记录验证该消息。
3. 将消息与已发布的示例装置进行比较。
4. 将生成的验证记录保存为发布证据的一部分。

首次公开验证运行#

1. 从一个已发布的配置文件以及一个匹配的示例测试样例或保留在同一公共记录系列中的候选消息开始。
2. 解决匹配 模式, 注册表，以及验证之前的规范页面路径，以便其他审阅者可以重现相同的数据包。
3. 运行 验证器，导出结果，并保留检查期间使用的确切示例或候选消息。
4. 附上相关的 实施轨道 追踪， 参考资料与贡献者，变更日志， 和 新闻 一旦工作从本地测试转移到公共审查或发布环境中。
5. 将生成的数据包视为当前的公共一致性证据，而不是作为未来修订的永久认证。

在每个准备步骤中可以声明什么#

• 经过一次验证器运行后： 您拥有当前的公开证据，表明一条消息或测试样例与审核时发布的记录一致。
• 组装发布包后： 您可以将工作描述为已准备好发布，以便在所选实施轨道内进行公众审查。
• 存在公共实施轨道记录后： 您只能描述公开支持的指定跟踪和发布，并且只能在网站上规定的所有者和范围内。
• 不要将本地测试、一次通过的结果或未发布的运行时工作转化为认证、全面生态系统支持或永久兼容性的声明。

首次公开发布时应保留哪些内容#

• 导出的验证记录 验证器。
• 所选择的 实施轨道以及与其相关的任何打包或运行时注释。
• 参考资料与贡献者 用于稳定的发现和引用链接。
• 变更日志 当下游实施者需要迁移姿势时。
• 新闻 当工作需要面向公众的发布摘要时。
• 媒体资料 当发布还需要经过批准的面向外的语言时。

下一步#

继续 UAI-1，然后依次阅读 模式, 注册表, 示例，验证器， 和 实施轨道 按这个顺序。使用 参考资料与贡献者，变更日志， 和 新闻 以保持首次公开发布的可追踪性。