---
title: "List Dismissed Risk Labels"
method: GET
path: "/internal/risk-labeling/labels"
tags: ["internal"]
---

# List Dismissed Risk Labels

`GET /internal/risk-labeling/labels`

Stored labels joined to their risks — the eval set, newest label first.

Scoped by company only, deliberately wider than the queue: a risk's
disposition can move after it is labeled (a re-run obsoletes it, a new rule
suppresses it), and narrowing this the same way would hide the row from the
one surface that offers to remove its label. So ``total`` here can exceed the
progress card's ``labeled``, which counts only what is still queue-eligible.

## Query parameters

- `company_id` string, uuid, nullable
- `category` 'ocr_or_av_processing' | 'missing_file_context' | 'bad_guideline' | 'user_preference' | 'compliance_officer_wrong' | 'other' — Root cause a labeler assigned to a dismissed marketing risk. Two axes in one list, which is the point. The first three say Kobalt got something wrong. ``USER_PREFERENCE`` and ``COMPLIANCE_OFFICER_WRONG`` say it did not: the risk was real and correctly raised, and the dismissal is explained by the reviewer either declining it deliberately or getting it wrong. Without those two, both land in ``OTHER`` and an eval set reads every one of them as an unexplained false positive. Stored as a plain VARCHAR (see the model), so adding a member here is a code change and needs no migration.
- `limit` integer
- `offset` integer

## Response `200`

Successful Response

- DismissedRiskLabelsResponse — Paginated stored labels, newest first.
  - `total` integer, required
  - `limit` integer, required
  - `offset` integer, required
  - `rows` DismissedRiskLabelRow[], required
    - `label_id` string, uuid, required
    - `risk_id` string, uuid, required
    - `category` 'ocr_or_av_processing' | 'missing_file_context' | 'bad_guideline' | 'user_preference' | 'compliance_officer_wrong' | 'other', required — Root cause a labeler assigned to a dismissed marketing risk. Two axes in one list, which is the point. The first three say Kobalt got something wrong. ``USER_PREFERENCE`` and ``COMPLIANCE_OFFICER_WRONG`` say it did not: the risk was real and correctly raised, and the dismissal is explained by the reviewer either declining it deliberately or getting it wrong. Without those two, both land in ``OTHER`` and an eval set reads every one of them as an unexplained false positive. Stored as a plain VARCHAR (see the model), so adding a member here is a code change and needs no migration.
    - `explanation` string, required
    - `labeled_by` string, nullable, required
    - `created` string, date-time, required
    - `file_id` string, uuid, required
    - `company_name` string, required
    - `filename` string, required
    - `short_text` string, required
    - `status` 'reject' | 'allow' | 'flag' | 'dismissed', required
    - `dismiss_reason` 'valid_ok' | 'already_met' | 'incorrect' | 'out_of_scope' | 'pre_approved' | 'other', required — Why a reviewer dismissed a marketing risk (status=dismissed).

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/kobaltlabs/apis/fastapi.md) · [All operations](https://skmtc.dev/kobaltlabs/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/kobaltlabs/fastapi/revisions/3ff4c0bd276b/schema)