Uaix AI Ready Web Master Prompt - Source Excerpt 04 - 8.7 Structured Data and Entity Clarity

Back to Uaix AI Ready Web Master Prompt

Summary

This source excerpt begins near 8.7 Structured Data and Entity Clarity 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

- representations derive from one source;
- `Content-Type` is accurate;
- `Vary: Accept` is present when representation changes by `Accept`;
- canonical identity is preserved;
- `Content-Location` is used where appropriate;
- cache behavior is correct;
- Markdown is sanitized and does not include hidden secrets;
- metadata identifies version, publication time, modification time, and source;
- links remain absolute or resolvable;
- code blocks preserve language identifiers;
- tables remain understandable;
- unsupported media types receive a correct response rather than silent corruption;
- parity is tested automatically.

Provide complete examples for:

- origin-based content negotiation;
- static `.md` alternates;
- edge/CDN transformation;
- WordPress;
- ASP.NET Core;
- Node.js.

# 8.7 Structured Data and Entity Clarity

Create a UAIX structured-data profile based on JSON-LD and appropriate Schema.org types.

Cover:

- `Organization`;
- `WebSite`;
- `WebPage`;
- `BreadcrumbList`;
- `Article` / `TechArticle`;
- `Person`;
- `SoftwareApplication`;
- `Dataset`;
- `CreativeWork`;
- `FAQPage` only when the page is genuinely an FAQ;
- `Product`, `Offer`, `Service`, `Event`, or other types where applicable;
- license;
- citations;
- `isPartOf`;
- `about`;
- `mentions`;
- `datePublished`;
- `dateModified`;
- `author`;
- `publisher`;
- stable identifiers and URLs.

Requirements:

- data must match visible content;
- dynamic values such as price and availability must be timestamped and fresh;
- one entity must not receive contradictory identifiers;
- `sameAs` must be curated;
- generated content must identify review status when required;
- structured data must not expose private fields;
- data must be validated in CI;
- content-template owners must be documented.

Create page-type JSON-LD templates and tests.

# 8.8 API Design for Agents

Use a current stable OpenAPI version and compatible JSON Schema dialect after verification.

Require:

- stable, descriptive `operationId` values;
- explicit summaries and descriptions;
- complete input and output schemas;
- required fields;
- formats;
- ranges;
- enumerations;
- examples;
- defaults only where behavior is truly defaulted;
- authentication requirements;
- authorization scopes;
- side effects;
- risk level;
- reversibility;
- rate limits;
- timeouts;
- error cases;
- deprecation state;
- version;
- support contact.

HTTP rules:

- GET and HEAD must be safe;
- PUT and DELETE must be idempotent according to their defined semantics;
- state-changing POST requests should support idempotency keys where retries are possible;
- do not use state-changing GET as general best practice;
- if UAIX retains a bounded GET-Action compatibility pattern, isolate it as a special legacy/minimal-agent profile with explicit security constraints, non-sensitive scope, anti-CSRF design, idempotency, confirmation rules, and no-op fallback;
- use conditional requests where concurrency matters;
- use cursor pagination for unstable large collections;
- expose explicit sorting and filtering;
- use accepted asynchronous responses for long operations;
- return a status URL, cancellation method, expiry, and result link;
- sign and replay-protect webhooks;
- validate callback URLs;
- limit redirects;
- use structured Problem Details based on the current RFC;
- never return stack traces or secrets;
- define retryability;
- honor `Retry-After`;
- publish deprecation and sunset information;
- keep API dates and timestamps in UTC.

CORS rules:

- do not recommend `Access-Control-Allow-Origin: *` as a default;
- use the narrowest required origins, methods, and headers;
- never combine wildcard origins with credentialed browser access;
- explain that server-to-server agents are not governed by browser CORS;
- treat CORS as a browser security policy, not API authentication.

# 8.9 Capability Surface Matrix

Expand the existing UAIX Capability Surface Matrix into a versioned machine-readable contract.

For every capability include:

- capability ID;
- human-readable name;
- action-oriented machine name;
- description;
- owner;
- lifecycle status;
- version;
- protocol bindings;
- input schema;
- output schema;
- examples;
- authentication profile;
- required scopes;
- human principal;
- agent principal;
- delegation requirements;
- preconditions;
- state dependencies;
- expected side effects;
- data classifications;
- retention;
- risk level;
- reversibility;
- dry-run support;
- confirmation requirement;
- human-review requirement;
- idempotency behavior;
- maximum execution time;
- cost or quota class;
- rate limit;
- retry behavior;
- error types;
- rollback path;
- audit fields;
- provenance requirements;
- support and incident contact;
- deprecation date;
- replacement capability.

Create:

1. a JSON Schema;
2. an HTML reference table;
3. an example catalog;
4. an OpenAPI mapping;
5. an MCP mapping where appropriate;
6. an A2A skill mapping where appropriate;
7. a browser-tool mapping for experimental WebMCP-like support;
8. a UAI-1 evidence mapping.

State clearly:

- discovering a capability is not permission to call it;
- possessing a schema is not authentication;
- authenticating is not authorization;
- authorization is not user consent;
- user consent is not proof that every downstream use is lawful;
- successful execution is not proof of correctness;
- conformance evidence is not certification of safety.

# 8.10 MCP, A2A, and Browser-Agent Integration

Create comparison and integration guidance.

For each protocol, document:

- official status and version;
- governing organization;
- purpose;
- trust boundary;
- transport;
- discovery;
- capability model;
- authentication model;
- authorization model;
- consent behavior;
- error model;
- state/task model;
- streaming;
- browser support;
- production readiness;
- fallback;
- UAIX relationship.

MCP guidance must:

- use the current official specification;
- distinguish tools, resources, prompts, and any current extension model;
- avoid assuming every AI client supports MCP;
- explain server trust and tool poisoning;
- require strict tool schemas and descriptions;
- require authorization and data-boundary review;
- map results into UAI-1 evidence only when a portable record is needed.

A2A guidance must:

- use the current official Linux Foundation project;
- verify the current agent-card/discovery path and schema;
- explain task delegation and status;
- distinguish A2A runtime coordination from UAIX evidence;
- document identity and policy gaps rather than inventing them.

WebMCP guidance must:

- label it according to its actual standards maturity;
- identify browser support accurately;
- use feature detection;
- require permission and human-in-the-loop review;
- expose only bounded functions;
- avoid leaking session state;
- provide an API fallback;
- include security and accessibility review;
- never present experimental APIs as universally available.

# 8.11 Identity, Authentication, Authorization, Delegation, and Consent

Design a zero-trust agent-access model.

Principals must be distinct:

- human user;
- agent software;
- agent operator/provider;
- client application;
- resource server;
- target service.

Requirements:

- no agent inherits a user’s unrestricted long-lived session by default;
- credentials are short-lived;
- tokens are audience-restricted;
- scopes are capability-specific;
- delegation is explicit;
- revocation is available;
- token storage is protected;
- refresh behavior is bounded;
- public clients use PKCE where appropriate;
- service credentials are not used as substitutes for user delegation;
- client-credentials grants are limited to the client’s own authority;
- high-risk actions require step-up authentication or explicit human confirmation;
- identity and authorization failures trigger no-op;
- replay protection is implemented;
- confused-deputy scenarios are tested;
- users can inspect and revoke active agent grants;
- consent is purpose-specific and time-bounded;
- consent records identify data, action, purpose, agent, operator, scope, expiry, and revocation route;
- privacy notices explain agent access;
- audit logs correlate user, agent, token, scope, capability, result, and approval.

Evaluate appropriate use of:

- OAuth 2.0;
- OpenID Connect;
- PKCE;
- token exchange;
- sender-constrained tokens;
- mutual TLS;
- DPoP;
- WebAuthn/passkeys for human approval;
- HTTP Message Signatures;
- verifiable credentials.

Do not mandate every mechanism. Define risk-based profiles.

# 8.12 Security and No-Op Safety

Create a detailed threat model that includes: