When a pattern looks wrong, the useful move is to ask the person who owns the rule, with the evidence attached. The tempting move is to decide you have found a fault and act on it. I have done the tempting thing myself, and I have watched a checker do it on its own. Both times the flag was wrong.
Spotting something odd is a real contribution. It is how most problems get found. The mistake is in what happens next, when the person or the check that spotted it also decides what it means and what to do about it.
In one back office: identical mileage
A back office I worked in processed travel reimbursement requests. Working through them, I noticed something that looked off. The same people were submitting the same mileage, week after week, down to the exact figure.
My first read was a system fault. If the numbers were identical, maybe approvals were not saving and the same request was coming back around. It was a plausible theory. It fit the data in front of me. I wrote it into a draft update to my supervisor as a likely fault.
Before that went anywhere, the operator who owned the process looked at it and said, simply, that people drive the same routes every week. Same destination, same distance, same number. Identical figures were not a symptom. They were normal.
So the flag was withdrawn, and the rule went into the notes: repeat mileage on a regular route is expected, and on its own it is not a reason to hold anything. That one line saved the next person the same detour.
Nothing bad happened, because the theory stayed a draft. But it is easy to see how it could have gone. A "likely system fault" sent upward starts its own chain. Someone checks the system, someone asks the vendor, someone starts doubting approvals that were fine. All of that from a pattern with an ordinary explanation the owner could give in one sentence.
A question costs the owner thirty seconds. A wrong conclusion costs trust, and usually someone else's afternoon.
On another team: the correction that broke a correct value
On another team, the flag came from a check rather than a person. Records were reviewed by a second pass that compared each entry against its supporting material and corrected anything that seemed to disagree.
One record described a product's packaging as a bag. The person who made that entry had looked at the photo, and the photo showed a bag. The checker read the text on the page instead, which said box, and "corrected" the record. A correct value was overwritten with a wrong one, and nothing in the record showed that it had happened.
The problem was not that the checker was wrong. Checkers will be wrong sometimes, and that is fine. The problem was that the checker had write access to the answer. Its opinion went straight into the record, with nobody in between who knew which source the rule said to trust.
The fix was not a better checker. It was a different route. Flags now go to a list with the evidence attached. The person who set the rule decides. Only confirmed errors get changed.
Why flags turn into decisions
It happens for understandable reasons. Spotting a pattern feels like progress, and acting on it feels like finishing the job. Asking feels slower. And the person who spotted it is usually close enough to the data to believe their own theory.
But spotting a pattern and knowing what it means are different skills. The person running a check sees the data. The person who owns the rule knows why the data looks the way it does: the regular routes, the photo that outranks the text, the exception agreed months ago and never written down. Without that context, a flag is a guess with good evidence attached.
That is still valuable. A guess with good evidence is exactly what an owner wants to see. It just has to arrive as a question.
How to write a flag
The format I use now is short and always the same:
I see X on these rows. Is this expected?
Then the rows, attached, not described. Three parts:
- What I see. The pattern, stated plainly, without a cause. "Same mileage on these twelve requests," not "approvals are not saving."
- The rows. The actual records, so the owner can check in seconds instead of rebuilding your search.
- The question. Is this expected? Not "should I fix it?", and never "I have fixed it."
The owner answers in one of two ways. Yes, it is expected, and here is why: you record the rule and close the flag. Or no, that is wrong: now you have a confirmed error, and the change has an owner behind it.
Either answer is useful. The first is arguably more useful, because it turns an unwritten rule into a written one, and the next person who sees the same pattern does not have to ask.
How to set up a checker
If you have a second pass of any kind, a reviewer, a script or a spreadsheet rule, give it somewhere to put its opinion that is not the answer.
- A flag column next to the record. Never write access to the answer column.
- A short reason in every flag, in plain words.
- One named person who owns each rule and reviews flags against it.
- Changes to the answer only after that owner confirms.
- A list of rules learned from withdrawn flags, kept where the checker can see it.
The last one matters more than it looks. Every withdrawn flag is a rule the checker did not know. Write it down, and the same false flag stops coming back.
The expense hold checker on this site works on the same principle. It holds the rows that need a note, says why each one is held, and drafts the request for the missing note. It does not reject anything, and it treats repeat trips on a regular route as normal. The decision stays with a person.
The takeaway
Write flags as "I see X on these rows. Is this expected?" and attach the rows. Send them to the person who owns the rule, not to whoever can make the change fastest.
Give every checker a flag column and never write access to the answer column. When a flag turns out to be wrong, record the rule that explained it. A flag is the start of a question. Only the owner gets to turn it into a decision.
Flags go to the rule owner as questions, with rows attached. Values change only after the owner confirms.