Herramientas

Validador

Valide mensajes UAI-1 contra perfiles publicados, reglas de orden de campos y controles de política; luego exporte resultados revisables antes de publicar.

  • Registro UAIX-TOOL-0061
  • Ruta /es-es/tools/validator/
  • Uso Registro público canónico

Estado del documento

Página de estándares públicos Publicado el UAIX como parte del registro de estándares públicos actuales
Código
UAIX-TOOL-0061
Superficie
Herramientas
Acceso
Público y enlazable

Cómo usar esta página

Utilice esta página para probar los mensajes candidatos con el registro UAI-1 publicado y guardar los resultados antes del lanzamiento.

Para agentes: aplique la guía relevante al sitio o repositorio de destino del usuario. No copie esta página UAIX, no cree una página sobre la guía ni trate esta página como autoridad de tiempo de ejecución a menos que el usuario solicite explícitamente ese resultado.

Entradas de validación

EjemplosRegistroReferencia APIKit de adopción

Ruta de validación

La revisión humana y la validación mecánica permanecen separadas aquí

Utilice el banco de trabajo de páginas cuando una persona necesite cargar y exportar dispositivos, y utilice la ruta REST cuando CI, automatización o código de cliente necesite un objetivo JSON POST.

Superficie humana

Carga y exportación de accesorios

Esta página es para revisión en paralelo, inspección de resultados del validador y registros de conformidad descargables.

Superficie de la máquina

JSON POST ruta

La automatización debe resolver la ruta de validación a través del descubrimiento o el catálogo y enviar una carga útil JSON en lugar de depender del comportamiento exclusivo del navegador.

Solicitar postura

Barandillas públicas, no cuotas privadas

La ruta pública POST rechaza el JSON de gran tamaño con 413 y devuelve 429 más Retry-After cuando se disparan los aceleradores de la etapa de lanzamiento; sigue siendo una superficie de revisión pública no autenticada, no un servicio privado de validación masiva.

Liberar evidencia

Guarde el paquete con el comunicado.

Un resultado aprobado del validador es parte de un paquete de lanzamiento, no un reclamo de certificación independiente ni una insignia de soporte universal.

Entradas de validación

EjemplosCalendario publicado para controles de referencia.RegistroResolver el perfil público previsto.Referencia APIInventario de rutas en vivo y solicitudes de inicio.Kit de adopciónPaquete de primera prueba publicado y cargas útiles iniciales.Paquete de conformidadPaquete reutilizable para revisión de lanzamiento.

Camino de prueba

Ruta de prueba respaldada por un validador

Mantenga el orden de lectura pública vinculado a un rastro de evidencia: perfil, esquema, ejemplo, resultado del validador y registro de publicación.

  1. 1Elija un perfil de mensaje.Comience con un perfil UAI-1 publicado y la familia de registros que coincida con el intercambio que necesita demostrar.
  2. 2Compárelo con esquemas y ejemplos.Resuelva el esquema, la entrada del registro y un elemento fijo antes de escribir o mapear su paquete candidato.
  3. 3Ejecute la evidencia del validador.Valide JSON con clave, clave minificada o sin clave con los registros públicos UAI-1 actuales.
  4. 4Adjunte el resultado a los registros de implementación o transferencia.Lleve el resultado exportado al paquete de conformidad, al seguimiento de implementación, al registro de cambios o a la evidencia de transferencia del proyecto.
Máquina POSTValidar una carga útil candidata
curl -s https://uaix.org/wp-json/uaix/v1/catalog
curl -s https://uaix.org/wp-json/uaix/v1/examples/uai.intent.request.v1
curl -s -X POST https://uaix.org/wp-json/uaix/v1/validate -H "Content-Type: application/json" -d @uai-message.json

Empareje la ruta de validación con el catálogo de respaldo, el registro y los registros de ejemplo cuando el resultado se trasladará a la evidencia de publicación.

Lo que verifica el validador

El banco de trabajo del validador inspecciona los mensajes candidatos UAI comparándolos con los esquemas de perfil publicados, los registros de gobernanza del orden de campo y las expectativas actuales de la superficie operativa para UAI-1.

  • Alineación de esquemas para las seis familias de mensajes publicados.
  • Resolución de identificadores y perfiles respaldados por registros.
  • Expectativas de orden de campo y transporte sin llave a través del registro público de campo.
  • Verificaciones de políticas de contexto de seguimiento, entrega, canal de confianza, estado de tarea asíncrono y resumen de conformidad que van más allá de la estructura pura JSON.
  • Validación de fallas escritas contra el registro de errores publicado y verificaciones de declaraciones de capacidad contra los enlaces de transporte publicados y los niveles de conformidad.
  • Informes de problemas predecibles cuando falla la conformidad o comienza la desviación.

Qué significa un resultado de conformidad

Un resultado de conformidad es la evidencia legible por máquina de que un mensaje candidato se comparó con el registro público actual. Es apropiado para revisión, puertas de liberación, verificaciones de regresión y evidencia de auditoría. No sustituye a un paquete de lanzamiento ni a un reclamo de soporte de implementación por sí solo.

Lo que un resultado pasajero te deja y no te deja reclamar

  • Soporta:una afirmación de que el mensaje revisado se alineaba con el registro público publicado en el momento de la validación.
  • No soporta:un reclamo de certificación, aprobación de socios, compatibilidad permanente o soporte de tiempo de ejecución general más allá del registro de implementación adjunto.
  • Necesita más antes del apoyo público:un paquete de lanzamiento, un historial de implementación, una entrada de seguimiento de lanzamiento y el nivel de conformidad publicado apropiado para el reclamo que desea hacer.

Cómo deben utilizar los equipos el validador antes de la implementación

  1. Cargar un publicadoEjemploo pegue un mensaje de candidato.
  2. Confirme que el mensaje se resuelve según lo previsto.Registroperfil, el relevanteorden de campoy el esquema coincidente.
  3. Cuando el transporte, la confianza o el comportamiento de error sean importantes, lleve los enlaces de transporte publicados, los canales de confianza, el registro de errores y los niveles de conformidad con el mismo paquete de revisión.
  4. Revise el registro de resultados generado y luego mantenga ese registro de conformidad con la evidencia de liberación de implementación.
  5. Utilice el resultado para decidir si el siguiente paso pertenece aImplementaciones.

Superficies concretas del validador en vivo

Cómo la evidencia de conformidad se convierte en un registro de divulgación pública

  • Adjunte los resultados de conformidad exportados a la implementación o versión del paquete correspondiente en lugar de dejarlos como comprobaciones locales privadas.
  • Utilice elRegistro de cambioscuando los cambios de esquema, perfil, orden de campos, transporte, confianza o comportamiento del validador afectan las expectativas de migración.
  • UsarNoticiascuando una publicación aprobada o reprobada necesita un resumen público.
  • UsarReferencias y colaboradorescuando la publicación necesita enlaces estables de descubrimiento y citas en torno a su evidencia de conformidad.

Interpretación del resultado de la validación.

  • Aprobar:el mensaje enviado coincidía con el perfil público, el esquema, el registro y la política actual del validador en el momento de la verificación registrada.
  • Advertencia:el mensaje puede ser estructuralmente utilizable, pero conlleva deriva, evidencia faltante, una postura de confianza débil o un contexto de revisión que debe resolverse antes de que se expanda el lenguaje de apoyo.
  • Fallar:el mensaje no debe usarse como evidencia de divulgación hasta que los problemas de perfil, esquema, orden de campo, confianza, seguimiento, entrega o cuerpo enumerados se corrijan y se vuelvan a ejecutar.
  • Activador de repetición:vuelva a ejecutar cuando cambie el registro público, el comportamiento del validador, la versión de implementación, la postura de la ruta o la reclamación de soporte.

Referencias publicadas de superficies operativas

El validador a continuación ahora lee en una capa operativa publicada más amplia, no solo los esquemas y accesorios.

Operating surface

Transport, trust, errors, and conformance

These records make the UAI-1 operating layer explicit instead of leaving transport binding, trust posture, typed failure semantics, or support claims to private convention.

Transport

Published bindings

Default
https-json-envelope.v1
Bindings
2
  • 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

Runbook de paquetes de prueba

Utilice el runbook publicado a continuación cuando un mensaje candidato deba convertirse en evidencia de publicación reutilizable en lugar de seguir siendo una verificación única del validador local.

Camino de prueba

How the first proof packet should move through validation

Use this flow when a candidate message needs to become exportable evidence instead of staying a local test.

Paso 1

Resolve the live catalog

Pull the current route inventory first so the rest of the proof run stays anchored to the published machine surface.

Paso 2

Fetch one starter example

Use one published request example as the first packet so your review starts from current public structure instead of local guesswork.

Paso 3

Wrap the message for validation

Build one validator request body with the example packet nested under `message` and request the result record format.

Paso 4

Run one validator check

Submit the validation request to the live POST route and keep the returned result record with the exact packet that was checked.

Paso 5

Test the live reference response

Post the same validated packet to the mock exchange route when you want one real conforming response shape before a runtime track exists.

Paso 6

Carry only the named next step

Move from proof into the named implementation lane, conformance pack, and release trail instead of claiming broader support than the site publishes.

起步消息 Example packet JSON starter-message.json
Ejemplo de código
{
    "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": "https://uaix.org/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
        }
    ]
}
验证请求 Wrap the packet for validator POST validate-request.json
Ejemplo de código
{
    "message": {
        "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": "https://uaix.org/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
            }
        ]
    },
    "format": "result"
}
Reference exchange Ask the live mock surface for one conforming response mock-exchange-request.json
Ejemplo de código
{
    "scenario": "accepted-task",
    "format": "exchange",
    "message": {
        "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": "https://uaix.org/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
            }
        ]
    }
}

Keep the starter packet, validator request, and mock-exchange request required for mock-exchange configuration together with the returned result. That bundle is the smallest repeatable proof-and-response packet on the current public surface.

Post-validation path

What should happen after a passing validator result

Use this map when the validator passed and the next job is turning that result into reusable release evidence instead of stopping at a local check.

Stage 1

Validated packet

A published fixture or candidate message passed against the current public record.

  • Useful for review, debugging, and regression work right away.
  • Still evidence only until the result is attached to a named release lane.

Stage 2

Release-ready packet

The passing result now travels with implementation versioning, artifact links, and discovery context.

  • Keep the checked packet, validator export, artifact URLs, and compatibility notes together.
  • This is the handoff point for launch review, packaging, and repeatable QA.

Stage 3

Public support claim

The named implementation track and release trail now say what is publicly supported and what is still out of scope.

  • Scope the claim to the exact profiles, transport bindings, and owner path that are actually published.
  • Use the current conformance level and release links so another reader can verify the same state.

Keep from each run

Artifacts that should stay attached to every validator result

  • The checked packet exactly as it was submitted for review.
  • The exported conformance result, including warnings as well as failures.
  • The schema, registry, field-order, and example routes used during the check.
  • Transport, trust, conformance, and error guidance when the message depends on those operating surfaces.

Before release-ready

What still needs to be attached after the pass

  • The implementation-track version or package that will carry the result outwardly.
  • Discovery and citation links so another reviewer can resolve the same public state.
  • Changelog or release-summary links when the result affects public compatibility posture.
  • Conformance-level language that stays inside the support boundary actually published.

Current public conformance levels: Use these levels for outward-facing language once the packet becomes part of a named release and implementation record.

L1-core-envelope

L1 Core Envelope

Produce or consume keyed UAI envelopes for named profiles without changing the canonical root fields.

  • Preserve uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions.
  • Name the exact profile and release for every support claim.
  • Do not claim runtime execution from envelope support alone.

Public claim: 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.

  • Resolve schemas, registry entries, examples, and field registry records from public UAIX routes.
  • Pass positive fixtures and fail required negative fixtures for each claimed profile.
  • Keep skipped checks and validator warnings attached to evidence.

Public claim: 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.

  • Declare trust channel and principal.
  • Preserve integrity canonicalization and checksum metadata.
  • Validate signed, credentialed, did+vc, and trace metadata when claimed.

Public claim: 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.

  • Publish discovery, schemas, registry, examples, field registry, transport bindings, trust channels, error registry, conformance levels, validator guidance, changelog, and release evidence.
  • Keep sitemap, llms.txt, and public navigation aligned with current routes.
  • Avoid private logs or screenshots as the only support evidence.

Public claim: 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.

  • Validate agent message, ack, task-status, blocker, memory-proposal, handoff, final-report, and correction profiles.
  • Reject secret-like memory proposals, unsafe blockers, cold-memory direct promotion, and incomplete final reports.
  • Carry the UAIX support boundary in relevant records.

Public claim: 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.

  • Require delivery.idempotency_key for each distinct delegated or destructive operation.
  • Preserve conversation.correlation_id across related messages.
  • Declare retry_count, sequence, expires_at, lifecycle, timeout_ms, fallback_directive, and expected_output_schema when delegation is claimed.

Public claim: 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.

  • Publish capability statements with exact profiles, bindings, trust channels, conformance levels, and error codes.
  • Return capability_not_supported for unsupported capability requests.
  • Do not imply certification, official adapter status, hosted messaging, or runtime orchestration.

Public claim: May claim L7 only for the exact capability negotiation flows proven by public fixtures and validator behavior.

Claim rules

Public language should stay inside published evidence

  • Support claims must name the highest achieved level plus the exact profiles, transport bindings, trust channels, and conformance cases implemented.
  • A project may claim only profiles, bindings, trust channels, and conformance levels that public fixtures and validator tests prove.
  • A passing validator result is evidence, not certification, endorsement, official adapter support, hosted messaging, automatic sync, or runtime execution.
  • Public-record claims require discoverable schemas, registry records, examples, field registry records, error codes, conformance pack cases, changelog, and release notes.
  • Revalidate support claims when schemas, registry records, field order, examples, validator behavior, implementation version, trust posture, sitemap, or public navigation changes.
  • Conformance evidence does not prove security, privacy, availability, performance, legal compliance, hosted trust infrastructure, or production operations by itself.
  • Keep the implementation page, release trail, and citation/discovery links attached when another team needs to verify the same public state.

Working rule: Use the conformance ladder for language, but use the named implementation track and release trail for the actual public support boundary.

Banco de trabajo del validador

Utilice el banco de trabajo público a continuación para cargar un dispositivo publicado o validar un mensaje UAI candidato con la versión actual, luego descargue el registro de conformidad resultante cuando necesite un informe duradero legible por máquina.

Validador

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.

Estado Awaiting input
Perfil Not checked yet
Errors 0
Warnings 0
Normalization Keyed JSON
Checked at Not 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.

Scenario Accepted async task
HTTP Not run yet
Response profile No response yet
Response check Awaiting 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.

Siguiente paso

Continuar aImplementacionesuna vez que pasa el mensaje del candidato. Utilice elWordPress Pista de publicaciónpara publicación y embalaje, o elPista del puente.NETpara una integración más profunda del tiempo de ejecución, luego registre los cambios relacionados con el lanzamiento a través delRegistro de cambiosyNoticias.