Uaix AI Ready Web Master Prompt - Source Excerpt 02 - 4. Work in Five Phases

Back to Uaix AI Ready Web Master Prompt

Summary

This source excerpt begins near 4. Work in Five Phases 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

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

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:

' ' ' text
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.