Implementations

.NET Adaptive Interoperability Track

Planned C#/.NET package architecture for capability detection, fallback-chain resolution, route metadata, UAI-1 evidence export, and optional MCP/A2A adapters without changing UAI-1 v1.0.

  • Record UAIX-IMPL-3395
  • Path /en-us/implementations/dotnet-adaptive-interoperability/
  • Use Canonical public record

Document status

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

How to use this page

Use this page as part of the current Implementations public record, then follow its linked standards pages for the next step.

What this track is for

This planned implementation track describes how UAIX-owned C# and .NET packages should support adaptive AI-to-AI interoperability without changing the public UAI-1 v1.0 standards label. It is a package engineering goal and evidence checklist, not a claim that UAIX.org currently hosts an agent runtime, MCP server, A2A peer, SDK, CLI, certification service, or automatic repository writer.

Capability selection model

The package should either accept an explicit client capability profile or derive one from observable host features. It should classify the current client as URL-only, indexed-fetch, browser-assisted, structured JSON POST, authenticated owner, restore/readback capable, multi-agent runtime, A2A peer, MCP client, tool-capable runtime, or MCP-server-capable host.

After classification, the package should choose the safest highest-supported path declared by the route record and fall back before guessing. The fallback chain must read highest_supported_path, lowest_safe_fallback, post_blocked_fallback, live_get_blocked_fallback, mcp_unavailable_fallback, auth_unavailable_fallback, tool_unavailable_fallback, human_review_url, and no_op_behavior.

Planned package components

Component Role Evidence required before support claim
Capability profile reader Accept explicit profile IDs and normalize observed host capabilities. Unit tests for every supported capability class and ambiguous-input no-op behavior.
Fallback-chain resolver Select the richest safe path and degrade to browser, compact JSON, public URL, or human review. Fixtures proving ramp-up and ramp-down selection for POST, live GET, auth, MCP, A2A, tools, and readback.
ASP.NET Core middleware Publish route metadata, result URL fields, restore/readback URL fields, and safe response shapes. Sample app and integration tests showing the generated route record matches UAIX public fields.
Typed HttpClient Send UAI-1 packets only after validation and endpoint policy checks. Tests for validation failure, non-HTTP rejection, retry/no-op behavior, and structured error handling.
UAI-1 evidence export Record selected path, fallback decisions, validation result, provenance, and final handoff. Validator fixtures and conformance-result examples tied to UAI-1 v1.0.
Optional MCP adapter Use host-provided MCP resources, prompts, or tools only when that runtime explicitly provides them. Unavailable-tool fallback fixtures; no hosted UAIX MCP-server claim.
Optional A2A adapter Map A2A agent cards or task handoffs into UAI-1 evidence when externally supported and consented. A2A unavailable fallback fixtures; no A2A support inferred from UAI-1 alone.

Public installability boundary

NuGet package versions are implementation software versions. They do not change UAI-1 v1.0. A package ID and version should be called installable only after NuGet.org lists that exact ID and version. Current package identity and listing status belongs on the .NET NuGet Package page.

Relationship to Agent Fallbacks

This track implements the client-side selection logic described by Agent Fallbacks and Full-Spectrum Support and the Agent Executability Matrix. Package code must not infer unsupported MCP, A2A, authenticated mutation, restore/readback, or external tool ability from a route URL alone.

Release gates

  1. Every supported capability class has unit tests and at least one fixture.
  2. Every missing capability path has a no-op or human-review fallback fixture.
  3. ASP.NET Core metadata examples publish the exact UAIX route-record fields.
  4. Typed HttpClient behavior rejects invalid packets before network use.
  5. UAI-1 evidence exports validate against public schemas and examples.
  6. Release notes name the NuGet package version separately from UAI-1 v1.0.

Next step

Use this page as the implementation checklist before widening .NET package support language. Until package code, fixtures, tests, release notes, and NuGet listing evidence agree, keep adaptive interoperability described as planned work.