Selection accuracy

GET /statistics/selections returns, for every request in a date range, how that request's positions were resolved into selections. Rows cover both request types shown on the dashboard — tenders and orders — and each carries a request_type (TENDER / ORDER) so you know whether its request_id resolves via GET /tenders/{id} or GET /orders/{id}. Each row carries these counts:

• position_count — the number of relevant positions on the request (lines Mercura kept for matching; irrelevant lines such as headings or notes are excluded).
• positions_with_selection — how many of those relevant positions actually got resolved, i.e. carry at least one selection. Always <= position_count (some relevant positions end up with no selection at all). This is the denominator behind the in-app time-per-position metric — see Status & handling time below.
• selection_count — the total number of surviving selections across those relevant positions. A single position can carry more than one selection (for example two articles chosen for one line), so selection_count may exceed position_count. It counts selections, not positions, so it is not interchangeable with positions_with_selection.
• auto_selected_count — selections made by a mechanism that resolves the line without going through prediction ranking. These fire when Mercura can resolve a line on its own: an exact article-number match; propagation from a master, historic, cluster, duplicate, or equivalent-position match; a parts-list lookup; a configured default article; or an auto-selection the order-entry agent makes on its own. In practice this is high whenever the customer supplied article numbers up front.
• prediction_correct_count — prediction-driven selections where the chosen article was among Mercura's predictions for that position (a "correct" prediction — the model surfaced the article the user picked). This is a straight predicted / not-predicted split: the earlier top-10 rank cut has been removed, since the order-entry agent surfaces only a handful of candidates per position rather than a long ranked list.
• manual_selection_count — prediction-driven selections where the chosen article was not among Mercura's predictions for that position (shown as Manual selections in the dashboard — the user picked something the model did not surface).

The three outcome counts (auto_selected_count, prediction_correct_count, manual_selection_count) are mutually exclusive and sum to selection_count.

Derive whatever rollups you need client-side, for example: