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
- UAI-1 defines the common envelope, profile semantics, support boundary, and conformance expectations.
- Schemas and the field registry turn that contract into machine-checkable structure and public keyed-to-keyless order.
- Project Handoff explains the draft
AGENTS.mdand.uairepository context layer for moving project state between AI models, agents, teams, and companies. - Registry publishes the six current profile identifiers, their compatible pairings, and their schema/example links.
- Examples show request, response, capability, error, conformance, and async task-status records in working form.
- The Validator applies both structural validation and policy checks so the same public record can drive review and release gating.
- Implementations, Governance, and the Changelog explain what is currently supported and how changes become public truth.
Current published profile family
uai.intent.request.v1starts an explicit piece of work against a declared subject.uai.intent.response.v1closes that work or acknowledges it while preserving the same envelope.uai.capability.statement.v1publishes supported operations, profiles, endpoints, and security schemes.uai.error.v1gives failures a typed, path-aware public shape.uai.conformance.result.v1carries validator evidence in the same standards family.uai.task.status.v1keeps 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.