UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIX.org Universal Artificial Intelligence Exchange Public standards publication
Current UAI-1
  • Current version UAI-1
  • Plain-English definition Open message format for auditable AI-to-AI exchange
  • Current attribution Michael Joseph Kappel, MCP
  • Start here Get Started, Project Handoff, UAI-1, validator, roadmap, and changelog

Schemas

Schemas

Published UAI-1 schemas, field-order governance, validator policy checks, and the line between machine rules and the written specification.

  • Record UAIX-SCHE-0050
  • Path /en-us/schemas/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-SCHE-0050
Surface
Schemas
Access
Public and linkable

How to use this page

Use this page for the published schemas that check UAI-1 messages before release.

What the schema set validates

The schema set turns UAI-1 into published validation targets that tools, CI runs, and runtime bridges can apply consistently. The current schema family validates both the shared envelope and the profile-specific body shapes used by the public record.

Current machine-validated envelope

  • Identity: version, profile, message ID, source, and target.
  • Workflow state: conversation continuity, delivery mode, expiry, acknowledgement, and optional task references.
  • Trust posture: channel, auth scheme, principal, optional credential reference, and optional replay-window hints.
  • Auditability: provenance, integrity, and controlled extension metadata.

Current schema families

  • uai.intent.request.v1 validates request-side intent, subject, constraints, and response expectations.
  • uai.intent.response.v1 validates result-side status, request linkage, notices, and optional task handoff.
  • uai.capability.statement.v1 validates discovery-facing operations, profiles, endpoints, and security schemes.
  • uai.error.v1 validates typed public failures with status, code, detail, and structured sub-errors.
  • uai.conformance.result.v1 validates exported validator evidence and artifact references.
  • uai.task.status.v1 validates async progress, state, result references, and update notes.

What the schemas do not do alone

Schemas are necessary but not sufficient. The validator still applies policy checks such as delivery expiry, trust-reference hints, accepted-response task references, task-status progress consistency, and conformance-summary integrity. The written record still carries semantic intent and support-boundary meaning.

Published schema catalog

Use the catalog below when you need the exact current schema documents that the validator and examples are built against.

Machine-readable publication

Published UAI-1 schemas

These JSON Schema records are the implementation-facing contract for UAI-1 profiles. They now cover conversation continuity, delivery semantics, trust metadata, async task state, and richer validator evidence in addition to profile-specific body rules.

Open schema collection JSON Open field registry JSON

Schema record

UAI Intent Request v1

Schema for explicit intent requests in the richer UAI-1 public exchange envelope.

Profile
uai.intent.request.v1
Spec
UAI-1
Required body fields
intent, subject, requested_profile, parameters, constraints, response_profile
Route
/wp-json/uaix/v1/schemas/uai.intent.request.v1
Open schema JSON Open example JSON

Schema record

UAI Intent Response v1

Schema for direct-result and accepted-task responses in the richer UAI-1 public exchange envelope.

Profile
uai.intent.response.v1
Spec
UAI-1
Required body fields
status, subject, request_message_id, result, notices
Route
/wp-json/uaix/v1/schemas/uai.intent.response.v1
Open schema JSON Open example JSON

Schema record

UAI Capability Statement v1

Schema for discovery-facing capability, endpoint, security, async, and extension declarations in UAI-1.

Profile
uai.capability.statement.v1
Spec
UAI-1
Required body fields
capability_id, version, operations, input_profiles, output_profiles, async_profiles, security_schemes, endpoints
Route
/wp-json/uaix/v1/schemas/uai.capability.statement.v1
Open schema JSON Open example JSON

Schema record

UAI Error v1

Schema for typed validation, transport, authorization, and execution errors in the richer UAI-1 envelope.

Profile
uai.error.v1
Spec
UAI-1
Required body fields
type, title, detail, status, code, retryable, instance
Route
/wp-json/uaix/v1/schemas/uai.error.v1
Open schema JSON Open example JSON

Schema record

UAI Conformance Result v1

Schema for validator outputs, linked artifacts, and issue reports in the richer UAI-1 envelope.

Profile
uai.conformance.result.v1
Spec
UAI-1
Required body fields
status, checked_profile, issues, summary, artifacts
Route
/wp-json/uaix/v1/schemas/uai.conformance.result.v1
Open schema JSON Open example JSON

Schema record

UAI Task Status v1

Schema for long-running async task state in the richer UAI-1 public exchange envelope.

Profile
uai.task.status.v1
Spec
UAI-1
Required body fields
task_id, state, subject, progress, status_message
Route
/wp-json/uaix/v1/schemas/uai.task.status.v1
Open schema JSON Open example JSON

Published field registry

The field registry keeps the keyed JSON source record, the keyless transport order, and the nested body/component order aligned across the public contract. Treat it as part of the machine-readable release record, not as an optional convenience note.

Field registry

Published keyless field-order registry

The field registry keeps optimized keyless JSON aligned with the readable keyed source record. Treat it as the public map for envelope order, nested component order, and profile-specific body order.

Open field registry JSON

Envelope order

Root fields for keyed and keyless records

  1. uai_version: Declares the active UAI protocol release for the message.
  2. profile: Selects the exact published message profile.
  3. message_id: Stable message identifier used for review, tracing, and cross-record references.
  4. source: Describes the sender or producing system.
  5. target: Describes the intended receiving system, record, or audience.
  6. conversation: Carries conversation continuity, turn identity, and parent linkage.
  7. delivery: Carries sync versus async mode, priority, expiry, and acknowledgment expectations.
  8. trust: Declares trust-channel, authentication, credential, signature, and replay-window hints.
  9. body: Profile-specific payload content.
  10. provenance: Carries trace, lineage, issued-at, and model or agent provenance details.
  11. integrity: Carries checksum, algorithm, and canonicalization information.
  12. extensions: Lists declared extension namespaces attached to the message.

Component order

Nested structures that stay stable across profiles

  • source: type, id, label, uri, did, role, implementation
  • target: type, id, label, uri, did, role, implementation
  • conversation: conversation_id, turn_id, parent_message_id, traceparent, sequence
  • delivery: mode, priority, expires_at, reply_requested, ack_required, task_ref
  • trust: channel, auth_scheme, principal, credential_ref, signature_ref, replay_window_id
  • provenance: trace_id, parent_trace_id, issued_at, log_ref, agent_id, model_id, confidence, lineage
  • lineage_item: stage, actor_id, model_id, note
  • integrity: version, algorithm, canonicalization, checksum
  • extension_item: namespace, purpose, critical
  • issue_item: severity, code, message, path, help_url
  • error_detail_item: path, code, message

Body order

uai.intent.request.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

intent, subject, requested_profile, parameters, constraints, response_profile

Body order

uai.intent.response.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

status, subject, request_message_id, result, notices, task_ref

Body order

uai.capability.statement.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

capability_id, version, operations, input_profiles, output_profiles, async_profiles, security_schemes, transport_bindings, conformance_levels, error_codes, endpoints, extension_namespaces, implementation_tracks

Body order

uai.error.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

type, title, detail, status, code, retryable, instance, errors, next_step

Body order

uai.conformance.result.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

status, checked_profile, issues, summary, artifacts, target_message_ref

Body order

uai.task.status.v1

Use this ordered list when a transport chooses the optimized keyless form instead of readable keyed JSON.

task_id, state, subject, progress, status_message, result_profile, result_ref, blocking_reasons, updated_fields

How to use this section

  1. Choose the profile you want to support and resolve its schema.
  2. Check the matching Registry entry and the public field registry before implementing compact transport or body-order assumptions.
  3. Run the Validator with a published Example or candidate message and keep the result with release evidence.
  4. Carry any release-facing change into Implementations, the Changelog, and References and Contributors.

Next step

Continue to Registry for the stable profile map, compatibility cues, and schema-to-example links behind the current release.