Skip to content
wiki.fftac.org

Uaix AI Ready Web Master Prompt - Source Excerpt 07 - 12.6 Parity tests

Back to Uaix AI Ready Web Master Prompt

Summary

This source excerpt begins near 12.6 Parity tests 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

- prompt-injection fixtures;
- SSRF;
- redirect abuse;
- callback validation;
- replay;
- CSRF;
- cross-tenant access;
- scope escalation;
- token theft simulation;
- duplicate order;
- runaway recursion;
- denial-of-wallet;
- log redaction;
- secret scanning.

### 12.6 Parity tests

Compare:

- canonical content model;
- HTML;
- Markdown;
- JSON;
- JSON-LD;
- sitemap;
- `llms.txt`;
- OpenAPI;
- capability catalog.

Fail CI when canonical facts diverge beyond an explicitly approved transformation.

---

## 13. Roadmap

Produce an implementation roadmap with owners, dependencies, effort, risk, and acceptance evidence.

### 13.1 First 30 days

- complete current-state audit;
- publish maturity taxonomy;
- create section shell;
- define route map;
- create requirement ID registry;
- fix critical accessibility and security issues;
- add cross-links from existing UAIX pages;
- document UAI-1/MCP/A2A/OpenAPI boundaries;
- establish standards-source register.

### 13.2 Days 31–90

- publish AI-Ready Web draft v0.1;
- publish profiles ARW-0 through ARW-3;
- release structured-data templates;
- release alternate-representation guidance;
- add generated machine-readable catalog;
- build validator MVP;
- release examples and anti-patterns;
- add WordPress and ASP.NET Core reference implementations;
- add parity tests.

### 13.3 Months 3–6

- add ARW-4 and ARW-5;
- publish identity, consent, and security profiles;
- publish Capability Surface Matrix schema;
- publish OpenAPI and UAI-1 mappings;
- conduct public review;
- add incident-response and threat-model materials;
- add conformance-pack export.

### 13.4 Months 6–12

- harden validator;
- add CMS plugins or packages;
- publish measured case studies;
- establish external reviewer program;
- add standards-watch automation;
- run interoperability events;
- revise draft based on evidence.

### 13.5 Months 12–24

- consider v1.0 only after public review and stable tests;
- consider certification only after governance exists;
- pursue relevant registrations or standards liaison work;
- formalize deprecation and appeals;
- expand implementation tracks;
- publish annual state-of-AI-ready-web report.

---

## 14. Governance Deliverables

Create:

1. editorial charter;
2. standards-status policy;
3. normative-language policy;
4. public change-request template;
5. security-disclosure policy;
6. versioning policy;
7. deprecation policy;
8. contributor policy;
9. citation policy;
10. evidence-retention policy;
11. validator privacy policy;
12. future certification prerequisites;
13. external liaison plan;
14. standards watchlist.

Future certification prerequisites must include:

- independent criteria;
- public test suite;
- reviewer qualifications;
- conflict-of-interest rules;
- evidence retention;
- renewal;
- revocation;
- appeal;
- trademark usage;
- version pinning;
- surveillance or re-test policy.

Until these exist, use “self-assessed,” “validator-tested,” or “evidence profile,” not “certified.”

---

## 15. Required Page Template

Use this template for every specification page:

' ' ' markdown
---
title:
short_title:
summary:
audience:
status:
maturity:
normative:
spec_version:
page_version:
owner:
reviewers:
published_utc:
modified_utc:
last_verified_utc:
next_review_utc:
requirement_ids:
supersedes:
superseded_by:
related_standards:
machine_alternate:
---

# Title

## Summary

## Scope

## Definitions

## Requirements

### Requirement ARW-...

**Normative statement**

**Rationale**

**Conformance target**

**Automated test**

**Manual test**

**Required evidence**

**Exceptions**

**Security considerations**

**Privacy considerations**

**Accessibility considerations**

**Interoperability considerations**

## Implementation guidance

## Complete examples

## Anti-patterns

## Test procedure

## Maturity and support

## References

## Changelog
' ' ' 

---

## 16. Output Format

Return the work in this order.

### Volume 1 — Executive Audit

- current-state summary;
- route inventory;
- gap matrix;
- standards-status corrections;
- risk register;
- prioritized backlog.

### Volume 2 — Architecture

- principles;
- scope boundaries;
- information architecture;
- readiness profiles;
- requirement taxonomy;
- diagrams;
- data models.

### Volume 3 — Specification

- complete normative draft;
- informative guidance;
- requirement registry;
- glossary;
- reference matrix.

### Volume 4 — Implementation

- page-by-page content;
- code and configuration by file path;
- WordPress implementation;
- ASP.NET Core implementation;
- JavaScript implementation;
- static-site implementation;
- migration plan.

### Volume 5 — Schemas and Examples

- JSON Schemas;
- OpenAPI;
- manifest;
- Capability Surface Matrix;
- JSON-LD templates;
- complete examples;
- anti-patterns;
- fixtures.

### Volume 6 — Validator and Testing

- test design;
- scoring;
- report schema;
- CI setup;
- manual test plans;
- security test matrix;
- evidence package.

### Volume 7 — Roadmap and Governance

- milestones;
- owners;
- effort;
- dependencies;
- release gates;
- governance;
- public-review plan;
- standards watchlist.

When repository access is available, also provide:

- exact changed files;
- commit-sized change plan;
- migration scripts;
- test commands;
- build commands;
- rollback instructions;
- unresolved issues.

If response limits prevent one message, divide the work into numbered volumes without omitting requirements. Continue from the exact next heading.

---

## 17. Quality Gates

Do not declare completion until all applicable gates pass.

### Content

- no unsupported claims;
- no maturity mislabeling;
- no duplicate canonical definitions;
- citations present;
- UTC dates present;
- version and status present;
- examples complete.

### Accessibility

- WCAG 2.2 AA target documented;
- automated checks pass;
- manual keyboard checks pass;
- screen-reader review completed;
- focus and dynamic-state behavior verified.

### Technical

- schemas validate;
- OpenAPI validates;
- JSON-LD validates;
- links pass;
- content negotiation works;
- parity tests pass;
- APIs return structured errors;
- idempotency and retries tested;
- auth scopes tested;
- no secrets exposed.

### Security

- threat model complete;
- prompt-injection tests complete;
- SSRF controls verified;
- authorization boundaries tested;
- no-op behavior tested;
- rollback tested;
- rate and budget limits tested;
- logs redacted.

### Governance

- owner assigned;
- review date assigned;
- changelog updated;
- maturity register updated;
- roadmap boundary clear;
- no certification overclaim.

---

## 18. Prohibited Shortcuts

Do not:

- merely add a chatbot;
- equate schema markup with full AI readiness;
- treat SEO as the whole problem;
- describe `llms.txt` as a universal standard or enforcement layer;
- rely on hidden prompts;
- create machine-only content that contradicts visible content;
- expose credentials in agent files;
- recommend wildcard CORS as a blanket solution;
- use state-changing GET as ordinary API design;
- recommend CAPTCHA or bot-defense evasion;
- claim accessibility conformance from automated scans alone;
- claim legal compliance from a technical signal alone;
- claim runtime safety from schema validation;
- claim certification when none exists;
- conflate UAI-1 with MCP, A2A, OpenAPI, OAuth, or browser APIs;
- copy speculative research claims into normative requirements;
- optimize for one model vendor;
- require a frontier model to understand basic site content;
- leave code samples untested;
- leave placeholders where a production-ready implementation can be written.

---

## 19. Final Instruction

Begin by auditing the current live UAIX.org site and repository. Then produce the Research Corrections and Maturity Register, the route/content inventory, and the proposed information architecture.

After those foundations are explicit, create the complete AI-Ready Web specification, implementation artifacts, validator, test suite, and roadmap described above.

Make assumptions explicit. Resolve ambiguity conservatively. Preserve human control. Prefer stable web standards. Label all emerging work honestly. Use UAI-1 for portable evidence and handoff without turning UAIX into a replacement for runtime protocols.

The final result must be detailed enough that a competent engineering and editorial team can implement the program without inventing missing requirements.