Uaix AI Ready Web Master Prompt - Source Excerpt 06 - 9. Phase C: Required Reference Artifacts

Back to Uaix AI Ready Web Master Prompt

Summary

This source excerpt begins near 9. Phase C: Required Reference Artifacts 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

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

' ' ' json
{
  "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:

' ' ' json
{
  "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:

| Category | Weight |
|---|---:|
| Accessibility and semantic foundation | 25 |
| Rendering and representation integrity | 15 |
| Discovery and structured data | 15 |
| API and capability quality | 15 |
| Identity, consent, and security | 15 |
| Privacy, rights, and provenance | 10 |
| Governance and operational evidence | 5 |

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