Human working preferences

Company OS can retain reviewed preferences for a human member of one company. This is collaboration context for an agent, not company policy or a second memory store.

This profile is separate from hitl_preferences, which controls approval modes and autonomy thresholds. A working preference cannot relax a human approval requirement.

Identity and task relevance

• The subject is a durable company_human_memberships.id, scoped by company_id.
• A task created with a verified human membership token binds to that membership. A child task inherits its parent's binding. Tasks created without either binding receive no human preference context.
• An existing task can be bound with POST /api/company/companies/{company_id}/tasks/{task_id}/human-preference-subject and { "membership_id": "<uuid>" }. The subject or a human owner/admin must authorize it; an existing binding cannot be replaced.
• The task llm-context includes only approved or corrected preferences for its bound human while that membership and identity are active. Each emitted item names its source event ID in the rendered human_preferences section; the context manifest records the section's digest.

Review workflow

GET and POST /api/company/companies/{company_id}/human-preferences/{membership_id}/events expose the bounded history and append events. Requests use the Company OS transport bearer; reads and human decisions also require a verified human principal token. The member can review their own profile; an active owner or admin member can review another member's profile. A scoped agent can propose but cannot approve, correct, reject, or retract.

History reads return up to 500 newest events and next_before_event_seq. Pass that value as ?before_event_seq=<number> to read the next page. Continue until the cursor is null.

Event actions:

Action	Predecessor	Effect on context
propose	none	Pending; excluded
approve	proposal	Copies its value and evidence into the reviewed profile
reject	proposal	Excluded
correct	current approved/corrected event	Replaces the reviewed value, preserving history
retract	current approved/corrected event	Removes the key from context, preserving history

propose and correct require a bounded value and evidence_ref. Valid references are task:<uuid>, run:<uuid> in the same company, or human_assertion by the subject themself. The optional evidence_excerpt is bounded and redacted before storage. Preference categories are communication, goal, frustration, and preference; keys use lowercase letters, digits, and underscores. For example:

{
  "category": "preference",
  "preference_key": "response_length",
  "action": "propose",
  "value": "Prefer concise answers with links to the changed files",
  "evidence_ref": "task:00000000-0000-0000-0000-000000000001"
}

The reviewer approves by posting action: "approve" with the same category and key plus the proposal's predecessor_id. The append-only event and its governance receipt commit together. A proposal is never silently promoted from an inference worker.