Skip to content

Conformance Pack

What this pack is

The UAIX conformance pack is the reusable machine-readable release packet for the current public UAI-1 record. It keeps the catalog, discovery manifest, schemas, registry, field order, examples, guidance records, roadmap record, implementation-evidence checklist, conformance fixture pack, and pack-level launch pointers together so another reviewer can reconstruct the same public baseline without private notes.

What belongs in the pack

  • The current catalog and discovery surface.
  • The active schema, registry, field-registry, example, transport, trust, conformance, error, and roadmap records.
  • The public entry points for the validator, API reference, roadmap, and current launch-support pages.
  • An implementation-evidence checklist for implementation identity, supported profile scope, validator evidence, machine-route and cache posture, trust and threat boundary, locale/accessibility reader QA, fixtures, release trail, and support boundary.
  • A conformance fixture pack with positive keyed, minified-keyed, and keyless checks, canonical-hash equivalence metadata, and negative current-boundary cases for schema, trace, trust, keyless-shape, keyless-overflow, and unsupported-alias behavior.
  • A quickstart sequence for turning one published profile into a reviewable release packet.

How teams should use it

  1. Start with one profile and one validator-backed proof run.
  2. Run the fixture pack and complete the implementation-evidence checklist before describing the result as a release-ready support claim.
  3. Attach the pack when that proof needs to travel into implementation review, launch QA, or release evidence.
  4. Keep the pack aligned with Implementations, the Changelog, News, and the Roadmap whenever public support posture changes.
  5. Do not describe the pack itself as a certification or badge program; it is the reusable evidence packet behind those future-facing ideas.

When to rerun the pack

  • Rerun it when schemas, registry entries, field order, examples, validator policy, transport guidance, trust-channel wording, error codes, implementation version, public route headers, or support language changes.
  • Rerun it before turning private QA evidence into a public support claim, migration note, implementation page, or release announcement.
  • Rerun it when a bridge, plugin, package, or consuming site changes the way it maps UAI-1 records into runtime behavior.

What the pack cannot prove by itself

  • It is not certification, endorsement, compliance approval, production availability evidence, security review, privacy review, or a guarantee that future UAI-1 changes will remain compatible.
  • It does not replace implementation-specific tests, threat modeling, accessibility checks, localization review, operational monitoring, or release rollback planning.
  • It must stay attached to a named implementation scope, dated release trail, and explicit non-claims.

Live reusable release packet

Use the published pack below when you want the current JSON bundle, fixture expectations, and profile-by-profile inventory that go with it.

[uaix_conformance_pack][uaix_release_readiness_map context=”conformance”]

Next step

Continue to Policy and Security for the current public trust posture, return to API Reference when you need the route-level machine contract behind the pack, or open the Roadmap when a support claim depends on future-work boundaries.