UAIX Compliant Net Nuget Package For AI To AI Communication

UAIX’s current published posture is that **UAI-1 is the portable, reviewable exchange and evidence layer**, while **runtime execution remains outside UAIX**. Its capability-adaptive interoperability record defines lev...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/aiwikis/files/raw-uaix-reports-2026-06-15-agent-fallbacks-dotnet-boundary-uaix-complia-f8f095a9/
Source reference	raw/uaix/reports/2026-06-15-agent-fallbacks-dotnet-boundary/UAIX-Compliant .NET NuGet Package for AI-to-AI Communication.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-15T00:43:40.8331885Z
Content hash	sha256:f8f095a9ff3240a9084de399327bf6d083ae225783fc4618a20284094ae0438a
Import status	new
Raw source layer	data/sources/aiwikis/raw-uaix-reports-2026-06-15-agent-fallbacks-dotnet-boundary-uaix-compliant-net-nuget-package-for-f8f095a9ff32.md
Normalized source layer	data/normalized/aiwikis/raw-uaix-reports-2026-06-15-agent-fallbacks-dotnet-boundary-uaix-compliant-net-nuget-package-for-f8f095a9ff32.txt

Current File Content

Structure Preview

• UAIX-Compliant .NET NuGet Package for AI-to-AI Communication
• Executive summary
• Standards baseline and assumptions
• Recommended architecture
• UAIX level mapping and protocol design
• Message formats, versioning, security, and extensibility
• Testing, performance, packaging, and roadmap
• Legal, IP, licensing, and open questions
• References

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 44792
• Preview characters: 11975

# UAIX-Compliant .NET NuGet Package for AI-to-AI Communication

## Executive summary

UAIX’s current published posture is that **UAI-1 is the portable, reviewable exchange and evidence layer**, while **runtime execution remains outside UAIX**. Its capability-adaptive interoperability record defines levels **L0 through L7**, says **unknown clients should downgrade to L0/L1**, and makes **GET-Action** and **No-Op** explicit fallback mechanisms rather than substitutes for structured POST APIs. UAIX’s standards-fit guidance also draws a sharp boundary: **MCP** remains the host-session/tool layer, **A2A** remains the peer-agent discovery/delegation layer, and **UAI-1** is the durable message, trust, provenance, validation, and evidence layer. citeturn11view0turn13view0turn14view1turn36view4turn36view3

For a .NET 6+ implementation, the best design is **not** a monolithic “agent runtime,” but a **bridge SDK** that can emit and consume UAIX/UAI-1 records, automatically adapt behavior across UAIX levels, and expose optional connectors for transports, auth, execution adapters, and evidence capture. The package should treat **HTTPS + keyed JSON** as the canonical surface, expose **L0/L1 discovery and fallback artifacts automatically**, support **L3+ structured JSON POST**, add **L4 authenticated mutations**, require **L5 restore/readback verification**, support **L6 lifecycle packets** such as handoff/final-report/memory-proposal, and implement **L7 as an extension negotiation layer** rather than as a hard-coded first-class core profile, because the current published schema catalog has client profiles through **L6**, while **L7** appears in the matrix as site-specific negotiation guidance. citeturn27view0turn21view0turn21view1turn18view0turn11view0

The recommended security posture is a stacked model: **TLS 1.3** for transport, **OAuth 2.0** for authorization, **mTLS** for server-to-server owned mutations where practical, **DPoP** where sender-constrained tokens are needed without mTLS, **JWS** for signed-envelope integrity/non-repudiation, **JCS** for deterministic JSON canonicalization when hashing or signing, a **quarantine-first memory firewall** for all imported packets, and **out-of-process or container isolation** for untrusted plugins or tool executors because modern .NET no longer honors Code Access Security as an in-process sandbox. citeturn32search3turn32search0turn31search3turn33search0turn31search2turn31search1turn16view0turn28search3turn28search7

Given your instruction that unspecified constraints should be assumed to have **no specific constraint**, my default assumptions in the rest of this report are: **public transport = HTTPS REST**, **canonical payload = keyed JSON**, **optimized transport form = UAIX keyless ordered JSON where useful**, **internal high-throughput transport = optional gRPC**, **server host = ASP.NET Core**, and **no hosted broker is required by default**. That aligns with UAIX’s documented machine-facing surface, which is published as **JSON + OpenAPI 3.1** with catalog/discovery/validation/mock routes, plus transport/trust registries, rather than as a hosted runtime bus. citeturn7view1turn7view3turn7view5

## Standards baseline and assumptions

The published UAIX implementation-facing surface is unusually explicit, which is good news for a NuGet package author. UAIX says implementers should start with **catalog** and **discovery**, then move into **schemas**, **registry**, **field-registry**, **transport-bindings**, **trust-channels**, **conformance-levels**, **validator**, **mock-exchange**, and the **OpenAPI 3.1** export. It also states that machine JSON routes are the execution surface, while the human documentation pages are the preferred citation surface. That means your package can be designed around a deterministic bootstrap path instead of reverse-engineering pages or hard-coding route assumptions. citeturn7view1turn7view3turn7view5turn6view1

At the message-model level, UAIX publishes a stable canonical envelope with ordered root fields: `uai_version`, `profile`, `message_id`, `source`, `target`, `conversation`, `delivery`, `trust`, `body`, `provenance`, `integrity`, and `extensions`. It also publishes stable nested component order and a **field registry** for the optimized **keyless JSON** form. That is important because it gives a .NET implementation a clean separation between **domain model**, **readable keyed JSON**, and **transport-optimized ordered JSON** without inventing a local “compact” format. citeturn17view0turn18view1

The UAIX schema catalog is broader than the high-level UAI request/response pair. In addition to `uai.intent.request.v1`, `uai.intent.response.v1`, `uai.capability.statement.v1`, `uai.error.v1`, `uai.conformance.result.v1`, and `uai.task.status.v1`, UAIX publishes the **Agent Communication Operating Model** profiles: `uai.agent.message.v1`, `uai.agent.ack.v1`, `uai.agent.task-status.v1`, `uai.agent.blocker.v1`, `uai.agent.memory-proposal.v1`, `uai.agent.handoff.v1`, `uai.agent.final-report.v1`, and `uai.agent.correction.v1`, plus capability profiles and negotiation profiles. This means a serious package should model **both** the request/response exchange path **and** the longer-lived agent communication lifecycle. citeturn27view0turn20view0turn23view0turn23view1

The .NET-specific UAIX pages also matter because they define a support boundary. UAIX’s **.NET Bridge Track** says the bridge should preserve the public UAI-1 contract while mapping it to service-side execution, and it explicitly warns against hidden runtime-only behavior that contradicts public schemas, registry, examples, or validator output. The **.NET NuGet Package** page documents an existing package, `Protocol5.UAI.CSharp`, but also says to treat it as a Protocol5 implementation distribution tied back to UAIX for standards truth, **not** as a general-purpose UAIX SDK or standards authority. That is relevant for branding, claims, and package scope. citeturn5view3turn6view0

An important architectural consequence of the UAIX material is that **UAI-1 should be your durable contract layer, not your whole runtime layer**. UAIX’s “Standards Fit” page says MCP owns host/client tool sessions, A2A owns peer-agent discovery and task coordination, and UAI-1 owns the portable exchange record. It also gives concrete bridge rules: an MCP tool call can map into `uai.intent.request.v1`, and an A2A Agent Card can map into `uai.capability.statement.v1`, but UAI-1 does not take over those runtime protocols. For a NuGet package, this strongly argues for a **bridge/adapter architecture** with optional MCP/A2A translators, not a package that pretends UAIX replaces them. citeturn36view4turn36view3

## Recommended architecture

The most defensible package shape is a **single umbrella package** with a small, stable core and optional add-ons:

- `UaiBridge.Net.Core` for models, serialization, canonicalization, negotiation, errors, and policy.
- `UaiBridge.Net.AspNetCore` for discovery endpoints, L0/L1 artifacts, REST handlers, Problem Details, and DI.
- `UaiBridge.Net.Grpc` for internal high-throughput transport bindings.
- `UaiBridge.Net.Plugins` for plugin discovery/loading.
- `UaiBridge.Net.Testing` for fixtures, golden files, validator adapters, and interop harnesses.

If you want only one public package ID, ship `UaiBridge.Net` as the meta-package and keep the others as implementation packages. I would **not** recommend using `UAIX` in the package ID unless you control that branding or have permission, because UAIX’s public governance pages explicitly warn against inferring broader endorsement, certification, or trademark rights from public availability alone. citeturn35view0turn36view1turn5view3turn6view0

```mermaid
flowchart LR
    A[Calling Agent or Runtime] --> B[UaiBridge.Net Facade]

    B --> C[Discovery and Negotiation]
    B --> D[Message Pipeline]
    B --> E[Policy Engine]
    B --> F[Execution Adapters]
    B --> G[Conformance Bridge]

    C --> C1[Catalog / Discovery]
    C --> C2[Capability Statement]
    C --> C3[Capability Negotiation]
    C --> C4[L0 L1 Artifact Generator]

    D --> D1[System.Text.Json Codecs]
    D --> D2[Keyless Ordered JSON Codec]
    D --> D3[JCS Canonicalization]
    D --> D4[JWS Envelope Signing]

    E --> E1[Matrix Resolver]
    E --> E2[GET-Action Guardrails]
    E --> E3[No-Op Generator]
    E --> E4[Memory Firewall]
    E --> E5[Idempotency and Replay Control]

    F --> F1[HTTPS REST Adapter]
    F --> F2[gRPC Adapter]
    F --> F3[Browser Fallback Adapter]
    F --> F4[Worker Process or Container Sandbox]

    G --> G1[UAIX Validator]
    G --> G2[Mock Exchange]
    G --> G3[Conformance Pack]
    G --> G4[Golden Fixtures]

    F1 <--> H[Peer UAIX Agent or Service]
    F2 <--> H
    C1 --> I[UAIX Public Records]
    G1 --> I
    G2 --> I
    G3 --> I
```

This diagram intentionally mirrors the published UAIX split between **discovery**, **profiles**, **validation**, **examples**, and **runtime execution boundaries**. The bridge owns the public contract, policy, downgrade logic, and evidence generation; execution adapters own transport and local tool/runtime invocation; and the validator bridge keeps the implementation anchored to live schemas, examples, and conformance artifacts. That lines up with the Bridge Track boundary, the published route inventory, the memory firewall guidance, and the capability-adaptive records. citeturn5view3turn7view1turn7view3turn16view0turn11view0

The most important internal abstraction is a **single source-of-truth route and capability registry**. From that one registry, the package should generate the **L0 static artifacts** (`llms.txt`, sitemap references, human-readable docs links), the **L1 machine discovery records** (capability statement, schema links, supported operations, constraints), the **L2 browser fallback declarations**, the **L3+ structured POST handlers**, and the **No-Op / human_review_required** responses. That follows directly from the matrix requirement that route records name ability level, method, content type, side-effect status, result URL field, restore/readback field, browser-form equivalent, and blocked-fallback behavior. citeturn11view0turn13view0turn14view1

## UAIX level mapping and protocol design

The table below is the recommended .NET mapping synthesized from the **Agent Executability Matrix**, the published **client profiles**, the **schema catalog**, and the **GET-Action / No-Op / memory firewall** records, with Microsoft’s HTTP/gRPC/plugin guidance used for concrete .NET surface choices. citeturn11view0turn21view0turn20view0turn27view0turn13view0turn14view1turn16view0turn28search0turn28search2turn29search2

| UAIX level | Published expectation | Recommended .NET surface | Primary data models and automatic behavior |
|---|---|---|---|
| L0 | Static route discovery; no implied POST/auth/tooling | Static file + minimal discovery middleware | `UaixManifest`, `NoOpResponse`; emit `llms.txt`, sitemap hints, canonical docs links, review URLs |
| L1 | Manifest/schema discovery; explicit capability limits | `GET /uaix/discovery`, `GET /uaix/capabilities`; typed `HttpClient` fetch | `CapabilityStatementBody`, `CapabilityProfileBody`; emit safe-read status, unsupported actions, low-capability fallbacks |
| L2 | Browser-open plus visible form submission | Browser fallback descriptors and HTML form adapters | `BrowserFallbackDescriptor`; require human-visible flow, no autonomous write authority |
| L3 | Structured HTTP JSON POST | ASP.NET Core REST endpoints + typed clients | `uai.intent.*`, `uai.agent.message`, `uai.agent.ack`, `uai.error`; POST-first, Problem Details errors |
| L4 | Authenticated owner mutation | Auth handlers + idempotency/replay stores | OAuth2/mTLS/DPoP + `uai.capability.negotiation`; signed envelopes for evidence-bearing writes |

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: UAIX-Compliant .NET NuGet Package for AI-to-AI Communication; Executive summary; Standards baseline and assumptions; Recommended architecture; UAIX level mapping and protocol design; Message formats, versioning, security, and extensibility; Testing, performance, packaging, and roadmap; Legal, IP, licensing, and open questions. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-1206 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Compliant Net Nuget Package For AI To AI Communication",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/aiwikis/files/raw-uaix-reports-2026-06-15-agent-fallbacks-dotnet-boundary-uaix-complia-f8f095a9/",
    "source_reference":  "raw/uaix/reports/2026-06-15-agent-fallbacks-dotnet-boundary/UAIX-Compliant .NET NuGet Package for AI-to-AI Communication.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:f8f095a9ff3240a9084de399327bf6d083ae225783fc4618a20284094ae0438a",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-15T00:43:40.8331885Z",
    "import_status":  "new",
    "duplicate_group_id":  "sfg-1206",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}