Decide what to change

Something is wrong and you know what it is. A check keeps firing, deployments keep failing, or drift keeps coming back. Picking what to change is the difficult part, because the same symptom can come from the rule, from how teams work, or from where enforcement happens.

Change one thing. If you adjust a rule, move a check earlier, and ask a team to work differently in the same cycle, the next review cannot tell you which of them helped.

Policy, practice, or pipeline

• The policy. The rule itself is wrong for your organization. A check fires on patterns your teams consider acceptable, its severity stops pipelines for findings that should only warn, or a package bundles rules that do not belong together. See Adjust policies, assignments, and scope.

• The practice. The rule is right and keeps catching the same real problem. The fix lives with the teams: How changes are authored, how early checks run, and how reviews work. See Adjust development and delivery practice.

• The pipeline. The rule and the practice are both right, but enforcement happens in the wrong place. Checks that run only at deployment time surface problems at the most expensive moment. Moving them into the developer’s own liquibase checks run before the change is pushed turns a blocked pipeline into a local fix.

Let the evidence choose

Which one you are looking at is a reading rather than a judgment call, and Identify the constraint: Policy, practice, or pipeline covers how to take it. In short, filter the Policy Checks dashboard to one project at a time and watch how the findings spread. One check failing everywhere is the rule. Many checks failing in one place is the practice. Findings that only appear on deployment runs are the pipeline.

Decide what should be different afterwards

Whatever you change, write down the expectation before you make it. It should name one figure and a direction, such as:

• Fewer violations of a specific check.

• A lower change failure rate.

• A higher pass rate on one project’s changes.

That expectation is what Verify the effect on the next measurement cycle checks against. Without it, the next review has nothing to check against.