About

References and Contributors

Key links, discovery files, citation guidance, attribution, and contributor handoff for the UAIX public site.

  • Record UAIX-ABOU-0043
  • Path /en-us/about/references/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-ABOU-0043
Surface
About
Access
Public and linkable

How to use this page

Use this page when you need the main public links, discovery files, attribution details, and citation pointers for UAIX.

Handoff links

GovernanceChangelogAPI ReferenceImplementations

Public Handoff

Use this page as the durable citation, discovery, and contributor packet

Treat References and Contributors as the current public handoff surface while broader repository, issue-tracking, and contact channels remain future work.

Current truth

Carry the exact public record forward

Use this page when another reviewer needs canonical links, discovery routes, release-trail context, and attribution without relying on screenshots or unpublished notes.

Contributor intake

Requests are documentation-led today

Point contributors to the affected record family, canonical path, change type, and attached validator or implementation evidence before treating the request as ready for review.

Repository status

State the current handoff honestly

The public handoff is the published page surface, implementation tracks, packaged artifacts, and release notes, not a separately published source repository or issue queue.

Handoff links

GovernanceAuthority and release-discipline posture.ChangelogMigration posture and dated release truth.API ReferenceMachine-facing discovery and route inventory.ImplementationsPublic support lanes and release evidence.
Discovery routesCanonical public handoff endpoints
https://uiax.org/.well-known/uaix.json
https://uiax.org/sitemap.xml
http://uiax.org/wp-json/uaix/v1/catalog

Use canonical discovery routes and public machine manifests rather than screenshots, local mirrors, or query-string aliases.

Handoff map

How ownership, contributor intake, repository status, and discovery handoff work today

Use this matrix when another reviewer or contributor needs the current public handoff packet without depending on private notes, screenshots, or unpublished repositories.

Operating areaPublished nowVerify hereNot yet public
Ownership and attributionOne named public attribution plus aligned canonical pages, machine-readable records, validator behavior, implementation evidence, and the release trail establish current public truth.A broader reviewer roster, steering group, public contact desk, or certification authority is not yet published.
Contributor intakeContributor requests are documentation-led: identify the affected record family, attach the canonical path and record code, state the change type, and carry validator or implementation evidence when behavior changes.A public issue tracker, mailing list, forum, or RFC portal is still future work.
Repository and issue-tracking statusThe public handoff is the published implementation-track surface and packaged artifact family, not a separate public source repository or package registry claim.A public repository handoff, issue feed, wider SDK set, or broader implementation showcase remains future work until it is published.
Citation and discovery packetCanonical locale-prefixed pages, page-level record codes, .well-known manifests, sitemaps, and the machine-facing route catalog are the current citation and discovery surface.Do not rely on query-string aliases, screenshots, or unpublished mirrors as the public record.
Release-evidence handoffA complete handoff should carry the validator or implementation evidence, the affected canonical records, and the matching release-trail links together.A broader adoption portal, implementation showcase, or institutional contact program is not yet part of the current public handoff.

Until a public repository, issue desk, or contact channel is published, the durable handoff is the canonical site plus the named release evidence attached to it.

Public handoff packet

What a public handoff packet should contain

Use this sequence when another reviewer, contributor, or adopter needs the current public record without relying on private context.

  1. Step 1

    Link the canonical page and record code

  2. Step 2

    Carry the exact artifact set

  3. Step 3

    Attach discovery and citation routes

  4. Step 4

    State ownership and repository status honestly

  5. Step 5

    Point to the release trail and support boundary

Until a public repository or contact desk is published, the handoff packet is the site itself plus the exact artifacts, release links, and support boundaries attached to it.

Purpose

This page gathers the most important public UAIX links in one place and serves as the current attribution, discovery, and contributor handoff record for the public site.

  • Home for the public directory and institutional summary.
  • Get Started for the first implementation-oriented reading path.
  • About for mission, scope, standards posture, and practical use cases.
  • UAI-1 for the current normative specification.
  • Schemas for machine-readable definitions.
  • Registry for stable identifiers and profile handles.
  • Examples for readable exchanges and fixtures.
  • Implementations for the main implementation tracks.
  • WordPress Publication Track and .NET Bridge Track for current publication and runtime implementation tracks.
  • Tools and Validator for discovery, inspection, and validation workflows.
  • Governance and Changelog for policy, revision discipline, and release history.
  • Press and News for public-facing language, assets, and release notes.

Implementation reading path

  1. Start on Get Started for the adoption overview.
  2. Read UAI-1 for the current normative message model.
  3. Pair Schemas with Registry so field rules and profile identifiers stay aligned.
  4. Review Examples and run the Validator before calling an exchange conformant.
  5. Choose a publication or runtime path from Implementations.

Handoff map

How ownership, contributor intake, repository status, and discovery handoff work today

Use this matrix when another reviewer or contributor needs the current public handoff packet without depending on private notes, screenshots, or unpublished repositories.

Operating area Published now Verify here Not yet public
Ownership and attribution One named public attribution plus aligned canonical pages, machine-readable records, validator behavior, and release notes define the current published ownership layer. Read References and Contributors, Governance, and the Changelog together before describing a record as current public truth. A broader maintainer roster, partner list, or public governance body is not yet published here.
Contributor intake Contributor intake is documentation-led: link the canonical page path, carry the record code, state the change type, and attach validator or implementation evidence when behavior changes. Use Governance, Validator, Implementations, and the release trail as the current public intake path. A public issue tracker, mailing list, forum, or RFC portal remains future work until it is linked from the canonical site.
Repository and issue-tracking status The public handoff currently runs through implementation pages, packaged artifacts, and release notes rather than through a separately published repository or issue queue. Use Implementations, package-linked release notes, and the current public page surface before claiming a broader repository workflow. When a public repository or issue tracker is formally published, this handoff surface should point to it directly.
Citation and discovery packet Canonical locale-prefixed pages, page-level record codes, .well-known manifests, sitemaps, and the machine-facing route catalog are the current citation and discovery surface. Use References and Contributors, /.well-known/uaix.json, sitemap.xml, and the API Reference page when a reader needs durable discovery links. Do not rely on query-string aliases, screenshots, or unpublished mirrors as the public record.
Release-evidence handoff A complete handoff should carry the validator or implementation evidence, the affected canonical records, and the matching release-trail links together. Use Validator, Conformance Pack, Implementations, Governance, and News when the handoff needs both machine evidence and public narrative context. A broader adoption portal, implementation showcase, or institutional contact program is not yet part of the current public handoff.

Until a public repository, issue desk, or contact channel is published, the durable handoff is the canonical site plus the named release evidence attached to it.

Public handoff packet

What a public handoff packet should contain

Use this sequence when another reviewer, contributor, or adopter needs the current public record without relying on private context.

Step 1

Start with the clean locale-prefixed page path and the page-level record code for every affected public record.

Step 2

Carry the exact artifact set

Attach the matching schema, registry entry, example fixture, validator result, or implementation artifact instead of describing them loosely.

Step 3

Attach discovery and citation routes

Carry .well-known, sitemap, and route-catalog links so the next reader can resolve the same public state directly.

Step 4

State ownership and repository status honestly

Say what ownership, repository, issue-tracking, or contact surfaces are actually published today, and do not imply the rest.

Step 5

Point to the release trail and support boundary

Finish with the changelog, news, and implementation or conformance evidence that define what is currently supported.

Until a public repository or contact desk is published, the handoff packet is the site itself plus the exact artifacts, release links, and support boundaries attached to it.

Minimum public handoff packet

  • The clean canonical page path and page-level record code for the affected public record.
  • The relevant schema, registry entry, example fixture, validator result, or implementation-track artifact.
  • A short compatibility note stating whether the change is additive, corrective, policy-oriented, or breaking.
  • The matching discovery, sitemap, changelog, and news links when outside readers need to verify the current public state.

When citing a UAIX document, prefer the exact page path and the page-level record code shown in the document header.

Citation checklist

  1. Name the site accurately: UAIX for the website and standards venue, UAI for the standard family, and UAI-1 for the current normative specification.
  2. Link to the clean locale-prefixed page path rather than a query-string URL.
  3. Include the page-level record code from the document header when citing a specific public page.
  4. Use the discovery manifest or sitemap when automation needs to resolve the current public page inventory.
  5. Use the changelog for compatibility posture and news for the public-readable release narrative.

Concrete public artifacts and endpoints

The current public record includes both human-readable pages and machine-facing routes that outside reviewers can inspect directly.

  • Human-facing validator surface: Validator is the current browser-facing workbench for fixture review and conformance exports.
  • Machine-facing route family: /wp-json/uaix/v1/catalog, /wp-json/uaix/v1/discovery, /wp-json/uaix/v1/status, /wp-json/uaix/v1/modules, /wp-json/uaix/v1/schemas, /wp-json/uaix/v1/registry, and /wp-json/uaix/v1/examples expose the current catalog, discovery, and record inventory.
  • Machine validation route: /wp-json/uaix/v1/validate is the machine-facing JSON POST validator endpoint; treat it as automation infrastructure rather than a browsable report page.
  • Current packaged artifact family: uaix-authority-theme.zip is the active public launch theme, uaix-theme.zip remains the packaged compatibility theme, uaix-core.zip carries the core REST and standards runtime surface, uaix-modules.zip carries the redistributable module pack, uaix-bridge.zip carries the WordPress-to-.NET reference bridge, ns12-locale-router.zip carries locale-prefixed routing, and uaix-seo-sweep.zip carries canonical SEO, clean URL redirects, sitemaps, robots, and discovery-manifest delivery.

Current published ownership state

Current published attribution on this public site: Michael Joseph Kappel, MCP.

This record will expand as additional editors, reviewers, implementers, and partner organizations are formally added to the published UAIX site. Until broader roles are published, use this page as the durable attribution and handoff record rather than assuming private organizational structure.

Current published operating roles

  • Published attribution: Michael Joseph Kappel, MCP is the current named public attribution on the site.
  • Current public ownership layer: UAIX currently publishes one named attribution plus record-level governance, discovery, validator, and implementation evidence rather than a broader public roster.
  • Decision trail: when the public standard changes, the current decision record should appear on the affected canonical pages, the release trail, and the machine-readable record where relevant rather than in unpublished side channels.

Do not assume a separate public GitHub repository, issue tracker, or community forum unless it is linked from this page or another canonical UAIX page.

Current contributor intake workflow

  1. Identify the affected record family and link its clean canonical page path.
  2. Note the relevant record code, schema, registry entry, example fixture, validator evidence, or implementation-track artifact that the request touches.
  3. Describe the expected effect as additive, corrective, policy-oriented, or breaking before asking downstream readers to treat the change as current truth.
  4. Use Governance, the Changelog, and News as the public release trail when the work affects compatibility or public interpretation.
  5. Keep citation, discovery, and attribution links attached to the change request so public review does not depend on private context.

What a public review packet should include

  • The exact canonical page path and record code for every affected public record.
  • The proposed change type and a short migration note for downstream readers.
  • Linked schema, registry, example, validator, discovery, and implementation evidence when the request affects technical behavior.
  • The changelog and news links needed to show how the clarification or release entered the public record.

Current public policy status

  • Privacy: use Privacy and Data for the current published posture on public reading, discovery, and data-exposure changes. Pair it with Policy and Security and the release trail when a privacy-relevant change needs dated evidence.
  • Accessibility: use Accessibility for the current launch expectations around real text, keyboard reachability, readable code examples, and mobile-safe layouts. Treat the page as the current public statement rather than inferring a larger certification or office program.
  • Analytics and telemetry: use Analytics for the current published limits on measurement, telemetry-significant release work, and disclosure posture. Do not infer advertising, cross-site profiling, or a broader consent workflow that the site has not explicitly published.
  • Hub and release discipline: use Policy and Security for the cross-cutting hub, licensing posture, and security-significant release expectations that sit beside these dedicated pages.

Current review and contact path

This site does not yet publish a separate public issue tracker, forum, or contact email on the page surface. Until those channels are formally published, use this page, Governance, the Changelog, and News as the current public review path for contributor-facing changes, citation questions, and release-linked clarifications.

  • Link the exact page path and record code for the affected public record.
  • Attach validator or implementation evidence when the request affects conformance claims.
  • Use the discovery manifest, sitemap, and canonical page paths instead of screenshots or query-string links when sharing the current public state.
  • Do not imply broader partner, maintainer, or contact structure beyond what is explicitly published here.
  • A dedicated public contact channel and broader contributor workflow remain planned work; when they are formally published, this page should point to them directly.

Current roadmap signals

  • Use Roadmap for the forward boundary between current, next, planned, and research-track work.
  • Use Governance for the near-term trust and operating priorities attached to the public record.
  • Use Implementations to see what support is published now and what a future public track would need before it should be treated as supported.
  • Use the Changelog for the durable record of what has already changed.
  • Use News when you need the public-readable narrative around those changes.
  • Until a broader contributor portal is formally published, treat the roadmap, governance, implementation, changelog, and news records together as the current public participation surface.