# Selection accuracy

## 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:

```
hit_rate = (auto_selected_count + prediction_correct_count) / selection_count
```

Version: 1.79.2

## Description:

  - `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: ```
hit_rate = (auto_selected_count + prediction_correct_count) / selection_count
```