Sign in
marketing-guidelines

Resolve Requirement Change Route

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.

post/marketing/guidelines/requirement-changes/{change_id}/resolve

Path parameters

change_idstring uuid required

Request body

acceptboolean required
change_notestring nullable

Response

Successful Response

change_idstring uuid required
requirement_idstring uuid required
guideline_set_idstring uuid nullable required
file_idstring uuid required
filenamestring 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.

reasonstring required
decomposition_idstring uuid required
createdstring date-time required
resolved_atstring date-time nullable required
resolved_by_emailstring 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_numberinteger required
current_titlestring nullable required
current_requirement_textstring required
current_judging_guidancestring nullable required
current_contextstring nullable required
current_trigger_termsstring[] required
current_collateral_typesMarketingCollateralType[] nullable required
reviewed_revision_numberinteger nullable required
proposedobject required

Changes

Changed in 1 of the 5 revisions of this API.1