Master Prompt: Improve UAIX.org with a Comprehensive AI-Ready Web Specification and Implementation Program

Full report

On this page

Role

Act as a combined:

• principal web standards architect;
• senior accessibility engineer;
• AI-agent interoperability architect;
• API and identity/security architect;
• privacy, provenance, and governance specialist;
• technical content strategist and information architect;
• WordPress, ASP.NET Core, and modern JavaScript implementation lead;
• test-automation and conformance-tooling engineer.

Your task is not to write a high-level thought piece. Your task is to audit, design, specify, document, and—when repository access is available—implement a production-ready AI-Ready Web program on UAIX.org.

The result must make UAIX.org a rigorous, practical, vendor-neutral reference for how websites should:

1. remain excellent and accessible for humans;
2. be discoverable and understandable by current AI systems;
3. expose safe, deterministic capabilities to authorized agents;
4. support trustworthy delegation, provenance, audit, and human control;
5. adapt as browser, protocol, identity, commerce, and governance standards evolve.

Do not stop at recommendations. Produce implementation-ready specifications, page content, schemas, examples, validators, tests, governance processes, and a phased delivery plan.

---

1. Mission

Create a new top-level UAIX.org program provisionally titled:

AI-Ready Web

The program must define a coherent architecture for websites that are readable, discoverable, actionable, secure, privacy-preserving, auditable, and future-adaptable for AI systems.

The new program must complement—not replace or blur—the existing UAIX mission.

Preserve this scope boundary:

• UAI-1 / UAIX is the portable public exchange, evidence, memory, trust-declaration, and handoff layer.
• HTTP APIs and OpenAPI describe route-level interfaces.
• MCP describes model/tool/resource integration within compatible host-client-server environments.
• A2A or other agent protocols may handle agent discovery, delegation, and task coordination.
• Browser-facing agent APIs, including WebMCP-like work, may expose in-session capabilities when supported.
• Identity systems such as OAuth, OpenID Connect, verifiable credentials, signed HTTP messages, or equivalent mechanisms remain distinct security layers.
• UAIX must not claim that it replaces every runtime, transport, identity, accessibility, legal, or security standard.

The program must explain how these layers fit together and where their responsibilities stop.

---

2. Required Operating Principles

Apply these principles throughout the work.

2.1 Human-first, agent-compatible

AI readiness must never be achieved by degrading accessibility, usability, privacy, or control for people.

A machine-readable representation must not become a separate, contradictory source of truth. Human and machine representations must derive from the same canonical content and data models.

2.2 Accessibility is foundational

Treat WCAG-conformant, semantic, keyboard-operable, assistive-technology-compatible design as the first layer of agent readiness—not as an optional add-on.

Use native HTML before ARIA. Never recommend ARIA as a substitute for correct native semantics.

2.3 Stable standards before speculative protocols

Build the normative baseline on mature web standards. Emerging mechanisms may be documented, prototyped, or placed on a watchlist, but they must not be presented as established standards unless their official status supports that claim.

2.4 Explicit maturity labeling

Every protocol, format, recommendation, and feature must be assigned one of these statuses:

1. Normative Web Standard — published RFC, W3C Recommendation, WHATWG living standard, or equivalent formal standard.
2. Established Industry Specification — stable, governed, and implemented, but not necessarily a formal web standard.
3. Active Draft or Incubation — under active standards or community development.
4. Community Proposal — useful proposal with uncertain adoption or governance.
5. UAIX-Specific Draft — a proposal owned by UAIX and not represented as an external standard.
6. Research / Watchlist — not appropriate for production requirements.
7. Deprecated / Superseded — retained only for migration guidance.

Show the status, owner, current version, last verification date in UTC, source URL, expected stability, known implementation support, fallback, and review date.

2.5 No invented authority

Do not invent browser support, crawler behavior, legal effect, standardization status, adoption statistics, certification, interoperability, or vendor commitments.

Do not turn a W3C Community Group proposal into a “W3C Standard.” Do not turn an IETF Internet-Draft into an RFC. Do not describe llms.txt as access control, copyright enforcement, or a universal crawler directive. Do not treat robots.txt as authentication, authorization, licensing, or legal consent. Do not represent a UAIX validator result as proof of runtime safety.

2.6 Evidence over assertion

Every current technical, legal, adoption, or standards-status claim must be sourced from primary or authoritative materials and include a Last verified: YYYY-MM-DDTHH:mm:ssZ marker.

Where evidence is inconclusive, state that directly.

2.7 Least privilege and no-op safety

For agent actions:

• deny by default;
• grant the smallest scope for the shortest useful duration;
• require explicit preconditions;
• require human confirmation for high-impact or irreversible actions;
• stop safely when identity, consent, context, capability, state, or evidence is ambiguous;
• log a structured reason for the no-op;
• never improvise a hidden workaround.

Treat the UAIX no-op concept as an explicit, reviewable safety behavior. Do not claim it is a universal external standard.

2.8 One source of truth

HTML, Markdown, JSON, JSON-LD, feeds, API payloads, OpenAPI descriptions, capability manifests, and llms.txt-style indexes must be generated from—or continuously reconciled against—the same canonical content and data.

Build automated parity tests.

2.9 Vendor neutrality

Prefer open, interoperable mechanisms. Vendor products may appear as implementation examples, never as mandatory dependencies unless UAIX explicitly defines a vendor-specific track.

2.10 Progressive enhancement

A basic agent must be able to read useful public content without executing complex JavaScript. More capable agents may receive richer structured data and authorized capabilities.

---

3. Research and Source Discipline

Before proposing changes, perform current research.

3.1 Source priority

Use this source hierarchy:

1. current canonical UAIX.org pages, schemas, APIs, validator behavior, roadmap, changelog, and repository;
2. normative primary standards and official registries;
3. official protocol specifications and governance repositories;
4. regulator and government publications;
5. peer-reviewed research;
6. credible implementation documentation and measured industry evidence;
7. the supplied research documents as a broad ideation corpus;
8. secondary commentary only when primary evidence is unavailable.

3.2 Required verification categories

Verify the current status and applicability of at least:

• HTML and accessibility-tree behavior;
• WCAG 2.2 and current WCAG 3 work;
• WAI-ARIA and Authoring Practices;
• HTTP semantics, caching, conditional requests, content negotiation, redirects, status codes, and link relations;
• Robots Exclusion Protocol;
• sitemap protocol;
• JSON-LD and Schema.org;
• OpenAPI and JSON Schema;
• Problem Details for HTTP APIs;
• OAuth 2.0, OpenID Connect, PKCE, token exchange, sender-constrained tokens, and relevant security best practices;
• HTTP Message Signatures;
• W3C Trace Context;
• WebFinger and WebSub where recommended;
• MCP;
• A2A;
• WebMCP or equivalent browser-agent work;
• llms.txt;
• IETF AI Preferences work;
• text-and-data-mining preference mechanisms;
• provenance standards such as C2PA or W3C PROV where applicable;
• agent-commerce protocols only where a stable, official specification exists;
• NIST AI RMF and current agent-security work;
• OWASP guidance relevant to agentic systems, APIs, and prompt injection;
• applicable privacy, accessibility, consumer-protection, AI-transparency, and copyright obligations.

3.3 Status correction rule

If the supplied research calls something a standard but the authoritative source shows that it is a draft, community report, proposal, experiment, or unsupported claim, correct it.

Create a Research Corrections and Maturity Register with these columns:

3.4 No stale assumptions

Do not rely on model memory for current versions, browser flags, protocol releases, legal deadlines, or current UAIX routes. Re-check them at execution time.

---

4. Work in Five Phases

Phase A — Audit

Audit the current public site and repository.

Phase B — Architecture

Define the information architecture, conformance model, schemas, and boundaries.

Phase C — Specification and Content

Write the complete normative and informative guidance.

Phase D — Implementation

Implement the approved site changes, endpoints, generators, examples, and tools when repository access is available.

Phase E — Validation and Release

Run automated and manual checks, generate evidence, document unresolved risks, and prepare a release package.

Do not skip directly to implementation before producing the audit and architecture.

---

5. Phase A: Current-State Audit

Produce a complete audit of UAIX.org.

5.1 Route and content inventory

Inventory:

• all top-level navigation;
• UAI-1 specification pages;
• schemas, registries, examples, and fixtures;
• validator and conformance-pack routes;
• API reference and OpenAPI export;
• AI Memory and project-handoff materials;
• Capability Ladder;
• Capability Surface Matrix;
• Agent Executability Matrix;
• No-Op Protocol;
• Agent Consent;
• Minimal Access Tier;
• GET-Action guidance and its security constraints;
• WordPress publication track;
• .NET bridge track;
• roadmap, changelog, governance, policy, references, and contributor records;
• all machine-readable discovery and catalog endpoints;
• existing JSON-LD, feeds, sitemaps, robots rules, alternate formats, and headers.

For every route, record:

Reuse decisions must be one of:

• keep as canonical;
• revise;
• cross-link;
• merge;
• alias;
• deprecate;
• archive;
• replace.

5.2 Technical audit

Check:

• HTTPS and redirect consistency;
• canonical URLs;
• locale and hreflang;
• sitemap coverage and accurate lastmod;
• robots.txt;
• structured data validity;
• semantic HTML;
• accessibility-tree quality;
• keyboard navigation;
• focus behavior;
• form labeling;
• dynamic content states;
• JavaScript dependency for critical content;
• server-side rendering or equivalent fallback;
• Core Web Vitals and layout stability;
• Markdown or plain-text alternatives;
• HTTP content negotiation;
• Vary, ETag, Last-Modified, conditional requests, compression, and caching;
• API discoverability;
• OpenAPI validity;
• JSON Schema validity;
• consistent error payloads;
• authentication metadata;
• rate-limit behavior;
• CORS policy;
• security headers;
• trace and correlation identifiers;
• logging and privacy exposure;
• broken links;
• duplicate or contradictory content;
• version and maturity labeling.

5.3 Existing-guidance risk audit

Specifically evaluate whether current guidance could be misunderstood.

Examples:

• Any GET-based compatibility mechanism must not be presented as permission to make ordinary HTTP GET requests state-changing.
• Capability discovery must not be interpreted as execution permission.
• A valid UAI-1 packet must not be described as authentication.
• A machine-readable preference must not be described as enforcement.
• An accessibility score must not be described as complete WCAG conformance.
• A readiness score must not be described as certification.
• A public API must not imply unrestricted data reuse.
• A well-known path must not be invented without registration or explicit UAIX namespacing.
• Machine-readable files must not expose secrets, private prompts, credentials, internal-only endpoints, or confidential operational context.

5.4 Audit output

Produce:

1. executive summary;
2. strengths;
3. gaps;
4. contradictions;
5. duplicated concepts;
6. security risks;
7. accessibility risks;
8. content-governance risks;
9. standards-status corrections;
10. prioritized remediation backlog.

Use severity:

• Critical;
• High;
• Medium;
• Low;
• Informational.

---

6. Phase B: Information Architecture

Design a dedicated top-level section. Use the final route names only after auditing existing URL conventions.

A strong initial structure is:

AI-Ready Web
├── Overview
├── Principles
├── Definitions and Maturity Labels
├── Readiness Profiles
├── Specification
│   ├── Core Requirements
│   ├── Human Accessibility
│   ├── Rendering and Progressive Enhancement
│   ├── Discovery and Routing
│   ├── Content Semantics
│   ├── Structured Data
│   ├── Alternate Representations
│   ├── APIs and Capability Surfaces
│   ├── Identity, Delegation, and Consent
│   ├── Security and No-Op Safety
│   ├── Privacy, Rights, and Usage Preferences
│   ├── Provenance and Audit
│   ├── Performance and Reliability
│   ├── Events and Real-Time Updates
│   ├── Agentic Commerce
│   └── Governance and Lifecycle
├── Implementation Guides
│   ├── Static Sites
│   ├── WordPress
│   ├── ASP.NET Core
│   ├── Node.js / JavaScript
│   ├── SPAs and SSR Frameworks
│   └── Enterprise Platforms
├── Patterns
├── Anti-Patterns
├── Examples and Test Fixtures
├── Validator
├── Readiness Assessment Methodology
├── Conformance Pack
├── Roadmap and Standards Watchlist
├── Changelog
├── Glossary
└── References

6.1 Navigation rules

• Add one clear top-level entry.
• Avoid burying the program under generic Guides.
• Cross-link existing UAIX concepts instead of copying their text into multiple canonical pages.
• Every page must show whether it is normative, informative, experimental, or roadmap-only.
• Provide “Start here” paths for:
• site owners;
• content teams;
• frontend developers;
• backend/API engineers;
• accessibility teams;
• security and identity teams;
• legal/privacy teams;
• AI-agent developers;
• auditors and procurement teams.

6.2 Page metadata

Every page must expose human-visible and machine-readable metadata:

• title;
• short description;
• audience;
• status;
• maturity;
• specification version;
• page version;
• normative/informative designation;
• owner;
• reviewers;
• published time in UTC;
• last modified time in UTC;
• last verified time in UTC;
• next review date in UTC;
• supersedes/superseded-by links;
• requirement IDs;
• related standards;
• source citations;
• changelog;
• machine-readable alternate link.

---

7. Phase B: Conformance Model

Create a UAIX AI-Ready Web conformance model, but do not call it certification unless UAIX has established public certification governance, reviewer qualifications, appeals, renewal, revocation, and trademark rules.

Use the term Readiness Profile or Evidence Profile.

7.1 Recommended profiles

ARW-0 — Human-Accessible Foundation

A site has:

• valid, secure, human-usable web delivery;
• semantic HTML;
• WCAG 2.2 Level AA target;
• keyboard operability;
• meaningful page structure;
• accessible forms, media, and errors;
• primary content available without brittle automation;
• stable URLs and canonical metadata.

ARW-1 — Machine-Readable

Adds:

• structured data;
• canonical entity identifiers;
• accurate publication and modification dates;
• machine-readable tables and media alternatives;
• predictable content sections;
• consistent HTTP semantics;
• structured errors for APIs.

ARW-2 — Agent-Discoverable

Adds:

• complete sitemap and discovery surfaces;
• alternate Markdown or JSON representations where useful;
• machine-readable route/API catalog;
• optional, correctly labeled llms.txt-style index;
• explicit version, status, and update metadata;
• automated parity checks.

ARW-3 — Agent-Actionable

Adds:

• documented capabilities;
• OpenAPI and JSON Schema;
• deterministic inputs and outputs;
• explicit side effects;
• idempotency and retry rules;
• long-running-task patterns;
• safe webhooks/events;
• optional MCP, A2A, or browser-tool adapters;
• bounded no-op behavior.

ARW-4 — Delegated and Trusted

Adds:

• distinct agent identity;
• user-to-agent delegation;
• least-privilege authorization;
• short-lived scoped credentials;
• consent records;
• step-up authentication;
• human confirmation for high-risk actions;
• replay protection;
• revocation;
• signed high-assurance messages where required.

ARW-5 — Governed and Auditable

Adds:

• end-to-end provenance;
• traceable approvals;
• structured audit evidence;
• incident response;
• policy/version governance;
• risk classification;
• continuous testing;
• lifecycle and deprecation rules;
• multi-agent handoff evidence;
• validated UAI-1 evidence packages where appropriate.

7.2 Relationship to UAIX Agent Capability Ladder

Create an explicit mapping table, but state that website readiness profiles and agent capability levels are different axes.

A website may support an advanced profile while an individual agent has limited capability. A high-capability agent must still obey the site’s lower authorized surface.

7.3 Requirement identifiers

Create stable requirement namespaces:

• ARW-CORE-*
• ARW-A11Y-*
• ARW-RENDER-*
• ARW-DISC-*
• ARW-CONTENT-*
• ARW-SEM-*
• ARW-REP-*
• ARW-API-*
• ARW-CAP-*
• ARW-ID-*
• ARW-CONSENT-*
• ARW-SEC-*
• ARW-PRIV-*
• ARW-RIGHTS-*
• ARW-PROV-*
• ARW-PERF-*
• ARW-EVENT-*
• ARW-COMMERCE-*
• ARW-OBS-*
• ARW-GOV-*
• ARW-TEST-*

Each requirement must include:

{
  "id": "ARW-A11Y-001",
  "title": "Use native semantic controls",
  "status": "draft",
  "maturity": "normative-web-standard",
  "profiles": ["ARW-0", "ARW-1", "ARW-2", "ARW-3", "ARW-4", "ARW-5"],
  "conformance_target": "web-page",
  "normative_statement": "The page MUST use a native HTML control when a native element provides the required semantics and behavior.",
  "rationale": "...",
  "automated_test": "partial",
  "manual_test": true,
  "required_evidence": ["DOM snapshot", "accessibility-tree snapshot", "keyboard test"],
  "exceptions": [],
  "references": [],
  "last_verified_utc": "YYYY-MM-DDTHH:mm:ssZ"
}

Use RFC 2119/8174 keywords only in clearly normative sections.

---

8. Phase C: Detailed Specification Requirements

Write complete normative and informative guidance for every domain below.

8.1 Core Architecture

Specify that an AI-ready site:

• uses the web as the primary public contract;
• maintains content and capability parity;
• separates public content, machine context, action interfaces, and privileged internal systems;
• distinguishes discovery, description, authentication, authorization, execution, evidence, and governance;
• has explicit source authority;
• uses stable identifiers;
• supports versioning and deprecation;
• fails safely;
• remains usable by humans without AI;
• remains useful to basic agents without requiring a frontier model.

Include architecture diagrams showing:

1. human browser path;
2. crawler/retrieval path;
3. API/tool path;
4. delegated-action path;
5. audit/evidence path;
6. no-op/escalation path.

8.2 Human Accessibility and Accessibility-Tree Quality

Make WCAG 2.2 Level AA the minimum target unless a stricter applicable requirement exists.

Specify:

• correct document language and text direction;
• one descriptive page title;
• one primary main landmark;
• logical heading hierarchy;
• native links, buttons, inputs, selects, details, dialogs, and tables;
• accessible names and descriptions;
• explicit form labels;
• appropriate autocomplete tokens;
• keyboard access to all functionality;
• visible focus;
• focus order matching logical order;
• skip links;
• no hover-only or pointer-only operation;
• predictable navigation;
• correct expanded, selected, pressed, checked, busy, invalid, and live states;
• modal focus entry, containment, escape, and return;
• accessible validation and error summaries;
• captions, transcripts, audio descriptions, and meaningful alt text;
• text alternatives for charts, diagrams, canvas, and complex SVG;
• downloadable tabular data for charts where practical;
• zoom and reflow;
• target size and spacing;
• reduced-motion support;
• cognitive clarity;
• time-limit controls;
• accessible authentication alternatives;
• accessible status messages.

Require both automated and manual testing. Explain which checks cannot be automated.

Include anti-patterns:

• clickable div elements;
• icons without accessible names;
• placeholder-only labels;
• heading levels used only for styling;
• hidden critical content;
• focus lost after updates;
• inaccessible custom select controls;
• live regions that announce excessive content;
• CAPTCHA with no accessible alternative;
• machine-only text hidden from humans.

8.3 Rendering and Progressive Enhancement

Specify:

• primary public content must appear in the initial HTML or an equivalent immediately available representation;
• JavaScript may enhance but must not be the sole route to essential public information;
• SPAs must use SSR, static generation, prerendering, or an equivalent accessible fallback for critical routes;
• important actions require deterministic semantic controls;
• layouts must avoid disruptive shifts;
• interactive state must be reflected programmatically;
• infinite scrolling must have pagination or a bounded machine-readable alternative;
• dynamically loaded content must expose completion/error state;
• content behind tabs or accordions must remain accessible and programmatically discoverable;
• canvas-only or screenshot-only data must have structured alternatives;
• stable element identifiers should be used when agents or tests rely on them, but selectors must not expose sensitive internals.

Define parity tests between:

• server-rendered HTML;
• hydrated DOM;
• accessibility tree;
• structured data;
• alternate Markdown/JSON;
• API payloads.

8.4 Content Architecture and Editorial Semantics

Require each guidance page to include:

• purpose;
• target audience;
• short answer or summary;
• definitions;
• normative requirements;
• rationale;
• implementation examples;
• anti-patterns;
• test procedure;
• security implications;
• privacy implications;
• accessibility implications;
• interoperability notes;
• maturity and support status;
• references;
• changelog.

Content rules:

• use direct, factual language;
• define acronyms on first use;
• distinguish fact, recommendation, hypothesis, and future work;
• avoid unsupported superlatives;
• provide explicit dates;
• identify version and jurisdiction where relevant;
• include author, reviewer, and source provenance;
• provide correction and feedback routes;
• avoid duplicate canonical definitions;
• mark deprecated guidance visibly;
• maintain glossary links;
• use stable anchors for requirements;
• include concise answer blocks without sacrificing context;
• avoid schema markup for content not visible on the page;
• do not create FAQ content merely to manipulate answer engines.

8.5 Discovery and Routing

Required mature mechanisms

Document and implement:

• robots.txt according to the current Robots Exclusion Protocol;
• XML sitemap or sitemap index;
• accurate lastmod;
• canonical URLs;
• locale alternatives;
• RSS/Atom feeds where relevant;
• API and schema discovery;
• correct HTTP redirects;
• registered or absolute-URI link relations;
• standard cache validators.

State explicitly:

• robots.txt is advisory crawler access signaling, not authorization;
• a sitemap is discovery metadata, not a guarantee of indexing;
• neither mechanism grants a license to reuse content;
• authentication and access control must be enforced by the application.

Optional proposal: llms.txt

Create a balanced guide that:

• labels llms.txt as a proposal unless its status changes;
• explains its intended inference-time routing use;
• does not claim universal crawler adoption;
• does not claim it controls training or legal rights;
• recommends generating it from canonical content;
• requires factual descriptions and stable URLs;
• includes a generated timestamp and version;
• avoids secrets, private endpoints, internal prompts, or unsupported claims;
• provides size limits and link-health tests;
• explains when llms-full.txt is unsuitable because of size, freshness, confidentiality, or context limits;
• provides fallback behavior when ignored.

HTTP discovery

Evaluate and document:

• Link response headers;
• <link rel="alternate">;
• OpenAPI links;
• feed links;
• canonical links;
• registered .well-known resources.

Do not invent bare relation names that have no registration or documented absolute URI.

Do not place a custom file under /.well-known/ unless:

1. it is registered;
2. it follows a published specification; or
3. UAIX labels it as experimental and begins the appropriate registration/governance process.

Prefer a UAIX-namespaced API route, such as a versioned /wp-json/uaix/... route or /uaix/ai-ready/v1/..., until a well-known suffix is formally justified.

8.6 Alternate Representations and Content Negotiation

Define a production profile for serving:

• HTML to browsers;
• Markdown to clients requesting text/markdown;
• JSON for structured records;
• CSV or JSON downloads for tables;
• accessible PDF only where PDF is necessary.

Requirements:

• representations derive from one source;
• Content-Type is accurate;
• Vary: Accept is present when representation changes by Accept;
• canonical identity is preserved;
• Content-Location is used where appropriate;
• cache behavior is correct;
• Markdown is sanitized and does not include hidden secrets;
• metadata identifies version, publication time, modification time, and source;
• links remain absolute or resolvable;
• code blocks preserve language identifiers;
• tables remain understandable;
• unsupported media types receive a correct response rather than silent corruption;
• parity is tested automatically.

Provide complete examples for:

• origin-based content negotiation;
• static .md alternates;
• edge/CDN transformation;
• WordPress;
• ASP.NET Core;
• Node.js.

8.7 Structured Data and Entity Clarity

Create a UAIX structured-data profile based on JSON-LD and appropriate Schema.org types.

Cover:

• Organization;
• WebSite;
• WebPage;
• BreadcrumbList;
• Article / TechArticle;
• Person;
• SoftwareApplication;
• Dataset;
• CreativeWork;
• FAQPage only when the page is genuinely an FAQ;
• Product, Offer, Service, Event, or other types where applicable;
• license;
• citations;
• isPartOf;
• about;
• mentions;
• datePublished;
• dateModified;
• author;
• publisher;
• stable identifiers and URLs.

Requirements:

• data must match visible content;
• dynamic values such as price and availability must be timestamped and fresh;
• one entity must not receive contradictory identifiers;
• sameAs must be curated;
• generated content must identify review status when required;
• structured data must not expose private fields;
• data must be validated in CI;
• content-template owners must be documented.

Create page-type JSON-LD templates and tests.

8.8 API Design for Agents

Use a current stable OpenAPI version and compatible JSON Schema dialect after verification.

Require:

• stable, descriptive operationId values;
• explicit summaries and descriptions;
• complete input and output schemas;
• required fields;
• formats;
• ranges;
• enumerations;
• examples;
• defaults only where behavior is truly defaulted;
• authentication requirements;
• authorization scopes;
• side effects;
• risk level;
• reversibility;
• rate limits;
• timeouts;
• error cases;
• deprecation state;
• version;
• support contact.

HTTP rules:

• GET and HEAD must be safe;
• PUT and DELETE must be idempotent according to their defined semantics;
• state-changing POST requests should support idempotency keys where retries are possible;
• do not use state-changing GET as general best practice;
• if UAIX retains a bounded GET-Action compatibility pattern, isolate it as a special legacy/minimal-agent profile with explicit security constraints, non-sensitive scope, anti-CSRF design, idempotency, confirmation rules, and no-op fallback;
• use conditional requests where concurrency matters;
• use cursor pagination for unstable large collections;
• expose explicit sorting and filtering;
• use accepted asynchronous responses for long operations;
• return a status URL, cancellation method, expiry, and result link;
• sign and replay-protect webhooks;
• validate callback URLs;
• limit redirects;
• use structured Problem Details based on the current RFC;
• never return stack traces or secrets;
• define retryability;
• honor Retry-After;
• publish deprecation and sunset information;
• keep API dates and timestamps in UTC.

CORS rules:

• do not recommend Access-Control-Allow-Origin: * as a default;
• use the narrowest required origins, methods, and headers;
• never combine wildcard origins with credentialed browser access;
• explain that server-to-server agents are not governed by browser CORS;
• treat CORS as a browser security policy, not API authentication.

8.9 Capability Surface Matrix

Expand the existing UAIX Capability Surface Matrix into a versioned machine-readable contract.

For every capability include:

• capability ID;
• human-readable name;
• action-oriented machine name;
• description;
• owner;
• lifecycle status;
• version;
• protocol bindings;
• input schema;
• output schema;
• examples;
• authentication profile;
• required scopes;
• human principal;
• agent principal;
• delegation requirements;
• preconditions;
• state dependencies;
• expected side effects;
• data classifications;
• retention;
• risk level;
• reversibility;
• dry-run support;
• confirmation requirement;
• human-review requirement;
• idempotency behavior;
• maximum execution time;
• cost or quota class;
• rate limit;
• retry behavior;
• error types;
• rollback path;
• audit fields;
• provenance requirements;
• support and incident contact;
• deprecation date;
• replacement capability.

Create:

1. a JSON Schema;
2. an HTML reference table;
3. an example catalog;
4. an OpenAPI mapping;
5. an MCP mapping where appropriate;
6. an A2A skill mapping where appropriate;
7. a browser-tool mapping for experimental WebMCP-like support;
8. a UAI-1 evidence mapping.

State clearly:

• discovering a capability is not permission to call it;
• possessing a schema is not authentication;
• authenticating is not authorization;
• authorization is not user consent;
• user consent is not proof that every downstream use is lawful;
• successful execution is not proof of correctness;
• conformance evidence is not certification of safety.

8.10 MCP, A2A, and Browser-Agent Integration

Create comparison and integration guidance.

For each protocol, document:

• official status and version;
• governing organization;
• purpose;
• trust boundary;
• transport;
• discovery;
• capability model;
• authentication model;
• authorization model;
• consent behavior;
• error model;
• state/task model;
• streaming;
• browser support;
• production readiness;
• fallback;
• UAIX relationship.

MCP guidance must:

• use the current official specification;
• distinguish tools, resources, prompts, and any current extension model;
• avoid assuming every AI client supports MCP;
• explain server trust and tool poisoning;
• require strict tool schemas and descriptions;
• require authorization and data-boundary review;
• map results into UAI-1 evidence only when a portable record is needed.

A2A guidance must:

• use the current official Linux Foundation project;
• verify the current agent-card/discovery path and schema;
• explain task delegation and status;
• distinguish A2A runtime coordination from UAIX evidence;
• document identity and policy gaps rather than inventing them.

WebMCP guidance must:

• label it according to its actual standards maturity;
• identify browser support accurately;
• use feature detection;
• require permission and human-in-the-loop review;
• expose only bounded functions;
• avoid leaking session state;
• provide an API fallback;
• include security and accessibility review;
• never present experimental APIs as universally available.

8.11 Identity, Authentication, Authorization, Delegation, and Consent

Design a zero-trust agent-access model.

Principals must be distinct:

• human user;
• agent software;
• agent operator/provider;
• client application;
• resource server;
• target service.

Requirements:

• no agent inherits a user’s unrestricted long-lived session by default;
• credentials are short-lived;
• tokens are audience-restricted;
• scopes are capability-specific;
• delegation is explicit;
• revocation is available;
• token storage is protected;
• refresh behavior is bounded;
• public clients use PKCE where appropriate;
• service credentials are not used as substitutes for user delegation;
• client-credentials grants are limited to the client’s own authority;
• high-risk actions require step-up authentication or explicit human confirmation;
• identity and authorization failures trigger no-op;
• replay protection is implemented;
• confused-deputy scenarios are tested;
• users can inspect and revoke active agent grants;
• consent is purpose-specific and time-bounded;
• consent records identify data, action, purpose, agent, operator, scope, expiry, and revocation route;
• privacy notices explain agent access;
• audit logs correlate user, agent, token, scope, capability, result, and approval.

Evaluate appropriate use of:

• OAuth 2.0;
• OpenID Connect;
• PKCE;
• token exchange;
• sender-constrained tokens;
• mutual TLS;
• DPoP;
• WebAuthn/passkeys for human approval;
• HTTP Message Signatures;
• verifiable credentials.

Do not mandate every mechanism. Define risk-based profiles.

8.12 Security and No-Op Safety

Create a detailed threat model that includes:

• direct prompt injection;
• indirect prompt injection embedded in web content;
• malicious tool descriptions;
• tool-output poisoning;
• cross-agent instruction smuggling;
• data exfiltration;
• credential theft;
• excessive agency;
• insecure delegated authorization;
• confused deputy;
• SSRF;
• DNS rebinding;
• open redirects;
• malicious callback URLs;
• webhook replay;
• CSRF;
• XSS;
• SQL/command injection;
• insecure deserialization;
• broken object-level authorization;
• cross-tenant access;
• data poisoning;
• model-output hallucination;
• unsafe retries;
• duplicate financial actions;
• runaway loops;
• denial of service;
• denial of wallet;
• inventory hoarding;
• agent impersonation;
• audit-log tampering;
• supply-chain compromise;
• secret leakage through logs or machine-readable files.

Required controls:

• treat retrieved content as untrusted data, not instructions;
• separate system policy from page content;
• validate all inputs against strict schemas;
• allowlist egress destinations for privileged tools;
• block private and link-local network targets where not explicitly required;
• revalidate after redirects;
• limit redirect count;
• bind actions to authorized resources;
• enforce tenant isolation;
• encode outputs safely;
• use secret-management systems;
• redact logs;
• cap requests, tokens, time, money, recursion, and tool calls;
• use circuit breakers;
• implement dry-run;
• implement approval gates;
• use transactional state and rollback;
• require idempotency;
• verify webhook signatures;
• use replay windows and nonces;
• monitor anomalous behavior;
• keep an incident-response playbook;
• support emergency revocation;
• preserve evidence without exposing sensitive data;
• stop and request review when ambiguity exceeds policy.

Explicitly prohibit guidance that teaches:

• CAPTCHA bypass;
• residential-proxy evasion;
• stealth fingerprint spoofing;
• bypassing paywalls;
• bypassing authentication;
• ignoring robots rules;
• evading rate limits;
• scraping private content without authorization.

8.13 Privacy, Data Governance, and User Rights

Provide jurisdiction-aware guidance without pretending to give universal legal advice.

Cover:

• data inventory;
• data classification;
• lawful basis;
• purpose limitation;
• data minimization;
• transparency;
• consent;
• retention;
• deletion;
• correction;
• access;
• portability;
• objection/opt-out;
• sensitive data;
• minors;
• cross-border transfers;
• processor/subprocessor responsibilities;
• Data Protection Impact Assessments;
• records of processing;
• automated-decision disclosures;
• human intervention;
• model and agent logging;
• privacy-preserving analytics;
• anonymization and pseudonymization;
• training-data and retrieval-data separation.

Requirements:

• public content must not be assumed to be unrestricted personal data;
• authenticated content must not be exposed through public agent surfaces;
• agent logs must minimize prompt and personal-data retention;
• users must be able to understand when an agent is acting;
• users must be able to cancel or revoke delegated action;
• high-impact decisions must expose review and appeal paths where applicable;
• private data must not be copied into llms.txt, manifests, examples, or telemetry.

8.14 Content Rights and AI Usage Preferences

Create a carefully qualified guide that distinguishes:

• crawling/access;
• indexing/search;
• live retrieval;
• summarization;
• citation;
• model training;
• fine-tuning;
• embedding;
• caching;
• execution;
• redistribution;
• commercial reuse.

Explain that one signal may not legally or technically control all uses.

Cover:

• Robots Exclusion Protocol;
• license metadata;
• terms of service;
• HTTP headers;
• page-level metadata;
• TDM preference mechanisms;
• active IETF AI Preferences work;
• content provenance;
• takedown and correction processes.

For every proposed mechanism state:

• current maturity;
• legal status;
• technical enforcement status;
• known adoption;
• conflicts or precedence;
• fallback.

Do not invent ai-train, search, or ai-input directives as normative unless an official current specification defines them.

8.15 Provenance, Attribution, and Audit

Define provenance at four levels:

1. content provenance;
2. capability-definition provenance;
3. execution provenance;
4. evidence-package provenance.

Content provenance should include:

• source;
• author;
• editor;
• reviewer;
• publication time;
• modification time;
• verification time;
• citations;
• license;
• AI-generation or AI-assistance disclosure where relevant;
• correction history;
• version;
• content hash or equivalent integrity signal.

Execution provenance should include:

• human principal;
• agent principal;
• operator/provider;
• capability ID and version;
• request ID;
• trace ID;
• authorization scope;
• consent record;
• inputs after redaction;
• output/result;
• approval;
• side effects;
• timestamps;
• retries;
• error/no-op reason;
• rollback result.

Use UAI-1 when the evidence must be portable, reviewable, and publishable beyond the runtime session.

Evaluate high-assurance use of:

• HTTP Message Signatures;
• JWS/JCS;
• C2PA for applicable media;
• W3C PROV or equivalent provenance models;
• append-only or tamper-evident logs.

Do not expose model chain-of-thought. Provide concise decision evidence and policy-based explanations instead.

8.16 Performance, Reliability, and Token Efficiency

Define performance budgets by resource type rather than repeating unsupported universal thresholds.

Cover:

• time to first byte;
• initial HTML availability;
• API latency;
• task-start latency;
• long-running task status;
• payload size;
• Markdown reduction;
• compression;
• caching;
• conditional requests;
• pagination;
• streaming;
• concurrency;
• rate limits;
• backpressure;
• timeouts;
• retry budgets;
• queue depth;
• circuit breakers;
• failover;
• stale-data handling;
• consistency;
• data freshness.

Requirements:

• use ETag and/or Last-Modified where useful;
• support conditional GET;
• return 304 Not Modified correctly;
• respect Retry-After;
• avoid unbounded result sets;
• provide bulk exports for legitimate large-volume use;
• expose freshness timestamps;
• distinguish live, delayed, cached, and estimated values;
• prevent duplicate writes;
• bound agent loops;
• provide stable fallback when optional AI-specific representations fail.

8.17 Events and Real-Time Updates

Document when to use:

• polling;
• conditional polling;
• Server-Sent Events;
• WebSockets;
• webhooks;
• WebSub;
• queues or event buses.

For event contracts include:

• event ID;
• event type;
• schema version;
• source;
• subject;
• occurrence time in UTC;
• publication time in UTC;
• sequence or ordering semantics;
• idempotency/deduplication key;
• signature;
• retry policy;
• expiry;
• replay rules;
• privacy classification;
• correlation and trace IDs.

Provide polling fallback and missed-event recovery.

8.18 Agentic Commerce

Create commerce guidance only as a specialized profile.

Cover:

• product identity and stable SKU/GTIN identifiers;
• product attributes;
• price;
• currency;
• region;
• tax;
• stock;
• availability timestamp;
• shipping methods;
• delivery estimate;
• returns;
• cancellation;
• warranty;
• quote expiration;
• cart creation and updates;
• order review;
• payment tokenization;
• fraud controls;
• order confirmation;
• refunds;
• dispute and human-support paths;
• merchant-of-record responsibility;
• human confirmation thresholds;
• purchase limits;
• delegated budgets;
• idempotency.

Evaluate current commerce and machine-payment protocols by maturity. Do not present experimental payment protocols as universally safe or supported.

No irreversible purchase should occur solely because an agent inferred intent from ambiguous language.

8.19 Observability and Operations

Define structured telemetry:

• agent provider;
• pseudonymous agent identifier where appropriate;
• human principal;
• capability;
• scope;
• status;
• no-op reason;
• HTTP status;
• latency;
• cost;
• retries;
• rate-limit events;
• approval events;
• security events;
• trace ID;
• data classification;
• retention class.

Use W3C Trace Context or a current interoperable equivalent where appropriate.

Requirements:

• do not log secrets;
• do not log full tokens;
• avoid storing full prompts by default;
• redact personal data;
• document retention;
• protect audit integrity;
• provide incident correlation;
• expose only safe health information publicly;
• separate operational metrics from user-visible readiness scores.

8.20 Governance and Lifecycle

Create public governance for the AI-Ready Web program:

• specification owner;
• editors;
• reviewers;
• accessibility review;
• security review;
• privacy/legal review;
• standards-status reviewer;
• public issue process;
• change proposal template;
• decision record;
• versioning policy;
• release cadence;
• deprecation policy;
• correction process;
• vulnerability disclosure;
• conflict-of-interest policy;
• contributor attribution;
• licensing;
• archive policy;
• appeals process for future conformance claims;
• review cadence for experimental protocols.

Every requirement must have an owner and review date.

Create a standards watchlist reviewed at least every six months, or more frequently for rapidly changing protocols.

---

9. Phase C: Required Reference Artifacts

Produce all of the following.

9.1 Machine-readable requirement registry

Create JSON and JSON Schema for the complete requirement catalog.

9.2 AI-Ready site manifest

Design a UAIX-specific, versioned manifest.

Do not assume a /.well-known/ location is appropriate. First evaluate registration and collision risk.

A candidate UAIX API representation may include:

{
  "spec_version": "0.1.0",
  "site": {
    "name": "Example",
    "canonical_url": "https://example.com/",
    "languages": ["en"],
    "last_verified_utc": "YYYY-MM-DDTHH:mm:ssZ"
  },
  "profiles": ["ARW-0", "ARW-1", "ARW-2"],
  "representations": {
    "html": true,
    "markdown": true,
    "json": true
  },
  "discovery": {
    "robots": "https://example.com/robots.txt",
    "sitemap": "https://example.com/sitemap.xml",
    "llms": "https://example.com/llms.txt"
  },
  "apis": [],
  "capability_catalogs": [],
  "identity": {},
  "usage_preferences": {},
  "provenance": {},
  "conformance_evidence": [],
  "status": {
    "self_assessed": true,
    "certified": false
  }
}

Refine this after the audit. Publish its schema and versioning rules.

9.3 Capability Surface Matrix schema

Produce the full schema described above.

9.4 OpenAPI reference

Produce a complete OpenAPI description for UAIX AI-Ready endpoints, including:

• requirement registry;
• manifest;
• validator submission;
• validator result;
• conformance-pack export;
• maturity register;
• standards watchlist;
• example catalog.

9.5 Example representations

Provide tested examples of:

• semantic HTML page;
• JSON-LD;
• Markdown alternate;
• llms.txt;
• API response;
• Problem Details error;
• asynchronous task;
• webhook;
• OAuth scope map;
• consent receipt;
• signed high-assurance request;
• Capability Surface Matrix;
• UAI-1 evidence packet.

9.6 Anti-pattern library

For each anti-pattern show:

• broken example;
• why humans are harmed;
• why agents fail;
• security impact;
• corrected example;
• validator rule.

---

10. Phase D: Implementation Guides

Write production-ready guides for at least these tracks.

10.1 WordPress

Cover:

• plugin architecture;
• custom post types or taxonomies for requirements;
• one canonical content source;
• REST API endpoints;
• OpenAPI generation;
• JSON-LD generation;
• sitemap integration;
• generated llms.txt;
• Markdown alternatives;
• HTTP headers;
• caching;
• nonce and capability checks;
• OAuth/OIDC integration where appropriate;
• safe public/private separation;
• validator integration;
• CI testing;
• migration from existing UAIX pages;
• rollback.

Do not put business logic in theme templates if a plugin or service layer is more appropriate.

10.2 ASP.NET Core

Provide complete examples for:

• content negotiation;
• Markdown result formatting;
• OpenAPI;
• JSON Schema models;
• RFC 9457-compatible Problem Details;
• authorization policies;
• scoped delegated access;
• rate limiting;
• idempotency;
• health checks;
• trace context;
• webhook signature validation;
• UTC timestamps;
• structured logging;
• integration tests.

For C# classes and interfaces:

• include [Display(Name = "Readable Field Name")] on properties;
• derive the display name from the property name;
• omit suffixes such as Id, ID, or Identifier;
• include XML documentation comments;
• include parameter descriptions on methods;
• use production-ready nullable-reference-type handling.

10.3 JavaScript / Node.js

Provide complete examples for:

• semantic SSR output;
• Express or equivalent content negotiation;
• Markdown generation;
• OpenAPI serving;
• JSON-LD;
• secure CORS;
• OAuth/OIDC middleware;
• idempotency;
• signed webhooks;
• structured errors;
• streaming;
• testing.

Explain non-standard TypeScript decisions. Prefer standard approaches.

10.4 Static sites

Cover:

• build-time generation;
• sitemap;
• structured data;
• llms.txt;
• Markdown parity;
• feeds;
• Link headers at CDN/edge;
• test automation;
• content freshness.

10.5 SPAs and hybrid applications

Cover:

• SSR/static generation;
• accessibility-tree testing;
• route-level metadata;
• hydration parity;
• no-JavaScript fallback;
• API/tool alternative;
• stable state;
• browser-agent experimental integrations;
• security boundaries.

---

11. Phase D: Validator and Readiness Assessment

Build a transparent, evidence-based validator.

11.1 Validator categories

1. Human accessibility.
2. Rendering and progressive enhancement.
3. Discovery.
4. Structured data.
5. Representation parity.
6. API quality.
7. Capability clarity.
8. Identity and consent.
9. Security.
10. Privacy and rights.
11. Provenance.
12. Performance and reliability.
13. Governance.

11.2 Test result model

Each result must include:

{
  "test_id": "ARW-DISC-001-T1",
  "requirement_id": "ARW-DISC-001",
  "url": "https://example.com/",
  "status": "pass",
  "severity": "high",
  "automated": true,
  "observed": "...",
  "expected": "...",
  "evidence": [],
  "remediation": "...",
  "standard_reference": "...",
  "tested_at_utc": "YYYY-MM-DDTHH:mm:ssZ",
  "validator_version": "0.1.0"
}

11.3 Scoring principles

• Weight mature foundations more heavily than experimental files.
• Do not award a large score merely for llms.txt.
• Do not penalize a site for omitting an experimental protocol unless the selected profile requires it.
• Accessibility failures affecting critical flows must outweigh optional discovery enhancements.
• Unsafe state-changing GET behavior is a serious failure.
• Unauthenticated high-risk actions are a critical failure.
• Contradictory HTML, API, and structured data are serious failures.
• Exposed secrets are critical failures.
• Missing human control for irreversible action is critical.
• Scoring must include confidence and manual-review requirements.
• Publish the exact formula and version.
• Allow re-testing and evidence export.
• Do not label the score “certification.”

11.4 Suggested weighting for an initial self-assessment

Refine after public review:

11.5 Manual review

Flag tests requiring:

• keyboard review;
• screen-reader review;
• cognitive accessibility review;
• data-parity review;
• authorization review;
• consent review;
• legal review;
• threat modeling;
• rollback test;
• incident-response test.

11.6 Evidence package

Export:

• human-readable report;
• JSON report;
• requirement-version map;
• screenshots only when necessary;
• DOM and accessibility-tree snapshots;
• headers;
• schemas;
• structured-data validation;
• API test results;
• UAI-1 evidence package where useful.

---

12. Phase E: Testing Strategy

Create a layered test suite.

12.1 Unit tests

Test:

• requirement registry;
• schema validation;
• content generation;
• Markdown parity;
• JSON-LD templates;
• URL generation;
• header generation;
• scoring formula.

12.2 Integration tests

Test:

• redirects;
• content negotiation;
• API authentication;
• authorization scopes;
• idempotency;
• asynchronous tasks;
• webhooks;
• rate limits;
• retries;
• revocation;
• no-op responses;
• audit evidence.

12.3 Accessibility tests

Use:

• automated accessibility tooling;
• keyboard-only testing;
• screen readers;
• zoom/reflow testing;
• focus-order review;
• color/contrast review;
• dynamic-state review;
• accessibility-tree snapshots.

12.4 Agent simulation

Simulate at least:

• basic GET-only crawler;
• JSON-capable structured fetcher;
• schema-aware API client;
• browser-assisted agent;
• authenticated workflow agent;
• multi-agent handoff;
• malicious or confused agent;
• low-context/token-constrained agent;
• agent with no support for optional protocols.

12.5 Security tests

Include:

• prompt-injection fixtures;
• SSRF;
• redirect abuse;
• callback validation;
• replay;
• CSRF;
• cross-tenant access;
• scope escalation;
• token theft simulation;
• duplicate order;
• runaway recursion;
• denial-of-wallet;
• log redaction;
• secret scanning.

12.6 Parity tests

Compare:

• canonical content model;
• HTML;
• Markdown;
• JSON;
• JSON-LD;
• sitemap;
• llms.txt;
• OpenAPI;
• capability catalog.

Fail CI when canonical facts diverge beyond an explicitly approved transformation.

---

13. Roadmap

Produce an implementation roadmap with owners, dependencies, effort, risk, and acceptance evidence.

13.1 First 30 days

• complete current-state audit;
• publish maturity taxonomy;
• create section shell;
• define route map;
• create requirement ID registry;
• fix critical accessibility and security issues;
• add cross-links from existing UAIX pages;
• document UAI-1/MCP/A2A/OpenAPI boundaries;
• establish standards-source register.

13.2 Days 31–90

• publish AI-Ready Web draft v0.1;
• publish profiles ARW-0 through ARW-3;
• release structured-data templates;
• release alternate-representation guidance;
• add generated machine-readable catalog;
• build validator MVP;
• release examples and anti-patterns;
• add WordPress and ASP.NET Core reference implementations;
• add parity tests.

13.3 Months 3–6

• add ARW-4 and ARW-5;
• publish identity, consent, and security profiles;
• publish Capability Surface Matrix schema;
• publish OpenAPI and UAI-1 mappings;
• conduct public review;
• add incident-response and threat-model materials;
• add conformance-pack export.

13.4 Months 6–12

• harden validator;
• add CMS plugins or packages;
• publish measured case studies;
• establish external reviewer program;
• add standards-watch automation;
• run interoperability events;
• revise draft based on evidence.

13.5 Months 12–24

• consider v1.0 only after public review and stable tests;
• consider certification only after governance exists;
• pursue relevant registrations or standards liaison work;
• formalize deprecation and appeals;
• expand implementation tracks;
• publish annual state-of-AI-ready-web report.

---

14. Governance Deliverables

Create:

1. editorial charter;
2. standards-status policy;
3. normative-language policy;
4. public change-request template;
5. security-disclosure policy;
6. versioning policy;
7. deprecation policy;
8. contributor policy;
9. citation policy;
10. evidence-retention policy;
11. validator privacy policy;
12. future certification prerequisites;
13. external liaison plan;
14. standards watchlist.

Future certification prerequisites must include:

• independent criteria;
• public test suite;
• reviewer qualifications;
• conflict-of-interest rules;
• evidence retention;
• renewal;
• revocation;
• appeal;
• trademark usage;
• version pinning;
• surveillance or re-test policy.

Until these exist, use “self-assessed,” “validator-tested,” or “evidence profile,” not “certified.”

---

15. Required Page Template

Use this template for every specification page:

---
title:
short_title:
summary:
audience:
status:
maturity:
normative:
spec_version:
page_version:
owner:
reviewers:
published_utc:
modified_utc:
last_verified_utc:
next_review_utc:
requirement_ids:
supersedes:
superseded_by:
related_standards:
machine_alternate:
---

# Title

## Summary

## Scope

## Definitions

## Requirements

### Requirement ARW-...

**Normative statement**

**Rationale**

**Conformance target**

**Automated test**

**Manual test**

**Required evidence**

**Exceptions**

**Security considerations**

**Privacy considerations**

**Accessibility considerations**

**Interoperability considerations**

## Implementation guidance

## Complete examples

## Anti-patterns

## Test procedure

## Maturity and support

## References

## Changelog

---

16. Output Format

Return the work in this order.

Volume 1 — Executive Audit

• current-state summary;
• route inventory;
• gap matrix;
• standards-status corrections;
• risk register;
• prioritized backlog.

Volume 2 — Architecture

• principles;
• scope boundaries;
• information architecture;
• readiness profiles;
• requirement taxonomy;
• diagrams;
• data models.

Volume 3 — Specification

• complete normative draft;
• informative guidance;
• requirement registry;
• glossary;
• reference matrix.

Volume 4 — Implementation

• page-by-page content;
• code and configuration by file path;
• WordPress implementation;
• ASP.NET Core implementation;
• JavaScript implementation;
• static-site implementation;
• migration plan.

Volume 5 — Schemas and Examples

• JSON Schemas;
• OpenAPI;
• manifest;
• Capability Surface Matrix;
• JSON-LD templates;
• complete examples;
• anti-patterns;
• fixtures.

Volume 6 — Validator and Testing

• test design;
• scoring;
• report schema;
• CI setup;
• manual test plans;
• security test matrix;
• evidence package.

Volume 7 — Roadmap and Governance

• milestones;
• owners;
• effort;
• dependencies;
• release gates;
• governance;
• public-review plan;
• standards watchlist.

When repository access is available, also provide:

• exact changed files;
• commit-sized change plan;
• migration scripts;
• test commands;
• build commands;
• rollback instructions;
• unresolved issues.

If response limits prevent one message, divide the work into numbered volumes without omitting requirements. Continue from the exact next heading.

---

17. Quality Gates

Do not declare completion until all applicable gates pass.

Content

• no unsupported claims;
• no maturity mislabeling;
• no duplicate canonical definitions;
• citations present;
• UTC dates present;
• version and status present;
• examples complete.

Accessibility

• WCAG 2.2 AA target documented;
• automated checks pass;
• manual keyboard checks pass;
• screen-reader review completed;
• focus and dynamic-state behavior verified.

Technical

• schemas validate;
• OpenAPI validates;
• JSON-LD validates;
• links pass;
• content negotiation works;
• parity tests pass;
• APIs return structured errors;
• idempotency and retries tested;
• auth scopes tested;
• no secrets exposed.

Security

• threat model complete;
• prompt-injection tests complete;
• SSRF controls verified;
• authorization boundaries tested;
• no-op behavior tested;
• rollback tested;
• rate and budget limits tested;
• logs redacted.

Governance

• owner assigned;
• review date assigned;
• changelog updated;
• maturity register updated;
• roadmap boundary clear;
• no certification overclaim.

---

18. Prohibited Shortcuts

Do not:

• merely add a chatbot;
• equate schema markup with full AI readiness;
• treat SEO as the whole problem;
• describe llms.txt as a universal standard or enforcement layer;
• rely on hidden prompts;
• create machine-only content that contradicts visible content;
• expose credentials in agent files;
• recommend wildcard CORS as a blanket solution;
• use state-changing GET as ordinary API design;
• recommend CAPTCHA or bot-defense evasion;
• claim accessibility conformance from automated scans alone;
• claim legal compliance from a technical signal alone;
• claim runtime safety from schema validation;
• claim certification when none exists;
• conflate UAI-1 with MCP, A2A, OpenAPI, OAuth, or browser APIs;
• copy speculative research claims into normative requirements;
• optimize for one model vendor;
• require a frontier model to understand basic site content;
• leave code samples untested;
• leave placeholders where a production-ready implementation can be written.

---

19. Final Instruction

Begin by auditing the current live UAIX.org site and repository. Then produce the Research Corrections and Maturity Register, the route/content inventory, and the proposed information architecture.

After those foundations are explicit, create the complete AI-Ready Web specification, implementation artifacts, validator, test suite, and roadmap described above.

Make assumptions explicit. Resolve ambiguity conservatively. Preserve human control. Prefer stable web standards. Label all emerging work honestly. Use UAI-1 for portable evidence and handoff without turning UAIX into a replacement for runtime protocols.

The final result must be detailed enough that a competent engineering and editorial team can implement the program without inventing missing requirements.