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

Summary

This source excerpt begins near Master Prompt: Improve UAIX.org with a Comprehensive AI-Ready Web Specification and Implementation Program and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-21-misplaced-uaix-ai-ready-web-duplicate/UAIX_AI_Ready_Web_Master_Prompt.md.
**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-21-misplaced-uaix-ai-ready-web-duplicate/UAIX_AI_Ready_Web_Master_Prompt.md
# Master Prompt: Improve UAIX.org with a Comprehensive AI-Ready Web Specification and Implementation Program

## 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:

| Item | Claim encountered | Verified status | Governing body | Current version/date | Production recommendation | Fallback | Source |
|---|---|---|---|---|---|---|---|

### 3.4 No stale assumptions