Master Prompt: Improve UAIX Org With A Comprehensive AI Ready Web Specification And Implementation Program

Act as a combined:

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/aiwikis/files/raw-uaix-reports-2026-06-21-ai-ready-web-program-uaix-ai-ready-web-maste-adfbbc7d/
Source reference	raw/uaix/reports/2026-06-21-ai-ready-web-program/UAIX_AI_Ready_Web_Master_Prompt.md
File type	md
Content category	prompt
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-21T14:21:18.0732024Z
Content hash	sha256:adfbbc7d2f071cb3ba51fc82f5ede7d4401e2fb74f5ceff98b33c6fa0bdedda5
Import status	new
Raw source layer	data/sources/aiwikis/raw-uaix-reports-2026-06-21-ai-ready-web-program-uaix-ai-ready-web-master-prompt-md-adfbbc7d2f07.md
Normalized source layer	data/normalized/aiwikis/raw-uaix-reports-2026-06-21-ai-ready-web-program-uaix-ai-ready-web-master-prompt-md-adfbbc7d2f07.txt

Current File Content

Structure Preview

• Master Prompt: Improve UAIX.org with a Comprehensive AI-Ready Web Specification and Implementation Program
• Role
• 1. Mission
• 2. Required Operating Principles
• 2.1 Human-first, agent-compatible
• 2.2 Accessibility is foundational
• 2.3 Stable standards before speculative protocols
• 2.4 Explicit maturity labeling
• 2.5 No invented authority
• 2.6 Evidence over assertion
• 2.7 Least privilege and no-op safety
• 2.8 One source of truth
• 2.9 Vendor neutrality
• 2.10 Progressive enhancement
• 3. Research and Source Discipline
• 3.1 Source priority
• 3.2 Required verification categories
• 3.3 Status correction rule
• 3.4 No stale assumptions
• 4. Work in Five Phases
• Phase A — Audit
• Phase B — Architecture
• Phase C — Specification and Content
• Phase D — Implementation

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 60924
• Preview characters: 11964

# 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

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:

| Route | Purpose | Audience | Canonical status | Normative or informative | Owner | Last updated | Machine representation | Reuse decision |
|---|---|---|---|---|---|---|---|---|

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

Why This File Exists

This is a prompt or operator instruction file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is a focused source unit. Its path, headings, and metadata give an agent a retrieval handle that is smaller than loading the entire site or repository.

Structure

The file is structured around these visible headings: Master Prompt: Improve UAIX.org with a Comprehensive AI-Ready Web Specification and Implementation Program; Role; 1. Mission; 2. Required Operating Principles; 2.1 Human-first, agent-compatible; 2.2 Accessibility is foundational; 2.3 Stable standards before speculative protocols; 2.4 Explicit maturity labeling. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-840 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Master Prompt: Improve UAIX Org With A Comprehensive AI Ready Web Specification And Implementation Program",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/aiwikis/files/raw-uaix-reports-2026-06-21-ai-ready-web-program-uaix-ai-ready-web-maste-adfbbc7d/",
    "source_reference":  "raw/uaix/reports/2026-06-21-ai-ready-web-program/UAIX_AI_Ready_Web_Master_Prompt.md",
    "file_type":  "md",
    "content_category":  "prompt",
    "content_hash":  "sha256:adfbbc7d2f071cb3ba51fc82f5ede7d4401e2fb74f5ceff98b33c6fa0bdedda5",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-21T14:21:18.0732024Z",
    "import_status":  "new",
    "duplicate_group_id":  "sfg-840",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}