A path is closed when the retest says so

It's common practice to treat a remediation as done once the underlying change merges and deploys. That's a reasonable proxy in most engineering workflows, but it's the wrong proxy for exposure. A configuration change can ship correctly and still leave a path reachable, because the model of what the fix would close and the reality of what it actually closes are not guaranteed to match. The only way to know which one happened is to go back and check the same route the finding described in the first place.

SCARP treats a change as closing exposure only after the original path is retested and found blocked — not when the change is approved, and not when it deploys. This sounds like a small distinction, but it changes what a report is allowed to claim. A fix that was expected to remove four paths doesn't get credit for four until a retest confirms four; if the retest only confirms three, the report says three; and the fourth stays open, owned, and queued for the next check.

That queuing matters as much as the count. A path that's still reachable after a fix isn't a failure of the process — it's exactly the kind of result the process exists to surface. The alternative, where a fix is marked closed on the strength of a deploy event, hides that fourth path until someone finds it the hard way.

A report that says three of four paths closed, one still reachable, is less comfortable to read than one that says the finding is resolved. It's also the only one of the two that a reader can act on. Projected, realized, and remaining are three different numbers, and collapsing them into a single 'fixed' status throws away the information that tells an owner exactly what's left and where to look. An underwriter or a security lead deciding whether to trust a report gets more value from a partial result they can verify than from a full one they have to take on faith.

This is also why retest results are timestamped and tied back to the same path identifiers as the original finding, rather than summarized as a status flip. A closure claim should be traceable to the specific check that produced it, the same way an observation is traceable to the specific source that produced it. Neither should ask the reader to trust a label instead of the evidence behind it.

In practice, most remediations land somewhere between fully closed and fully open. A fix removes most of what it was expected to, a retest confirms exactly how much, and whatever's left gets carried forward instead of quietly dropped. That's a slower, more honest way to report progress than a queue of tickets marked resolved, but it's the only version of 'closed' that means what it says.