---
title: "Decompose a question into children"
method: POST
path: "/v2/workspaces/{id}/inquiries/{inquiry}/split"
tags: ["Inquiries"]
---

# Decompose a question into children

`POST /v2/workspaces/{id}/inquiries/{inquiry}/split`

## Request

- Base URL: `https://api.infolang.ai`
- URL: `https://api.infolang.ai/v2/workspaces/{id}/inquiries/{inquiry}/split`
- Auth: one of:
  - HTTP bearer
  - HTTP bearer
  - HTTP bearer

The parent leaves the agenda as `superseded` WITH RECORDED LINEAGE — which is the difference between decomposition and deletion (IR3). Never `answered`.

`coverage_claim` is an opaque `il-warrant` edge id under which somebody CLAIMS the children cover the parent. It is carried verbatim and never dereferenced (S2): whether N children really cover a parent is a defeasible claim in another graph, not a fact this fold can check. D3 conserves ACCOUNTABILITY, not coverage.

**Refining a question is not answering it, and similarity cannot retire a question.**

`narrow` marks the parent `narrowed`, which is a LIVE status: the parent STAYS on the agenda (IR2). `split` leaves the parent `superseded` with recorded lineage, never `answered` (IR3) — and never `split`, a status in the wire vocabulary that the fold never produces.

An `answer` must NAME an assertion (IR4), and a memory NEVER answers a question by arriving on its subject key. The match would be exact, which is exactly why it looks defensible; the rule it breaks is IR4. Pass `answers_inquiry` on a `remember` to state one.

An agenda ROW is an equivalence CLASS, not a question (IR6): two questions joined by `same_as` are ONE row with two members, and `outstanding` counts ROWS. `same_as` groups the VIEW and merges no identity, no lineage and no history.

`abandon` and `same_as` are authority-floored; a below-floor record is written and folds INERT, never rejected (D4). There is NO delete: reopening an abandonment is an append that cites ONE specific abandon record.

Requires the `coord:write` scope. Accepts all three lanes: a session JWT (bounded by the caller's role on this workspace) or an `il_*` machine credential whose own scope set, workspace set and validity window cover it — both ceilings apply and neither can raise the other, so a credential carrying `coord:write` is still refused where the role does not permit it.

A credential with no scope record resolves to `LEGACY_DEFAULT`, which does NOT include `coord:write` — mint a key with it explicitly (`POST /v2/workspaces/{id}/keys`).

## Path parameters

- `id` string, required
- `inquiry` string, required

## Request body

- object
  - `children` string[], required
  - `coverage_claim` string
  - `record` string, uuid

## Response `201`

The record, and what the parent's status became

- object
  - `inquiry` string, required
  - `children` string[], required
  - `record` string, required
  - `authority` string, required
  - `appended` boolean, required
  - `supersedes` object, required
    - `answered` false, required
    - `status` 'superseded', required
    - `message` string, required
  - `status_note` string, required

## Other responses

- `401`: Missing/invalid credential, or `credential_expired` — the credential is outside its `[not_before, expires_at)` window and must be replaced
- `403`: `insufficient_scope` — the credential's own scope set, or the caller's role on this workspace, does not cover the scope this route requires (the missing scope is named in the message). Or `forbidden` — the credential is not scoped to this workspace, or holds no grant on it
- `501`: The inquiry verbs are not compiled into this deployment (`kernel-verbs` is off upstream)

---

[API](https://skmtc.dev/infolang/apis/infolang-api.md) · [All operations](https://skmtc.dev/infolang/apis/infolang-api/llms.txt) · [OpenAPI document](https://skmtc.dev/infolang/apis/infolang-api/revisions/d04bf6de72c8?raw)