One thing is wrong. Everything else works. The risk now is that fixing it costs you the everything else.
This is a different situation from a change that arrived larger than requested. Here you are the one asking for the change, and the danger comes from how you ask. A vague report invites a broad response, and a broad response to a narrow fault is how a working system with one defect becomes a partly-working system with three.
The discipline is unglamorous: describe precisely, gather evidence before requesting anything, correct the smallest thing that accounts for the difference, and check what you did not touch.
Start by separating observed from expected
Before asking for anything, write two sentences.
What actually happens, in terms of what you can see. What should happen instead. Nothing else — no theory about the cause, no suggestion of a fix.
Suppose a summary screen shows the wrong total.
Observed: with three claims of £20, £15 and £5, the total shows £35.
Expected: the total should show £40.
Two lines, and they have already done a lot of work. They give a reproducible case, a specific discrepancy and an implicit boundary — this is about the total, not about claims generally. Compare that with "the totals are broken", which describes a feeling and leaves the scope entirely open.
Resist including your guess about the cause. If you say "I think the loop is skipping the last item", you have redirected attention towards the loop, and if you are wrong the fix will be applied there anyway.
Gather a little evidence first
A few minutes narrowing the fault will save considerably more later, and it is work you can do without writing any code.
Does it happen every time, or only sometimes? With two claims as well as three? With round numbers? What if all the values are identical? Does the figure look like a specific wrong answer — one item missing, a value doubled, rounding — or is it arbitrary?
In the example, trying two claims of £20 and £15 gives £20. That is a much better problem than the one you started with: it is not a rounding issue or an arbitrary fault, it is dropping the last item. You now have a bounded question to ask, and you will be able to tell immediately whether an answer addresses it.
The habit here is worth more than the technique. Every minute spent turning "it's wrong" into "it's wrong in this specific way, under these specific conditions" reduces the size of the change you will need to accept.
Ask for the smallest correction, and bound it
Give the observed and expected behaviour, the narrowing you did, and an explicit boundary.
The claims total is excluding the last item — three claims of £20, £15 and £5 total £35, and two claims of £20 and £15 total £20. It should include every claim shown. Change only the total calculation on the summary screen. Do not alter how claims are stored, the claim list, or anything about the display of individual rows.
That last sentence does most of the protective work. Without it, a reasonable model may decide that the calculation would be clearer restructured, or that the display logic nearby could be tidied while it is in there. Both may even be improvements. Neither is what you asked for, and both make the change harder to verify.
If the response comes back touching more than you allowed, treat that as a signal rather than an inconvenience — it usually means the fault is entangled with something else, which is worth knowing before you accept anything.
Check the fix, then check what you did not change
Re-run the exact case from your observation. Three claims should now total £40. Then re-run the narrowing cases: two claims, identical values, a single claim.
Then — and this is the part most often skipped — look at the neighbours. Does the claim list still show every row? Are individual amounts still formatted correctly? Does an empty list still behave sensibly?
It is easy to treat a fix as exempt from review, on the grounds that it was only putting something right. It is not exempt: a fix can introduce a fault as readily as the work that caused one. That specific failure — the correction succeeds and something adjacent stops working — is common enough to be worth its own treatment: when a fix breaks something that was working.
Know when to stop fixing and go back
Sometimes the second correction does not work either, and the third introduces something new. At that point the useful question is no longer "what is wrong with this code?" but "how did I get here?".
If you have a version you know was correct, going back to it and re-approaching the change as a small, well-described piece of work is almost always faster than continuing. It feels like losing ground. It usually is not: you are exchanging an unknown amount of tangled work for a known starting point.
This is the practical reason for keeping something to return to. Where a verified earlier version exists, a bad correction can simply be abandoned. Where none does, the only direction available is forwards, and that is exactly the pressure that turns one defect into several.
Preserve the result
When the fix is verified — the fault gone, the neighbouring behaviour intact — record that state as one you trust before starting anything else.
The value is not tidiness. It is that the next piece of work now begins from something known-good, so if that one goes wrong you have somewhere to stand. Corrections made on top of unverified corrections are how small faults compound, and the habit that prevents it costs a few seconds. What separates a genuine fallback position from a commit that merely looks like one is the subject of always have something that works to go back to.