{"version":"2.1.234","anchor":"refusal-records-remember-whether-any-step-of-the-episode-was","canonical_anchor":"refusal-records-remember-whether-any-step-of-the-episode-was","heading":"Refusal records remember whether any step of the episode was a cyber refusal","tier":"internal","area":"Safety Fallbacks","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234\/e\/refusal-records-remember-whether-any-step-of-the-episode-was","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234","markdown":"### Refusal records remember whether any step of the episode was a cyber refusal\n\nRefusal records now remember if any step of an episode was a cyber refusal, so restores re-arm protection.\n\n**What**\n\nRefusal-fallback records persist a new `saw_cyber_refusal` field, also echoed in the SDK event stream. Its description says it is set when any hop of a banner's episode was a cyber refusal, not just the first, and that it exists so the CLI can re-arm its cyber-exclusion header when a session is restored.\n\n**Details**\n\n- Marked internal and never rendered to the user; written whenever the condition holds, with no gate.\n\n**Evidence**\n\n`saw_cyber_refusal`\n\n- Area: Safety Fallbacks\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}