Uaix AI Ready Web Master Prompt - Source Excerpt 03 - 7.3 Requirement identifiers
Back to Uaix AI Ready Web Master Prompt
Summary
This source excerpt begins near 7.3 Requirement identifiers 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
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:
' ' ' json
{
"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: