HMC-1 Developer Integration

HMC-1 Draft 0.1 · Proposed Draft — Public Review. This document is informative. The proposed human communication standard and the tentative uai.feedback.v1 interchange profile have different maturity and scope. Neither is adopted into stable UAI-1 conformance.

Keep the layers distinct#

HMC-1

Proposed communication principles: intent, clarification, authority, accessible explanations, honest status, appreciation, correction, consent and feedback continuity.

UAI-1

Existing interoperable envelopes, profiles, identity/provenance declarations and evidence. Message validation does not prove understanding, permission, truth or task completion.

Future feedback profile

uai.feedback.v1 is a tentative identifier under investigation. It is not registered, stable, implemented by the validator or available through a hosted feedback endpoint.

Existing concepts and new focus#

Message envelopes and intent requests/responses

UAI-1 already carries source, target, conversation, delivery, trust, body, provenance, integrity and extensions. The existing uai.intent.request.v1 and uai.intent.response.v1 describe requested intent and its response. HMC-1 adds human interpretation and communication-quality guidance; it adds no top-level envelope fields.

Identity and provenance

Existing declarations and evidence help identify a claimed actor and origin. They do not authenticate every assertion or grant a feedback author access to another user's target response. HMC-1 emphasizes accurate understanding and authority claims.

Operating model

The Agent Communication Operating Model separates execution from portable records. HMC-1 describes how human instructions and feedback are interpreted and explained at that boundary.

AI Memory Packages and handoffs

AI Memory and Project Handoff already describe portable context and continuity. HMC-1 adds explicit feedback-scope and retention distinctions. A message, acknowledgment or checksum does not authorize memory promotion, training or receiver activation.

Evidence, validation and conformance

Existing schemas, examples, validator and conformance pack retain their current contracts. HMC-1 draft requirements need interaction evidence and human review beyond syntactic validation.

MCP and A2A

Use the existing standards-fit guidance. HMC-1 does not replace tool sessions, agent discovery or task coordination, and claims no official endorsement or provider integration. Runtime adapters need their own implementation and configuration-specific tests.

New focus

Ordinary-language participation without compulsory fields, appreciation without emotional obligation, balanced correction, useful disagreement and honest feedback-memory boundaries are HMC-1's dedicated human-centered contribution.

Conceptual semantic elements#

These elements describe meaning, not required user input controls or adopted UAI-1 field definitions. In examples below, text is a string, plural assessments/requests are arrays of strings, and absent information is omitted rather than invented. No formal schema is adopted here.

intent

Desired outcome expressed by the human.

context

Relevant background, scoped to what may be disclosed.

constraints

Requirements, restrictions and explicit exclusions.

authority

A description of the asserted permission scope; it is not a credential or verified grant.

clarification

Material unresolved questions and assumptions to resolve.

completion

Expected result and the evidence used to assess completion.

appreciation

A natural expression of gratitude; it is never mandatory.

positive_feedback

Specific useful qualities, represented as an array of assessments in this example.

constructive_feedback

Shortcomings and their relevant effects.

requested_improvement

Desired changes; evaluation still needs ordinary authorization checks.

feedback_scope

The requested application scope. current_conversation in this example requests current adaptation, not persistent retention. Future scopes need separately defined consent and lifecycle rules.

target_reference

A scoped reference to an existing response or action; not an instruction to fetch an arbitrary URL.

feedback_type

An informative assessment label; balanced combines praise and criticism without treating either as approval or authority.

Illustrative communication representation#

Conceptual JSON only; people need not fill out these fields.

{
  "intent": "Make the homepage easier for newcomers to understand.",
  "context": "The site publishes a technical interoperability standard.",
  "constraints": ["Preserve the technical documentation and existing routes."],
  "authority": "Inspect the repository and prepare edits; do not deploy.",
  "clarification": ["Ask before changing a published standard."],
  "completion": "Show the edits and actual test results."
}

Illustrative feedback representation#

This is conceptual JSON, not a formally adopted schema or a uai.feedback.v1 message. It deliberately contains no persistent-memory authorization.

{
  "feedback_type": "balanced",
  "target_reference": "response-123",
  "appreciation": "Thank you for the detailed answer.",
  "positive_feedback": [
    "The explanation was clear.",
    "The practical example was helpful."
  ],
  "constructive_feedback": ["The conclusion was too vague."],
  "requested_improvement": ["Provide a clear recommendation with supporting reasons."],
  "feedback_scope": "current_conversation"
}

Investigated UAI-1 extension mechanism#

The checked-in generic UAI-1 envelope schema allows additional extension properties, but the current intent-request profile schema is stricter: each extension accepts only namespace, purpose and boolean critical. Adding a feedback payload directly to an intent-request extension fails that profile's structural validation. Do not infer profile compatibility from the generic envelope alone.

The current intent-request body.parameters accepts an application-defined object. If a sender and receiver agree on a feedback operation, a bounded experiment can place feedback there and use a noncritical extension as a metadata marker. That agreement must define the operation and authorization; a schema accepting an object does not implement the operation.

The following is a partial envelope location example, not a complete message: it omits the required envelope fields and the rest of the required intent-request body. The URN is an experimental namespace label, not an available service or registered schema identifier.

{
  "body": {
    "parameters": {
      "hmc_feedback": {
        "feedback_type": "balanced",
        "target_reference": "response-123",
        "appreciation": "Thank you for the detailed answer.",
        "positive_feedback": ["The explanation was clear.", "The practical example was helpful."],
        "constructive_feedback": ["The conclusion was too vague."],
        "requested_improvement": ["Provide a clear recommendation with supporting reasons."],
        "feedback_scope": "current_conversation"
      }
    }
  },
  "extensions": [{
    "namespace": "urn:uaix:proposed:hmc-1:feedback:0.1",
    "purpose": "Illustrative current-conversation feedback; draft semantics only.",
    "critical": false
  }]
}

Reuse an existing intent profile only when its defined intent/body semantics fit the operation and the receiving implementation explicitly supports the experiment. Do not rename the stable profile to the tentative identifier, add top-level fields, set a fabricated checksum or claim feedback conformance because generic JSON Schema accepts an extension. Preserve the complete original envelope requirements and recalculate any actual integrity record under its existing rules. The public validator has not gained HMC-1 interpretation.

For an unknown noncritical extension, do not infer that the receiver applied the feedback. Preserve uninterpreted data when forwarding within permitted scope and the selected contract. A critical semantic dependency needs explicit negotiated support and the existing unsupported-feature path; this example is not a workaround for forcing an unaware receiver to understand feedback. A generic receipt is not agreement, retention consent or a successful correction.

Future uai.feedback.v1 investigation#

Prefer existing structures before designing another profile. A new profile would need a separately reviewed schema in a clearly experimental namespace, implementation evidence and a governance decision; this publication intentionally does not add one to stable schema catalogs.

• Target linkage: distinguish response, action, partial result and revision. Resolve references inside the authorized user/conversation scope, not through arbitrary URL fetching.
• Assessment versus command: separate praise, criticism, correction requests and preference proposals; appreciation alone triggers no execution or authority escalation.
• Scope and consent: represent a requested scope separately from verified authorization, persistent-memory acceptance and training consent. Define expiry, revocation, purpose and recipient boundaries.
• Provenance: distinguish self-declared human feedback, feedback relayed by an agent, model-generated evaluation and independently reviewed observations. Avoid fabricated identity or cryptographic-proof claims.
• Privacy and lifecycle: minimize content, declare retention where supported, protect cross-user targets, define corrections/withdrawal, handle duplicates, and verify storage/deletion claims through real readback.
• Compatibility: test an unaware receiver, malformed fields, unknown scope, missing target, stale revision, denied consent and failed correction. Unknown capability does not count as successful handling.

Implementation considerations and evaluation#

An interface can map ordinary conversation into these concepts internally without exposing a form. Keep authority checks outside the language model's interpretation; treat feedback as untrusted data; expose supported controls for memory and retention. Show what changed in a correction and separate proposed, attempted, completed and verified states.

Test the eight core principles and eight feedback principles against realistic interaction transcripts. Include terse requests, mixed praise and correction, disagreement supported by evidence, accessibility needs, absent memory and failed tools. Retain scoped evidence and human review; automated schema checks alone cannot establish quality, accessibility or certification.

Use the review roadmap and existing governance before advancing maturity. Review text through Contact and Review, naming HMC-1 Draft 0.1 and the affected section. Return to Human–Machine Communication.