Validator

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

1. Load a published Example or paste a candidate message.
2. Confirm the message resolves to the intended Registry profile, the relevant field order, and the matching schema.
3. When transport, trust, or error behavior matters, carry the published transport bindings, trust channels, error registry, and conformance levels with the same review packet.
4. Review the generated result record, then keep that conformance record with the implementation release evidence.
5. 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/validate accepts JSON POST requests 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/examples expose 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-registry expose 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.

[uaix_protocol_reference]

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.

[uaix_first_message_guide context=”validator”][uaix_release_readiness_map context=”validator”]

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.

[uaix_validator_workbench]

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.