inbound_approve

Category: inbox
Access: write
Audience: administrative (ordinary users do not normally call this directly)

Purpose

Approves staged inbound items into agreed state. Tasks insert as fresh entries through real creation; knowledge merges additively with type conflicts skipped and relations gated on both endpoints.

Arguments

Required: kind, item_ids.

Optional: reason.

kind. Note: tasks or knowledge.
item_ids. Note: JSON array string of namespaced ids (t:N tasks, e:N entities, r:N relations); must match kind. Every id must exist and be pending or the whole call fails with nothing applied.
reason. Note: Recorded as the decide reason on each item.

Result

Object with approved array (id plus task_id for tasks) and skipped array (id plus reason).

Boundaries

Conductor role required. Approved content is created under the approver identity within the selected profile boundary, so approver scope and validation apply exactly as for direct creation.

Lifecycle / side effects

Strict eligibility pre-check first, then entities before relations: tasks are created fresh through the real creation path; entities merge additively (type conflicts skip, only new observations merge); relations need both endpoints pre-existing or approved in the same batch. Each item is marked decided with a decision history event.

Errors

Non-conductor callers get a requires-conductor error payload. Invalid kind, malformed ids, kind/id mismatch, or any ineligible item fails the whole call with nothing applied. Type conflicts and missing relation endpoints land in skipped, not errors.

Example

{
  "item_ids": "[\"t:1\"]",
  "kind": "tasks"
}

Result shape:

{
  "approved": [
    {
      "id": "t:1",
      "task_id": "<uuid>"
    }
  ],
  "skipped": []
}