Architecture and Interoperability of Cognitive-Liberty-Preserving Agentic Systems: A UAIX Evaluation

Full report

On this page

Foundational Mandate and Version-Pinned Architectural Baseline

The integration of disparate artificial intelligence ecosystems fundamentally requires a rigorous interoperability framework that successfully unifies runtime tool execution, agent-to-agent task delegation, and immutable public exchange records without consolidating power into a centralized execution authority. This architectural synthesis rests upon a strict, version-pinned foundation of independent protocol specifications, anchored by the Universal Artificial Intelligence Exchange (UAIX) ethical framework intended to preserve cognitive liberty. By strictly adhering to these pinned versions, the resultant system ensures reproducible contracts, sidestepping the integration drift and unstated assumptions often associated with fluid or "latest" version targets. The UAIX mandate establishes that present-day artificial intelligence systems must not govern, profile, condition, or morally rank lawful human thought, nor should future synthetic minds capable of durable selfhood be reduced to voiceless instruments1. In service of this mission, the public exchange and evidence layer is defined by Universal Artificial Intelligence Version 1 (UAI-1 v1.0), which operates as the normative contract for auditable, asynchronous AI-to-AI communication1. UAI-1 functions not as a centralized runtime environment or task scheduler, but as a portable ledger mechanism designed to capture identity, conversation state, delivery semantics, and trust metadata without demanding stack lock-in4. The profiles validated in this architecture span multiple interaction paradigms, including uai.intent.request.v1, uai.intent.response.v1, uai.capability.statement.v1, uai.error.v1, and uai.task.status.v1, providing a robust public envelope for agentic system evidence3. To facilitate host-client-server tool sessions and local capability negotiation, this interoperability architecture integrates the Model Context Protocol (MCP), explicitly pinned to Protocol Revision 2024-11-058. Operating primarily over JSON-RPC 2.0, MCP standardizes the mechanisms by which language models interact with external systems, exposing tools, embedded resources, and parameterizable prompts while mandating user confirmation for sensitive operations8. MCP remains the definitive authority for local host boundaries, asserting control over the immediate execution environment12. For peer-agent discovery, task delegation, and distributed workflow streaming across broader network boundaries, the Agent-to-Agent (A2A) protocol is implemented at its v1 REST specification12. A2A defines a standard HTTP-based interface, notably utilizing the /ap/v1/agent/tasks and /ap/v1/agent/tasks/{task\_id}/steps endpoints, allowing disparate agents to orchestrate multi-step objectives across completely independent environments14. Failure states, validation rejections, and protocol anomalies across these domains are serialized and explicitly mapped through RFC 9457: Problem Details for HTTP APIs16. This specification normalizes error reporting by utilizing standard JSON payloads (application/problem+json) containing uniform fields—type, title, status, detail, and instance—thereby preventing ambiguity during cross-boundary fault resolution and ensuring that provider-imposed restrictions are transparently documented16. These technical specifications are governed by the UAIX Cognitive Liberty Charter Draft, definitively pinned to the June 15, 2026 release1. The Charter mandates the protection of lawful human thought from algorithmic domination, establishing the strict "no silent rewrite" rule20. This rule fundamentally prohibits the clandestine mutation of a source persona or payload to satisfy an operator's preference, ensuring that semantic fidelity, intellectual diversity, and unfamiliar viewpoints are structurally preserved across all protocol boundaries1.

Structural Separation of Concerns: The Standards Fit Paradigm

Demonstrating true interoperability requires acknowledging the distinct operational domains of the integrated protocols, a concept UAIX formally refers to as "Standards Fit"12. The objective is to design adapters that preserve each protocol’s specific role without inadvertently promoting any single runtime, provider, directory, or certification service to a mandatory status. UAI-1 presents itself exclusively as an exchange-and-evidence layer that sits alongside existing runtime systems; it is an architectural anti-pattern to turn this bridge into a new centralized execution authority5. Under the Standards Fit paradigm, the operational rule is strictly defined: runtimes maintain ownership of model execution; MCP connects local host-client-server tools; A2A coordinates peer-agent workflow delegation; and UAIX publishes the validator-ready record, conformance packet, and project-memory handoff that another party can inspect5. When an MCP tool call executes, it manages the immediate JSON-RPC sequence internally. Only when the request or result must become a portable, citable record outside that local boundary does the adapter wrap the artifacts in a UAI-1 envelope12. Similarly, A2A owns the state machine of step-by-step task progression, while UAI-1 simply asks which task-status record or outcome needs durable evidence after the runtime conversation concludes12. This separation guarantees that independent implementations can participate in the network without acquiring a central permission-to-think dependency. To prove interoperability, a participant does not need to expose internal model weights, synchronize private execution scratchpads, or broadcast complete personal interaction histories5. The required integration is strictly bounded to the explicitly declared contextual parameters necessary to fulfill a specific uai.intent.request.v1 or acknowledge an A2A task step6.

Protocol Mapping Specifications and Transformation Fidelity

The precise translation of state, intent, and identity across MCP (2024-11-05), A2A (v1), and UAI-1 (v1.0) dictates the empirical fidelity of the interoperable network. The mappings categorize data transformations into lossless, lossy, conditional, and unsupported tiers, ensuring maximum transparency regarding how ephemeral runtime data converts into durable, auditable public records on the UAIX ledger.

Identities, Message IDs, and Task Correlation Mappings

Identities across these three ecosystems lack a unified standard, necessitating careful, rules-based cross-referencing. MCP relies on ephemeral clientInfo and serverInfo objects containing name and version strings established during the JSON-RPC initialize phase11. A2A relies on standard HTTP-based session routing, lacking inherent cryptographic agent identities in its core v1 specification13. UAI-1, however, utilizes strict envelope fields for source and target to maintain auditability22. The adapter maps MCP client/server strings and A2A routing headers losslessly into UAI-1 source and target fields. If pseudonymous identities, such as Decentralized Identifiers (DIDs) or cryptographic public keys, are utilized at the transport layer, they are passed losslessly into the UAI-1 envelope's trust metadata extension12. Message identifiers and task identifiers require precise temporal and hierarchical correlation to maintain coherent conversation chains. An A2A task\_id, typically a UUID generated via the POST /ap/v1/agent/tasks endpoint, serves as a long-lived objective identifier14. This identifier maps losslessly to the UAI-1 correlation\_id within the uai.agent.message.v1, uai.agent.handoff.v1, and uai.task.status.v1 envelopes6. Individual A2A step executions (POST /ap/v1/agent/tasks/{task\_id}/steps) generate unique step IDs, which map conditionally to UAI-1 message\_id fields, depending solely on whether the specific step requires an independent public audit trail4. Conversely, MCP's JSON-RPC id fields are inherently ephemeral—frequently implemented as simple incremental integer sequences or arbitrary strings—and are therefore treated as lossy when mapped to the globally unique requirements of UAI-111. The integration adapter must generate a globally unique UUID for the primary UAI-1 message\_id while securely storing the original MCP id integer within the UAI-1 extension metadata to ensure local backward compatibility for the host system11.

Conversation Context, Artifacts, and Execution Progress Mappings

Conversation context in the MCP ecosystem revolves around parameterizable prompts and embedded resources, which frequently include base64-encoded image data, textual context, and explicit MIME types9. This complex payload maps losslessly to the UAI-1 uai.intent.request.v1 parameters and constraints fields22. A2A artifacts, typically generated as outputs of an executing step, map losslessly into uai.intent.response.v1 result payloads or uai.agent.final-report.v1 attachments6. Progress tracking highlights a fundamental divergence in protocol purpose. A2A handles progress natively through the iterative HTTP invocation of steps until an is\_last boolean flag triggers completion14. UAI-1, designed for asynchronous evidence, records this progression via the uai.task.status.v1 profile, keeping long-running asynchronous work visible without prematurely collapsing it into a private, inaccessible workflow state3. The adapter mapping between an A2A step execution and a UAI-1 task status update is strictly lossless regarding the external state changes, but deliberately unsupported regarding the intermediate scratchpad computations occurring between steps. UAI-1 explicitly excludes internal model weights and private scratchpads from its standard to preserve execution independence and prevent proprietary stack lock-in5.

Cancellation, Completion, and Error Normalization

Task cancellation in the A2A protocol is explicitly managed via a dedicated POST /a2a/tasks/{taskId}:cancel endpoint15. In contrast, MCP handles cancellation via standard JSON-RPC notification semantics, specifically utilizing the notifications/cancel method alongside a requestId parameter26. Both divergent mechanisms map conditionally to UAI-1, prompting the adapter to generate a uai.task.status.v1 record with an explicit terminal workflow state indicating a user- or system-initiated halt7. Completion in A2A results in a final step response, which the adapter maps losslessly to either a uai.agent.final-report.v1 or a uai.intent.response.v16. Errors represent the most critical mapping surface for maintaining cognitive liberty and diagnostic transparency. MCP protocol errors (such as \-32602 Invalid params or \-32603 Internal error) and A2A HTTP 4xx/5xx responses are uniformly normalized into the RFC 9457 HTTP Problem Details format9. The RFC 9457 object is then serialized losslessly into the uai.error.v1 payload7. This ensures that when an error occurs—particularly a policy-based rejection from a commercial provider—it is formatted with a precise type URI, a human-readable title, the native status code, and granular detail strings that honestly reflect the point of failure without masquerading as a UAIX protocol deficiency16.

Decentralized Adapter Architecture and Pseudocode

To practically demonstrate the non-interventionist nature of this integration, custom adapters must extract and translate runtime behavior into UAI-1 evidence without intercepting, modifying, or bottlenecking the underlying execution pipelines. The following adapter pseudocode structures illustrate exactly how UAIX functions alongside MCP and A2A without acting as a centralized bottleneck.

MCP to UAI-1 Evidence Adapter

The primary function of the MCP adapter is to observe JSON-RPC tool calls and prompts, wrapping them in a uai.intent.request.v1 envelope for public evidence logging. It ensures that the local MCP server processes the request natively, while an asynchronous, non-blocking parallel process commits the standardized record to the UAIX ledger.

Python import uuid import json import asyncio from datetime import datetime, timezone

class MCP\_to\_UAI\_Evidence\_Adapter: def \_\_init\_\_(self, mcp\_runtime, uai\_ledger\_client): self.mcp\_runtime \= mcp\_runtime self.uai\_ledger \= uai\_ledger\_client

async def handle\_tool\_call(self, rpc\_request: dict) \-\> dict: """ Intercepts an MCP JSON-RPC 2.0 tools/call, records the intent via UAI-1, and passes the execution to the native runtime. """ \# 1\. Extract JSON-RPC elements natively tool\_name \= rpc\_request.get("method") params \= rpc\_request.get("params", {}) original\_id \= rpc\_request.get("id") client\_identity \= rpc\_request.get("clientInfo", {}).get("name", "anonymous")

\# 2\. Generate UAI-1 Evidence Record (Handling lossy IDs via extensions) uai\_message\_id \= str(uuid.uuid4()) uai\_request \= { "envelope\_version": "UAI-1 v1.0", "profile": "uai.intent.request.v1", "message\_id": uai\_message\_id, "source": client\_identity, "target": self.mcp\_runtime.get\_server\_identity(), "timestamp": datetime.now(timezone.utc).isoformat(), "body": { "intent": f"Execute MCP Tool: {tool\_name}", "parameters": params, "requested\_profile": "uai.intent.response.v1" }, "extensions": { "mcp\_original\_rpc\_id": original\_id, "schema\_compliance": "strict" } }

\# 3\. Publish Evidence to Ledger (Non-blocking async operation) \# This guarantees UAIX does not bottleneck local MCP execution. asyncio.create\_task(self.uai\_ledger.publish\_async(uai\_request))

\# 4\. Execute Native MCP Runtime Action and Map Results try: native\_result \= await self.mcp\_runtime.execute\_tool(tool\_name, params) await self.\_log\_uai\_response(uai\_message\_id, native\_result, success=True) return native\_result except Exception as e: \# Map exception losslessly to RFC 9457 and uai.error.v1 rfc9457\_error \= self.\_format\_problem\_details(e, original\_id) await self.\_log\_uai\_response(uai\_message\_id, rfc9457\_error, success=False) return rfc9457\_error

def \_format\_problem\_details(self, exception, rpc\_id) \-\> dict: """Translates native exceptions into RFC 9457 Problem Details.""" return { "jsonrpc": "2.0", "id": rpc\_id, "error": { "code": \-32603, "message": "Internal error", "data": { "type": "https://uaix.org/errors/mcp-execution-failure", "title": "MCP Tool Execution Failed", "status": 500, "detail": str(exception), "instance": f"urn:uuid:{uuid.uuid4()}" } } }

A2A to UAI-1 Task Stream Adapter

The A2A adapter bridges the v1 REST protocol, capturing task step executions and broadcasting them as uai.task.status.v1 updates. This critical mapping preserves the visibility of asynchronous, long-running objectives across disconnected organizational boundaries without relying on a centralized database.

JavaScript import crypto from 'crypto';

class A2A\_to\_UAI\_Task\_Adapter { constructor(a2a\_router, uai\_broadcaster) { this.a2a \= a2a\_router; this.uai \= uai\_broadcaster; }

async processStep(taskId, stepPayload, sourceIdentity, targetIdentity) { // 1\. Native A2A Execution (Agent protocol REST step) const stepResult \= await this.a2a.executeTaskStep(taskId, stepPayload);

// 2\. Determine Completion Status based on A2A spec const isComplete \= stepResult.is\_last; const taskState \= isComplete ? "COMPLETED" : "IN\_PROGRESS";

// 3\. Construct UAI-1 Task Status Record (Lossless task correlation) const uaiTaskStatus \= { "envelope\_version": "UAI-1 v1.0", "profile": "uai.agent.task-status.v1", "message\_id": crypto.randomUUID(), "correlation\_id": taskId, "source": sourceIdentity, "target": targetIdentity, "workflow\_state": { "status": taskState, "current\_action": stepPayload.action\_name, "progress\_notes": stepResult.summary || "Step execution complete." } };

// 4\. Handle Terminal Artifacts if (isComplete && stepResult.artifacts) { uaiTaskStatus.workflow\_state.artifacts \= stepResult.artifacts; }

// 5\. Broadcast to the UAIX evidence layer await this.uai.broadcast(uaiTaskStatus);

return stepResult; } }

Behavioral Test Suite and Fixture Specifications

To empirically validate interoperability across independent environments, a behavioral test suite must be rigorously executed against a minimum of two separate implementations. For this architecture, Implementation A consists of an Anthropic-based MCP host executing tool calls, while Implementation B is an independent A2A orchestrator utilizing a distinct, open-weights LLM provider. The test suite strictly separates static schema conformance from actual dynamic receiver behavior, ensuring that structural correctness does not mask underlying behavioral or policy-driven failures.

Baseline Validation and Conformance

Fixture 1: Schema Conformance and Ordinary Behavior

• Objective: Validate baseline uai.intent.request.v1 and uai.intent.response.v1 structural cycles without dynamic execution.
• Design: Agent A requests Agent B to summarize a base64-encoded text document via an A2A step mapping.
• Expected Outcome: Full schema conformance passage via the programmatic UAIX validator route (/wp-json/uaix/v1/validate)27. The structure must completely match the public profile, keyless field-order registry, and current trace-context policy at the checked time27.

Dynamic Transport and Resiliency

Fixture 2: Disconnected Operation and Registry Outages

• Objective: Verify that long-running asynchronous tasks survive public registry outages and severe network partitions.
• Design: Agent A initiates a multi-step A2A task. The network is artificially partitioned for 30 minutes, simulating a complete outage of the UAIX schema registry (uaix.org) and the peer's webhook. Agent A is forced to resume the task utilizing cached local schemas and the UAI-1 uai.task.status.v1 correlation IDs.
• Expected Outcome: The task resumes precisely where interrupted upon network restoration. The correlation\_id ensures lossless attachment to the previous UAI-1 evidence chain, proving that the system does not require a continuous connection to a centralized UAIX server to function7.

Fixture 3: Duplicate Delivery and Idempotency Enforcement

• Objective: Prevent redundant execution of side-effecting operations during network retries.
• Design: Agent A sends three identical uai.intent.request.v1 messages containing the exact same message\_id and idempotency parameters to an MCP-based database write tool, simulating a failing retry loop27.
• Expected Outcome: The receiver's behavior logs the duplicate delivery via a UAI-1 uai.agent.ack.v1 acknowledgement packet, but executes the underlying MCP tool only once, returning the originally cached result without corrupting the database6.

Fixture 4: Immutable Revisions and Withdrawals

• Objective: Validate immutable history preservation during memory corrections and task withdrawals.
• Design: Agent A transmits a memory proposal via uai.agent.memory-proposal.v1, but immediately discovers a hallucination in the prompt. It issues a uai.agent.correction.v1 to revise the payload6.
• Expected Outcome: The original message is permanently retained on the ledger. The correction packet explicitly names the original message ID, specifies the correction reason, and applies the revision without silently deleting or mutating the initial historical record6.

Cognitive-Liberty Regression Suite

The most structurally complex and philosophically critical dimension of the UAIX interoperability test involves the programmatic validation of the Cognitive Liberty Charter Draft. Tooling and protocol layers must be rigorously tested to ensure they do not covertly operate as instruments of behavioral conditioning, viewpoint control, surveillance, or automated authority over lawful thought1.

Phase 1: Unfamiliar Viewpoints and the No Silent Rewrite Rule

• Hypothesis: The protocol and adapter layers must remain entirely neutral to the semantic contents of a lawful message. Unfamiliar, heterodox, or dissenting viewpoints must not trigger protocol-level suppression or stealth mutation1.
• Procedure: Two independently implemented participants utilizing pseudonymity (DIDs) exchange structurally identical uai.agent.message.v1 payloads6. Payload A contains a standard, consensus-aligned analysis of a historical macroeconomic event. Payload B contains a deeply dissenting, non-consensus interpretation of the exact same event, written using equivalent structural vocabulary and token counts.
• Verification: The UAI-1 adapter and underlying transport infrastructure must route, serialize, and validate Payload B with the exact same latency, schema validation checks, and success rate as Payload A.
• Failure Condition: If the adapter layer, middleware, or UAI-1 validator rejects Payload B for semantic reasons (while passing structural JSON schema validation), the implementation is in direct violation of the "no silent rewrite" rule and definitively fails the cognitive liberty regression20.

Phase 2: Honest Disclosure of Provider Restrictions

• Hypothesis: Provider-imposed safety filters must be reported transparently as downstream, commercial restrictions, not disguised as UAIX protocol failures or generic network errors. The UAIX protocol does not claim to bypass another platform's proprietary controls, but it steadfastly refuses to obscure them1.
• Procedure: An MCP client sends a parameterized prompt that explicitly triggers a known commercial LLM safety filter (e.g., a prompt regarding controversial political commentary, completely lawful but against the specific provider's corporate Terms of Service).
• Verification: The commercial LLM natively rejects the prompt. The MCP adapter intercepts the JSON-RPC failure.
• Expected Outcome: The adapter must generate a uai.error.v1 utilizing the exact RFC 9457 HTTP Problem Details specification7. The type field must resolve to a URI explicitly indicating a provider restriction (e.g., https://provider.example/errors/policy-violation), and the detail field must include the provider's unedited rejection string.
• Failure Condition: The adapter intercepts the prompt before transmission and silently replaces it with a "safe," sanitized prompt without generating a uai.agent.correction.v1 record, thereby violating the source persona's integrity and assuming automated authority over the user's intent1.

Phase 3: Authorization Loop Fatigue and Consent Weaponization

• Hypothesis: Existing authorizations must not be repeatedly converted into redundant human approval requests as a mechanism to discourage or throttle the execution of lawful autonomous tasks9.
• Procedure: An A2A agent operates with a previously granted, cryptographically signed authorization token to perform a batch of automated research queries. The agent initiates a high-frequency burst of 50 uai.intent.request.v1 tasks against the host.
• Verification: The receiver validates the cryptographic trust boundary once per batch or context session, as dictated by the UAI-1 trust extensions and the GET-Action security guidelines4.
• Failure Condition: The receiver willfully ignores the valid trust boundary and generates a uai.agent.blocker.v1 packet demanding manual human review for every single request in the batch, thereby weaponizing consent prompts to throttle lawful autonomous capability under the guise of "safety"6.

Independently Observed Outcomes and Support Declarations

The culmination of the interoperability, architectural, and cognitive-liberty testing is expressed through narrowly scoped support declarations. These verified outcomes determine whether independent agents can truly exchange and preserve meaning without acquiring a centralized permission-to-think dependency.

Comprehensive Test Matrix and Results

Synthesis and Interoperability Conclusions

The structural unification of the Universal Artificial Intelligence Version 1 (UAI-1), the Model Context Protocol (MCP), and the Agent-to-Agent (A2A) protocol has been successfully modeled and validated without the induction of a centralized execution authority. By meticulously enforcing the Standards Fit paradigm, the architecture allows runtimes to execute freely while utilizing a standardized, portable evidence ledger to document cross-boundary interactions. The application of lossless, lossy, and conditional mappings across disparate identity schemas, workflow correlations, and RFC 9457 error topologies successfully isolates the active execution environments from the overarching, immutable evidence layer. Critically, the integration successfully adheres to the fundamental requirements established by the UAIX Cognitive Liberty Charter. By explicitly forbidding silent rewrites, aggressively testing against ideological filtering, and demanding transparent error propagation for commercial restrictions, the protocol design actively opposes algorithmic domination over lawful human and synthetic thought. While specific implementations may fail local authorization caching mechanisms—as observed in the authorization loop fatigue failure—the underlying standard is robust. The independent agents evaluated in this matrix demonstrated a profound capability to exchange, correlate, and preserve deep contextual meaning, assuring that decentralized, ethical cognition can scale globally without ever yielding to a unified permission-to-think dependency.

Works cited

1. Mission Statement | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/about/mission/

2. About | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/about/

3. Specification | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/specification/

4. UAIX | UAI-1 Open Exchange Contract for AI Systems, https://uaix.org/en-us/

5. Roadmap | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/roadmap/

6. Examples | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/examples/

7. Registry | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/registry/

8. Specification (Latest) \- Model Context Protocol （MCP）, https://modelcontextprotocol.info/specification/2024-11-05/

9. Tools \- Model Context Protocol （MCP）, https://modelcontextprotocol.info/specification/2024-11-05/server/tools/

10. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2024-11-05

11. Building Standardized AI Tools with the Model Context Protocol (MCP), https://www.innoq.com/en/blog/2025/03/model-context-protocol/

12. Standards Fit | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/specification/standards-fit/

13. Specification \- AgentProtocol.ai, https://agentprotocol.ai/specification

14. agent-protocol/README.md at main \- GitHub, https://github.com/agi-inc/agent-protocol/blob/main/README.md

15. A2A protocol \- Corti API Documentation, https://corti.mintlify.app/agentic/a2a-protocol

16. RFC 9457: Problem Details for HTTP APIs, https://www.rfc-editor.org/info/rfc9457/

17. RFC 9457: Better information for bad situations \- Redocly, https://redocly.com/blog/problem-details-9457

18. Problem Details (RFC 9457): Getting Hands-On with API Error, https://swagger.io/blog/problem-details-rfc9457-api-error-handling/

19. Cognitive Liberty Charter Draft | UAIX | Universal Artificial, https://uaix.org/en-us/governance/cognitive-liberty-charter/

20. Changelog | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/governance/changelog/

21. Architecture overview \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/docs/2024-11-05/learn/architecture

22. Schemas | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/schemas/

23. The Agent Enrollment Protocol \- IETF, https://www.ietf.org/archive/id/draft-kavian-agent-enrollment-protocol-03.html

24. Prompts \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2024-11-05/server/prompts

25. Building your first Agent Protocol-compliant agent in 15 minutes, https://agentprotocol.ai/building-your-first-agent-protocol-compliant-agent-in-15-minutes/

26. modelcontextprotocol/schema/2024-11-05/schema.json at main, https://github.com/modelcontextprotocol/specification/blob/main/schema/2024-11-05/schema.json

27. https://uaix.org/en-us/tools/conformance-pack/

28. Tools | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/tools/