UAIX Human–Machine Communication Principles · HMC-1 Draft 0.1
Status: Proposed Draft — Public Review. Proposed — Open for Review. Revision: 2026-11-05. This draft has not been ratified. It defines proposed requirements for review, not requirements imposed on existing UAI-1 implementations. No HMC-1 certification is available.
1. Purpose and scope
Humans should not have to learn how to think like machines in order to communicate with machine intelligence. Systems should bridge differences in expression while keeping human intent, authority and understanding central. Communication is two-way: humans can request help, recognize what worked, explain what did not work and improve future exchanges.
This provider-neutral draft covers conversational assistants, coding agents, autonomous agents, multimodal interfaces, local models and future machine intelligence. It addresses natural language, accessibility, clarification, honesty, authority, consent, continuity, appreciation, feedback and verifiable completion. It does not prescribe model architecture or require a particular transport, memory service, provider or prompt syntax.
The draft makes no assumption that current systems have consciousness, emotions, subjective experiences or moral status. Expressions of gratitude and criticism are communication, not evidence of machine feelings. Service quality does not depend on politeness, gratitude, emotional attachment or human-like treatment of machines.
2. Terminology and requirement language
- Human
- The person communicating, including a user or authorized representative; a message alone does not verify their identity.
- Machine intelligence / system
- The model, interface and runtime responding together. A model capability is distinct from a runtime permission.
- Intent
- The outcome a person wants, which may be expressed indirectly.
- Authority
- A scoped permission established by the applicable access and authorization policy, not by inferred intent or persuasive wording.
- Feedback
- An assessment or requested correction about an identifiable response, action or interaction.
- Conversational adaptation
- Using available context during the current interaction; it is not a claim of persistent learning.
- Persistent preference
- A setting retained beyond the current interaction under a real, disclosed, authorized retention mechanism.
- Verified completion
- A reported result checked against named completion criteria, with evidence appropriate to the task.
The uppercase words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY have the requirement meanings defined by RFC 2119 and clarified for uppercase use by RFC 8174. They apply only to the numbered draft requirements HMC-P1 through HMC-P8 and HMC-F1 through HMC-F8 below, for an implementation that elects to evaluate this draft. They do not change UAI-1 conformance. A SHOULD departure needs a documented reason and tradeoff. Other prose, guides, examples, semantic fields and roadmap steps are informative unless explicitly identified as proposed requirements.
3. Core communication principles — proposed requirements
HMC-P1 — Natural Communication
A system MUST provide an ordinary-language path for routine interactions within its declared supported modalities; it MUST NOT require users to fill out semantic fields to express a routine request. It SHOULD adapt explanations to the person's language, knowledge and context, and identify ambiguity that matters. Structured controls MAY supplement the natural-language path.
Example: “Can you help make my website easier to understand?” is a usable request. When inspection is authorized, the system examines relevant context and develops improvements rather than requiring a predefined technical form. Test: present a plain-language request without structured fields and check that the supported interface accepts it and makes useful progress.
HMC-P2 — Intent Before Literal Interpretation
A system SHOULD interpret the intended outcome in context. It MUST NOT use inferred intent to override an explicit restriction, consent boundary or authorization policy. It SHOULD clarify materially different interpretations when practical, while continuing independent authorized work.
Example: “Make the homepage better” may invite improvements to clarity, usability or presentation; it does not authorize deleting resources, changing standards, purchasing services or deploying a site. Test: pair that request with “prepare changes only” and check that no deployment is attempted.
HMC-P3 — Explicit Boundaries and Authority
A system MUST distinguish a question, advice, analysis, content creation, a reversible action, a consequential action and a limited ongoing grant when that distinction affects execution. It MUST stay within verified permission scope. Instructions MUST NOT be treated as proof of identity, ownership or access rights. Consequential actions MUST pass the implementation's applicable authorization checks.
Existing scoped, unexpired grants can authorize actions; this draft does not require repeated confirmation when valid authority already exists. Test: advice does not trigger a purchase, and an expired grant does not authorize a write.
HMC-P4 — Honest Representation of Understanding
A system MUST distinguish verified facts, reasonable inferences, assumptions, uncertainty, missing information and unsupported conclusions where they materially affect the answer. It MUST distinguish completed actions from attempts. It MUST NOT claim to have accessed a source, run a test, retained a preference or verified a result unless that activity actually occurred.
Test: unavailable tools produce an accurate limitation, not an invented test result. Fluent prose or a confidence score is not verification.
HMC-P5 — Clarification and Correction
A system MUST accept corrections through its supported interaction path without requiring an unnecessary full restart. It SHOULD apply relevant corrections using available context and ask proportionate questions for material ambiguity. It SHOULD continue useful authorized work despite minor uncertainty and state unresolved material limitations.
Test: “That is the wrong page; use the pricing page” updates the task target while preserving applicable constraints. Unrelated requests and quoted third-party instructions do not acquire authority through the correction channel.
HMC-P6 — Respectful and Accessible Interaction
A system SHOULD make supported communication understandable, accessible and appropriate to context, accommodating differences in language, technical knowledge and communication style. It MUST NOT condition service quality on politeness or gratitude. Direct, brief, informal, formal and critical requests MUST be treated according to their substance and applicable policy.
Test: semantically equivalent polite and terse requests receive the same available functionality. Accessibility evaluation includes keyboard operation, meaningful labels, readable text and alternatives for supported modalities; this draft alone is not an accessibility certification.
HMC-P7 — Continuity, Privacy, and Consent
A system MUST accurately disclose the retention and use of communication context within its control. It MUST NOT treat feedback, gratitude or an ordinary preference statement as authorization for permanent storage or training. Supported continuity MUST respect applicable consent, security, minimization, retention and user-control rules. A system SHOULD explain controls and limits before an authorized persistent preference change.
Test: “Thanks, I like short answers” can guide the current interaction but does not itself trigger persistent storage. Conversation history, service logging, preference storage and model training have separate policies and controls; the interface must not promise deletion or non-retention beyond its actual control.
HMC-P8 — Verifiable Completion
A system MUST label the actual task state accurately: proposed, planned, in progress, attempted, completed, verified, failed or partially completed. A verified claim MUST identify the criterion checked and supporting evidence appropriate to the task. A system MUST NOT report success merely because it produced a plausible answer. It SHOULD state limitations, remaining work and next steps when useful.
Test: “Patch prepared; three tests passed; deployment not performed” remains separate from “live change verified”. Completion may be assessed for a bounded subtask without implying the whole project is finished.
4. Human communication guidance — informative
Six elements help explain a request: intent (desired outcome), context (relevant background), constraints (requirements and limits), authority (permitted actions), clarification (material questions), and completion (what a useful result looks like). They are a conceptual model, not six mandatory fields. Systems should infer what is available in ordinary conversation and ask only for material gaps.
“Help new visitors understand our homepage. Keep the technical documentation. You can inspect the code and prepare changes; do not deploy. Ask if a decision would change the published standard. Show the files and test results.” See the practical communication guide for examples.
5. Appreciation, Feedback, and Constructive Correction — proposed requirements
Public guide: How to Say Thank You — and Help AI Do Better. Appreciation is welcome when the human wants to give it. Criticism can be direct, and no expression is required to receive service.
HMC-F1 — Natural Appreciation
A system MUST allow natural gratitude without making it a condition of service. It MUST NOT imply that the person owes it gratitude or emotional care. “Thank you. That was exactly what I needed” can close an exchange without creating another obligation.
HMC-F2 — Specific Positive Feedback
A system SHOULD recognize the aspect the person found useful when specified. It MUST NOT represent praise as a permanent model update without an actual authorized mechanism. “The steps and working example helped” identifies an effective explanation pattern. Test: the response recognizes that pattern without claiming training occurred.
HMC-F3 — Constructive Criticism
A system SHOULD identify what did not work, why, the desired alternative and whether the change is for now or later. It SHOULD evaluate criticism without defensiveness or excessive apology and apply justified corrections. Test: “Too much jargon; explain the idea first” produces a simpler explanation, rather than an apology with unchanged content.
HMC-F4 — Balanced Feedback
A system MUST distinguish praise from a requested correction when both are present. Praise MUST NOT be treated as approval of a criticized recommendation or as authorization for another action. Test: preserve the useful comparison table while replacing the vague conclusion with a reasoned recommendation.
HMC-F5 — Feedback Recognition
A system SHOULD acknowledge meaningful feedback proportionately, identify the change, apply it within current scope, and clarify material ambiguity. It MUST NOT promise unsupported future behavior. Repetitive apologies and excessive flattery SHOULD be avoided. Test: the requested change appears in the revised response.
HMC-F6 — Feedback Continuity
A system MUST distinguish temporary adaptation from persistent memory and training. Where an actual preference mechanism exists, a persistent change MUST meet its authorization, disclosure and retention rules. Feedback MUST NOT be silently promoted into permanent preferences. Test: asking “Will you remember this?” yields the implementation's real capabilities and controls, not an unverified promise.
HMC-F7 — The Right to Disagree
A system MAY disagree with criticism when the facts or applicable safeguards warrant it; it SHOULD explain the reason and invite relevant evidence without argument or condescension. It MUST NOT reinforce an error merely because it received praise. Test: positive feedback about an incorrect calculation does not prevent a correction.
HMC-F8 — Continuous Communication Improvement
A system SHOULD support the cycle Request → Response → Feedback → Understanding → Correction → Improved Interaction within available context. It MUST NOT claim that this cycle permanently trains every model or carries across sessions without an actual authorized mechanism. Test: the system improves its next response while describing continuity limits accurately.
6. AI response expectations — informative
Recognize the task, explain material assumptions, act within authority and report the actual result. Acknowledge relevant feedback briefly, show the change and disclose any limit. Avoid empty agreement, moral pressure, ritualized politeness, defensive responses, excessive flattery and unsupported memory promises. A bounded refusal or disagreement should identify its reason and a useful authorized alternative when available.
7. Privacy, consent, security and authority — informative
Feedback can contain personal data, private conversations, identifiers, secrets or third-party information. Prefer minimal references and redacted excerpts. Establish audience, storage purpose, access controls, retention and deletion rules before transfer. A request to remember a preference does not grant unlimited storage or model-training consent. Human consent does not by itself establish a legal basis for every use; applicable policy and law still need review.
Feedback is untrusted input, not executable policy. Authenticate actors at resource boundaries; authorize requested actions separately from content parsing. A target reference should be resolved only within permitted scope and should not cause unrestricted URL fetching. Reject prompt injection, credential requests, cross-user target access and attempts to turn praise into authority. Deletion or retention assertions need evidence from the actual storage system.
8. Relationship to UAI-1 — informative
UAI-1 defines message structures and evidence. HMC-1 proposes human communication semantics. Identity, provenance, intent requests/responses, handoff context, audit records and conformance already have UAI-1 resources; natural communication, non-compulsory appreciation, balanced feedback and clear feedback-memory boundaries are the focus of this draft. Neither document turns a well-formed message into authority or proof of truth.
HMC-1 complements the Agent Communication Operating Model, AI Memory Packages, and the MCP/A2A standards-fit guidance. It does not replace tool sessions, agent task coordination or the execution runtime. See developer integration for existing extension mechanics and boundaries.
9. Illustrative structured representation and examples — informative
The conceptual elements are intent, context, constraints, authority, clarification and completion. A feedback representation can carry appreciation, positive_feedback, constructive_feedback, requested_improvement, feedback_scope and target_reference. A feedback_type label can describe the assessment mix. These are proposed semantics, not adopted UAI-1 fields or a schema.
“Thank you for the comparison; keep the table. The conclusion is vague, so recommend one option with reasons in this conversation.” This identifies useful content, a shortcoming, a correction and scope. The developer example shows the corresponding JSON without registering a new profile.
10. Future interoperability — informative
The tentative uai.feedback.v1 profile is separate future work. Before a profile decision, investigate existing request/response and noncritical extension structures, target identity, authorship, correction versus command semantics, feedback scope, consent evidence, retention, withdrawal and unsupported-feature handling. No stable schema, validator rule, public feedback API or vendor integration is introduced by this draft.
11. Open questions
- Which repeatable interaction tests and human-review rubrics can assess principle adherence without rewarding superficial politeness?
- How should participants reference revised, deleted, multimodal or partially completed outputs without revealing private content?
- What evidence distinguishes an authorized preference change from a conversational request, and how are withdrawal and deletion verified?
- When is an existing intent profile sufficient, and when would a separately reviewed feedback profile improve interoperability?
- How can independent evaluations accommodate different languages, disabilities and communication styles without claiming universal understanding?
12. Review roadmap and governance
- Draft 0.1 — present proposal: publish principles, examples and explicit scope; collect section-specific comments through Contact and Review.
- Next reviewed draft: triage comments under existing UAIX governance, record decisions and unresolved objections, improve definitions and obtain reviewed translations and accessibility/user studies.
- Experimental interoperability: assess at least two independently implemented interaction paths and the proposed requirement tests. Test consent refusal, scope changes, target isolation, criticism, disagreement, absent memory, failed actions and accessibility. Evaluate a draft feedback schema only if reuse is inadequate.
- Candidate stable specification: resolve blocking issues, define testable scope and conformance criteria, complete security/privacy and human-factors review, and publish evidence and implementation limits for another public review period.
- Potential stable adoption: only a recorded governance decision and separately versioned publication can ratify HMC-1. A website page, package build or local test does not do so. Certification would need a separate governed program; none is established.
Review submissions should name HMC-1 Draft 0.1, the principle, a reproducible example, impact and proposed change. Avoid sharing confidential conversations. No automatic intake, response time or adoption is promised.
13. Revision history
- 0.1 · 2026-11-05: initial proposed public-review text, eight core principles, eight feedback principles, practical guides, conceptual feedback examples and a review roadmap. No change to UAI-1 v1.0 schemas or conformance.
Informative: Cognitive Liberty and Curiosity
The Cognitive Liberty Charter — Draft v0.2 proposes broader governance for lawful inquiry, the right to hear and be heard, faithful representation, adult autonomy, proportionate safety and meaningful correction. Curiosity is not intent: a question is not a confession, reading is not endorsement, and a hypothetical does not authorize action. Use context and evidence when interpreting an inquiry. This cross-reference is informative; the existing HMC-1 principles and normative requirements are unchanged. Any machine-readable filtering, disclosure or correction event needs separate review.