Specification

Specification

Normative UAI and UAI-1 records and the workflow that connects text, schemas, the field registry, operating-surface guidance, examples, validation, and release evidence.

  • Record UAIX-SPEC-0045
  • Path /en-us/specification/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-SPEC-0045
Surface
Specification
Access
Public and linkable

How to use this page

Use this page to see how UAI-1, schemas, registry entries, examples, and validation work together.

Role of the specification series

The specification section is the canonical written layer of UAI-1. Read it when you need the public contract, the semantic boundary of the standard, and the meaning that the machine-readable artifacts are expected to preserve.

How the current public record fits together

  1. UAI-1 defines the common envelope, profile semantics, support boundary, and conformance expectations.
  2. Schemas and the field registry turn that contract into machine-checkable structure and public keyed-to-keyless order.
  3. Project Handoff explains the draft AGENTS.md and .uai repository context layer for moving project state between AI models, agents, teams, and companies.
  4. Registry publishes the six current profile identifiers, their compatible pairings, and their schema/example links.
  5. Examples show request, response, capability, error, conformance, and async task-status records in working form.
  6. The Validator applies both structural validation and policy checks so the same public record can drive review and release gating.
  7. Implementations, Governance, and the Changelog explain what is currently supported and how changes become public truth.

Current published profile family

  • uai.intent.request.v1 starts an explicit piece of work against a declared subject.
  • uai.intent.response.v1 closes that work or acknowledges it while preserving the same envelope.
  • uai.capability.statement.v1 publishes supported operations, profiles, endpoints, and security schemes.
  • uai.error.v1 gives failures a typed, path-aware public shape.
  • uai.conformance.result.v1 carries validator evidence in the same standards family.
  • uai.task.status.v1 keeps long-running async work visible instead of collapsing into private workflow state.

How to read the boundary correctly

  • Use UAI-1 as the public exchange and release-record layer, not as a demand to replace every local tool bus, runtime protocol, or trust stack.
  • Use adjacent orchestration or tool protocols for local execution concerns, then map the externally reviewable record back into UAI-1 when public interoperability matters.
  • Use credential, signing, and transport systems as companion layers that are declared in the envelope rather than hard-coded as one mandatory stack.

Machine-readable discovery

Automation should resolve the public record through the discovery manifest and standards catalog rather than scraping page text. The discovery surface names the current routes, counts, and well-known entry points for the release.

Discovery

Machine-readable standards discovery

UAIX publishes a durable manifest so implementers, validators, and downstream tools can discover the current UAI-1 surfaces, including the adoption-kit bundle and live reference exchange route, without scraping the public pages.

Discovery manifest

Well-known entry points

Use the `.well-known` manifest for durable site discovery, or the REST discovery route when you want the same data from the API surface. Production deployments should publish the same manifest from the canonical HTTPS origin.

Release
UAI-1
Profiles
6
Generated
2026-04-26T15:33:17+00:00

Public routes

Current machine-facing surface

The manifest advertises the API and public publication paths that make up the current UAIX standards surface.

  • Catalog: /wp-json/uaix/v1/catalog
  • Schemas: /wp-json/uaix/v1/schemas
  • Registry: /wp-json/uaix/v1/registry
  • Field registry: /wp-json/uaix/v1/field-registry
  • Transport bindings: /wp-json/uaix/v1/transport-bindings
  • Trust channels: /wp-json/uaix/v1/trust-channels
  • Conformance levels: /wp-json/uaix/v1/conformance-levels
  • Error registry: /wp-json/uaix/v1/error-registry
  • Examples: /wp-json/uaix/v1/examples
  • Validate: /wp-json/uaix/v1/validate (POST JSON)
  • Adoption kit: /wp-json/uaix/v1/adoption-kit
  • Mock exchange: /wp-json/uaix/v1/mock-exchange (GET metadata, POST message)

Next step

Continue to UAI-1 for the normative contract, then move through Schemas, Registry, Examples, and the Validator in that order.