{"version":"2.1.280","anchor":"compliance-taint-list-now-filters-out-entries-via-a-new-pred","canonical_anchor":"compliance-taint-list-now-filters-out-entries-via-a-new-pred","heading":"Compliance-taint handling reworked to separate server data, hints, and HIPAA","tier":"internal","area":"Compliance","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/compliance-taint-list-now-filters-out-entries-via-a-new-pred","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Compliance-taint handling reworked to separate server data, hints, and HIPAA\n\nCompliance-taint checks now distinguish server-fetched state, local hints, and HIPAA when deciding restrictions\n\n**Unclear.** What specific taints the new filter excludes, and why, is not stated in the evidence.\n\n**What**\n\nClaude Code's handling of `compliance_taints` (labels used to decide feature restrictions) was reworked:\n\n- The function that merges incoming `compliance_taints` now filters out taints that fail a new predicate before merging and truncating the combined list.\n\n- The restriction check (`fTt`) now only applies `compliance_taints` from state when the session data actually came from a server fetch (`sessionFromServerFetch`); otherwise it falls back to locally hinted taints only.\n\n- The `hipaa` taint is now special-cased separately from other compliance taints, and is checked against server-populated feature restrictions rather than being folded in with generic hints.\n\n**Why**\n\nThis avoids applying compliance restrictions based on stale or unverified local hints when authoritative server data isn't available yet, and gives HIPAA-specific restrictions more careful, server-backed handling than generic compliance taints.\n\n- Area: Compliance\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}