{"version":"2.1.277","anchor":"hipaa-related-failopenverdict-compliance-branch-gate-unreso","canonical_anchor":"hipaa-related-failopenverdict-compliance-branch-gate-unreso","heading":"Policy checks can now fail open when a compliance verdict can't be reached","tier":"soon","area":"Compliance","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/hipaa-related-failopenverdict-compliance-branch-gate-unreso","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Policy checks can now fail open when a compliance verdict can't be reached\n\nA new failOpenVerdict signal lets certain org-policy checks proceed when the compliance verdict service is unreachable\n\n**Unclear.** Which specific compliance keys or actions this exception applies to is not stated\n\n**What**\n\nOrg-policy compliance checks now have a fail-open path for when the system that decides compliance verdicts is unreachable:\n\n- A new `failOpenVerdict` boolean is tracked in the session's policy-limits cache and updated whenever `replaceSessionCache` or hint updates run.\n\n- The cache also emits a new `heldStartSignal` on every `emitVerdictChanged()` call, separate from the verdict-changed signal itself.\n\n- When the verdict service is unreachable and the identity that settled without a verdict matches the current principal, certain otherwise-denied compliance keys (such as HIPAA-related ones) become allowed again, unless the required HIPAA evidence hasn't been loaded or can't be read.\n\n**Why**\n\nThis prevents a temporarily unreachable compliance-verdict service from blocking users outright, while still requiring the right evidence to be present before allowing HIPAA-related actions through the fail-open path.\n\n- Area: Compliance\n- Tier: Nothing to try yet\n- Useful: 3\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}