---
title: "Get Standard"
method: GET
path: "/internal/evals/standards/documents/{file_id}"
tags: ["internal", "internal-standards-extraction"]
---

# Get Standard

`GET /internal/evals/standards/documents/{file_id}`

One standard's requirements, in the order they were extracted.

Polled by the detail view while a decomposition runs, which is exactly when the previous library
is still the one on screen.

Carries the bulk ceiling the customer library publishes on its requirement *list* route, which
this console does not use — see `StaffStandardDetailResponse`.

## Path parameters

- `file_id` string, uuid, required

## Query parameters

- `company_id` string, uuid, required — The company whose library to operate on.
- `state` GuidelineRequirementState[], nullable

## Response `200`

Successful Response

- StaffStandardDetailResponse — One standard's requirements, plus the ceiling the console has to respect at the tick. The customer library learns its bulk cap from the requirement *list* route, which this console does not use — it works one document at a time, beside the document. Without the number here the console would either hardcode a copy of the server's constant or let a reader tick sixty rows and meet a validation error after the press, which turns the large clean-up bulk actions exist for into the one case they refuse. A subclass rather than a wrapper: the payload *is* the guideline detail, and a nested field would make every reader of it reach one level deeper on the staff surface than on the customer one.
  - `guideline` GuidelineSummary, required — A marketing standards document and the state of its requirement library.
    - `file_id` string, uuid, required
    - `filename` string, nullable, required
    - `upload_id` string, uuid, nullable, required
    - `newer_version_processing` boolean, required
    - `active_requirement_count` integer, required
    - `total_requirement_count` integer, required
    - `needs_requirements` boolean, required
    - `stale` boolean, required
    - `latest_decomposition` DecompositionSummary, required — One extraction run, and how it went. `status` is the *effective* status: a run whose worker never reported back reads as failed rather than as permanently running, so the surface never offers a spinner that will not resolve.
      - `decomposition_id` string, uuid, required
      - `upload_id` string, uuid, required
      - `status` 'queued' | 'running' | 'succeeded' | 'failed', required — Lifecycle of one decomposition run.
      - `stage` 'queued' | 'downloading' | 'extracting' | 'grounding' | 'storing' | 'done', required — Where a running decomposition has got to. Only the stages a watching human can perceive. Resolving the model's channel names to `MarketingCollateralType` and writing the rows are both sub-second, so they are not stages — a step that never renders is a step that misleads. `EXTRACTING` is the one that takes the minute.
      - `queue_wait_seconds` integer, nullable, required
      - `requirements_total` integer, nullable, required
      - `requirements_written` integer, required
      - `page_count` integer, nullable, required
      - `error` string, nullable, required
      - `started_at` string, date-time, nullable, required
      - `finished_at` string, date-time, nullable, required
      - `requested_by_email` string, nullable, required
      - `superseded` boolean, required
  - `requirements` GuidelineRequirementResponse[], required
    - `requirement_id` string, uuid, required
    - `file_id` string, uuid, required
    - `filename` string, nullable, required
    - `decomposition_id` string, uuid, required
    - `ordinal` integer, required
    - `revision_number` integer, required
    - `state` 'active' | 'disabled' | 'archived' | 'superseded', required — Whether a requirement is in the working library, and if not, why not. All four are recorded as revisions, so every one of them is reversible and readable. ARCHIVED and SUPERSEDED are deliberately distinct: ARCHIVED is a person deciding this obligation does not apply to them, SUPERSEDED is a newer decomposition of the same guideline taking over. A regeneration must never overwrite the first with the second — that would erase a human decision.
    - `requirement_text` string, required
    - `judging_guidance` string, nullable, required
    - `collateral_types` MarketingCollateralType[], nullable, required
    - `marketing_team_ids` string[], nullable, required
    - `source_collateral_terms` string[], nullable, required
    - `trigger_terms` string[], required
    - `unresolved_collateral_terms` string[], required
    - `section_label` string, nullable, required
    - `title` string, nullable, required
    - `source_page` integer, nullable, required
    - `citation` GroundedSpan, required — Where a requirement appears to have come from, and how much to trust it.
      - `page_number` integer, required
      - `boxes` BoundingBox[]
        - `x0` number, required
        - `y0` number, required
        - `x1` number, required
        - `y1` number, required
      - `source_text` string, nullable
      - `matched_terms` string[]
      - `score` number
      - `basis` string
      - `cited_page` integer, nullable
      - `refusal` string, nullable
    - `change_kind` 'extracted' | 'edited' | 'disabled' | 'enabled' | 'archived' | 'restored' | 'superseded', required — What a revision was for. Redundant with comparing a revision to its predecessor, and that is the point: the reason a change was made is the part a diff cannot recover.
    - `change_note` string, nullable, required
    - `updated_at` string, date-time, required
    - `updated_by_email` string, nullable, required
    - `has_human_edits` boolean, required
    - `signal` RequirementSignal — One requirement's track record, as a ranked read reports it. Present only when the list was asked for an `order`; `None` otherwise, so an ordinary library read pays neither the aggregate nor the payload. A row whose requirement has never been checked is absent from a ranked read entirely rather than carrying zeros — there is nothing to rank. **The two halves are in different units and must not be added or compared.** `collateral_checked` and the three `checks_*` count *checks* — one per (evaluation, requirement), which `uq_marketing_requirement_check_once_per_evaluation` guarantees. The `risks_*` count *risks*, and one check can produce several, so `risks_flagged + risks_over_flagged` is not bounded by `checks_failed`. The rates come from the server because the server ordered by them. A client re-deriving them would be a second definition of the number the ranking was built on. `None` means no evidence, which is a different claim from `0.0`.
      - `collateral_checked` integer, required
      - `checks_failed` integer, required
      - `checks_passed` integer, required
      - `checks_not_determined` integer, required
      - `checks_current_revision` integer, required
      - `verdicts` object, required
      - `risks_superseded` integer, required
      - `false_positive_rate` number, nullable, required
      - `dismissal_rate` number, nullable, required
      - `fire_rate` number, nullable, required
    - `downvotes` integer, nullable
  - `superseded_with_human_edits` integer, required
  - `max_requirements_per_state_change` integer, required

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