Examples

Why examples matter

Examples turn UAI-1 from a written contract into something teams can compare against running code. The current fixture set shows how the shared envelope, typed bodies, field-order governance, and validator evidence work together in real records.

What the current fixture set covers

• uai.intent.request.v1 for an explicit request entering the public contract.
• uai.intent.response.v1 for a synchronous result or accepted async handoff.
• uai.capability.statement.v1 for discovery-facing capability publication.
• uai.error.v1 for typed failure handling.
• uai.conformance.result.v1 for validator-backed evidence.
• uai.task.status.v1 for async progress, blocking reasons, and completion signals.

How fixtures connect to the rest of the record

• Each example should map back to a concrete UAI-1 behavior.
• Each fixture should satisfy the matching schema and published registry entry.
• Each keyless transport view should remain aligned with the keyed source record through the field registry.
• The same fixture should be usable as a regression baseline in the Validator.

How implementers should use examples

1. Start from the closest current fixture before inventing your own envelope variant.
2. Keep readable keyed JSON as the reviewable source record, then derive compact transport from the published field order.
3. Use request, response, error, and task-status fixtures together when your workflow can cross sync and async boundaries.
4. Keep the validator result with the fixture whenever the example becomes release evidence.

Published example catalog

The examples below are version-controlled public fixtures used by the validator and linked from the registry.

[uaix_example_catalog]

Copyable starter requests

Use the live snippets below when you want to pull one published fixture, keep the packet readable in local review, and submit the same message to validation without inventing a private helper layer.

[uaix_client_examples]

What to do after a passing fixture

• Carry the result into Implementations if it supports a concrete runtime or publication claim.
• Record release-facing fixture changes in the Changelog.
• Use References and Contributors when the fixture needs durable discovery or citation support.

Next step

Continue to the Validator to turn these fixtures into repeatable conformance evidence, then attach that evidence to the current implementation and release trail.