### Problem Statement Currently, security policy violations are registered for all branches and later [excluded during evaluation ](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/approval_state.rb#L328)if branch rules don't apply. This creates technical debt and friction as we build additional features on top of the violation system. The current approach also contributes to false positive violation details appearing in Policy Bot comments (related to issue #553183). ### Hypothesis We can improve system efficiency and reduce false positives by evaluating policy applicability before registering violations, rather than registering all violations and filtering them later. ### Spike Goals **Primary:** * Evaluate feasibility of pre-filtering violations based on branch rules * Assess performance impact of rule evaluation during branch changes * Identify architectural changes required for implementation **Secondary:** * Document current violation registration flow * Analyze impact on existing features that depend on violation data ### Success Criteria * [ ] Performance benchmarks comparing current vs proposed approach * [ ] Decision recommendation with clear next steps ### Research Questions 1. What is the performance cost of evaluating all policy rules on target branch changes? 2. How would this change affect existing violation-dependent features? ## References: Registering violations: It's either in: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/approval_project_rule.rb#L269 which is called from [MergeRequests::CreateService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/ee/merge_requests/create_service.rb#L31) and [MergeRequests::RefreshService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/ee/merge_requests/create_service.rb#L31) Or in [UpdateViolationsService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/security/security_orchestration_policies/update_violations_service.rb#L96) when a new violation is detected (for example after a finished pipeline)