Governance

Why governance is part of implementation#

UAIX governance keeps UAI and UAI-1 public, versioned, redistributable, and implementation-ready. Governance is part of the standard surface because compatibility, review, and change discipline shape whether downstream teams can trust a release.

What implementers should watch#

• Public review of normative text, schemas, examples, and changelog entries.
• Stable identifiers, durable canonical paths, and versioned release records.
• Clear compatibility statements for specification, schema, validator, and package changes.
• Public notes that explain how release decisions affect implementers and downstream publishers.

Current public governance state#

UAIX currently governs UAI-1 through the published record itself: normative pages, schemas, registry entries, example fixtures, validator behavior, implementation-track evidence, changelog entries, and public news notes.

The public site currently names one published attribution on References and Contributors. Broader named maintainer and reviewer rosters, a dedicated public contact channel, and a more plural governance body remain planned work rather than completed public structure.

Current published authority model#

• Named public attribution: the current published attribution is Michael Joseph Kappel, MCP, as listed on References and Contributors.
• Current governance reading: treat today’s public surface as a single-publisher standards record with visible release discipline, not yet as a finished multi-stakeholder standards body.
• Current decision rights on the public surface: current truth is whatever has been aligned across the canonical pages, machine-readable records, validator expectations, and release trail.
• What is not yet claimed: UAIX does not yet claim a broader published reviewer roster, advisory board, public contact desk, or formal certification program.

Current public participation model#

UAIX participation is currently documentation-led and release-note-led. The site itself is the main public review surface rather than a broad member portal, forum, or contact center.

• Use References and Contributors for attribution, discovery, citation, and contributor-handoff context.
• Use the Validator and the published examples as the hands-on review path for conformance questions.
• Use the Changelog and News when a proposed change affects compatibility, interpretation, or release posture.
• Use Implementations when public review needs packaging or runtime evidence tied back to the current record.

Current public policy posture#

UAIX treats privacy, accessibility, analytics, and security-significant release behavior as part of the launch-stage trust surface. The current posture now includes the hub on Policy and Security plus dedicated child pages for Privacy and Data, Accessibility, and Analytics.

• Privacy: public standards pages, discovery records, and validation guidance should remain usable without implied account walls or unpublished intake flows. If a release changes public data exposure, form collection, or telemetry-relevant behavior, record that change through Privacy and Data, the release trail, and observable site behavior.
• Accessibility: current public expectations include readable real text, contrast-safe presentation, keyboard-reachable interactions, and mobile-safe layouts across the launch surface. When a release changes templates, navigation, validator workflows, or downloadable records, manual accessibility QA should travel with the release evidence and the Accessibility posture.
• Analytics and telemetry: current public analytics posture is limited to what is explicitly published on the site. Do not imply a broader analytics disclosure, consent, or measurement program that has not yet been published, and use Analytics for the current public boundary.
• Policy discipline: keep policy language aligned with discovery files, validator behavior, front-end behavior, the policy hub, the dedicated governance child pages, and release notes so the trust surface remains reviewable.

Current public policy coverage#

• Published now: a governance-led posture for privacy, accessibility, analytics-significant changes, security-significant release checks, and trust-affecting behavior.
• Dedicated trust surfaces: use Policy and Security for the hub, licensing posture, and security-significant release discipline; use Privacy and Data, Accessibility, and Analytics for the current public statements in each area.
• Still future work: broader standalone consent, contact-center, partner, or institutional legal-program surfaces beyond what the site explicitly publishes today.
• How to verify current posture: read this page with the policy hub, the dedicated governance child pages, References and Contributors, the front-end launch surface, root discovery files, and the public release trail.

Current release discipline#

• Update the affected canonical page, machine-readable record, example fixture, validator expectation, and implementation note together when the change touches them.
• Record the change type and migration posture on the Changelog before asking downstream teams to treat the new state as current.
• Use News when the same change also needs a public-readable release summary or operating-context explanation.
• Keep validator or implementation evidence attached when the release changes conformance, discovery, policy, or runtime behavior.

Change proposal workflow#

1. Identify the affected record family: specification prose, schema, registry entry, example fixture, validator behavior, implementation-track package, or discovery metadata.
2. Describe the compatibility effect as additive, corrective, policy-oriented, or breaking.
3. Update the affected public records together so prose, machine-readable records, examples, and validator expectations do not diverge.
4. Attach validator or implementation evidence when the change affects conformance claims.
5. Publish the migration posture through the changelog and use news when the change also needs a public-readable summary.

Compatibility labels#

• Additive: new guidance, profile metadata, examples, or implementation-track notes that do not invalidate existing conformant usage.
• Corrective: clarifications or fixes that align the public record with already intended behavior.
• Policy-oriented: governance, safety, citation, or publication-process changes that affect how the standard is interpreted or maintained.
• Breaking: changes that require downstream implementations, validators, schemas, or citations to update before claiming current conformance.

Conformance and assurance#

UAIX treats conformance profiles, validator checks, test fixtures, and implementation tracks as part of how authority is earned. The goal is not only to publish a specification, but to make it testable, auditable, and operationally credible.

Near-term governance priorities#

• Publish clearer named ownership and review roles when those roles are formally part of the public record.
• Keep contributor intake, decision trails, and compatibility notes on public pages instead of private side channels.
• Keep canonical routes, discovery manifests, validator expectations, and implementation evidence aligned so trust signals stay operational.
• Turn validator exports, fixture baselines, and release records into reusable public conformance packets before claiming any broader certification surface.
• Expand toward broader public review windows and a more multi-stakeholder governance posture once the initial operating layer is stable.

Current trust and policy reference#

Use Policy and Security with this page when you need the current public statement of launch-stage trust posture across licensing, privacy, accessibility, analytics, and security-sensitive release work.

How to read the current roadmap#

• Current public priorities: keep canonical records, validator behavior, discovery routes, and implementation evidence aligned as one reviewable trust surface.
• Near-term operating work: improve contributor handoff, reusable proof packets, ownership clarity, and release-trail discipline before claiming broader ecosystem scale.
• Future-facing work: broader public contact channels, plural governance bodies, wider runtime coverage, certification surfaces, and institutional partnerships should be treated as future work unless separately published.
• Best reading today: use Roadmap for the current forward-plan boundary, then read this page, Implementations, the Changelog, and News when a roadmap item needs governance or release context.

Which public records carry governance decisions#

• The Changelog for compatibility posture, migration guidance, and record-by-record change history.
• News for the public narrative around a governance-relevant release.
• Implementations when governance choices affect packaging, publication, or runtime evidence.
• References and Contributors when discovery, citation, and attribution links must travel with the governing record.
• Press when a governance update also needs approved outward-facing language.

Safety and interpretability#

UAIX does not treat hidden or covert machine communication as a feature. UAI surfaces should prefer declared semantics, explicit profiles, provenance, logging, and reviewable exchange records so implementers can detect divergence before deployment.

Next step#

Use the Changelog for release-by-release migration notes, and use News when you need the public narrative around the change. Bring validator evidence from the Validator into both when relevant, then keep the resulting release trail connected to Implementations and References and Contributors.