---
title: "Resolve Requirement Change Route"
method: POST
path: "/marketing/guidelines/requirement-changes/{change_id}/resolve"
tags: ["marketing-guidelines"]
---

# Resolve Requirement Change Route

`POST /marketing/guidelines/requirement-changes/{change_id}/resolve`

## Request

- Base URL: `https://api.kobaltlabs.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.kobaltlabs.com/marketing/guidelines/requirement-changes/{change_id}/resolve`
- Auth: none declared

Accept or reject one change a re-reading proposed.

The only path that lets a reading's opinion about an existing rule become a change to it, and it
runs as the reviewer: accepting writes an ordinary revision — EDITED for a rewording, ARCHIVED
for a removal — recorded against the person who pressed it. Rejecting writes no revision and
leaves the rule exactly as it was, which is what makes rejecting cheap enough to be honest.

## Path parameters

- `change_id` string, uuid, required

## Request body

- ResolveRequirementChangeRequest: A reviewer's answer to a change a re-reading proposed. Two answers rather than an edit-then-accept: a reviewer who wants something other than what the reading proposed rejects it and edits the requirement themselves, so the history records what the model asked for and what the person actually did as two separate facts rather than one revision claiming to be both.
  - `accept` boolean, required
  - `change_note` string, nullable

## Response `200`

Successful Response

- RequirementChangeProposal: One thing a re-reading proposed doing to a rule already in the library. Carries the wording as it stands *and* the wording proposed, because the reviewer's question is a comparison: this is the only surface in the library where a person is asked to approve a change they did not make. `current_*` is the live revision at read time, not the one the reading was shown — if a person has edited the rule since, that is what the reviewer needs to see, and `reviewed_revision_number` is how they can tell the two apart.
  - `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

[Operation history](https://skmtc.dev/kobaltlabs/apis/kobaltlabs-api/changes/marketing/guidelines/requirement-changes/:change_id/resolve/post.md)

---

[API](https://skmtc.dev/kobaltlabs/apis/kobaltlabs-api.md) - [All operations](https://skmtc.dev/kobaltlabs/apis/kobaltlabs-api/llms.txt) - [OpenAPI document](https://skmtc.dev/kobaltlabs/apis/kobaltlabs-api/revisions/8587332d5e43?raw)