# 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:

```json
{
  "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.