A wrong salary is not a bug report.

A wrong salary is not a bug report.

A wrong salary reaches further than the person reporting it. It can reach the rent, the household budget and a promise made at home. We cannot treat that consequence as another item waiting for attention.

The consequence belongs to a person.

A defect in an ordinary piece of software can interrupt an afternoon. Someone tries again, finds another way through or waits for a correction. That can be frustrating and expensive. Pay introduces a different kind of consequence. The person affected may have already committed the money before it reaches their account. A correction later does not move the rent deadline with it.

We run our own payroll on Anusuya Workspace. That makes the consequence close to the work. The person whose record is being considered is part of the business that depends on the result. We do not need a story about an anonymous customer to explain why this matters. We need to remember what the record represents when we decide how carefully to handle it.

An apology can acknowledge a mistake. It cannot make the month unfold as though the mistake never happened. That is why our starting question should be about preventing an incorrect amount from reaching someone, rather than about how quickly we could close a report afterwards. A tidy record of a correction is useful. It is not a substitute for getting the original work right.

Check the meaning, not just the amount.

A salary amount can look plausible and still be wrong. The joining date might belong to another period. Approved leave might not have reached the person preparing pay. A correction might have been understood in conversation but not carried into the record. Checking a total without checking those relationships can leave the very thing that matters untouched.

We should be able to follow an amount back to the person, the period and the decisions behind it. That is a practical standard for review. It means asking whether the record describes the work we intend to pay for, whether a change has taken effect in the right period and whether an exception has been understood. A familiar looking total should not end that conversation.

The small cases deserve attention because they are where assumptions hide. A joining date entered near the end of a month is still somebody's joining date. A bank detail corrected after an offer is still the detail that may receive a salary. A handoff that loses either one is not made harmless by the fact that the rest of the record looks complete.

A second pair of eyes has a job.

Review should not mean asking another person to agree with the person who made the change. It should give them enough context to question it. What was the intended result? Which people and periods could be affected? What would an incorrect result look like? A reviewer who has to reconstruct the reason for a change is being asked to spend attention on the wrong part of the work.

This is also why size is a poor measure of consequence. A short change can alter an amount that somebody acts on. A longer change may affect only how a heading reads. We should direct the second pair of eyes towards the consequence, even when the edit itself looks too small to deserve a conversation. The salary does not know how small the change was.

Timing belongs in the same decision. A change that alters pay should not be put out late on a Friday and left for somebody else to discover over the weekend. The useful question is whether the people who can understand and correct the result are available. A convenient release time for the person making the change may be an inconvenient one for everyone who depends on it.

Responsibility continues after a correction.

If something does go wrong, the person affected needs a clear account of what happened and what comes next. They should not have to carry a message between people who each know only part of the answer. We should be able to establish which record needs attention, who can settle it and how the correction will be checked before it is acted on.

Then we need to look at the conditions that allowed the mistake through. Did a handoff lose context? Was a review asked to check the total without its basis? Did a deadline make an unresolved record look finished? Those questions are more useful than treating the person who noticed the problem as the final step in our checking process.

We build for the ordinary working day, when people have other responsibilities and cannot spend it investigating their own salary. Correctness is treated as a hard requirement because an amount in a record becomes an amount in someone's life. The people who built Anusuya Workspace use it for that work themselves. That is the standard we have to answer to.