What the validator checks
The validator workbench inspects candidate UAI messages against the published profile schemas, the field-order governance records, and the current operating-surface expectations for UAI-1.
- Schema alignment for the six published message families.
- Registry-backed profile and identifier resolution.
- Field-order and keyless-transport expectations through the public field registry.
- Trace-context, delivery, trust-channel, async task-state, and conformance-summary policy checks that go beyond pure JSON structure.
- Typed failure validation against the published error registry and capability-statement checks against published transport bindings and conformance levels.
- Predictable issue reporting when conformance fails or drift begins.
What a conformance result means
A conformance result is the machine-readable evidence that a candidate message was checked against the current public record. It is appropriate for review, release gates, regression checks, and audit evidence. It is not a substitute for a release packet or an implementation support claim by itself.
What a passing result does and does not let you claim
- Supports: a claim that the reviewed message aligned with the published public record at the time of validation.
- Does not support: a claim of certification, partner approval, permanent compatibility, or general runtime support beyond the attached implementation record.
- Needs more before public support: a release packet, implementation-track record, release-trail entry, and the appropriate published conformance level for the claim you want to make.
How teams should use the validator before deployment
- Load a published Example or paste a candidate message.
- Confirm the message resolves to the intended Registry profile, the relevant field order, and the matching schema.
- When transport, trust, or error behavior matters, carry the published transport bindings, trust channels, error registry, and conformance levels with the same review packet.
- Review the generated result record, then keep that conformance record with the implementation release evidence.
- Use the result to decide whether the next step belongs in Implementations.
Concrete live validator surfaces
- Human-facing workbench: use this page for fixture loading, side-by-side review, and downloadable conformance records.
- Machine-facing validation route:
/wp-json/uaix/v1/validateaccepts JSONPOSTrequests for automation and release pipelines. - Supporting machine-readable record routes:
/wp-json/uaix/v1/catalog,/wp-json/uaix/v1/schemas,/wp-json/uaix/v1/registry,/wp-json/uaix/v1/field-registry, and/wp-json/uaix/v1/examplesexpose the core catalog, schema, registry, field-order, and fixture inventory used during validation. - Operating guidance routes:
/wp-json/uaix/v1/transport-bindings,/wp-json/uaix/v1/trust-channels,/wp-json/uaix/v1/conformance-levels, and/wp-json/uaix/v1/error-registryexpose the transport, trust, support-claim, and failure-handling guidance the validator now references.
How conformance evidence becomes a public release record
- Attach exported conformance results to the relevant implementation or package release rather than leaving them as private local checks.
- Use the Changelog when schema, profile, field-order, transport, trust, or validator behavior changes affect migration expectations.
- Use News when a passing or failing release needs a public-facing summary.
- Use References and Contributors when the release needs stable discovery and citation links around its conformance evidence.
Validation result interpretation
- Pass: the submitted message matched the public profile, schema, registry, and current validator policy at the recorded check time.
- Warning: the message may be structurally usable but carries drift, missing evidence, weak trust posture, or review context that should be resolved before support language expands.
- Fail: the message should not be used as release evidence until the listed profile, schema, field-order, trust, trace, delivery, or body issues are corrected and rerun.
- Rerun trigger: rerun when the public record, validator behavior, implementation version, route posture, or support claim changes.
Published operating-surface references
The validator below now reads against a broader published operating layer, not just the schemas and fixtures.
Operating surface
Transport, trust, errors, and conformance
These records keep delivery, trust posture, typed failure semantics, and support claims explicit.
Transport
Published bindings
https-json-envelope.v1: application/vnd.uaix.uai+jsonhttps-json-keyless.v1: application/vnd.uaix.uai-keyless+json
Trust
Published trust channels
public-web: Publicly readable records over HTTPS with no prior bilateral trust setup.private-api: Service-to-service exchange on a scoped network or tenant boundary.mtls: Transport-authenticated exchange where peer identity is anchored at the connection layer.signed-envelope: Message-level signature or detached signature reference accompanies the record.credentialed: The sender or execution context is backed by a machine-verifiable credential or comparable signed identity assertion.
Conformance
Published level ladder
L1-core-envelope: L1 Core EnvelopeL2-profile-validation: L2 Profile ValidationL3-trust-and-integrity: L3 Trust and IntegrityL4-public-record-publisher: L4 Public Record PublisherL5-agent-communication-profiles: L5 Agent Communication ProfilesL6-reliable-delegation-idempotency-correlation: L6 Reliable Delegation with Idempotency and CorrelationL7-capability-negotiation: L7 Capability Negotiation
Errors
Published message error codes
invalid_message: Invalid messageunknown_profile: Unknown profilecapability_not_supported: Capability not supportedauth_required: Authentication requiredinsufficient_trust: Insufficient trusttask_not_found: Task not foundtask_expired: Task expiredreplay_window_violation: Replay window violationrate_limited: Rate limitedupstream_unavailable: Upstream unavailableconformance_failed: Conformance failedidempotency_required: Idempotency required
Proof packet runbook
Use the published runbook below when a candidate message needs to become reusable release evidence instead of remaining a local one-off validator check.
First message
Run one reproducible UAI-1 proof
Start with a published fixture, validate the exact profile, then keep the result with release evidence.
Step 1
Read the catalog and select a published profile.
Step 2
Download its schema and example record.
Step 3
Validate a keyed message before transport.
Step 4
Use the Mock Exchange for a deterministic reference response.
{
"uai_version": "1.0",
"profile": "uai.intent.request.v1",
"message_id": "msg-2026-04-22-0001",
"source": {
"type": "agent",
"id": "agent.alpha",
"label": "Agent Alpha",
"uri": "https://agents.alpha.example/runtime",
"did": "did:web:agents.alpha.example",
"role": "requesting-agent",
"implementation": "alpha-runtime-2.4.1"
},
"target": {
"type": "service",
"id": "uaix.gateway",
"label": "UAIX Gateway",
"uri": "/wp-json/uaix/v1/discovery",
"did": "did:web:uaix.org",
"role": "public-record-gateway",
"implementation": "uaix-core-0.4.0"
},
"conversation": {
"conversation_id": "conv-2026-04-22-uaix-001",
"turn_id": "turn-001",
"traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
"sequence": 1
},
"delivery": {
"mode": "async",
"priority": "interactive",
"expires_at": "2026-04-22T16:05:00Z",
"reply_requested": true,
"ack_required": true
},
"trust": {
"channel": "credentialed",
"auth_scheme": "did+vc",
"principal": "did:web:agents.alpha.example",
"credential_ref": "https://agents.alpha.example/credentials/uai-interop.json",
"signature_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws",
"replay_window_id": "rw-2026-04-22-0001",
"trust_profile": "uai.trust.did-vc-reference.v1",
"verification_status": "not_verified",
"credential_status": "not_checked",
"verifier_ref": "https://agents.alpha.example/verifiers/uai-trust-policy.json",
"trust_root_ref": "https://agents.alpha.example/.well-known/uai.json",
"proof_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws",
"replay_policy_ref": "https://agents.alpha.example/trust/replay-policy.json",
"verification_checked_at": "2026-04-22T16:00:00Z",
"verification_expires_at": "2026-04-22T16:05:00Z",
"assurance_level": "reference_only"
},
"body": {
"intent": "resolve-profile",
"subject": "uai.task.status.v1",
"requested_profile": "uai.task.status.v1",
"parameters": {
"include_schema": true,
"include_example": true,
"include_field_registry": true
},
"constraints": [
"public-record-only",
"trace-linked",
"validator-ready"
],
"response_profile": "uai.intent.response.v1"
},
"provenance": {
"trace_id": "trace-7f3a2d",
"parent_trace_id": "trace-root-uaix-2026",
"issued_at": "2026-04-22T16:00:00Z",
"log_ref": "urn:uaix:log:2026:0001",
"agent_id": "agent.alpha",
"model_id": "model.alpha.reasoner-2",
"confidence": 0.98,
"lineage": [
{
"stage": "request-composition",
"actor_id": "agent.alpha",
"model_id": "model.alpha.reasoner-2",
"note": "Requested the async task-status profile and matching field registry."
}
]
},
"integrity": {
"version": 2,
"algorithm": "sha256",
"canonicalization": "jcs",
"checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8"
},
"extensions": [
{
"namespace": "urn:uaix:ext:delivery",
"purpose": "Explicit async request handling and expiry semantics.",
"critical": false
}
]
}Release readiness
From first packet to bounded support claim
A passing validation result is evidence for one packet, not certification or an unlimited support claim.
L1-core-envelope
L1 Core Envelope
Produce or consume keyed UAI envelopes for named profiles without changing the canonical root fields.
Claim boundary: May claim L1 only for the exact named profiles whose canonical envelope round-trips successfully.
L2-profile-validation
L2 Profile Validation
Pass published schema and validator checks for the exact profiles claimed.
Claim boundary: May claim L2 only for profiles with validator-backed evidence.
L3-trust-and-integrity
L3 Trust and Integrity
Preserve trust metadata, replay-window hints, provenance, integrity, and trace continuity.
Claim boundary: May claim L3 only for the trust channels and integrity behavior proven by fixtures.
L4-public-record-publisher
L4 Public Record Publisher
Publish discoverable public artifacts needed for external inspection and reproduction.
Claim boundary: May claim L4 only for the public release surface that is discoverable and evidenced.
L5-agent-communication-profiles
L5 Agent Communication Profiles
Support the eight uai.agent.*.v1 profiles as canonical UAI-1 envelope records.
Claim boundary: May claim L5 only for the specific agent profiles with passing positive and negative conformance cases.
L6-reliable-delegation-idempotency-correlation
L6 Reliable Delegation with Idempotency and Correlation
Use idempotency, correlation, retry, lifecycle, timeout, fallback, acknowledgement, and expected-output rules for delegated work.
Claim boundary: May claim L6 only for reliable delegation behavior proven by conformance fixtures and receiver behavior.
L7-capability-negotiation
L7 Capability Negotiation
Publish and validate capability discovery, assertions, negotiation failures, and unsupported-capability responses.
Claim boundary: May claim L7 only for the exact capability negotiation flows proven by public fixtures and validator behavior.
Validator workbench
Use the public workbench below to load a published fixture or validate a candidate UAI message against the current release, then download the resulting conformance record when you need a durable machine-readable report.
Validator
UAI-1 validator workbench
Paste a candidate message, load a published fixture, choose keyed or keyless normalization, and validate it against the current public UAI-1 profile schemas. The validator now checks the richer envelope, async task-state records, typed error details, field-registry alignment, trace context, delivery expiry, capability-declared transport bindings, conformance levels, and trust-policy hints before deployment.
Conformance input
Validate a UAI message
Use the published fixtures below as known-good starting points or paste a candidate payload from your own integration. Each validation run can also be exported as a `uai.conformance.result.v1` record for CI logs, release evidence, or audit trails.
Use this page as the human-facing validation workflow. The REST validate route is a machine-facing POST endpoint for JSON payloads, not a browsable report page.
Conformance result
Ready to validate
Load a fixture or paste a candidate message, then run the validator.
What will appear here
Run the validator to group issues by severity, resolve the exact public artifacts used during the check, and export a reusable conformance record.
Errors
0Warnings
0Resolved public artifacts
Carry these exact records with the validation result so another reviewer can reproduce the same proof packet without private context.
Run the validator to generate a conformance record.Live response proof
Ready when the packet is validated
Run a passing packet through the live mock exchange to inspect one deterministic response shape before a runtime-specific track exists.
Use the mock exchange after a passing validation
The live reference route returns deterministic accepted, completed, and typed-error envelopes so you can inspect one conforming response shape before a runtime track publishes its own server behavior.
Mock response validation notes
0Run the mock exchange to capture a deterministic response envelope.Next step
Continue to Implementations once the candidate message passes. Use the WordPress Publication Track for publication and packaging, or the .NET Bridge Track for deeper runtime integration, then record release-facing changes through the Changelog and News.
Architecture proposals
UAI-1 v1.0 remains the current published contract. Explore separately versioned proposals for independent exchange, capabilities, recovery and source preservation.
Proposed designs and local reference examples; hosted runtime services and independent interoperability are not claimed.
The English proposal is the source for normative interpretation.
Read the architecture proposals · Machine-readable proposal catalog