Vocabulary is governance

If you cannot name what changed, you cannot govern it. HUMΛN uses four terms consistently (HumanOS orchestration canon — memory, feedback, adaptation, capability update):

Term	Means
Memory	What you can retrieve later — scoped, policy-bounded storage.
Feedback	Signals from outcomes — thumbs-up, rejections, operator notes — append-only evidence.
Adaptation	Behavior change driven by memory + feedback under rules (proposals, approval, apply).
Capability update	What the system believes about quality / routing — evidenced, not vibes.

Where the API reflects the split

• Feedback (evidence): POST /v1/humanos/feedback/events with a registered payload_type; list with GET /v1/humanos/feedback/events (cursor pagination).
• Adaptation (governed): POST /v1/humanos/learning/proposals → lifecycle via PATCH /v1/humanos/learning/proposals/:proposal_id → POST …/apply (writes humanos_tuning_actions when approved).
• Inspectability: GET /v1/humanos/policy/effective exposes the merged learning envelope (what is allowed before you mutate).

SDK entry points (same paths)

@human/client-sdk:

await client.humanos.recordFeedbackEvent({
  payload_type: 'accepted',
  scope: 'user',
});
await client.humanos.listLearningProposals({ status: 'draft' });

@human/sdk: use client.humanosLearning (recordFeedbackEvent, createLearningProposal, …).

Next

Part 3 — Why the OS should own it · Part 1