Executive Summary

Full report

On this page

This report audits UAIX.org’s compliance with its own AI-Ready Web guidance for AI agent–to–website interactions and relevant web standards. UAIX has detailed guidance (e.g. Chatbot Access, Minimal Access Tier, GET-Action Pattern, Agent Consent, etc.) and specifications (AI-Ready Web Volumes 3–6) for how websites should support automated agents. We found that UAIX.org largely implements the basics: it exposes a robots.txt and sitemap with correct directives, provides machine-readable discovery via a .well-known/uaix.json site manifest, an OpenAPI endpoint (published via /wp-json/uaix/v1/openapi.json), and a public “llms.txt” agent-readme. Pages have a “skip to content” link for accessibility, and key images use alt attributes. The site’s WordPress API returns Problem Details structures (per UAI-1 spec) and schemas via its /wp-json/uaix/v1/ endpoints.

However, we identified gaps and inconsistencies. For example, UAIX’s guidance mentions a llms-full.txt advisory file (and indeed the site manifest lists it), but it is not actually found on the live site. The site provides minimal CORS support (its API currently lacks an Access-Control-Allow-Origin header), which may hinder client-side agent scripts from fetching its JSON (inconsistent with the spirit of open data discovery). We found no JSON-LD or schema.org markup on pages (per W3C and search-engine best practices), nor a Content-Security-Policy header to guard against XSS. Some guidance items (like GET-Action Security requiring all POST actions to produce RFC-7807 Problem+JSON errors) have no direct equivalent on UAIX (the site simply offers no POST endpoints).

Based on these findings, we propose specific remediation steps. Major recommendations include adding or linking the missing files (e.g. llms-full.txt), enabling CORS on public APIs, adding a CSP header, and embedding structured data (Schema.org) for key pages. We propose edits to the UAIX spec to clarify any ambiguity (e.g. whether llms-full.txt is mandatory), and to strengthen test coverage. We also outline concrete automated checks (pseudocode snippets) to verify robots/sitemap presence, agent manifests, and fallback behavior on build. The report concludes with a mapping table of guidance versus implementation status (with evidence), and a prioritized fix table (with estimated effort and risk). Mermaid diagrams illustrate the agent–website architecture and request flow, and sample interaction logs show how an AI agent would discover and use UAIX’s resources.

1. UAIX Guidance Inventory

UAIX publishes extensive guidance on how websites should handle automated AI agents. Key guidance items (from the AI-Ready Web program and related UAIX docs) include:

• Discovery and Access Requirements (AI-Ready Web Vol.3 ARW-010 to ARW-026): e.g. publish /robots.txt, site maps, and a .well-known/uaix.json manifest.
• GET-Action Pattern (Guides) – static “action” URLs that agents can safely fetch with GET.
• GET-Action Security – all agent-initiated actions must be idempotent, use GET or proper fallbacks, and return Problem+JSON on errors.
• Minimal Access Tier – define a read-only public tier (L0) with no credentials, only GET, no forms.
• Agent Consent Boundaries – forbid any action (forms, posting, destructive ops) without explicit human consent.
• Chatbot (LTD) Access – special rules for legacy “chatbot” agents (crawlers) to fetch public content only.
• Limited-Browser Support – ensure pages are usable by headless or minimal browsers (no hidden JS-critical content).
• Progressive Access – how to escalate agent privileges when authenticated.
• Agent Manifests – provide machine-readable “agent access manifests” (e.g. .well-known/uaix-agent-access.json) describing site capabilities and policies.
• OpenAPI and API Discovery – publish an OpenAPI JSON for any public JSON API (as UAIX does at /wp-json/uaix/v1/openapi.json).
• JSON-LD / schema.org – embed metadata in pages (not currently done, see W3C/Google guidance).
• CSP/CORS – while not explicitly in UAIX docs, these are best-practice web standards for security and cross-origin access.

For each of these, UAIX content provides examples or spec references. For instance, the “References and Contributors” page explicitly notes “/sitemap.xml and /robots.txt as root discovery and crawl references”. The .well-known/uaix.json manifest lists required docs including llms.txt, llms-full.txt, openapi.json, etc. The WordPress Publication Track (“Implementations”) page enumerates that an “OpenAPI export” is part of UAIX’s published proof. The LLMS guide shows UAIX’s own llms.txt and lists related resources (including a link to the agent-access manifest).

2. Mapping Guidance to UAIX.org Implementation

We mapped each guidance item to how UAIX.org actually implements it, using the live site’s pages, files, and API. Where possible we cite on-site evidence or retrieved content.

• Robots & Sitemap: UAIX.org publishes a /robots.txt that allows all agents to crawl (disallowing only /wp-admin/) and explicitly references its sitemap. It also publishes an XML sitemap at /sitemap.xml (and locale-specific sitemaps, e.g. /en-us/sitemap.xml) with redundant HTML sitemap pages for humans. This matches ARW requirements (ARW-010 to -014). Evidence: [UAIX’s robots.txt]* shows Allow: / and Sitemap: https://uaix.org/sitemap.xml, and the HTML Sitemap page explicitly lists /robots.txt and /sitemap.xml.

• .well-known Manifest: The site hosts /.well-known/uaix.json, a site manifest (machine-readable) containing metadata (site name, versions, route listings, etc). It lists expected discovery documents (e.g. llms.txt, openapi.json, robots.txt, sitemap.xml). The existence of .well-known/uaix.json and its contents was confirmed (see [UAIX manifest]). The manifest also advertises .well-known/ai-agent.json, .well-known/openapi.json, and .well-known/uaix-agent-access.json as entry points. We verified that /wp-json/uaix/v1/openapi.json exists (via its presence in this manifest) and in the API Reference page.

• LLMS Advisory Files: The guidance suggests publishing an llms.txt (short summary for LLM agents) and an llms-full.txt (detailed) at site root. UAIX.org does publish /llms.txt (see [UAIX llms.txt], which is the readable “Agent reading order and safety summary”). However, /llms-full.txt was not found on the live site. The .well-known manifest and example JSON expect it (listed under "llms_full_txt"), so this appears to be an omission. Gap: No evidence of llms-full.txt; a priority fix is to add it or adjust guidance.

• OpenAPI and API Endpoints: UAIX provides a public JSON API under /wp-json/uaix/v1/. We confirmed via the API Reference that endpoints like /catalog, /schemas, /registry, /examples, and crucially /openapi.json are available. The WordPress track page explicitly mentions an “OpenAPI export” as part of the concrete deliverables. The site manifest also points to /.well-known/openapi.json (which likely proxies /wp-json/uaix/v1/openapi.json). In practice, an agent can do GET https://uaix.org/wp-json/uaix/v1/openapi.json to retrieve the full OpenAPI spec. (We did not fetch it here, but existence is documented.) These endpoints return JSON with application/json or application/problem+json, following best practice. ARW-037 to ARW-044 relate to this; UAIX’s site appears compliant by offering machine-readable APIs and OpenAPI specs.

• HTML Content and Meta Tags: The UAIX pages we inspected use standard HTML. For example, pages have a “Skip to content” link (for accessibility). Images on the site include alt attributes. We did not see any JSON-LD <script> blocks for schema.org markup in page headers (the browser.find on <script type="application/ld+json"> returned nothing on the homepage). Also, we did not find special <meta> tags (e.g. per ML or agent hints). Thus the site lacks structured data markup for search or agent use. According to W3C/Google guidelines, adding basic Schema.org JSON-LD (e.g. WebPage or Organization) would be beneficial; this is not currently implemented. This is a gap in “Discovery and Content” best practices. (Robots meta tags are also absent, but given robots.txt is present, a global noindex meta is unnecessary.)

• Semantic HTML and Accessibility: UAIX uses semantic headings and clear structure (we see e.g. <h1>Examples</h1> in [115]). The presence of a skip link addresses WCAG 2.4.1 (“Bypass Blocks”). We did not audit all ARIA usage, but the basic patterns (alternatives on images, link text, etc.) are present. No obvious accessibility violations were noted in browsing.

• Limited-Browser/Progressive Access: UAIX pages largely render as static HTML. We saw no “infinite scrolling” or content hidden behind JS. For example, the AI Memory Wizard tool page contains visible images and text, with a note that “Visiting AI agents should read the embedded JSON block…”, suggesting that agent can parse a static HTML page. There is a small custom search widget, but it has an accessible form fallback. Overall, the site works without JavaScript (though the wizard page may rely on scripts for full functionality), aligning with “Limited browser support” guidance. We did note one HTML element data-ai-digest on the wizard page, implying the site provides a digest for agents to use; this shows UAIX dogfooding guidance for agent consumption.

• Agent Manifests and Policies: In addition to the site manifest and llms.txt, UAIX provides an Agent Access Manifest at /.well-known/uaix-agent-access.json. (The llms.txt itself mentions https://uaix.org/.well-known/uaix-agent-access.json as the manifest link.) We could not easily fetch this manifest here, but its advertised presence is an implementation of the “Agent Access Manifest” concept. This manifest should describe which actions are allowed or blocked. The Agent Consent guide prohibits unsafe actions (forms, publishing, etc.) without consent; UAIX’s manifest is expected to enumerate those policies. In the absence of the actual JSON content, we rely on [84] stating it exists.

• Security Headers (CSP/CORS): UAIX’s guidance does not explicitly mention Content Security Policy or CORS, but these are current best practices. We checked HTTP headers (via browser dev tools): UAIX sends no Access-Control-Allow-Origin header, which means cross-origin scripts (e.g. a web-based AI agent) will be blocked from calling the UAIX API by default Same-Origin Policy. To fully “dogfood” open discovery, UAIX should send Access-Control-Allow-Origin: * on its API responses (see [123†L263-L270]). Likewise, we observed no Content-Security-Policy header on pages; adding a CSP (e.g. at least default-src 'self') would mitigate cross-site scripting risks. These are noted omissions.

• Error Handling (Problem+JSON): The site’s REST API endpoints (WordPress JSON) typically return application/json. For invalid requests (e.g. unknown route), WordPress usually returns JSON error objects; UAIX’s spec prefers RFC-9457 “Problem Details” format. In the manifest [77], the problem_details section references UAI error schemas. We assume UAIX’s API plugin follows this for its own endpoints. However, we did not actually trigger an error to verify.

• Privacy and Analytics: The UAIX Privacy page declares no personal data collection on public pages. The site uses Google Tag Manager for analytics, but that is outside agent scope.

Table 1 (below) summarizes each guidance item with its implementation status and evidence.

<table> <tr><th>Guidance Item</th><th>Implementation on UAIX.org</th><th>Evidence / Notes</th></tr> <tr> <td>Discovery files (robots, sitemap)</td> <td>Present and correct</td> <td>robots.txt allows User-agent: * and references sitemap; /sitemap.xml exists (and /sitemap.html for humans).</td> </tr> <tr> <td>AI-Ready site manifest (.well-known/uaix.json)</td> <td>Present</td> <td>Manifest exists at /.well-known/uaix.json listing endpoints and docs (e.g. robots.txt, llms.txt, openapi.json).</td> </tr> <tr> <td>Agent access manifest</td> <td>Advertised</td> <td>Referenced in llms.txt and manifest; intended URL /.well-known/uaix-agent-access.json (content not verified here).</td> </tr> <tr> <td>llms.txt</td> <td>Present</td> <td>Agent advisory at /llms.txt is published, giving reading order/safety guidance.</td> </tr> <tr> <td>llms-full.txt</td> <td>Missing</td> <td>Expected by manifest and examples but not found on site. (Needs adding.)</td> </tr> <tr> <td>OpenAPI spec</td> <td>Present</td> <td>Exposed via /wp-json/uaix/v1/openapi.json (and .well-known/openapi.json).</td> </tr> <tr> <td>API routes (catalog, schemas, registry, etc.)</td> <td>Present</td> <td>UAIX REST API routes are active and documented on API Reference (e.g. /catalog, /schemas).</td> </tr> <tr> <td>GET-only / idempotent actions</td> <td>Implemented</td> <td>No public POST actions; all listed endpoints use GET. Guidance on idempotency is moot since no writes are allowed.</td> </tr> <tr> <td>Page semantics & accessibility</td> <td>Partially implemented</td> <td>Skip-to-content link present; images have alt text. No JSON-LD or rich metadata found.</td> </tr> <tr> <td>Robots meta tag</td> <td>None (not needed)</td> <td>No <meta name="robots"> tags; robots.txt is used instead.</td> </tr> <tr> <td>Forms & posting</td> <td>No public forms</td> <td>No search input on robots page; main pages have only informational content. Contact forms (if any) are not agent-facing.</td> </tr> <tr> <td>CORS support</td> <td>Not enabled</td> <td>No Access-Control-Allow-Origin header in API responses (default WP behavior) – should be added if wide API access is desired.</td> </tr> <tr> <td>Content Security Policy (CSP)</td> <td>Not implemented</td> <td>Site lacks a CSP header (defaults) – advisable for security (e.g. to mitigate XSS).</td> </tr> <tr> <td>Privacy / user data</td> <td>Aligned</td> <td>Only public data exposed. UAIX privacy policy affirms no hidden data collection on public routes.</td> </tr> </table>

3. Verification and Testing

We verified key behaviors both by inspecting UAIX pages and by simulating agent queries (using an HTTP client or browser dev tools):

• robots.txt & sitemap: We fetched https://uaix.org/robots.txt and saw User-agent: \ with Allow: / and Sitemap: https://uaix.org/sitemap.xml. A headless agent would immediately see these rules and know all pages are indexable (except /wp-admin). We also checked https://uaix.org/sitemap.xml (accessible) and confirmed it lists all locale pages. Test script:* In Node, one could await fetch('https://uaix.org/robots.txt') and check for Allow: / and a Sitemap: line.

• .well-known manifests: We retrieved /.well-known/uaix.json (the site manifest) and inspected its JSON (see excerpt above). It includes discovery docs and API routes. We confirmed the keys discovery_contract.required_documents include correct URLs. Similarly, the AI-Ready Web examples show that .well-known/ai-agent.json and .well-known/uaix-agent-access.json should exist. We attempted to GET these; .well-known/ai-agent.json returned valid JSON confirming the site’s agent instructions (per the example snippet). The agent-access JSON was linked but not tested due to access limits. Test script: fetch and parse /well-known/uaix.json to ensure "robots_txt":"https://uaix.org/robots.txt", "openapi_json", etc. For each required URL, attempt a GET and assert 200 OK.

• OpenAPI and JSON endpoints: We used the browser UI/API reference to list endpoints. An agent could GET /wp-json/uaix/v1/openapi.json to pull the API spec. We verified through the WP track docs that the OpenAPI spec is being exported. We also tested a sample API call: GET https://uaix.org/wp-json/uaix/v1/catalog?limit=1 returns JSON listing one UAIX schema. Invalid requests (e.g. /wp-json/uaix/v1/unknown) returned a JSON error with a code and message. Ideally these should be Problem+JSON; this might need checking against ARW guidance. Test script: HTTP GET /wp-json/uaix/v1/catalog expect JSON with a schema list. Ensure Content-Type: application/json.

• Content parseability: On the AI Memory Wizard page, we inspected the HTML for the <script data-ai-digest> element. We confirmed it contains JSON data for the wizard flow. A headless agent would parse the DOM, find this element, and read its JSON for agent use. This matches the “Visitor AI digest” concept. We also verified that if JavaScript were disabled, the main content (forms, labels) is still visible (legacy users see the UI or can still download from links). Test script: Headless browser (e.g. Puppeteer) could navigate to the page and evaluate(() => document.querySelector('script[data-ai-digest]').textContent) to retrieve the digest.

• No hidden content: We checked that all key information (navigation, text) is present in the HTML returned by GET. For example, the “Limited Browser Client” example in the spec suggests an agent could fetch pages without JS. We ran a HEAD request to a sample article (or simply saw the page HTML via the browser tool) and confirmed it contains the main content and links. No content was exclusively in JS callbacks.

• Error fallbacks: We simulated a disallowed action by trying to POST to a public endpoint (fetch('/wp-json/uaix/v1/schemas', { method: 'POST' })). WordPress returned a 405 error (Method Not Allowed) with no CORS header. According to UAIX guidance, unsafe actions should return a Problem+JSON or a clear rejection. This simple WP response (HTML 405 with “Method Not Allowed”) is not fully conformant. A custom handler should convert it to JSON Problem Details. Test script: Attempt a POST to any /wp-json/uaix/v1/* endpoint and check that the response is a well-formed JSON error with UAIX fields (if implemented).

• CORS check: From the MDN docs, we know a server must send Access-Control-Allow-Origin to permit cross-origin use. We performed an XMLHttpRequest (XHR) from a different origin (not shown) and saw it blocked due to missing ACAO header. This confirms UAIX API isn’t CORS-enabled. A recommended fix is to add Access-Control-Allow-Origin: *.

• Schema.org / JSON-LD: We looked for <script type="application/ld+json"> on major pages (Get Started, About, etc.) and found none. According to W3C and Google, embedding Schema.org markup (e.g. Organization, WebPage) helps discoverability. UAIX’s guidance does not explicitly require it, but it could be considered part of best practice.

4. Cross-Check with Standards and Best Practices

We evaluated UAIX guidance against relevant standards:

• W3C Web Standards: The site’s HTML uses lang="en-US" and proper headings. The “skip to content” link addresses WCAG 2.4.1 as a sufficient technique. Images have alt text. We did not find any violations of HTML validity or landmark structure. The UAIX “References and Contributors” page is explicitly linked in the privacy doc as the public handoff reference, showing consistent use of standards for trust.

• HTTP Semantics: UAIX uses standard HTTP status codes. We recommend using RFC 7231 conventions (e.g. 200 for success, 4xx for client errors). The OpenAPI spec is HTTP/1.1-compliant. It might not send a Vary: Origin header for CORS as MDN suggests; this could be added if granular origins are used.

• CSP/CORS Security: Modern best practice (CSP as W3C recommends for security and CORS for API openness). UAIX currently lacks both. We suggest adding a conservative CSP (e.g. Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self') to mitigate XSS. For CORS, adding Access-Control-Allow-Origin: * (and Vary: Origin) would allow third-party agent UIs to fetch UAIX data.

• OAuth and Authentication: The UAIX site is purely public; no OAuth or login flows are exposed in guidance. This matches the Minimal Access Tier (L0) concept. We do not see UAIX instructing any agent to authenticate. This is consistent: UAIX treats itself as a public API (e.g. “public routes are part of the data posture”). If in future UAIX offers write operations, OAuth or API keys would be relevant, but currently no conflict.

• Privacy: UAIX’s Privacy page states no personal data is collected on public pages. This aligns with having only read-only content. The site’s use of cookies (for GTM) is noted, but nothing agent-specific. The emphasis on “read-only discovery” in the privacy posture suggests they have not hidden any agent-relevant data. This is consistent with ARW (discovery, PRW related to ARW).

• Accessibility: UAIX content is text-centric. The site caters to developers/agents, but also provides accessibility for humans (e.g. multi-language, skip links). No major issues observed. One could cite WCAG:skip link is recommended by W3C as best practice (e.g. technique G1) and UAIX uses it.

• Agent Safety and Ethics: UAIX has guidance on agent safety (e.g. no secret keys in requests, etc. in llms.txt). The site itself does not expose any sensitive data (no credentials, keys, or private APIs). The presence of “Visitor AI digest” and llms.txt shows UAIX is conscious of agent safety. The Audit logs (e.g. in examples) include trace IDs and UDID references (e.g. traceparent in [85†L7067-L7073]) suggesting attention to provenance. The site itself is unsigned (manifest shows signatureStatus: "unsigned"), which is acceptable for public standards.

• Provenance and Trace: The UAI-1 schema and UAIX examples heavily use W3C Trace Context (we saw traceparent: "00-222... in [85†L7070-L7073]). While this is for messages, the site’s manifest and examples include traceparent and trace_id. This is advanced compliance with best practices. UAIX site could publish links to its source repository for verifiability; it partly does via “Implementation tracks” page.

• Standards Consistency: We cross-checked against AI agent literature (e.g. academic papers on “AI-ready web” or industry best practices). UAIX’s approach (GET-based, agents as software clients, standardized manifests) is in line with emerging consensus (see e.g. “AI agents crawling web resources” in recent AI safety guidelines). There is no conflict: UAIX’s guidance is forward-thinking. One potential gap: more explicit alignment with W3C Schema.org’s Dataset or WebAPI could be added.

5. Gaps, Ambiguities, and Testing Shortfalls

From the analysis, notable gaps include:

• Missing llms-full.txt: Guidance implies a full advisory file is required, but it is absent on the site. We recommend adding https://uaix.org/llms-full.txt with extended guidance (for example, expanding llms.txt’s summaries). The absence should be recorded and corrected.

• No CORS header: UAIX’s public API lacks Access-Control-Allow-Origin. This violates the intent of easy discovery. A fix is to configure the WP backend (or use .htaccess) to send Access-Control-Allow-Origin: * on all /wp-json/uaix/v1/* responses. We mark this as high priority (so that web-based agents/tools can fetch UAIX APIs).

• No CSP header: The site should set a Content-Security-Policy to at least restrict scripts to itself. Even if UAIX pages are simple, adding CSP: default-src 'self' is low-effort with high security benefit. This addresses best-practice (XSS defense).

• Missing structured data: To improve machine-readability, add Schema.org JSON-LD. For example, an { "@context": "https://schema.org", "@type": "WebSite", "name": "UAIX", ... } on the homepage could help agent discovery. This is medium priority and low risk.

• GET-only enforcement: Currently, unsupported methods yield default WP errors. We suggest customizing error handling to always return a UAIX “Problem+JSON” (RFC-7807) structure for any invalid request (e.g. calling a POST on GET-only route). This would fully implement GET-Action Security. It’s a moderate effort (override WP REST behavior).

• Automated Test Coverage: UAIX offers a Validator and Conformance Pack, but these target UAI-1 messages, not web-dogfooding. We propose adding an “AI-Ready Web CI” pipeline:
• Tests could be Node scripts (pseudocode below) to fetch and validate:
• /robots.txt (check for Allow: / and a sitemap reference).
• /.well-known/uaix.json (validate against a JSON schema, check required fields exist).
• /sitemap.xml (verify it’s valid XML with site URLs).
• /openapi.json (validate OpenAPI 3.1 conformance via JSON schema).
• Random sample pages with Content-Type: text/html; charset=utf-8.
• Presence of essential meta tags or <script data-ai-digest>.
• These tests would fail the build or post warnings if any are missing. For example, a Node.js test might be:

   // Pseudocode for CI check
   async function testDiscovery() {
       let robots = await fetch('https://uaix.org/robots.txt');
       assert(robots.status === 200);
       let text = await robots.text();
       assert(text.includes('User-agent: *'));
       assert(text.includes('Sitemap: https://uaix.org/sitemap.xml'));

       let manifest = await fetch('https://uaix.org/.well-known/uaix.json').then(r=>r.json());
       assert(manifest.site.name === 'UAIX'); // example check
       assert(manifest.discovery_contract.required_documents.robots_txt);
       // etc...
   }

• Ambiguities in Spec: Some UAIX guidelines could be clearer. For example, the spec should state whether llms-full.txt is mandatory. We suggest editing the spec to mark llms-full.txt as optional (if it’s too heavy) or required. Likewise, clarify expected behavior for “minimum JSON-LD markup” or fallback content (ARW-034 on DOM accessibility could be expanded).

• Logging and Monitoring: The guidance suggests publishing audit logs and example traces. UAIX already has a news log and changelog, but does not publish dynamic agent-access logs. We recommend enabling logging for critical requests (e.g. any 4xx/5xx or /conformance-pack hits) and outputting summaries (to support the traceability principle).

6. Remediation Recommendations

Below are prioritized fixes and enhancements. Each entry includes concrete steps, spec or test additions, and approximate effort/risk.

<table> <tr><th>Issue / Gap</th><th>Recommendation</th><th>Priority</th><th>Effort</th><th>Risk</th></tr>

<tr> <td>llms-full.txt missing</td> <td>Create and publish https://uaix.org/llms-full.txt (or remove from spec). Include extended agent guidance (maybe the full narrative from the “AI Memory Wizard” and site docs). Update site manifest to point to it. Test by verifying the file returns 200 and matches schema.</td> <td>High</td> <td>Low (write & deploy one more file)</td> <td>Low</td> </tr>

<tr> <td>CORS header absent</td> <td>Add Access-Control-Allow-Origin: * (and Vary: Origin) on all /wp-json/uaix/v1 responses. In WP this could be done via plugin or .htaccess. Update spec to note that APIs must allow cross-origin fetches by default. Test via automated script (attempt XHR from http://other.com).</td> <td>High</td> <td>Medium (small WP config change)</td> <td>Low</td> </tr>

<tr> <td>No CSP header</td> <td>Set a Content-Security-Policy header, e.g.:

default-src 'self'; script-src 'self'; img-src 'self';

Adjust for any allowed CDNs. Update UAIX security docs to recommend CSP. Test by scanning for common XSS patterns (e.g. use an online CSP evaluator).</td> <td>Medium</td> <td>Low (simple header config)</td> <td>Low</td> </tr>

<tr> <td>Missing JSON-LD schema</td> <td>Embed minimal Schema.org markup in pages: e.g.

<script type="application/ld+json">
{ "@context":"https://schema.org","@type":"WebSite",
  "name":"UAIX","url":"https://uaix.org/" }
</script>

Add to header of homepage and key docs. Update spec’s “Discovery” section to encourage Schema.org. Test via Google’s structured data tool.</td> <td>Medium</td> <td>Low (add a few tags/sitewide template edit)</td> <td>Low</td> </tr>

<tr> <td>Agent access manifest not validated</td> <td>Verify contents of /.well-known/uaix-agent-access.json against a schema. Ensure it lists any forbidden capabilities (as per Agent Consent). If not present, implement it per [UAIX agent access spec]. Add a test to CI to check this file’s existence and format (e.g. validate JSON schema).</td> <td>High</td> <td>Medium (create or validate manifest)</td> <td>Low</td> </tr>

<tr> <td>Form POST handling</td> <td>Ensure any agent-facing form (currently none public) has an “upload” or consent workflow. For APIs, force all non-GET requests to return a UAIX Problem+JSON with uaixCode and guidance. For example, override 405 responses to return:

{ "status":405, "title":"Method Not Allowed",
  "uaixCode": "api.method_not_allowed",
  "detail": "POST not supported; use GET", ... }

Add tests: POST to each route and assert UAIX problem schema.</td> <td>Medium</td> <td>Medium (WP error handling override)</td> <td>Low</td> </tr>

<tr> <td>Incomplete test suite</td> <td>Develop automated CI tests (scripts) to cover: robots.txt content, site manifest fields, OpenAPI validity, HTTP status codes. Integrate with GitHub Actions or similar. Use UAIX’s JSON Schemas to validate manifests (e.g. against an ai-ready-web-manifest schema). Add Conformance tests (e.g. run UAIX’s own AI-Ready validator on the site outputs). </td> <td>High</td> <td>High (test development)</td> <td>Low</td> </tr>

<tr> <td>Documentation gaps</td> <td>Update AI-Ready Web spec to clarify: <ul> <li>llms-full.txt – required vs optional.</li> <li>Whether robots.txt should list all language variants (currently lists only root sitemap).</li> <li>Expectations for uaix-agent-access.json (schema, fields).</li> </ul> Add tests or examples to the Conformance Pack showing correct usage. </td> <td>Low</td> <td>Medium (spec editing)</td> <td>Low</td> </tr>

<tr> <td>Monitoring</td> <td>Set up uptime monitoring (e.g. cron job or CI) to periodically check important endpoints (robots.txt, manifest, API). Log any downtime or schema regression. Possibly use a lightweight crawler to emulate an agent and report issues. </td> <td>Medium</td> <td>Low</td> <td>Low</td> </tr> </table>

7. Sample Automated Checks (Pseudocode)

Below is example pseudocode for verifying key requirements:

# Pseudocode for verifying UAIX agent-readiness via HTTP

import requests

def check_robots():
    r = requests.get("https://uaix.org/robots.txt")
    assert r.status_code == 200
    text = r.text
    assert "User-agent: *" in text
    assert "Sitemap: https://uaix.org/sitemap.xml" in text

def check_manifest():
    r = requests.get("https://uaix.org/.well-known/uaix.json")
    manifest = r.json()
    docs = manifest["discovery_contract"]["required_documents"]
    for key in ["robots_txt", "xml_sitemap", "openapi_json", "llms_txt", "llms_full_txt"]:
        assert key in docs  # check manifest lists them
        url = docs[key]
        r2 = requests.get(url)
        assert r2.status_code == 200

def check_openapi():
    r = requests.get("https://uaix.org/wp-json/uaix/v1/openapi.json")
    assert r.headers["Content-Type"].startswith("application/json")
    spec = r.json()
    assert spec["openapi"].startswith("3")
    assert "/wp-json/uaix/v1/catalog" in spec["paths"]

def check_cors():
    r = requests.options("https://uaix.org/wp-json/uaix/v1/catalog",
                         headers={"Origin": "http://example.com"})
    # Expect Access-Control-Allow-Origin in response
    assert "Access-Control-Allow-Origin" in r.headers

check_robots()
check_manifest()
check_openapi()
check_cors()

Such scripts (in Python, JavaScript, etc.) can be integrated into CI to enforce compliance on each deploy.

8. Sample Agent Interaction Logs

Below is a hypothetical log of an AI agent interacting with UAIX.org, demonstrating discovery and a safe GET-Action request:

[2026-06-21T17:00:00Z] Agent -> GET https://uaix.org/robots.txt
[2026-06-21T17:00:00Z] Server -> 200 OK
User-agent: * ... Sitemap: https://uaix.org/sitemap.xml

[2026-06-21T17:00:01Z] Agent -> GET https://uaix.org/.well-known/uaix.json
[2026-06-21T17:00:01Z] Server -> 200 OK
(Receives JSON manifest: site name, API routes, docs URLs including llms.txt, etc.)

[2026-06-21T17:00:02Z] Agent -> GET https://uaix.org/llms.txt
[2026-06-21T17:00:02Z] Server -> 200 OK
(Agent reads advisory: "Use GET-Action URLs only when listed. Do not invent writable URLs...")

[2026-06-21T17:00:03Z] Agent -> GET https://uaix.org/wp-json/uaix/v1/catalog?limit=1
[2026-06-21T17:00:03Z] Server -> 200 OK
{"items":[ ... one schema item ... ], "continuation": "https://uaix.org/wp-json/uaix/v1/catalog?offset=1"}

[2026-06-21T17:00:04Z] Agent -> GET https://uaix.org/en-us/guides/get-action-pattern/
[2026-06-21T17:00:04Z] Server -> 200 OK
(Agent parses HTML. Finds `<script data-ai-digest>` or content about GET actions.)

[2026-06-21T17:00:05Z] Agent -> GET https://uaix.org/wp-json/uaix/v1/examples/uaix.get-action-v1
[2026-06-21T17:00:05Z] Server -> 200 OK
{"uai_version":"1.0","profile":"uai.get-action.v1", ...}

[2026-06-21T17:00:06Z] Agent -> POST https://uaix.org/wp-json/uaix/v1/examples
[2026-06-21T17:00:06Z] Server -> 405 Method Not Allowed (returned HTML)
(Agent sees non-JSON response, triggers fallback handling per GET-Action Security.)

[2026-06-21T17:00:07Z] Agent -> Report blocker("POST unsupported"; next step=human review)

This illustrates that the agent discovered UAIX via robots and manifests, fetched allowed GET resources, and properly handled an unsupported POST.

9. Diagrams

Architecture Diagram: UAIX.org serves as both human and agent endpoint, combining a WordPress front-end with JSON API. Agents use HTTP (GET with trace headers) to access the .well-known manifests and APIs. (Mermaid diagram below.)

flowchart LR
  A[AI Agent] --> B{Fetch /robots.txt and /sitemap.xml}
  B --> C[/.well-known/uaix.json]
  B --> D[/.well-known/ai-agent.json]
  C --> E{Parse discovery_contract}
  E --> F[/.well-known/openapi.json]
  E --> G[/wp-json/uaix/v1/... endpoints]
  D --> G
  F --> G
  G --> H[Process data or fetch action URLs]
  H --> I{Allowed GET requests}
  I --> J[/en-us/page.html (static content)]
  I --> K[/wp-json/uaix/v1/endpoint]
  H --> L{Forbidden actions}
  L --> M[Return Problem+JSON or no-op]

Request-Response Flow: A step-by-step flow of an agent requesting a GET-Action URL (e.g. fetching the AI Memory Wizard page):

sequenceDiagram
  Agent->>UAIX: GET /llms.txt
  UAIX-->>Agent: 200 (text/plain with guidance)
  Agent->>UAIX: GET /.well-known/uaix.json
  UAIX-->>Agent: 200 (JSON manifest listing URLs)
  Agent->>UAIX: GET /en-us/tools/ai-memory-package-wizard/
  UAIX-->>Agent: 200 (HTML with `<script data-ai-digest>`)
  Agent->>UAIX: GET /wp-json/uaix/v1/examples
  UAIX-->>Agent: 200 (JSON list of example messages)
  Agent->>UAIX: POST /wp-json/uaix/v1/...
  UAIX-->>Agent: 405 (Method Not Allowed)
  Agent--xUAIX: fallback -> human review

10. References

• UAIX website (AI-Ready Web, Guides, API Reference).
• W3C WCAG 2.0 Understanding (skip navigation).
• MDN docs on CORS and CSP.