One row per candidate run of an assessment, unified across standalone
and pipeline assessments. Read source on every row before joining —
it tells you which system produced the row and therefore what
candidate_id refers to.

This is a top-level resource rather than
/assessments/{id}/results because a single query legitimately spans
assessments. Narrow with assessment_id when you want just one.

Ordering

created_at only. It is the one ordering key backed by a real column
on both underlying tables, which lets the two sides be paged in the
database and merged exactly. score and submitted_at are derived
on the standalone side (see AssessmentResult) and cannot be ordered
server-side. Pinning source does NOT unlock extra sort keys —
sort=-score returns 400 regardless of source. Sort a retrieved
page client-side if you need score order.

Deep pagination

When a query can match both sources, each side is read up to
page × per_page rows so the merged page is exact. Beyond 2 000
combined rows that read is refused with 400 pagination_limit_exceeded.

The limit is computed from page × per_page alone, before any row is
read, so only the filters that collapse the query to ONE source lift
it: source=standalone, source=pipeline, or pipeline_id (which
implies pipeline, since standalone assessments have no pipeline). A
single source is paged directly in the database and is not capped.
Other filters — assessment_id, candidate_id, date ranges — reduce
how many pages you need but do NOT raise the limit.

has_more accounts for this: it reports false once the next page
would be unreachable, even if total is larger.