联系与评审

Purpose#

联系与评审 is the dedicated public operating path for launch-stage UAIX questions, contribution packets, change proposals, and release-linked review notes. It turns the contributor guidance that was previously scattered across governance, references, roadmap, and changelog pages into one route.

Direct contact#

For UAI-1, AI 记忆, 项目交接, 代理文件交接, contribution packets, or implementation-review questions, contact Michael Kappel directly at Michael.Kappel@Protocol5.com or 1 (630) 362-7576. You can also start from MichaelKappel.com or LinkedIn.

Professional background#

Michael Kappel is the published UAIX maintainer and principal author behind the current UAI-1 public record. He is a senior software engineer and software architect with more than two decades of experience delivering enterprise web systems, modernizing complex legacy platforms, designing scalable application architectures, and raising software quality across .NET, SQL Server, TypeScript, JavaScript, cloud, and AI-assisted engineering environments.

His background spans ASP.NET Core, C#, Web API, Razor Pages, EF Core, ADO.NET, SQL Server, semantic search, OpenAI API work, LLM tooling, automated testing, performance optimization, technical mentoring, and durable AI-readable project memory. He also holds a broad portfolio of Microsoft professional credentials, including developer, database, Azure, and application-platform certifications. This public profile intentionally summarizes the professional authority behind UAIX without listing former employers or private client histories.

当前 review intake path#

Use this page as the public intake checklist before a change becomes launch truth. UAIX does not yet publish a separate public issue tracker, forum, or repository queue on the site surface, so review packets should stay tied to the contact details above, canonical pages, machine-readable artifacts, validator evidence, and the dated release trail.

1. Identify the affected record family: specification, schema, registry, example, validator, implementation, governance, discovery, packaging, or locale content.
2. Link the clean canonical page path and include the page-level record code when one is visible in the document header.
3. Attach the relevant machine artifact, fixture, validator result, package output, or route response when behavior changes.
4. State whether the change is additive, corrective, policy-oriented, localization-only, or breaking.
5. Update 英语, zh-CN, French, and Spanish public copy together when the affected surface is visible to localized readers.
6. Record launch-facing changes through 变更日志 and News when outside readers need a dated public trail.

Contributor guidelines#

• Use UAI-1, 模式, 注册表, 示例, and the 验证器 as the technical baseline before proposing protocol behavior.
• Use 路线图 when the proposal affects future support language, bridge evidence, compact transfer, conformance maturity, developer tooling, or governance expansion.
• Use Governance and 政策与安全 when the change affects ownership, release discipline, privacy, accessibility, analytics, licensing, or security posture.
• Use Implementations when a proposal affects packaged software, runtime mapping, release evidence, or support-claim scope.
• Do not describe a local experiment, single passing validator result, unpublished implementation, or private note as current public support until the page copy, machine artifact, evidence, and release trail agree.

Change proposal template#

Record family:
Canonical path:
Record code:
Change type:
Expected public effect:
证据 attached:
验证器 or package result:
Locale copy impact:
发布版本-trail update:
Owner or reviewer:
Open questions:

Review windows and decision trail#

During pre-launch, UAIX remains a focused single-publisher standards record. The current named public attribution and the canonical site records are the decision trail; broader reviewer rosters, public voting, certification, or partner governance should not be implied until they are published.

• Decision rights: current launch decisions are published by updating canonical pages, machine artifacts, and release records together.
• Review window: a change should stay planned until the affected public page, route, validator expectation, package evidence, and locale copy can be reviewed as one packet.
• 发布版本 cadence: pre-launch changes are release-note-led rather than calendar-led; compatibility-affecting changes should receive a dated changelog entry.
• Public comments: a comment becomes part of the public record when its disposition is reflected in an updated canonical page, roadmap item, changelog entry, news summary, validator expectation, or implementation record.

What to include before launch review#

• Canonical page and route links, never query-string aliases or screenshots as the source of truth.
• Machine-facing route responses when the change affects API 参考, discovery, roadmap, adoption kit, conformance pack, schemas, registry, examples, or validation.
• Package build, smoke-test, launch-audit, or implementation-track evidence when the change affects distributable software.
• Updated zh-CN content when public localized readers will see the new page, route, or release statement.

下一步 step#

Start with 引用 and Contributors for discovery and attribution context, use this page to assemble the review packet, then carry the public decision through Governance, 路线图, 变更日志, and News as needed.