Get a pipeline's structured results (poll-able)

The pipeline run's structured rows, poll-able as JSON — the same governed read (review holdback, demoted-field projection, __ diagnostics filtering, assembly awareness) that previously existed only as the run.completed webhook or a data-product CSV export. The default record shape mirrors the pipeline.capture webhook envelope: document_id, filename, run_id, pipeline_id, record_id, status, completed_at, optional metadata/batch_id, and clean fields. Held (pending_approval) values never leave this surface — fields serializes null for them.

view=composed (the default when the run has an assembly product set) returns one row per assembled group, the same rows the data product and CSV exports serve; view=documents returns one row per pipeline document from the main record set. A non-assembly run only has the documents view — view=composed degrades to it rather than erroring. An anchor-less composed row (the product record's anchor could not be resolved — a known per_group_jobs identity-stamp gap) serializes document_id/filename/run_id: null, status: "complete", and completed_at: null; such rows are excluded by any document_id, status, since, or until filter and appear only in unbounded reads.

since/until filter on completed_at, which tracks DOCUMENT PROCESSING completion, not value change: a later review promotion or assembly recompose never advances it, and a phase rerun NULLS the completion stamps for every affected document until it re-processes. Poll unbounded (or by document_id) to pick up review outcomes; pending_review_count on the page is the signal that held values are outstanding.

A field backed by a structured subschema is projected to its declared subfield types on this poll — in both the fields map and the ?include=cells cells[].value — matching the run.completed webhook; a number/boolean subfield parse-miss serializes null and an enum/date miss passes through raw (see the ResultsCell/ResultsRecord schemas and the Webhooks event catalog for the full per-type contract). The include=audit trail is the raw history view and is NOT type-projected.

include=cells,provenance,audit (comma-separated) add shape beyond fields. cells adds per-field { value, status, confidence, source, document_id, filename } — source is an opaque-but-stable vocabulary; new values may appear over time. provenance adds a stable projection of the cell's audit trail (kind one of span, assembly_override, auto_adjudication, human, derived, legacy, with an open derived_reason enum); a held cell's projection is kind-only — no displaced/previous values. audit adds the full cell-version trail, bounded to structure_pipeline.results_api.audit_max_records (default 20) records per page — a broader page 400s with audit_include_too_broad. For any field whose LATEST version is held, every version in its audit trail serializes value: null (the hold mechanism copies the value forward, so the prior version is an equal leak).

Pagination is house cursor pagination (pagination.next_cursor, keyed on record_id), never an invented page param. Per-record status folds ~10 internal states to four public values — complete, partial, and error pass through, everything else (queue/phase states, awaiting_ocr, …) folds to processing. This deliberately KEEPS partial, unlike GET /v1/run/{id}'s 3-state documents[] fold, because a partial row's held fields are the reason to keep polling. Poll this envelope's status until completed for a single-request pipeline; an append pipeline never settles at the pipeline level, so append consumers should loop on per-record status/completed_at or poll GET /v1/run/{id}/results instead, whose run-scoped status does settle. Preview pipelines are served. Requires read scope.