The questions a destination’s application form asks

`/v1/documents` answers what to *send*; this answers what to *answer*, which is the other half of the same capture. Four portals ask four different sets of questions, and this is the only place that knows which — a client drawing the fields by hand asked Somalia for a father’s name no capture contains, and never asked Kenya where the traveller arrives, which its form requires.

Fields are grouped by `page` — **the portal’s own route** where the capture recorded one (`/form/apply/individual/contact-information`), and `map:<n>` where it did not. Grouping by `screen` alone was too coarse: Kenya has five screens and fourteen routes, so its four Trip Information tabs and its separate Travel Information page all arrived as a single step of thirty-six fields, every mode’s questions together.

Each field carries `options` already resolved: where a list lives in another file — Kenya’s 57 occupation codes, Djibouti’s marital statuses — it is returned inline, so a caller never has to know which capture keeps what where. An empty `options` means no list was captured, and a renderer should ask for text rather than offer an empty dropdown.

**`capture` is not decoration.** A step marked `title-only` had only its title read; a client that treated it as an empty step would drop real questions. `captured` dates the whole file, and `capture_boundary` says in the capture’s own words where the reading stopped.