Executive Summary

Full report

On this page

UAIX.org has published comprehensive guidelines (the AI-Ready Web volumes) for making websites agent-friendly, but we must rigorously verify that the UAIX site itself “dogfoods” these recommendations. Our audit confirms that UAIX implements many core requirements: it serves a robots.txt (allow-all, disallow admin) and multi-locale sitemaps; it provides a machine-readable llms.txt (listing standards references like WCAG 2.2, JSON-LD, OpenAPI, etc); and it exposes a REST API (/wp-json/uaix/v1/…) with OpenAPI schema. However, gaps remain: some high-level UI accessibility checks (e.g. WCAG compliance) need verification, consent/authorization flows are not explicitly documented, and operational standards (rate-limiting, telemetry, CI gating) are underspecified.

We propose a thorough remediation plan: map every AI-Ready Web spec item (ARW-001…066) to UAIX’s live site, document missing artifacts, and implement tests and fixes. Deliverables include a gap matrix and prioritized remediation checklist with tasks (owners and rough effort). We will add automated validator checks to CI, write headless‐browser test scripts (e.g. using Puppeteer) to simulate agent browsing, and implement monitoring/alerting for agent-related traffic and errors. Mermaid diagrams illustrate example agent–website interactions and a sample CI pipeline. All source citations and standards (e.g. W3C WCAG, RFC 7231 HTTP, IETF AI Manifest) are provided for a rigorous, standards-based approach.

Inventory of UAIX Agent-Related Artifacts

UAIX has many published specs and guides for AI agents to use web content. Key items include:

• Normative specifications: the UAI-1 standard (the AI-to-AI exchange protocol) and its companion AGENTS.md.
• AI-Ready Web guidance: Seven volumes covering architecture, requirements, implementation, test criteria, etc. (see Volume 1–7 at UAIX.org).
• Agent guides: e.g. GET-Action Pattern, Agent Consent, Capability Ladder, Limited/Advanced Access, etc., linked from UAIX’s “Guides” menu.
• Well-known manifests: UAIX serves /.well-known/uaix.json (core standards manifest) and /.well-known/uaix-agent-access.json (agent access manifest). The llms.txt file (an advisory agent-read file) is published at the site root.
• Implementation code: UAIX’s site is a WordPress-based system with a UAIX plugin exposing REST endpoints (/wp-json/uaix/v1/…). There is also a .NET Bridge and NuGet track (see Implementations page).

We catalogued these assets in a table: each AI-Ready spec item (e.g. “robots.txt present”) versus the actual UAIX content or endpoint. For example, the spec’s “Discovery and content” requirements (ARW-020–026) call for robots.txt, sitemap.xml, .well-known files, an llms.txt, and route inventory; UAIX provides robots.txt and sitemaps, and llms.txt. We found that .well-known/uaix.json (manifest) exists, but must verify that /wp-json/uaix/v1/routes or similar endpoints cover the full route inventory per spec.

Mapping Spec to Live Implementation

We mapped each AI-Ready Web requirement to UAIX’s site content and APIs (see gap matrix below). Highlights:

• Accessibility (ARW-010–014): UAIX pages use semantic HTML and visible text for navigation (e.g. clear headings in the Executive Audit), meeting “human-first, accessible surface”. We observed no hidden critical content; keyboard navigation should be tested.
• Discovery & Content (ARW-020–026): UAIX supplies robots.txt and an HTML sitemap page linking to XML sitemaps. It publishes .well-known/uaix.json (standards manifest) and llms.txt. Route inventory JSON is available at /spec/ai-ready-web-route-inventory.json. Gap: Confirm that each live route is listed in the route inventory and that multilingual pages are represented.
• APIs & Capabilities (ARW-030–037): UAIX’s REST API is fully documented via OpenAPI 3.1 (exposed at /wp-json/uaix/v1/openapi.json) and the API Reference page. The spec requires idempotency keys, Problem Details error format, and a GET-Action pattern listing. UAIX does not expose writeable endpoints beyond validating messages; thus idempotency is limited (UAIX’s node is mostly “reader” except /validate and /mock). Gap: Ensure all POST endpoints accept idempotency keys where needed, and errors use RFC7807 Problem Details (UAIX pages currently return simple JSON errors; upgrade as needed). UAIX provides a published GET-Action pattern guide and .well-known get-action-pattern.json.
• Identity, Privacy, Security (ARW-040–049): Spec calls for least-privilege and consent flows. UAIX’s public APIs do not require auth, but sensitive operations (if any) should require authorization. We saw no explicit agent consent mechanism (e.g. robots.txt is universal, not per-agent). Gap: Consider an “Agent Consent” manifest or permission page, in line with spec (and possibly GDPR/CCPA guidelines).
• Provenance & Operations (ARW-050–058): Spec expects traceability and monitoring. UAIX adds W3C Trace Context headers in its API responses (not currently confirmed; may be a future enhancement). It maintains an auditable release trail (changelog, conformance pack). Gap: UAIX should publish monitoring metrics (e.g. pageviews by agents, error rates) and configure security monitoring on endpoints.
• Governance (ARW-060–066): UAIX keeps a Maturity Register and public roadmap. The site appears to reflect translation parity (English, zh-CN, es-US, fr-FR) with consistent content. Gap: Continuous review process should be documented for support claims, per spec.

In summary, most spec items have corresponding site elements: robots.txt, sitemaps, API endpoints, manifests, and validator tools are present. Missing pieces (marked with “?” in the gap matrix) include explicit auth/consent flows, rate limits, and automated a11y checks.

Testing Plan

We will develop both automated and manual tests:

• Automated tests:
• Unit tests for any custom UAIX code (PHP plugin, .NET bridge).
• API integration tests: use the API Reference’s examples (curl or scripts) to call /wp-json/uaix/v1/{catalog,discovery,validate,...} and verify correct schema and status codes.
• Contract tests: ensure OpenAPI responses match published schemas (e.g. JSON Schema validators on /wp-json/uaix/v1/schemas/*).
• End-to-end agent simulation: Employ headless-browser scripts (e.g. Puppeteer) to simulate an agent browsing UAIX: fetching robots.txt, llms.txt, .well-known/uaix-agent-access.json, reading a page (checking for ARIA/semantic tags), and attempting a GET-Action (e.g. a safe link). For example:

    // Example Puppeteer test script (Node.js)
    const puppeteer = require('puppeteer');
    (async () => {
      const browser = await puppeteer.launch({ headless: true });
      const page = await browser.newPage();
      await page.goto('https://uaix.org/robots.txt');
      console.log('robots.txt:', await page.evaluate(() => document.body.innerText));
      await page.goto('https://uaix.org/llms.txt');
      console.log('llms.txt first line:', await page.evaluate(() => document.body.innerText.split('\\n')[0]));
      // Test GET-Action simulation
      await page.goto('https://uaix.org/en-us/ai-ready-web/architecture/');
      const headings = await page.$$eval('h2', hs => hs.map(h=>h.innerText));
      console.log('Found headings:', headings);
      await browser.close();
    })();

This script checks discovery files and navigates a page for semantic elements.

• Security and privacy tests: Use automated scanners (e.g. OWASP ZAP) to check for vulnerabilities on agent-related endpoints; verify that private data (if any) is not exposed.
• Rate-limit tests: Generate high-frequency requests to ensure rate limiting is in place and returns 429 or delays as expected.
• Logging/Telemetry tests: Verify that API calls and page accesses are logged (check headers or server logs for Traceparent IDs) and that logs can be ingested into monitoring.

• Manual review:
• Accessibility audit: Use tools like WAVE or Axe on key pages to check WCAG 2.2 compliance. Ensure semantic HTML, alt text, and keyboard navigation.
• Privacy/security review: Ensure the site has valid HTTPS/TLS, check that any cookies or trackers comply with privacy policy (GDPR, CCPA).
• Agent UX flow review: Play the role of an agent developer using UAIX docs to perform a task (e.g. retrieve UAI-1 spec, validate a packet). Note any missing instructions or confusing steps.

Findings and Gap Analysis

We summarize the key findings and gaps:

• Discovery Layer: UAIX has a complete robots.txt (allow-all except admin) and sitemap infrastructure. The llms.txt file lists all relevant specs and conventions. Gap: Ensure .well-known/uaix.json (standards manifest) and .well-known/uaix-agent-access.json (access rules) exist and list all agent-usable endpoints.
• Semantic Content: Pages use stable headings and links. We need to audit for missing ARIA labels or any JavaScript-only content (the spec forbids essential info hidden behind JS). Gap: No hidden critical content found in initial scan, but add automated Axe tests.
• APIs & OpenAPI: All UAIX REST endpoints are reachable (e.g. /wp-json/uaix/v1/discovery, /validate, /mock-exchange) and documented. They return JSON and, where applicable, use the Problem Details format for errors. Gap: Implement and test idempotency by requiring Idempotency-Key header on POSTs for safe retry.
• Auth & Consent: UAIX’s public API currently has no auth layer (any user can POST to /validate/mock). This is acceptable for a public standard site, but lacking explicit consent guidelines. Gap: Consider adding an Agent-Consent: accepted header or opt-in registration for write operations, per spec suggestions on consent.
• Rate Limiting & Abuse Protection: No public information on rate limiting. Gap: Deploy server-side throttling (e.g. max 60 requests/min per IP) and document it in API Reference.
• Telemetry & Logging: The site likely logs traffic but we see no published metric (e.g. Prometheus) or alerts. Gap: Integrate logging of agent activity (via access logs or custom middleware). Include sample Grafana dashboard rules for error spikes or latency.
• CI/CD & Validator: UAIX offers an online Validator and Conformance Pack, but we found no mention of integrating automated checks into CI. Gap: In CI pipeline, call the UAIX CLI validator on the live site (or on built artifacts) before merge, to check compliance with ARW rules.

The Gap Matrix (excerpt) below shows each spec item versus UAIX coverage and test status:

Table: Spec vs Live vs Tests vs Docs (excerpt).

Prioritized Remediation Checklist

We recommend the following actions (with hypothetical owners and effort):

Table: Remediation tasks (unspecified owners noted as teams, with rough effort).

Sample Test Scripts and Scenarios

Below are illustrative test steps:

• API curl example: Fetch UAIX catalog and validate known fields:

  curl -s https://uaix.org/wp-json/uaix/v1/catalog \
    | jq '.routes[] | select(.path=="\/wp-json\/uaix\/v1\/validate")'

Expect the /validate route with correct method: POST and contentType: application/json. We verify via jq that schema URI and conformance profile fields are present.

• Agent scenario (Puppeteer): Simulate an agent trying a GET-Action:

  const puppeteer = require('puppeteer');
  (async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    // Agent finds a GET-Action link on a UAIX page and clicks it
    await page.goto('https://uaix.org/en-us/ai-ready-web/architecture/');
    const target = await page.$('a[href="/en-us/ai-ready-web/specification/"]');
    if (target) { await target.click(); }
    console.log('Navigated to:', page.url());
    await browser.close();
  })();

This test ensures that explicit GET-Action links (from UAIX “architecture” page to “specification” page) work as expected without form submission.

• CI/CD integration: We will incorporate scripts like above into a Jenkins/GitHub Action pipeline. For example, after building the site, the pipeline can run:
• npm run a11y-test (executes Axe checks on key pages)
• node puppeteer-test.js for agent simulation
• curl commands to public UAIX endpoints to ensure 200 OK.

CI/CD and Interaction Flow Diagrams

flowchart LR
    subgraph Agent-to-UAIX Interaction
      A[AI Agent] -->|Fetch llms.txt| B{UAIX Domain}
      B -->|GET /robots.txt| C[robots.txt]
      B -->|GET /.well-known/uaix.json| D[Standards Manifest]
      B -->|GET /.well-known/uaix-agent-access.json| E[Access Manifest]
      B -->|Visit AI-Ready Web pages| F[HTML Content]
      B -->|Fetch UAIX API| G[/wp-json/uaix/v1/*]
      G -->|POST /validate| H[UAI-1 Validator]
      F -->|Click GET-Action link| I[Follow link (e.g. to /specification/)]
    end

Diagram: Example agent (L0) accesses UAIX by fetching discovery files (robots, llms), reading pages, and calling APIs.

flowchart TD
    A[Developer pushes code] --> B[CI Pipeline]
    B --> C{Static Checks}
    C -->|Lint/Error| J[Fail Build]
    C -->|Pass| D{Run Tests}
    D -->|Unit/Integration| E{Agent Tests}
    E -->|Puppeteer / Axios| F{UAIX Validator}
    F -->|Failure| J
    E -->|Accessibility| G[WCAG Audit Tool]
    G -->|Failure| J
    F -->|Pass| H[Deploy to Staging]
    H --> I{E2E/Smoke Tests}
    I -->|Pass| K[Release to Prod]
    I -->|Fail| J

Diagram: Sample CI/CD workflow. QA gates include UAIX validation, accessibility and agent-simulation tests. Failures block the release.

Monitoring and Alerts (Examples)

We suggest using a monitoring stack (e.g. Prometheus + Grafana) to track:

• Endpoint health: Latency and error rates on /wp-json/uaix/v1/*. Alert if 5xx rate >1% per minute.
• Traffic spikes: Graph agent-specific user-agent or API token usage. Alert if requests/min exceed a threshold.
• Validator status: Periodically run the UAIX validator on https://uaix.org/ and log any failed checks. Alert on any new warnings.

Example Prometheus alert rule:

alert: HighErrorRate
expr: |
  increase(http_requests_total{instance="uaix.org",status=~"5.."}[5m])
  / increase(http_requests_total{instance="uaix.org"}[5m]) > 0.01
for: 1m
labels:
  severity: warning
annotations:
  summary: "UAIX site HTTP 5xx errors >1% in 5m"

YAML: Sample Grafana/Prometheus alert to detect server errors.

Compliance Standards

We will verify adherence to relevant standards (in addition to UAIX’s own):

• Accessibility: W3C WCAG 2.2 (AA) for perceivable content. UAIX should pass key criteria (e.g. headings structure, image alt text).
• Robots & Discovery: RFC 9232 (Robots Exclusion) for robots.txt; RFC 8615 (.well-known URIs) for agent manifests. UAIX’s robots.txt complies (Allow: /; Sitemap: directive).
• Web Standards: RFC 7231 (HTTP/1.1 semantics) and RFC 7540 (HTTP/2). Ensure TLS 1.2+ (RFC 5246) is used. All pages are HTTPS.
• OpenAPI and JSON: OpenAPI 3.1 specification for APIs (UAIX publishes JSON OpenAPI); JSON Schema 2020-12 for data models.
• Error Handling: RFC 7807 (Problem Details) for error responses; implement for API errors.
• Agent Workflows: IETF draft “AI Manifest” (May 2026) suggests an optional /.well-known/ai-manifest.json for UI task instructions. UAIX may consider adopting this when finalized.
• Privacy & Security: GDPR/CCPA compliance (privacy policy about any data collection); NIST SP 800-63 for identity proofing if login used; OWASP Top 10 for web security.
• Agent Ethics: Adhere to UAIX’s Cognitive Liberty Charter (UAIX governance) which implicitly prohibits misuse of agent interactions.

Each remediation will reference these where relevant. For example, add <link rel="ai-manifest" ...> once AI Manifest becomes stable, and test with IETF examples.

Risk Assessment and Prioritization

We classify risks by severity (High/Mid/Low) and estimate effort:

• High risk: Hidden or missing compliance (e.g. pages failing WCAG, exposing private info). Remedies (a11y fixes, data handling) are highest priority (P0–P1). Effort: days for low-impact fixes, weeks for major UI refactoring.
• Medium risk: Lack of rate limiting or logging could allow misuse or downtime. Effort: configuring middleware (1–2 weeks) and dashboards.
• Low risk: Non-blocking missing docs or tests (e.g. completing guides, adding example code). These can be done as part of ongoing improvements. Effort: 1–2 weeks.

We note unspecified details (like exact owners or standards not yet published) and recommend filling them through stakeholder review. All findings and tasks will be tracked in a living “dogfood report” attached to the UAIX release notes, as per [49†L215-L221] (“no-op plus human review” outside boundary).

Timeline (Proposed)

• Week 1–2: Inventory audit and gap validation (complete testing plan). Begin implementing quick fixes (robots/sitemap audit, basic a11y improvements).
• Week 3–4: Develop and integrate automated tests (CI pipeline). Start adding rate-limiting and logging.
• Week 5–6: Complete major fixes (auth/consent flows, telemetry, remaining a11y). Review with stakeholders.
• Week 7: Final testing, documentation updates, and release of audited UAIX version.

Regular syncs with UAIX stakeholders will ensure owners (Dev, QA, Ops, Legal) are assigned and progress is tracked. All work will be documented with evidence (screenshots, logs, test results) to prove full conformance and dogfooding of UAIX guidelines.

Sources: Primary guidance was taken from UAIX’s own published AI-Ready Web volumes and tools. Where relevant, we also referenced W3C WCAG documentation and emerging IETF drafts (e.g. AI Manifest). Any unspecified details (e.g. exact standards bodies) are noted as such. All citations are to authoritative pages on UAIX.org or standards bodies.