---
title: "List Requirement Changes"
method: GET
path: "/marketing/guidelines/requirement-changes"
tags: ["marketing-guidelines"]
---

# List Requirement Changes

`GET /marketing/guidelines/requirement-changes`

What re-readings have proposed doing to rules already in the library.

Defaults to the pending ones, which is the worklist; the resolved ones are readable by asking
for them, because "what did the reviewer decide about that proposal" is a question the history
of a compliance library has to be able to answer.

Each row carries the rule as it stands beside what the reading would write, which is the
comparison the reviewer is making. The live revision is read per row rather than joined so the
identity lock discipline every other writer here follows is not silently bypassed by a read that
happens to be cheaper.

## Query parameters

- `guideline_set_id` string, uuid, nullable
- `file_id` string, uuid, nullable
- `proposal_status` 'pending' | 'accepted' | 'rejected' — Where a proposed change has got to. PENDING is the only status the partial unique index counts, so a requirement carries at most one open proposal at a time and a second reading cannot stack a contradictory one behind it.

## Response `200`

Successful Response

- RequirementChangeProposalList
  - `proposals` RequirementChangeProposal[], required
    - `change_id` string, uuid, required
    - `requirement_id` string, uuid, required
    - `guideline_set_id` string, uuid, nullable, required
    - `file_id` string, uuid, required
    - `filename` string, nullable, required
    - `kind` 'update' | 'remove', required — What a re-reading proposes doing to a rule the library already holds. A reading may now say something about the obligations its document produced last time, which it could not before. What it may *not* do is act on them: both kinds are recorded as pending changes a reviewer accepts or rejects, because the alternative is a model rewording a rule that is in force, or switching one off, with nobody having looked. There is no `KEEP` member. A rule the reading is content with is a rule it says nothing about, and a row recording "no change proposed" for every untouched obligation in a four-hundred-rule library is noise a reviewer has to page through to find the two that matter.
    - `status` 'pending' | 'accepted' | 'rejected', required — Where a proposed change has got to. PENDING is the only status the partial unique index counts, so a requirement carries at most one open proposal at a time and a second reading cannot stack a contradictory one behind it.
    - `reason` string, required
    - `decomposition_id` string, uuid, required
    - `created` string, date-time, required
    - `resolved_at` string, date-time, nullable, required
    - `resolved_by_email` string, nullable, required
    - `current_state` 'active' | 'disabled' | 'archived' | 'superseded' | 'proposed', required — Whether a requirement is in the working library, and if not, why not. All of them are recorded as revisions, so every one 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.
    - `current_revision_number` integer, required
    - `current_title` string, nullable, required
    - `current_requirement_text` string, required
    - `current_judging_guidance` string, nullable, required
    - `current_context` string, nullable, required
    - `current_trigger_terms` string[], required
    - `current_collateral_types` MarketingCollateralType[], nullable, required
    - `reviewed_revision_number` integer, nullable, required
    - `proposed` object, required

## Other responses

- `422` — Validation Error

## Changes

- **2026-09-05** `eb329fb4c94a` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/kobaltlabs/apis/fastapi/changes/marketing/guidelines/requirement-changes/get.md)

---

[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/eb329fb4c94a/schema)