Tools

Validator

Validate UAI-1 messages against published profiles, field-order rules, and policy checks, then export reviewable results before release.

  • Record UAIX-TOOL-0060
  • Path /en-us/tools/validator/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-TOOL-0060
Surface
Tools
Access
Public and linkable

How to use this page

Use this page as the canonical public reference for Validator and its standards-facing content.

For agents: apply the relevant guidance to the user's target site or repository. Do not copy this UAIX page, create a page about the guidance, or treat this page as runtime authority unless the user explicitly asks for that output.

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

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+json
  • https-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 Envelope
  • L2-profile-validation: L2 Profile Validation
  • L3-trust-and-integrity: L3 Trust and Integrity
  • L4-public-record-publisher: L4 Public Record Publisher
  • L5-agent-communication-profiles: L5 Agent Communication Profiles
  • L6-reliable-delegation-idempotency-correlation: L6 Reliable Delegation with Idempotency and Correlation
  • L7-capability-negotiation: L7 Capability Negotiation

Errors

Published message error codes

  • invalid_message: Invalid message
  • unknown_profile: Unknown profile
  • capability_not_supported: Capability not supported
  • auth_required: Authentication required
  • insufficient_trust: Insufficient trust
  • task_not_found: Task not found
  • task_expired: Task expired
  • replay_window_violation: Replay window violation
  • rate_limited: Rate limited
  • upstream_unavailable: Upstream unavailable
  • conformance_failed: Conformance failed
  • idempotency_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.

Starter packetuai-first-packet.json
Code example
{
    "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.

Validate first, then run the same packet against the live mock exchange to inspect one conforming response shape before you widen support claims.

Conformance result

Ready to validate

Load a fixture or paste a candidate message, then run the validator.

StatusAwaiting input
ProfileNot checked yet
Errors0
Warnings0
NormalizationKeyed JSON
Checked atNot run yet

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.

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.

ScenarioAccepted async task
HTTPNot run yet
Response profileNo response yet
Response checkAwaiting proof run

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.

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