The scorer rates deferral as mitigation, because it scores one hop rather than the path
wr-risk-scorer:pipeline scores the action in front of it. Deferring work moves the hazard outside the scored window, so any recommendation to hold work back scores lower on the current hop regardless of whether total risk fell. There's no mechanism to price un-integrated work, so deferral reads as mitigation.
What we saw
The agent scored a deploy/** push to trunk at 20/25, and the identical change on a short-lived branch at 5/25, and recommended the branch.
The branch didn't remove the production Terraform apply. It postponed it. Because the held-back work then had to land separately, it would have produced two applies instead of one.
Re-scored with the whole path stated explicitly, the agent withdrew its own recommendation:
under trunk-based the split produces two applies to reach the same end state rather than one
It only saw it when forced to score the path. Left alone, the recommendation stood, and we followed it.
Why it's structural
The agent is asked "what is the risk of this action?" and answers correctly. Deferral changes which action is being asked about, so it lowers the answer without lowering the risk. A control removes or bounds a hazard; a deferral relocates it. Nothing in the current rules distinguishes those two things, so this is available on every run rather than being a one-off misjudgement.
It's also a bias with a direction: it will always favour smaller batches of change per action, which for teams practising trunk-based development is the opposite of what they want. Our repo makes trunk-based delivery mandatory, and the scorer's recommendation argued against it with a number.
Suggested rule
A control that defers an action does not reduce that action's risk. When a proposed mitigation moves work out of the current action rather than removing a hazard, score the end state, including the deferred action and any additional applies, deploys or releases the split introduces, and call it mitigation only if the total is lower.
Testable form: a scorer recommending "hold this back" must show the total is lower, not merely that this hop is.
One caution on scope
The rule shouldn't over-reach. Some splits genuinely reduce risk: separating an unrelated change out of a risky commit narrows blast radius without deferring anything. The rule needs to bite on deferral of the same work, not on separation of different work. The test is whether the end state still requires the held-back action.
Placement
We first tried to put this in our RISK-POLICY.md, but /wr-risk-scorer:update-policy explicitly scopes the policy to appetite, impact levels, likelihood levels and the matrix, and states that assessment rules and scoring mechanics live in the agent instead. That is the right split, so this belongs in the agent definition rather than being something adopters can configure.
If you want the wording as a patch, say so and I'll open a PR.
The scorer rates deferral as mitigation, because it scores one hop rather than the path
wr-risk-scorer:pipelinescores the action in front of it. Deferring work moves the hazard outside the scored window, so any recommendation to hold work back scores lower on the current hop regardless of whether total risk fell. There's no mechanism to price un-integrated work, so deferral reads as mitigation.What we saw
The agent scored a
deploy/**push to trunk at 20/25, and the identical change on a short-lived branch at 5/25, and recommended the branch.The branch didn't remove the production Terraform apply. It postponed it. Because the held-back work then had to land separately, it would have produced two applies instead of one.
Re-scored with the whole path stated explicitly, the agent withdrew its own recommendation:
It only saw it when forced to score the path. Left alone, the recommendation stood, and we followed it.
Why it's structural
The agent is asked "what is the risk of this action?" and answers correctly. Deferral changes which action is being asked about, so it lowers the answer without lowering the risk. A control removes or bounds a hazard; a deferral relocates it. Nothing in the current rules distinguishes those two things, so this is available on every run rather than being a one-off misjudgement.
It's also a bias with a direction: it will always favour smaller batches of change per action, which for teams practising trunk-based development is the opposite of what they want. Our repo makes trunk-based delivery mandatory, and the scorer's recommendation argued against it with a number.
Suggested rule
Testable form: a scorer recommending "hold this back" must show the total is lower, not merely that this hop is.
One caution on scope
The rule shouldn't over-reach. Some splits genuinely reduce risk: separating an unrelated change out of a risky commit narrows blast radius without deferring anything. The rule needs to bite on deferral of the same work, not on separation of different work. The test is whether the end state still requires the held-back action.
Placement
We first tried to put this in our
RISK-POLICY.md, but/wr-risk-scorer:update-policyexplicitly scopes the policy to appetite, impact levels, likelihood levels and the matrix, and states that assessment rules and scoring mechanics live in the agent instead. That is the right split, so this belongs in the agent definition rather than being something adopters can configure.If you want the wording as a patch, say so and I'll open a PR.