A policy whose controls carry EMPTY configs currently scores 100 on a project whose local run fails hard - so an unconfigured control is silently inert, and a fresh policy governs nothing with no signal anywhere.
Since ComputePlumberScore is the one scoring authority (the platform recomputes through the pinned CLI, never re-implements scoring), this is a CLI-semantics decision:
- Should an empty or absent control config yield
not_evaluable (zero points, out of the denominator - the honest 'this control was not actually evaluated' outcome), rather than pass/100?
- Or expose an explicit 'unconfigured' signal the platform contract can name and surface, so the console can warn that a control governs nothing?
Reported via the platform side (getplumber/monorepo issue #91). The current behaviour lets an org ship a policy that appears green while evaluating nothing.
A policy whose controls carry EMPTY configs currently scores 100 on a project whose local run fails hard - so an unconfigured control is silently inert, and a fresh policy governs nothing with no signal anywhere.
Since ComputePlumberScore is the one scoring authority (the platform recomputes through the pinned CLI, never re-implements scoring), this is a CLI-semantics decision:
not_evaluable(zero points, out of the denominator - the honest 'this control was not actually evaluated' outcome), rather than pass/100?Reported via the platform side (getplumber/monorepo issue #91). The current behaviour lets an org ship a policy that appears green while evaluating nothing.