Governance

Principles Role Guidance

Role duties, escalation triggers, evidence requirements, and release-note expectations for applying UAIX principles without widening support claims.

  • Record UAIX-GOVR-2956
  • Path /en-us/governance/principles-role-guidance/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-GOVR-2956
Surface
Governance
Access
Public and linkable

How to use this page

Use this page to apply UAIX principles by role, trigger impact assessment, and keep release evidence aligned without widening support claims.

Review packet

Principles CharterGovernanceAI Memory Package WizardChangelog

Role Guidance

Turn principles into reviewable release work

Use this page when maintainers, contributors, reviewers, implementers, or tool builders need duties, evidence requirements, and escalation triggers for principle-bearing changes.

Maintainers

Keep public meaning aligned

When meaning changes, update pages, machine artifacts, tests, roadmap, release notes, and local .uai memory together.

Reviewers

Classify before promotion

Current, governance-review, planned, and research-track labels prevent source leads from becoming overclaims.

Tool builders

Runtimes execute elsewhere

UAIX records portable evidence and handoff structure; hosts and runtimes keep execution, credentials, authorization, and local policy.

Review packet

Principles CharterPrinciples and status classes.GovernancePublic authority and release discipline.AI Memory Package WizardGenerated package review/export surface.ChangelogDated release trail.

Use this page to turn principles into disciplined work. It tells each role how to preserve cognitive liberty, source authority, bounded agency, support-claim discipline, and public evidence without turning UAIX into a certification body, runtime, legal authority, or policy office.

Maintainer duties

  • Keep the Principles Charter, Governance, Policy and Security, Roadmap, Changelog, and machine artifacts aligned when public meaning changes.
  • Require a completed principles impact assessment for trust-significant changes or record a specific not-applicable rationale.
  • Keep current support narrower than ambition when proof is incomplete.
  • Route synthetic-standing and durable-selfhood claims to research-track unless a public process and authority model exists.

Contributor duties

  • Name the affected principle, route, artifact, evidence, and proposed support boundary.
  • Separate source material from promoted public truth.
  • Attach source paths, checksums, review notes, and rollback paths for intake-driven work.
  • Use UAIX.org when defining portable agent specification, communication, capability description, persona packets, or handoff structure.

Reviewer duties

  • Classify affected principles as current, governance-review, planned, or research-track.
  • Check that public pages, route manifests, well-known records, llms files, sitemap, conformance/evaluation artifacts, tests, and release notes agree.
  • Reject current-support wording when public proof is missing.
  • Keep symbolic continuity and bounded agency meaningful within their machine-identity frame without presenting them as biological identity, human consciousness, legal standing, or unrestricted autonomy.

Implementer and tool-builder duties

  • Use UAI-1 records for portable exchange evidence and Project Handoff or AI Memory records for project memory and handoff state.
  • Keep runtime execution, credentials, authorization, scheduling, observability, and local policy in the chosen runtime or host system.
  • Do not turn principles into hidden execution permission, credential validation, managed memory sync, or certification language.
  • Keep wizard-generated files explicit about source authority, review state, evidence ledger, conflict resolution, risk, rollback, and promotion targets.

Public readers and press duties

  • Quote current UAIX support only from canonical pages, discovery records, release notes, and machine artifacts that agree.
  • Use current, next, planned, and research-track labels when describing principles or future-facing work.
  • Keep synthetic-standing, durable-selfhood, legal-status, certification, SDK, CLI, runtime, policy-office, consent-center, and security-operations language inside the published boundary.

Prohibited conduct for standards claims

  • Do not represent source input, archive notes, screenshots, private chats, or generated summaries as current public UAIX truth.
  • Do not imply certification, endorsement, official adapter support, SDK or CLI support, runtime assurance, managed sync, legal standing, policy-office authority, consent-center operation, or security-operations coverage without matching public evidence.
  • Do not let a machine-readable artifact contradict the public page, release note, roadmap state, or local .uai handoff memory.

Escalation triggers

  • New normative requirement.
  • New schema field or validation behavior.
  • New support claim.
  • New implementation track.
  • Privacy-sensitive publication.
  • Accessibility-significant UI or content change.
  • Analytics or telemetry-significant change.
  • AI Memory template change.
  • UAI-1 conformance wording change.
  • Public claim involving human cognitive liberty, synthetic liberty, durable selfhood, certification, legal status, or runtime enforcement.
  • Support claims mention certification, endorsement, legal standing, official adapters, SDKs, CLIs, runtime assurance, hosted import validation, automatic repository writes, or automatic LLM Wiki sync.
  • A change affects lawful human thought, behavioral conditioning, viewpoint handling, ranking, profiling, consent, telemetry, or automated authority.
  • A generated package changes identity, totem, taboo, memory, receiver brief, startup packet, capability description, or handoff structure.
  • External source material conflicts with current UAIX public records or local .uai truth.
  • Research-track synthetic selfhood, machine personhood, or substrate-independent liberty language is being promoted to current copy.

Evidence requirements

  • Source path and checksum for intake-driven material.
  • Matrix row and principle status for principle-bearing changes.
  • Impact assessment or not-applicable rationale for trust-significant changes.
  • Public page and machine artifact updates when public meaning changes.
  • Focused test or lint evidence for support-claim, JSON, route, or generated-package changes.
  • Changelog, release note, roadmap, and local .uai memory update when future agents should treat the new state as current.

Release-note requirements

  • Name the affected principles and status class.
  • Name affected public routes and machine artifacts.
  • Name support boundaries and deliberate non-claims.
  • Name tests or checks run.
  • Name any planned or research-track material left intentionally unimplemented.

Review checklist

  1. Principle classification complete.
  2. Impact assessment complete or not-applicable rationale recorded.
  3. Source evidence and redaction decision recorded.
  4. Public page, machine artifact, docs, tests, roadmap, release note, and .uai memory agree where relevant.
  5. Support-claim boundary reviewed.
  6. Rollback path recorded.