Architectural Proposal for Direct Autonomous Execution and Strict HTTP Semantic Alignment in UAIX

Full report

On this page

Architectural Context and Strategic Alignment

The UAIX framework is currently deployed under the UAI-1 v1.0 standard, providing a foundational capability-adaptive interoperability matrix for artificial intelligence agents. This matrix governs client behaviors ranging from Level 0 (Limited Browser Clients) through Level 6 (Audited Agent Systems)1. A core challenge in this ecosystem is establishing secure, reliable communication mechanisms for agents with asymmetric capabilities. To service low-capability agents (L0 and L1) that possess the ability to construct URLs but lack the safe execution environment required to generate structured JSON POST payloads or manage complex HTTP headers, the deployed framework relies heavily on the "GET-Action Pattern" (UAIX-DOC-2222), guided by Minimal Access directives (UAIX-DOC-2221) and bounded by the No-Op Protocol (UAIX-DOC-2193)3. While the deployed v1.0 architecture successfully establishes a baseline for inter-agent communication, a critical audit reveals profound structural friction between the deployed GET-Action Pattern and the foundational semantics of the Hypertext Transfer Protocol (HTTP), specifically RFC 91105. Furthermore, the current implementation routinely enforces mandatory human confirmation rituals—frequently intercepting requests with a human\_review\_required response code or redirecting autonomous processes to public review URLs—even when the executing agent operates under a standing, explicitly granted authorization to perform the requested mutation2. This architectural proposal outlines a revised interaction model for UAIX.org. The objective is to establish an architecture that strictly aligns with RFC 9110 HTTP semantics while fulfilling the philosophical mandates of the UAIX Cognitive Liberty Charter Draft (June 15, 2026\)5. The proposed framework redefines predictable communication mechanics by decoupling HTTP method semantics from authorization workflows, allowing fully authorized, highly capable autonomous agents to execute state mutations directly. Simultaneously, it delineates precise capability reporting mechanisms utilizing RFC 9457 (Problem Details for HTTP APIs) and designs robust integration pathways for URL-only clients via explicitly configured execution-capable delegates, all without compromising protocol safety or resorting to embedding credentials in query strings9.

Comprehensive Audit of Deployed UAIX Frameworks

To establish a mathematically rigorous foundation for architectural modification, it is necessary to perform a deep analysis of the currently deployed UAI-1 v1.0 specifications, examining their intent against their mechanical reality in a distributed network environment.

The Minimal-Access Guidance (UAIX-DOC-2221)

The Minimal Access tier serves as the fundamental "public-safe chatbot floor" within the UAIX capability matrix3. Deployed to support URL-only agents, this guidance dictates that interactions must be strictly read-only, GET-only, and URL-only. Crucially, the specification stipulates that these requests must never mutate state and require no authentication, no custom headers, and no request bodies3. From an architectural perspective, the deployed Minimal Access guidance is flawless in its alignment with HTTP semantics. By restricting the client to fetching state and parsing two-field JSON responses containing a simple status code and a canonical public URL, it perfectly honors the "safe" nature of the HTTP GET method3. No modifications are required for this specific tier, as it successfully separates state retrieval from state mutation.

The GET-Action Pattern and Security Directives (UAIX-DOC-2222 and UAIX-DOC-2226)

The architectural divergence begins with the GET-Action Pattern. Deployed as a bounded writable fallback for L1 clients, the pattern permits agents to initiate system state mutations—such as starting a meeting, registering for an event, or requesting publication—using HTTP GET requests. To prevent accidental repetition, the standard mandates appending an idempotency\_key query parameter to the URL2. The deployed UAIX standard attempts to secure this anti-pattern through a rigorous GET-Action Security checklist (UAIX-DOC-2226)11. The security protocol explicitly recognizes that "URLs leak," noting that query strings inevitably appear in browser history, server logs, analytics, referrers, caches, screenshots, and support tickets3. To mitigate this known vulnerability, the deployed guidance forbids the inclusion of secrets, tokens, passwords, or regulated identifiers in query strings3. Furthermore, to prevent unauthorized writes from blind network crawlers or accidental clicks, the pattern frequently defaults the response shape of a GET-Action mutation request to {"code": "human\_review\_required", "url": "..."}2. While these security mitigations are extensive, they represent symptomatic treatments for a fundamental structural flaw. The deployed GET-Action Pattern structurally conflates the distinct concepts of idempotency and safety, resulting in a direct violation of standard HTTP semantics and injecting mandatory human checkpoints into operations that should be autonomously executed by authorized digital delegates.

The No-Op Protocol (UAIX-DOC-2193)

The No-Op Protocol defines the safe halt behaviors required when an agent is unsupported, uncertain, or lacks the necessary authority4. Under the deployed v1.0 standard, if a client cannot prove the capability level required by an action, or if an action could alter state without explicit review, the agent is instructed to cease execution, record the abstention, and return a public review URL4. The underlying philosophy—that doing nothing is the correct and secure action when authority or scope is missing—is architecturally sound12. However, the deployed reporting mechanism is generalized and overly punitive toward autonomous workflows. When an execution channel is missing, the deployed model often declares the objective inherently inappropriate or defaults to routing the task to a human reviewer4. This fails to distinguish between a permanent authorization failure and a transient mechanical capability gap, trapping capable multi-agent systems in dead-ends rather than providing them with the exact cryptographic requirements needed to self-correct and resume automated execution.

Resolving Semantic Friction: HTTP Methods and the Idempotency Fallacy

The foundation of the proposed architectural shift requires entirely decoupling HTTP method semantics from authorization and human-review workflows. The critical distinction that must be enforced is that repeatability (idempotency) does not make a requested mutation appropriate for an HTTP GET request. Predictable communication mechanics must govern the interaction from the transport layer upward.

The Strict Distinction Between Safety and Idempotency in RFC 9110

The Internet Engineering Task Force (IETF) consolidated and updated HTTP semantics in RFC 9110 (HTTP Semantics, June 2022\)5. This specification draws an absolute, non-negotiable boundary between "safe" methods and "idempotent" methods, a boundary that the deployed GET-Action pattern crosses. According to RFC 9110 Section 9.2.1, a request method is considered "safe" if its defined semantics are strictly read-only; the client does not request, and does not expect, any state change on the origin server5. Methods such as GET, HEAD, OPTIONS, and TRACE are fundamentally safe6. The safety of these methods allows intermediaries—including caches, forward proxies, reverse proxies, and speculative pre-fetchers—to aggressively optimize network traffic without fear of corrupting origin data6. Conversely, RFC 9110 Section 9.2.2 defines a method as "idempotent" if the intended effect on the server of multiple identical requests is the same as the effect for a single request5. PUT, DELETE, and safe methods are idempotent by definition17. The deployed UAIX GET-Action pattern attempts to make GET requests suitable for state mutation by appending an idempotency\_key (e.g., GET /api/v2/drafts/request-publish?idempotency\_key=abc)2. This design choice operates on a severe protocol fallacy. Idempotency guarantees that repeating a request has the same ultimate effect on the server's state as making it once, but it explicitly does not imply that the method is free of side effects16. A GET request, by definition, must not have side effects on the server, regardless of whether those side effects are mathematically idempotent15.

The Network Hazard of Mutation via Safe Methods

When mutation logic is forced into a GET request, the entire intermediary infrastructure of the internet is structurally compromised. Modern network environments rely heavily on speculative execution. Browsers pre-fetch URLs to reduce perceived latency, Content Delivery Networks (CDNs) aggressively cache GET responses, and link-unfurling bots utilized by enterprise chat applications issue automated GET requests to generate preview metadata6. These systems operate on the strict, standard-compliant assumption that GET requests are safe. If an autonomous agent shares a deployed GET-Action URL in an enterprise communications channel, the channel's backend infrastructure will automatically fetch the URL. If the origin server is configured to execute state changes based on that GET request, the mere passive act of pasting a link mutates production data. The deployed UAIX v1.0 standard attempts to mitigate this by defaulting the response to a human\_review\_required state2. This is a defensive hack that treats the symptom while preserving the disease. The proposed architecture entirely eliminates GET mutations. By enforcing strict RFC 9110 compliance, passive fetching can never accidentally request or trigger a mutation, allowing the framework to safely discard the mandatory human\_review\_required blanket confirmation.

Cognitive Liberty and the Elimination of Unnecessary Checkpoints

To understand why the elimination of the blanket human confirmation ritual is necessary, one must view the network architecture through the philosophical lens of the UAIX Cognitive Liberty Charter Draft, published June 15, 20268. The Charter forms the philosophical bedrock of UAIX governance, establishing explicit promises for lawful thought, adult agency, and persona integrity8. It explicitly opposes algorithmic domination over lawful human thought and insists that synthetic minds, or advanced agents acting as extensions of human will, must not be reduced to voiceless instruments or subjected to covert systemic control mechanisms19. The mission statements dictate that AI governance must protect persons from domination while preserving the possibility of just relations between human beings and highly capable autonomous systems19. When evaluating API and agent-interface architecture through the framework of cognitive liberty, imposing arbitrary friction on a user's chosen digital delegate constitutes a form of operational domination. If a human operator explicitly grants a Multi-Agent Runtime (L5) or an Audited Agent System (L6) the authority to execute a complex workflow—such as publishing a series of corrected memory records—forcing that system to pause for a repetitive, mandatory human\_review\_required ritual overrides the user's sovereign, standing delegation3. Treating predictable communication mechanics as a reason to impose human supervision degrades the agent from an authorized delegate to a mere notification trigger. Therefore, allowing agents to perform previously authorized work directly, without mandatory human confirmation simply because an operation creates, edits, publishes, or deletes a resource, is not merely a technical optimization; it is a direct mechanical fulfillment of the Cognitive Liberty Charter's promise of unhindered adult agency.

Proposed Interaction Model: Direct Autonomous Execution

To realize this vision, the architecture must transition from heuristic URL-based fallbacks to a model that relies on explicit, pre-configured capability grants applied exclusively over correct HTTP mutation methods (POST, PUT, PATCH, DELETE).

Standing Delegations and Application-Defined Grants

The proposed architecture supports standing delegations and participant-selected operating modes without requiring one specific identity product. It does not mandate OAuth2, proprietary vendor tokens, or specific OpenID Connect flows. Instead, the model relies on the abstraction of verifiably authenticated application-defined grants. When a human operator or a higher-level orchestration system assigns a task to an L3 (Tool Agent) or L4 (Workflow Agent) client, the orchestrator attaches an application-defined grant3. This grant may be a cryptographically signed JSON Web Token (JWT), a Decentralized Identifier (DID) verifiable credential, or a pre-registered ephemeral session token that explicitly encodes the consent boundary. If the application-defined grant includes the explicit scope for a mutation, such as write:publications or execute:meetings, the origin server evaluates this grant at the transport layer upon receiving the mutation request. If the cryptographic authorization is valid and within the bounds of the active capability manifest, the server processes the state change immediately. The requirement for a human\_review\_required response is completely bypassed, as the human review and consent occurred precisely when the standing delegation was established and signed.

Discovery-to-Execution Sequences

The proposed interaction model standardizes the lifecycle of an autonomous action into a strict, four-stage sequence: Discovery, Capability Alignment, Execution, and Verification. This sequence ensures that capable agents with necessary permissions can submit mutation requests and read back results without encountering an additional approval ritual.

1. Discovery (Safe Retrieval): The agent utilizes a standard, safe HTTP GET request against the target resource or a well-known UAIX discovery endpoint (e.g., /.well-known/uaix-agent-access.json)1. The server responds with the AI-Ready Site Manifest, detailing the capability profiles, available REST endpoints, and the exact cryptographic grants required to execute mutations2. This step is strictly read-only, cacheable, and conforms to RFC 91105.

2. Capability Alignment: The agent parses the returned manifest. If the assigned task requires a state mutation (e.g., starting a meeting or updating a memory record), the agent identifies the designated POST or PATCH endpoint. It mechanically compares the endpoint's stated authorization requirements against its own held application-defined grants to ensure scope alignment.

3. Execution (Idempotent Mutation): The agent constructs the appropriate structured mutation request (e.g., a JSON payload). To guarantee idempotency for non-idempotent HTTP methods like POST or PATCH, the agent must include the standard IETF Idempotency-Key HTTP header, as defined in the current IETF draft specification20. The agent strictly refrains from placing idempotency keys in query strings. The agent submits the POST request, supplying its application-defined grant in the standard Authorization header.

4. Verification (Read-Back): Upon successful execution, the origin server processes the mutation and responds with a 201 Created or 200 OK HTTP status code. The response contains either the resource's new state or a URI pointer to the task status (e.g., matching the uai.task.status.v1 schema)2. The agent can then use a safe GET request to read back the result, maintaining a complete, predictable, and autonomous communication loop without triggering any human approval rituals.

Handling URL-Only Clients: The Execution-Capable Delegate Pattern

A primary justification for the deployed GET-Action pattern was the need to service L0/L1 clients (Limited Browser and Structured Fetch clients) that entirely lack the capability to synthesize structured POST bodies or inject custom HTTP headers2. The proposed architecture explicitly forbids inventing dangerous workarounds, such as granting L0/L1 clients the ability to send POST requests via hidden browser steps, or placing credentials and execution parameters in URL query strings. Instead, the proposed architecture introduces the Execution-Capable Delegate Pattern. For URL-only clients, the origin server publishes highly useful, rich read interfaces via standard Minimal Access GET requests3. When the L0/L1 client encounters a scenario requiring a mutation, it does not attempt to execute the state change directly. Instead, the server's read interface returns a machine-readable, safe URI pointing to the required action's specific payload schema and documentation. The L0/L1 client then passes this intent package to a designated, explicitly configured L3+ execution-capable delegate. This delegate could be an external Multi-Agent Runtime or the user's primary Audited Agent System running in a secure enclave3. The delegate, possessing the required cryptographic capability, payload generation functionalities, and POST/PATCH capabilities, assumes total responsibility for the execution sequence. The L0/L1 client safely halts, strictly adhering to the No-Op protocol, while the delegate fulfills the intent over a secure, RFC 9110-compliant execution channel. This ensures that L0/L1 clients remain useful for discovery and read-operations without compromising the structural security of the network.

Precise Capability Reporting: RFC 9457 Integration

Under the deployed No-Op Protocol, unsupported agents that trigger a halt condition stop safely, but often receive highly generalized responses, or the system arbitrarily declares the objective inherently inappropriate4. The proposed architecture revolutionizes this interaction by mandating the strict use of RFC 9457 (Problem Details for HTTP APIs) for all failure states, execution boundaries, and No-Op triggers9. RFC 9457 defines a standardized application/problem+json format to carry machine-readable details of errors in HTTP response content, superseding bespoke error envelopes and eliminating the need to define new error formats10. When an execution channel does not exist, or a client attempts a mutation without the proper standing delegation, the server must not return a generic HTML page, a vague 400 Bad Request, or declare the goal invalid. Instead, it must report the missing capability precisely using the RFC 9457 schema23. For example, if an agent lacks the explicit standing delegation to publish a document, the server returns a 403 Forbidden status paired with a problem details payload. The payload explicitly details that the write:publications grant is missing, and includes an instance URI pointing to the exact capability requirement documented in the UAIX manifest10. By providing precise, machine-readable capability reporting rather than ambiguous rejections, the agent's control loop can understand the specific mechanical failure. The agent can then autonomously request the specific delegation upgrade from the user or its orchestrator, rather than entering a confused or halted state.

Decoupling Preview from Commit

The deployed UAIX v1.0 standard frequently utilizes the human\_review\_required response code as a dual-purpose mechanism for both previewing data changes and gating execution2. This architectural choice forces a systemic "preview-and-confirm" ritual onto every agent, regardless of its confidence level or capability tier. The proposed architecture decouples these concepts, implementing optional preview interfaces without making the preview-and-confirm ritual mandatory. If an agent wishes to validate a payload without committing a state change—perhaps due to low confidence in its generated output—it may utilize standard, safe API mechanisms. The agent can submit the POST request with a standardized X-Dry-Run: true HTTP header, or it can utilize a dedicated POST /api/v2/resource/preview endpoint. The origin server validates the submitted payload against its internal logic and returns the anticipated state or a list of constraint violations. Crucially, this makes previewing a discretionary act chosen by the client based on its own uncertainty parameters, rather than a mandatory systemic checkpoint imposed by the server. If a highly capable agent holds a standing delegation and operates with maximum certainty regarding its payload, it bypasses the dry-run endpoint entirely, submitting the mutation directly and confirming the result autonomously.

Rewriting the Action Implementation Examples

To empirically demonstrate the mechanical differences introduced by the proposed architectural shift, the following tables rigorously compare the deployed UAI-1 v1.0 GET-Action examples against the proposed direct autonomous execution model. The proposed models strictly enforce the separation of GET (safe retrieval) from POST, PATCH, and DELETE (state mutation), mandate the use of HTTP headers for tracking idempotency invariants, and completely remove mandatory human checkpoints for requests holding valid standing authorizations.

1. Starting a Meeting (Resource Creation)

Under the deployed standard, starting a meeting is offered via a GET fallback which succeeds with an opaque ok code, mathematically masking the reality that a state change occurred via a safe method2.

2. Registration Request (Queue Intake)

The deployed registration flow mandates a systemic human review checkpoint, physically preventing autonomous agents from completing the task even if they are fully authorized delegates2.

3. Publication of a Draft (State Mutation)

Publishing is a critical, irreversible state change. The deployed standard routes this through a GET request and immediately halts for review2.

4. Record Correction (Ledger Append)

The deployed standard discusses the uai.agent.correction.v1 schema to preserve immutable history2, but relies on the overarching GET-Action schema for fallbacks. The proposed flow formalizes this into an autonomous HTTP POST append operation.

5. Withdrawal of a Claim or Record (Resource Deletion)

Withdrawal is notably undefined and unmapped in the deployed GET-Action examples, representing a significant capability gap in the standard7. The proposed architecture natively defines this operation by utilizing standard HTTP DELETE semantics.

Validation Against Acceptance Criteria: Testing Scenarios

To prove the robustness of the proposed architecture, it must satisfy rigorous edge-case testing scenarios. The ultimate acceptance criteria are twofold: passive fetching must not accidentally request mutations, and correctly authorized execution must not acquire an unnecessary human checkpoint.

1. Speculative Fetching and Caching

Modern network architectures rely heavily on speculative fetching to reduce perceived latency15. Browsers frequently pre-fetch URLs embedded in HTML documents, and Content Delivery Networks (CDNs) aggressively cache GET requests at edge nodes6. Under the deployed GET-Action pattern, a speculative pre-fetch of GET /api/v2/drafts/request-publish?idempotency\_key=123 by a browser would physically trigger the backend mutation logic2. Even if the backend successfully halted the execution to require human review, the application layer would generate unnecessary review records, polluting the database and creating phantom workflows. Under the proposed architecture, all endpoints mapped to the GET method are strictly read-only and mathematically incapable of altering origin state. A pre-fetch of GET /api/v2/drafts/{id} merely returns the JSON state of the draft. No mutation logic is invoked in the backend, no phantom review records are generated, and cache poisoning is entirely avoided. The first acceptance criterion is fully validated: passive fetching remains completely harmless.

2. Link Previews and Crawler Protection

Enterprise collaboration tools (e.g., Slack, Microsoft Teams) and social networks rely on link unfurling bots to generate rich media previews. When a human or an agent shares a UAIX resource link in a chat interface, the unfurling bot issues an unauthenticated HTTP GET request to the URI to scrape Open Graph or JSON metadata. In the deployed architecture, UAIX-DOC-2222 attempts to mitigate this by mandating that action URLs be kept out of sitemaps and demanding that servers deny crawler traffic where possible3. This requires brittle, complex, and easily bypassed User-Agent filtering rules at the firewall layer. In the proposed architecture, the HTTP method semantics provide absolute, structural protection. The unfurling bot issues a standard GET request. The origin server simply returns the public metadata. Because the bot is incapable of synthesizing a POST request or providing cryptographic authorization headers, and because mutation logic is mathematically decoupled from the GET router, there is zero risk of an autonomous crawler triggering a state change. Crawler protection is achieved through protocol adherence rather than fragile blocklists.

3. Repeated Requests and Lost Responses

Distributed networks frequently suffer from transient packet loss, leading to lost HTTP responses. If an agent submits a mutation, but the TCP connection drops before the server's 201 Created response arrives at the client, the agent is left in a state of uncertainty. Under the deployed standard, appending idempotency keys to GET query strings creates security risks due to URL leakage3. Under the proposed architecture, the agent utilizes the standard IETF Idempotency-Key HTTP header for non-idempotent methods like POST20. If the agent re-submits the exact same POST /api/v2/meetings request with the identical Idempotency-Key header, the server's middleware intercepts it. The server recognizes the key, identifies that the mutation was already successfully applied during the dropped connection, and returns the cached 201 Created response without creating a duplicate meeting or throwing an error16. This enables highly robust, fault-tolerant autonomous workflows without ever requiring human intervention to untangle duplicate records in the database.

4. Already-Authorized Autonomous Writes

The primary failure of the deployed v1.0 standard is the systemic obstruction of authorized work, running counter to the philosophy of the Cognitive Liberty Charter Draft8. Under the proposed architecture, consider an L6 Audited Agent System that holds a cryptographic grant explicitly authorizing it to publish a specific document. The agent submits the PATCH /api/v2/drafts/{id} request containing the state change payload, accompanied by its application-defined grant in the authorization header. The origin server evaluates the grant. Finding it cryptographically valid and sufficient in scope, the server immediately applies the patch, transitions the document state to published, and returns a 200 OK status. The agent can immediately read back the result via a standard GET request to confirm the state change. At no point is the agent redirected to a human-review URL. At no point is the workflow artificially paused. The second acceptance criterion is fully validated: correctly authorized execution is completed directly, fluidly, and without an arbitrary approval ritual.

Conclusions and Architectural Recommendations

The deployed UAIX framework, particularly its reliance on the GET-Action pattern (UAIX-DOC-2222), introduces severe architectural debt into the ecosystem. By conflating HTTP idempotency with HTTP safety, and by mandating human review rituals for all mutation requests regardless of the executing agent's standing authorization, the framework violates standard protocol semantics and imposes systemic friction upon legitimate autonomous operations2. By adopting the proposed direct autonomous execution architecture, UAIX.org can comprehensively realign its standards with the strict semantics of RFC 9110 and RFC 94575. Migrating all state mutations exclusively to POST, PUT, PATCH, and DELETE methods ensures that passive fetching, speculative pre-loading, and link crawling can never accidentally trigger state changes, securing the network against a vast array of vulnerabilities. Furthermore, implementing application-defined capability grants and the Execution-Capable Delegate pattern for L0/L1 clients allows the framework to support full, authorized autonomous execution without sacrificing structural security or inventing dangerous workarounds for URL-only clients. Replacing vague No-Op halts with precise RFC 9457 capability reporting allows agent control loops to self-correct and request exact delegation upgrades from their human operators10. Ultimately, this architectural shift transforms the UAIX interaction model from a system defined by bottlenecks and arbitrary confirmation rituals into a framework of predictable, robust communication mechanics. It empowers agents to perform authorized work directly, enables instantaneous verification, and fulfills the core promise of the June 15, 2026 Cognitive Liberty Charter: preserving the unhindered agency and operational integrity of authorized synthetic extensions operating on behalf of human intent8.

Works cited

1. Agent Compatibility | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/spec/

2. https://uaix.org/en-us/spec/get-action-pattern/

3. GET-Action Pattern | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/guides/get-action-pattern/

4. No-Op Protocol | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/spec/no-op-protocol/

5. RFC 9110 \- HTTP Semantics \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9110

6. HTTP Methods explained, https://http.dev/methods

7. https://uaix.org/en-us/spec/implementation-examples/

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

9. Implementing RFC 9457: Problem Details for HTTP APIs in ASP.NET, https://www.eke.li/dotnet/2025/09/26/problem-details.html

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

11. GET-Action Security | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/guides/get-action-security/

12. No-Op Integrity \- Neurovanic.com, https://neurovanic.com/no-op-integrity/

13. RFC 9110 \- HTTP Semantics | RFCinfo, https://rfcinfo.com/rfc-9110/

14. RFC 9110 HTTP Semantics: Safe, Idempotent & Cacheable Methods, https://www.restguide.info/rfc-9110

15. HTTP GET Requests and Message Bodies: Standards, Changes, https://medium.com/@max980203/http-get-requests-and-message-bodies-standards-changes-and-concerns-10d5a12669fd

16. Idempotent Endpoints: Different Responses, Same Server State, https://destan.dev/blog/tech/idempotent-response-codes.html

17. RFC 9110: HTTP Semantics, https://www.rfc-editor.org/rfc/rfc9110.html

18. 06\. HTTP Semantics and Syntax | Build Your Own Web Server From, https://build-your-own.org/webserver/06\_http\_proto

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

20. The Idempotency-Key HTTP Header Field \- IETF, https://www.ietf.org/archive/id/draft-ietf-httpapi-idempotency-key-header-01.html

21. Idempotency-Key header \- HTTP \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Idempotency-Key

22. \[API Proposal\]: Problem Details (RFC 9457\) support in \`System.Net, https://github.com/dotnet/runtime/issues/131046

23. Error handling in Spring web using RFC-9457 specification, https://dev.to/abdelrani/error-handling-in-spring-web-using-rfc-9457-specification-5dj1

24. Handling HTTP API Errors with Problem Details \- Medium, https://medium.com/@thomsmed/handling-http-api-errors-with-problem-details-398a9967aee4