Reports

Relationship Audit of AIWikis, LLMWikis, and UAIX

Dated cross-site audit synthesis for keeping AIWikis as dogfood implementation, LLMWikis as handbook blueprint, and UAIX as canonical UAI-1 authority.

  • Record UAIX-REPT-0337
  • Path /en-us/reports/relationship-audit-aiwikis-llmwikis-uaix/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-REPT-0337
Surface
Reports
Access
Public and linkable

How to use this page

Use this page as part of the current Reports public record, then follow its linked standards pages for the next step.

Relationship Audit of AIWikis, LLMWikis, and UAIX

AIWikis, LLMWikis, and UAIX are useful together only when their authority boundaries stay visible: AIWikis dogfoods and observes, LLMWikis explains and teaches, and UAIX remains canonical for UAI-1.

Publication boundary

This report summarizes cross-site audit material. It does not make AIWikis or LLMWikis a UAI-1 authority, and it does not create a new UAIX generator, hosted validator, SDK, CLI, certification, endorsement, or conformance claim.

The Layered Relationship

The audit found a coherent role model across the three sites. AIWikis.org is best understood as the implementation and dogfood layer: it can consume source packages, expose lessons learned, and retain long-term archive memory. LLMWikis.org is the handbook layer: it explains LLM Wiki practice, source policy, templates, page states, quality controls, and non-normative standards explainers. UAIX.org is the canonical protocol layer for UAI-1: it owns the specification, schemas, registry records, validator behavior, machine routes, support boundaries, roadmap, governance, and changelog.

The practical reading direction is therefore one-way for authority: AIWikis and LLMWikis may point readers toward UAIX for UAI-1 truth, but neither site replaces UAIX’s public record.

What UAIX Should Absorb

The strongest usable lesson is not that UAIX needs to publish more claims. It is that public claims must line up with observable routes, machine-readable files, and dated evidence. The audit reinforces these UAIX operating rules:

  • Discovery files named as machine-readable surfaces should return machine-readable content, not themed HTML.
  • Production examples, manifests, and fallback root assets should use canonical HTTPS UAIX URLs.
  • The public registry page, REST registry route, field registry, schemas, examples, and validator should remain visibly connected.
  • Route inventories should stay synchronized across References, API Reference, Launch Readiness, sitemaps, well-known manifests, and audits.
  • Report pages and research notes may explain rationale, but current support claims still need UAI-1 evidence, validator behavior, implementation records, roadmap status, or release notes.

What AIWikis Should Learn From UAIX

For UAI-related pages, AIWikis should be explanatory rather than normative. Each UAI or UAI-1 explainer should carry a visible canonical-source panel that points readers back to UAIX for the specification, registry, schemas, validator, roadmap, governance, and support boundary. AIWikis can be a valuable public implementation example only if its discovery files, advertised routes, manifests, source maps, package ownership language, and internal navigation agree with one another.

What LLMWikis Contributes

LLMWikis contributes editorial discipline: source-status labels, page templates, review dates, canonical-source fields, related-page routing, source policy, governance, and quality checks. UAIX should continue to treat that material as a handbook pattern, not as UAI-1 authority. The useful transfer is procedural: clear page states and source boundaries reduce drift as AI-facing documentation grows.

QA Lessons For UAIX

Audit theme UAIX acceptance rule Where to verify
Discovery and crawlability /.well-known/uaix.json, /.well-known/uai.json, robots.txt, and sitemap.xml should be directly retrievable in their intended formats. Launch-surface HTTP audit and production response checks.
Registry identity /en-us/registry/ should resolve to the public Registry page, while /wp-json/uaix/v1/registry returns the machine registry. Route identity audit, sitemap output, and API Reference links.
Protocol scheme Public production examples should not downgrade canonical UAIX routes from HTTPS to HTTP. Search metadata, launch-surface checks, generated fallback root assets, and public copy review.
Authority boundary AIWikis and LLMWikis can explain or dogfood UAI patterns, but UAIX remains the source of truth for UAI-1. Related Links, AI Memory, Project Handoff, Reports, Roadmap, and Changelog.
Package ownership UAIX-produced packages remain UAIX-owned even when sister sites consume or mirror them for evaluation. UAIX Agents Protocol, package checksums, source-package copy, and release notes.

Disposition

UAIX incorporated this audit as public relationship guidance, a Related Links update, and stronger route/discovery QA framing. The report is evidence that the three-site architecture is understandable, not evidence that every future tool, route, SDK, certification, or implementation layer is currently supported.

  • AI Memory for the broad memory framing and the LLM Wiki boundary.
  • Project Handoff for the practical repository-context transfer pattern.
  • UAI-1 for the canonical exchange contract.
  • Validator for current evidence behavior and non-certification boundaries.
  • Related Links for sibling surfaces and external context without treating them as UAIX authority.