Short answer
OpenAPI and UAI-1 can sit beside each other. OpenAPI tells a client how to call an HTTP API; UAI-1 explains the shape and evidence expectations of the AI exchange that may move through that API.
OpenAPI's boundary
OpenAPI is strongest at documenting endpoints, methods, request and response shapes, authentication requirements, examples, and SDK or client tooling around HTTP APIs.
UAI-1's boundary
UAI-1 is about the portable AI exchange record: what profile applies, how delivery works, which trust and provenance evidence travels with the message, and how the candidate exchange can be validated.
| Criterion | UAI-1 | OpenAPI |
|---|---|---|
| Primary object | AI exchange envelope and evidence | HTTP API contract |
| Validation target | Message profile, registry, provenance, integrity | Request/response schema and endpoint behavior |
| Best fit | Cross-boundary handoffs and review trails | API documentation, SDK generation, endpoint testing |
| Failure question | Is the exchange record valid, traceable, and reviewable? | Was the endpoint called with an allowed request shape? |
| Use together? | Yes. OpenAPI can describe the transport API while UAI-1 describes the portable exchange payload and evidence. | |
Why both may be needed
- Use OpenAPI for endpoints, authentication shape, request and response objects, and SDK generation.
- Use UAI-1 inside the payload or exchange record when provenance, delivery, trust, registry, and validation evidence need to survive beyond the API call.
- Store validator output with release or handoff evidence when the exchange becomes a public support claim.
Common confusion
A valid API request is not automatically a valid UAI-1 exchange. The endpoint can accept a payload while the exchange record still fails schema, registry, trust, provenance, or integrity checks.