{"version":"2.1.234","anchor":"safeguard-and-refusal-notices-now-name-the-category-and-vali","canonical_anchor":"safeguard-and-refusal-notices-now-name-the-category-and-vali","heading":"Safeguard and refusal notices now name the category and validate the request ID","tier":"notice","area":"API Errors","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234\/e\/safeguard-and-refusal-notices-now-name-the-category-and-vali","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234","markdown":"### Safeguard and refusal notices now name the category and validate the request ID\n\nSafeguard and refusal notices now end with a Details line naming the refusal category.\n\n**What**\n\nWhen the API flags or refuses a message, the notice now ends with a `Details:` line naming the server-supplied refusal category. This applies to the safeguards notices, their switched-model and same-model variants, and the invalid-request path.\n\n**Details**\n\n- The category is stripped of backticks and square brackets and length-capped before being shown; if the response carries no category, or it is not a string, no line is appended.\n- The Request ID appended to refusal messages is now only shown when it matches `^[A-Za-z0-9_-]{1,255}$`.\n- The cyber-refusal fallback latch re-arms on a `sawCyberRefusal` flag as well as on the category, and takes its request id from an entry that is genuinely categorised as cyber.\n\n**Evidence**\n\n`'s safeguards flagged this message. `, `tengu_refusal_fallback_resume_latch`\n\n- Area: API Errors\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}