Improving UAIX UAI-1 vNext Without Redesign

Full report

On this page

Executive summary

UAIX already has a stronger baseline than many early agent-interoperability efforts because UAI-1 is not just an envelope: it already publishes a keyed canonical message shape, a keyless compact form tied to a public field registry, named profiles for requests, responses, capabilities, typed errors, conformance results, and async task status, plus transport bindings, trust-channel declarations, a validator-backed proof path, conformance levels, release governance, and named implementation tracks. The specification also explicitly positions itself as the portable public exchange and release-record layer beside MCP, A2A, tracing, identity, and runtime orchestration rather than as a replacement for them.

The highest-value vNext work is therefore not a redesign. It is a maturity pass that makes the current contract more explicit, more internally consistent, and more operationally usable in production. The most important changes are: clarify compatibility and versioning rules; resolve current schema/registry/conformance mismatches; make idempotency, correlation, retry, QoS, and ordering first-class optional semantics; deepen the trust model with anchors, audience, status, and revocation references; standardize privacy, consent, and telemetry extensions; expand the error taxonomy and binding mappings; and publish more official transport bindings and test vectors. These changes can all be additive if they preserve the current keyed envelope, preserve existing field positions as prefixes, and negotiate new keyless field-registry releases explicitly.

The main current risk is not that UAI-1 lacks concepts. The risk is that some concepts are already implied in the broader ecosystem around UAIX, or even in the conformance ladder, but are not yet fully reflected in the canonical field registry or profile schemas. The clearest examples are reliable delegation fields such as delivery.idempotency_key, conversation.correlation_id, retry_count, timeout_ms, and related lifecycle semantics, which appear in the L6 conformance description but are not yet present in the baseline conversation and delivery component orders. Likewise, the error profile schema currently advertises a richer required body than the field registry order and shorter public error-code list imply. That kind of mismatch slows implementers, complicates validators, and makes interop claims harder to defend.

My overall recommendation is to treat vNext as a contract hardening release with three horizons. In the short term, publish clarifications, additive fields, richer error and trust registries, and more complete validator cases. In the medium term, add official bindings for gRPC, message buses, and WebSockets, along with bridge annexes for MCP, A2A, ACP, and OpenAPI. In the long term, formalize an extension registry, deprecation policy, revocation and trust-anchor packages, and multi-implementation interoperability governance. That trajectory expands maturity materially while keeping the existing UAI-1 shape recognizable and backwards-compatible.

Current baseline and where maturity already exists

UAI-1’s current baseline is broader than a simple request/response format. The field registry defines twelve required root fields—uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions—and also publishes component orders for source, target, conversation, delivery, trust, provenance, and integrity. That means the spec already has explicit places for identity, provenance, conversation state, delivery semantics, trust metadata, and integrity metadata, rather than leaving those concerns to prose or private convention.

The currently published profiles cover the core public exchange loop: uai.intent.request.v1, uai.intent.response.v1, uai.capability.statement.v1, uai.error.v1, uai.conformance.result.v1, and uai.task.status.v1. Examples show direct requests, accepted async handoffs, capability publication, typed errors, exported validation evidence, and long-running task status updates. The examples also demonstrate detached signature references, DID-style principals, JCS canonicalization, and trace linkage.

The transport and trust layer is already unusually explicit for a launch-stage protocol. UAIX currently publishes two transport bindings—https-json-envelope.v1 and https-json-keyless.v1—with explicit content types, fallback guidance, traceparent header usage, and accepted-async HTTP 202 patterns. It also publishes trust channels for public-web, private-api, mtls, signed-envelope, and credentialed. Importantly, the public guidance already says authorization belongs in companion transport layers rather than as ad hoc body semantics, which is a solid design choice that aligns well with MCP’s transport-level authorization direction and with modern API practice.

The validator and supporting evidence path are also strong. UAIX explicitly describes a proof flow of profile, schema, example, validator result, and release record. The schemas page states that validation is not only JSON Schema validation: the validator also applies policy checks such as delivery expiry, trust-reference hints, accepted-response task references, task-status progress consistency, and conformance-summary integrity. The changelog further records that validation now supports keyed-json, minified-keyed-json, and keyless-json, and that release packets can carry reusable positive and negative fixtures including missing profile, missing required fields, undeclared fields, invalid traceparent, DID/VC trust evidence, keyless-shape errors, and unsupported alias cases.

UAIX also already has a real support-claim model. The published conformance ladder runs from L1 core envelope through L7 capability negotiation, with L6 specifically addressing reliable delegation, idempotency, correlation, retry, lifecycle, timeout, fallback, acknowledgements, and expected-output rules. The public site couples those claims to implementation tracks and dated release evidence rather than implying institutional certification. Current public implementation tracks are the WordPress Publication Track and the .NET Bridge Track.

flowchart LR
  R[Agent runtime or workflow harness] -->|local tools and resources| M[MCP]
  R -->|delegation and streaming| A[A2A or ACP]
  M --> U[UAI-1 portable record]
  A --> U
  U --> V[Validator and conformance evidence]
  U --> G[Governance and release trail]
  U --> T[Trust and trace references]

That layering is not an invention of this report; it is close to the way UAIX already describes itself. The Standards Fit pages state that MCP owns host-client-server tools and context sessions, A2A owns peer-agent discovery, delegation, and task coordination, and UAI-1 owns the portable exchange record that must remain reviewable outside the runtime session. The agentic harness guide makes the same separation: planning, retries, approvals, traces, and orchestration stay in the harness, while UAIX preserves the portable evidence and handoff record.

Gaps and risks in the current baseline

The most immediate maturity gap is internal consistency. The field registry still defines conversation as conversation_id, turn_id, parent_message_id, traceparent, and sequence, and delivery as mode, priority, expires_at, reply_requested, ack_required, and task_ref. But the L6 conformance level now requires delivery.idempotency_key, conversation.correlation_id, retry_count, lifecycle, timeout_ms, fallback_directive, and expected_output_schema when reliable delegation is claimed. That is a good direction, but until those fields are in the component orders and the relevant schemas, reliable delivery is described more strongly than it is canonically modeled.

A similar issue appears in the error model. The UAI-1 page and error registry summary still present a compact public code list—invalid_message, unknown_profile, capability_not_supported, auth_required, insufficient_trust, and task_not_found. But the schema catalog now describes uai.error.v1 as requiring a much richer set of fields including uaixCode, uaixCategory, uaixSeverity, documentationUrl, traceId, correlationId, evidenceRecommended, suspensionRecommended, and redactionApplied, while the field registry’s uai.error.v1 body order still only lists the smaller problem-details-style core. That creates ambiguity over what is normative, what is optional, and what keyless peers should expect.

Trust posture is another area where the baseline is strong conceptually but still thin operationally. UAIX trust channels already distinguish public-web, private-api, mtls, signed-envelope, and credentialed, and they recommend replay-window handling, least disclosure, public verification material, and release-packet attachment of credential or signature references. But there is no fully specified notion of trust anchor sets, stable verifier metadata, audience restriction, authorization scope, credential status or revocation references, or proof-format negotiation beyond examples like did+vc and detached JWS references. Policy pages also explicitly say that broader consent centers, disclosure portals, and managed trust-service programs are not yet public.

Versioning and release compatibility need the same hardening. Today, UAI-1 uses uai_version: "1.0" and versioned profile IDs such as .v1, supported by a detailed changelog and roadmap. That is workable, but the rules for when to update uai_version, when to mint a new profile, when to extend only the field registry, and how long old keyless registry releases remain valid are not yet explicit in the same way MCP’s date-based protocol versioning or A2A’s explicit Major.Minor compatibility rules are. OpenAPI also publishes a clear distinction between minor releases and dated schema revisions. UAI-1 would benefit from adopting that level of precision without changing the underlying model.

Interoperability breadth is another current boundary. UAIX’s published bindings are HTTP keyed JSON and HTTP keyless JSON. Standards Fit explicitly says alias JSON, binary media types, formal bridge profiles, SDKs, and CLIs remain planned or research-track until public evidence exists. That discipline is healthy, but it also means that gRPC, message-bus, and WebSocket use cases currently require implementation-specific interpretation instead of a UAIX-maintained binding annex. In contrast, A2A already defines JSON-RPC, gRPC, and HTTP+JSON binding concepts, and ACP is explicitly HTTP-native, async-first, streaming-capable, and oriented toward load-balancer and OpenTelemetry integration.

Finally, governance is real but still narrow. UAIX already has a strong dated release trail, evidence-promotion gates, implementation evidence checklists, and public policy pages, but the public record remains a single authority surface with named implementation tracks rather than a multi-vendor working group, extension registry, or deprecation board. That is not a flaw for an initial release; it simply means vNext maturity should focus on process transparency, extension admission rules, and deprecation discipline before broader ecosystem claims.

Backward-compatible vNext extensions

The right vNext strategy is additive formalization. Preserve the twelve current root fields and their meaning. Preserve existing keyed JSON examples. Preserve current content types. Preserve current profile IDs. Then add optional fields at the tail of existing component orders, plus a small number of formally namespaced extension families for cross-cutting concerns that are not universal enough to force into every message. That approach keeps current messages valid while giving new implementations better operational semantics. It also matches UAIX’s current philosophy that companion layers should remain explicit beside the envelope rather than hidden inside application behavior.

The most important core additions should go into conversation, delivery, trust, and provenance, because those are the places where the public contract already expects runtime-adjacent facts to become durable evidence. In practice, I recommend adding the following optional fields in the next field-registry release:

That is not a redesign. It is the natural completion of patterns already present in the examples, trust channels, and L6 conformance text. The trust proposal is also consistent with transport-level authorization in MCP, with A2A’s published security schemes, and with W3C DID/VC models in which credentials can carry verification material and status information.

For privacy, consent, telemetry, and evidence, I recommend a namespaced extension family rather than more root expansion. The extension mechanism already exists, and the capability example already declares extension namespaces such as urn:uaix:ext:delivery and urn:uaix:ext:evidence. vNext should formalize extension item tails such as schema_ref, payload_ref, payload_hash, and optional inline payload. That would allow UAIX to publish constrained extension families such as:

• urn:uaix:ext:privacy.v1
• urn:uaix:ext:consent.v1
• urn:uaix:ext:telemetry.v1
• urn:uaix:ext:evidence.v2
• urn:uaix:ext:qos.v1

This approach keeps the core envelope readable while giving implementers stable places for cross-cutting semantics that may vary by deployment. It also keeps the keyless story manageable: the extension list remains at the current root position, while the field registry defines the tail shape and normalization rules for extension payloads.

A practical versioning rule set is the single most important clarification to publish in vNext. The closest fit for UAIX is a hybrid of current UAI-1 practice with lessons from MCP, A2A, and OpenAPI:

On errors, UAI-1 should keep its problem-details style but make the taxonomy much more usable operationally. RFC 9457 already provides a stable HTTP problem model, and gRPC already has a well-defined status code system. A2A explicitly publishes binding-specific error mappings, while ACP emphasizes code-driven error handling regardless of where the error appears. UAI-1 should adopt the same layered pattern: a protocol-level semantic code, a category, retry guidance, and a transport-binding mapping table.

A workable vNext error taxonomy would separate:

• Syntax and schema: invalid_message, missing_required_field, undeclared_field, invalid_trace_context, unsupported_keyless_shape
• Negotiation and capability: unknown_profile, unsupported_binding, capability_not_supported, unsupported_extension
• Authn and trust: auth_required, invalid_credential, signature_invalid, anchor_untrusted, credential_revoked, replay_detected
• Authz and consent: forbidden_scope, consent_required, human_approval_missing
• Reliability and lifecycle: task_not_found, idempotency_conflict, ordering_conflict, expired_message, timeout, too_many_retries
• Policy and privacy: redaction_required, policy_blocked, sensitive_data_prohibited
• System and upstream: rate_limited, temporarily_unavailable, upstream_failure, internal_error

That still fits the current uai.error.v1 shape; it simply gives the registry enough breadth to be useful across bindings and implementations.

The trust model should be similarly strengthened without stack lock-in. UAIX is correct not to hard-code one universal identity system. The right move is to standardize the metadata needed to verify whatever proof stack is chosen. A2A already allows API key, HTTP auth, OAuth 2.0, OpenID Connect, and mTLS security schemes, and MCP explicitly defines authorization at the transport layer for HTTP-based transports. DID Core and Verifiable Credentials provide a portable model for decentralized identities, signed claims, and credential status information. A good UAIX vNext therefore does not pick a winner; it standardizes how to declare the chosen approach.

Concretely, trust should gain:

• proof_format: for values such as jws, cose, vc-jose, vc-di, or mtls
• audience: to bind authorization to an intended receiver
• scopes: to declare what the proof authorizes
• anchor_ref: to identify the relevant trust root, CA set, DID method policy, or verifier set
• status_ref: to point to revocation or status material
• nonce: to support replay resistance beyond window labels
• verified_at: for durable audit evidence when verifiers attach results

Because UAIX examples already use detached JWS references and JCS canonicalization, and A2A uses JWS plus JCS for signed Agent Cards, publishing a common signed-envelope verification annex would also be a high-value additive improvement.

Privacy and consent need to move from governance prose into machine-readable semantics. UAIX’s policy pages are explicit that broader consent-management workflows are not yet part of the public trust surface, but the broader UAIX ecosystem already discusses agent consent, approval checkpoints, and evidence-led handoffs. ACP’s run lifecycle includes an awaiting state for client-provided input and approval-like interactions, and OAuth 2.1 remains the core modern framework for obtaining limited delegated access with resource-owner involvement. vNext should therefore define a minimal, portable consent model without turning UAIX into a consent platform.

A good urn:uaix:ext:consent.v1 payload would include:

{
  "required": true,
  "basis": "user-approval",
  "scope": ["calendar.write", "email.send"],
  "granted_at": "2026-06-10T15:00:00Z",
  "expires_at": "2026-06-10T15:30:00Z",
  "proof_ref": "urn:consent:approval:4e3e",
  "human_present": true
}

A matching urn:uaix:ext:privacy.v1 payload should cover only portable facts:

{
  "data_classification": "internal",
  "contains_personal_data": true,
  "redaction_applied": true,
  "retention_class": "release-evidence-90d",
  "shareability": "audited-partners-only"
}

For observability, UAIX already reuses conversation.traceparent, and external standards are clear that W3C Trace Context is the common way to propagate trace identity. OpenTelemetry’s default propagator uses Trace Context, and OpenTelemetry also publishes messaging semantic conventions for queue-like transports. ACP explicitly relies on HTTP monitoring and OpenTelemetry integration. The best UAIX vNext move is therefore not to invent a tracing stack but to standardize how trace and messaging facts appear in the envelope or extension payloads.

I recommend three explicit rules:

1. conversation.traceparent remains the wire propagation field.
2. provenance.trace_id remains the portable audit identifier.
3. urn:uaix:ext:telemetry.v1 carries optional runtime metadata such as transport, destination, span_kind, sampling_decision, and otel_attributes_ref.

That gives implementers stable tracing hooks without leaking private trace stores into the portable record.

Proposed schema fragment

The fragment below shows what a conservative additive update could look like for the core reliability and trust fields:

{
  "$id": "urn:uaix:schema:delivery-trust-vnext-fragment",
  "type": "object",
  "properties": {
    "conversation": {
      "type": "object",
      "properties": {
        "correlation_id": { "type": "string" },
        "causation_message_id": { "type": "string" },
        "ordering_key": { "type": "string" }
      },
      "additionalProperties": true
    },
    "delivery": {
      "type": "object",
      "properties": {
        "idempotency_key": { "type": "string" },
        "retry_count": { "type": "integer", "minimum": 0 },
        "timeout_ms": { "type": "integer", "minimum": 1 },
        "guarantee": {
          "type": "string",
          "enum": ["at-most-once", "at-least-once", "effectively-once-caller-managed"]
        },
        "backoff_hint": {
          "type": "string",
          "enum": ["none", "fast", "standard", "congestion-aware"]
        },
        "reply_channel": { "type": "string" }
      },
      "additionalProperties": true
    },
    "trust": {
      "type": "object",
      "properties": {
        "proof_format": { "type": "string" },
        "audience": { "type": "string" },
        "scopes": {
          "type": "array",
          "items": { "type": "string" }
        },
        "anchor_ref": { "type": "string" },
        "status_ref": { "type": "string" },
        "nonce": { "type": "string" }
      },
      "additionalProperties": true
    }
  }
}

Proposed vNext interaction

The next example keeps the current UAI-1 shape while making reliable async semantics explicit:

{
  "uai_version": "1.0",
  "profile": "uai.intent.request.v1",
  "message_id": "msg-2026-06-10-1001",
  "source": {
    "type": "agent",
    "id": "agent.requestor",
    "uri": "https://requestor.example/runtime",
    "did": "did:web:requestor.example"
  },
  "target": {
    "type": "service",
    "id": "agent.executor",
    "uri": "https://executor.example/uai"
  },
  "conversation": {
    "conversation_id": "conv-2026-06-10-42",
    "turn_id": "turn-004",
    "parent_message_id": "msg-2026-06-10-0999",
    "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
    "sequence": 4,
    "correlation_id": "job-7182",
    "ordering_key": "tenant-7/order-44"
  },
  "delivery": {
    "mode": "async",
    "priority": "interactive",
    "expires_at": "2026-06-10T16:05:00Z",
    "reply_requested": true,
    "ack_required": true,
    "idempotency_key": "idem-7182-v1",
    "retry_count": 0,
    "timeout_ms": 30000,
    "guarantee": "at-least-once"
  },
  "trust": {
    "channel": "credentialed",
    "auth_scheme": "did+vc",
    "principal": "did:web:requestor.example",
    "credential_ref": "https://requestor.example/credentials/interop.json",
    "signature_ref": "https://requestor.example/signatures/msg-2026-06-10-1001.jws",
    "replay_window_id": "rw-2026-06-10-1001",
    "proof_format": "vc-jose",
    "audience": "https://executor.example/uai",
    "scopes": ["task.submit"],
    "anchor_ref": "https://requestor.example/.well-known/trust-anchors.json",
    "status_ref": "https://requestor.example/credentials/status/interop"
  },
  "body": {
    "intent": "delegate-task",
    "subject": "invoice-reconciliation",
    "requested_profile": "uai.task.status.v1",
    "parameters": {
      "invoice_batch_id": "batch-991",
      "max_parallelism": 4
    },
    "constraints": ["validator-ready", "redacted-output"],
    "response_profile": "uai.intent.response.v1"
  },
  "provenance": {
    "trace_id": "trace-7f3a2d",
    "issued_at": "2026-06-10T16:00:00Z",
    "agent_id": "agent.requestor",
    "model_id": "model.requestor-3",
    "confidence": 0.98
  },
  "integrity": {
    "version": 2,
    "algorithm": "sha256",
    "canonicalization": "jcs",
    "checksum": "sha256:abc123"
  },
  "extensions": [
    {
      "namespace": "urn:uaix:ext:consent.v1",
      "purpose": "Carries the human approval record for write-capable delegation.",
      "critical": false
    },
    {
      "namespace": "urn:uaix:ext:telemetry.v1",
      "purpose": "Carries portable observability hints.",
      "critical": false
    }
  ]
}

Proposed transport snippets

UAIX only publishes the two HTTP JSON bindings today, so the following should be read as candidate official vNext bindings, not current UAIX behavior. Current official UAIX transport is still HTTPS JSON envelope or keyless JSON.

JSON over HTTP

POST /uai HTTP/1.1
Content-Type: application/vnd.uaix.uai+json
Accept: application/vnd.uaix.uai+json, application/problem+json
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Authorization: Bearer eyJ...

{ ...full keyed UAI-1 message... }

gRPC candidate binding

syntax = "proto3";

package uaix.vnext;

message UaiEnvelope {
  string media_type = 1;          // application/vnd.uaix.uai+json
  string profile = 2;
  string traceparent = 3;
  string content_sha256 = 4;
  bytes  json_payload = 5;        // canonical keyed JSON bytes
}

message UaiReply {
  UaiEnvelope envelope = 1;
}

service UaiService {
  rpc Send(UaiEnvelope) returns (UaiReply);
  rpc StreamStatus(UaiEnvelope) returns (stream UaiReply);
}

Message queue candidate binding

Headers:
  content-type=application/vnd.uaix.uai+json
  uai-profile=uai.intent.request.v1
  uai-message-id=msg-2026-06-10-1001
  uai-idempotency-key=idem-7182-v1
  traceparent=00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Payload:
  { ...full keyed UAI-1 message... }

WebSocket candidate frame

{
  "type": "uai.message",
  "content_type": "application/vnd.uaix.uai+json",
  "message": { "...": "full keyed UAI-1 message" }
}

A strong design rule for all of these bindings is that the canonical object remains keyed JSON, and any compact or framed representation must normalize back to that form before validation, hashing, signing, or support claims. UAIX already follows that rule for keyless JSON, and extending it consistently to gRPC, MQ, or WebSockets would preserve the current architecture.

Proposed async sequence

sequenceDiagram
  participant S as Sender
  participant R as Receiver
  participant V as Validator
  participant P as Publisher

  S->>R: uai.intent.request.v1
  Note over S,R: includes idempotency_key, correlation_id, traceparent
  R-->>S: uai.intent.response.v1 status=accepted
  R-->>S: uai.task.status.v1 state=working
  R-->>S: uai.task.status.v1 state=completed
  R-->>S: uai.intent.response.v1 status=success
  V-->>P: uai.conformance.result.v1
  P-->>P: changelog + implementation evidence + registry links

Mappings to adjacent standards and runtimes

UAIX’s own Standards Fit pages already define the high-level interoperability map: MCP is for local tools, resources, prompts, and host-side context; A2A is for discovery, delegation, and task coordination between agents; OpenAPI describes route contracts; JSON Schema validates structure; DID/VC, mTLS, and signed envelopes support trust; and Trace Context carries distributed trace linkage. UAI-1, in turn, carries the portable record that must survive outside the runtime session. That framing is strong and should remain the center of the vNext design.

The best vNext improvement is to turn those relationship statements into explicit mapping annexes with canonical field correspondences, validator fixtures, and non-claims. That matters because the external protocols are already structurally mature in ways UAIX can borrow from without copying wholesale. MCP has an explicit source of truth in its schema-driven specification, transport-level authorization for HTTP transports, and date-based versioning. A2A has major/minor compatibility semantics, well-known Agent Card discovery, JWS+JCS signed cards, multiple bindings, and published error mappings. ACP is now folding into the A2A world, is HTTP-native and async-first, and emphasizes discoverability, run lifecycle, distributed sessions, and OpenTelemetry-friendly observability. OpenAPI 3.1 gives first-class JSON Schema 2020-12 compatibility for HTTP API descriptions.

The most valuable bridge work would be a set of official annexes titled along the lines of “UAI-1 ↔ MCP Evidence Mapping”, “UAI-1 ↔ A2A Capability and Task Mapping”, and “UAI-1 ↔ ACP Run Mapping”. UAIX’s own roadmap already treats bridge evidence examples as current but formal bridge profiles as planned. vNext should move selectively from “examples” to “annexes” in the highest-value areas, but only where fixtures and validator behavior can prove the mapping.

For orchestration and runtime frameworks more broadly, UAIX should keep its current separation of concerns. The agentic harness guide is correct that workflow engines, application harnesses, approvals, traces, interruptions, and retries belong with the runtime owner. The vNext opportunity is to define portable excerpts from those environments rather than to imitate them. In practice, that means standardized exported fields for correlation, retry count, timeout, consent posture, redaction posture, and evidence references—exactly the additions proposed above.

The transport-binding story should also be turned into an explicit alternatives matrix. Today, keyed JSON over HTTPS is the review baseline and keyless JSON is a compact transport optimization. vNext should preserve that, then add three formal optional bindings. The best candidate structure is:

That layout keeps UAIX true to its current “record, not runtime replacement” principle while making it substantially easier to implement in real systems.

Conformance, governance, migration, and implementation plan

The current conformance ladder is a good backbone, but vNext should turn it into a sharper implementation program. The first step is to align the validator and field registry with what the levels already imply. L6 is especially important: until the registry, schemas, and fixtures all carry idempotency and correlation fields explicitly, reliable delegation will remain partly aspirational. The same principle applies to error and trust metadata. Every field or code that appears in conformance language should be backed by schema definitions, example fixtures, negative cases, and binding mappings.

A strong vNext conformance plan should add test vectors in five groups:

That plan extends what UAIX already does. The change log shows current negative cases for structure, trace context, DID/VC trust evidence, and keyless shape. vNext should keep that discipline and broaden it to reliability, trust status, privacy, and bridge semantics.

On maturity, I recommend keeping the existing L1–L7 conformance ladder intact and adding a separate operational maturity overlay. The current ladder expresses protocol support well, but it does not entirely express deployment maturity. A practical overlay would look like this:

That overlay is intentionally orthogonal to L1–L7 rather than a replacement.

Governance improvements should be equally additive. UAIX already has a dated changelog, roadmap state labels, evidence promotion gates, and public trust pages. vNext should add four missing pieces: an extension registry, a deprecation policy, a normative document-precedence rule, and a change-classification table that distinguishes editorial, additive, corrective, security-significant, deprecated, and breaking changes. Since UAIX already emphasizes that every trust-significant change should appear on the public page, machine artifact, QA evidence, and release trail together, these governance additions would extend existing release discipline rather than replace it.

A clean migration strategy can be published in one page:

That migration path preserves existing messages, current media types, and public examples while letting implementers adopt richer semantics incrementally.

Prioritized recommendations

Risk and benefit table

Implementation guidance for senders, receivers, validators, and publishers

For senders, the main vNext rule should be simple: emit full keyed JSON first, attach traceparent, use one message_id per semantic packet, generate an idempotency_key only for retriable or side-effecting work, and keep any proof, consent, or privacy claims referenced and hashed rather than improvised in free text. That is already consistent with UAIX’s current orientation toward explicit, reviewable records.

For receivers, the key change is to formalize claim-aware validation. If a sender claims L6-like semantics, then correlation_id, idempotency_key, timeout, and retry semantics must be present and internally consistent. If a sender claims credentialed, the relevant anchor and status references must verify according to the declared proof format. If a sender uses privacy or consent extensions, the receiver must either understand them or fail safely when they are marked critical. That is the right way to preserve additive compatibility without weakening trust.

For validators, vNext should distinguish three classes of outcomes much more clearly: structural invalidity, semantic policy failure, and claim inconsistency. Structural invalidity is current schema or field-registry failure. Semantic policy failure is things such as expired delivery, replay, or missing revocation proof. Claim inconsistency is when the packet is structurally valid but the support claim or conformance marker overstates what the packet actually proves. UAIX’s existing support-claim boundary already points in this direction; vNext should make it machine-readable.

For publishers, the discipline should remain “page + machine artifact + evidence + release trail.” The roadmap’s evidence-promotion gates are already excellent: public page update, machine artifact update, fixture or validator evidence, implementation or package evidence, and dated release trail. The best possible governance improvement is not a new institution; it is stronger enforcement of those gates and clearer deprecation windows.

Open questions and limitations

The public UAIX record is unusually complete for a launch-stage specification, but some machine-readable route bodies were easier to verify through public pages, examples, and route descriptions than through complete crawler-visible JSON dumps. In particular, the route listings for the error registry and conformance levels were discoverable, but the full error-registry body was not as accessible in the browsing output as the schema catalog, field registry, examples, and conformance ladder. Recommendations about the richer error taxonomy therefore rely primarily on the published schema catalog, examples, and route descriptions rather than a full registry dump.

ACP is also in a moving governance state: its own official docs now say it is becoming part of A2A under the Linux Foundation. That makes ACP still useful as a design reference for HTTP-native run lifecycle, manifests, and observability, but it also means UAIX should target ACP compatibility through A2A-aware bridge materials rather than treating ACP as a permanently separate strategic center.

The biggest open design question for UAIX is not whether to add more semantics. It is where to draw the line between portable evidence and runtime execution state as more production operators ask for delivery guarantees, consent records, telemetry enrichment, and richer trust verification. My recommendation throughout this report has been to keep that line where UAIX already places it: standardize only the smallest portable subset needed for reviewable interoperability, and leave the rest to runtimes, workflow engines, identity systems, and observability stacks. That preserves the core strength of UAI-1.