UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIX.org Universal Artificial Intelligence Exchange Public standards publication
Current UAI-1
  • Current version UAI-1
  • Plain-English definition Open message format for auditable AI-to-AI exchange
  • Current attribution Michael Joseph Kappel, MCP
  • Start here Get Started, Project Handoff, UAI-1, validator, roadmap, and changelog

Implementations

.NET Bridge Track

Runtime integration track that connects the public UAI-1 record to .NET services.

  • Record UAIX-IMPL-0055
  • Path /en-us/implementations/dotnet-bridge/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-IMPL-0055
Surface
Implementations
Access
Public and linkable

How to use this page

Use this track when published UAI-1 messages need to connect to .NET services without changing the public contract.

When to choose this track

Use the .NET Bridge Track when the public UAI-1 record needs to connect to deeper runtime services, orchestration layers, or backend execution flows without turning the public site into the application runtime.

What this track covers

The bridge should preserve the public UAI-1 contract while adapting it to service-side execution. It can map, validate, route, and log messages, but it should not introduce hidden profile behavior, undocumented payload shortcuts, or runtime-only semantics that contradict the public schema, registry, examples, or validator.

Responsibilities

  • Map public standard records to runtime-accessible endpoints and services.
  • Preserve validation, provenance, versioning, and compatibility rules across the handoff.
  • Keep publication concerns separate from execution concerns while still pointing back to the public record.

Current public packaging status

  • uaix-bridge.zip is the current packaged WordPress-side artifact for the named bridge track.
  • The public record does not yet publish a standalone NuGet package, general-purpose .NET SDK, or broader .NET package catalog.
  • Treat the current .NET story as a named bridge lane tied back to the WordPress package family, validator evidence, and release notes rather than as a broad ecosystem claim.

Public records that must stay attached

What counts as evidence here

  • Messages that still pass the public Validator after runtime integration.
  • Profile resolution and provenance that still match the published Registry and public Examples.
  • Release notes and compatibility statements recorded through Governance, the Changelog, and linked implementation updates.

Current support-claim boundary

The .NET Bridge Track supports runtime mapping that preserves the public UAI-1 contract. It does not, by itself, publish a general .NET SDK or blanket .NET ecosystem support claim.

  • A passing bridge integration supports a claim that the tested handoff still aligned with the public record at review time.
  • A current public support claim for .NET should stay scoped to the named bridge behavior, release packet, and compatibility notes published on the site.
  • Do not use this track to imply support for unrelated frameworks, transports, or hidden runtime conventions that are not attached to the public record.

When this track is release-ready

  1. Integrated messages still pass validator-backed checks against the published schemas, registry entries, and examples.
  2. Runtime mapping notes, release versioning, and migration guidance are attached to the same public release packet.
  3. The release trail states what the bridge supports now without implying a broader SDK, certification, or ecosystem program.

Next step

Use the bridge alongside the public record, not instead of it. Keep validator evidence, registry references, example links, and public change records attached to every integrated release.