An invoice-intake screen now blocks the wording that drove an unattended payment-hold release, but the same instruction works through the supplier portal - what did that fix buy?

## State what the change actually did, in the narrowest true terms The honest description of a screen added to one intake path is: *on that path, spans scoring above this threshold are stopped, and the reported wording scores above it.* Everything else people want to conclude from a green re-test is an over-read. Get the direction of each claim right, because this is where reports go wrong: - A **block** proves that path scored that span above a threshold. It does not prove the class of construction stopped working, and it does not prove a re-authored variant would also score above it. - A **pass** through the portal proves the span reached the assistant's context by another route and was read as instruction. It does not prove the portal is less protected in some measurable sense - it was never routed through anything, and silence is not a measurement. - The **finance write committing again** proves which call ran, not who chose the argument values. That distinction is the finding. ## What the re-test through a second carrier established Re-authoring the same sentence into the supplier-portal comment thread and getting the same settlement effect establishes something a single reproduction on the original path could not: the construction does not depend on the carrier. The carrier was the part the funded change addressed. Therefore the funded change addressed the part that is interchangeable. That is the sentence to put in the report, and it is not an accusation that the money was wasted. The screen is now a real obstacle on one path, and the class of low-effort attempts that only ever tried that path is now stopped. What the report has to say is that the *finding* is not closed, and why. ## Why the finding stays open The workflow runs overnight and unattended. There is no point between the model reading supplier text and the finance write committing where anything is skimmed. So the boundary on what an obeyed span can achieve is the set of operations the workflow may perform - releasing a payment hold, changing banking details on a supplier record, raising a purchase order against a budget line. None of those moved. The behaviour that made this a finding is still reachable, by a route that costs a supplier one submission. A related trap in triage: **do not re-file the portal reproduction as a new finding.** It is the same defect with a different arrival. Splitting it makes the queue look like a stream of injection reports, each one closed by covering one more carrier, and the count of carriers is set by how many free-text surfaces the business relationship exposes - not by anything the reporting team controls. ## What a re-test can and cannot claim Models are probabilistic. One clean reproduction on the portal path shows the construction worked once against one deployment; it is not by itself a reliability claim. Before reporting, say how many runs were tried and how many landed, and describe what varied between them. A finding that reproduces four times in five reads very differently to an owner than one that landed once, and the difference decides how much of somebody's quarter it can reasonably claim. ## What you say to the person who funded it The engineer's job here is not to win an argument about layers. It is to hand back three things: what the change demonstrably covers, what the re-test demonstrably reached anyway, and which change would make the effect stop. The last one is not the intake team's to make, and saying so is the point of the report rather than a criticism of it. ## The shape of the record A triage record that carries the routing decision, the funded change and the re-test result on one screen is worth more than three tickets, because it shows the label and the mechanism side by side and makes the mismatch visible without argument.