The Verified Pack That Is Not Verified
You lead a six-person data quality team at a payments company. It is Friday 16:40. A senior manager two levels above you, who is not your line manager, wants the monthly merchant-compliance pack released to the client by Monday 09:00. Your own manager is on leave until Wednesday and no deputy has been named.
At 15:00 a junior analyst, Maya, found that 12 of 8,000 records have mismatched settlement dates caused by a known upstream bug. The compliance percentages are unaffected to two decimal places, but the raw record list in the appendix would not reproduce the totals. Fixing the data needs a developer who returns Tuesday. The senior manager has already emailed the client saying the pack is 'final and verified', and has told you by phone to 'just send it, nobody reads the appendix'. Maya has asked you not to put her name on the issue log because she is six weeks into her probation.
The client contract requires notification of any material data defect within two business days of discovery.
1. What do you do in the next two hours? Set out your actions in order and explain why that order.
Read the worked answer
1. Quantify the defect precisely (first 30 minutes). Confirm the count (12 of 8,000 = 0.15%), which figures are affected, and whether any of the 12 touches a compliance threshold rather than only the appendix. Materiality determines everything downstream; without it you cannot weigh the contract's notification duty, and you would be arguing from impression.
2. Put it in writing to the senior manager today. A phone instruction to 'just send it' is not a record. Send a short email: the defect, its scope, the fact that the appendix will not reconcile, the three options (release with a stated data qualification; release totals only and defer the appendix; delay to Tuesday), and your recommendation. Ask for a written decision. This protects the analyst, the client and you.
3. Check the contract notification clock in parallel. Two business days from Friday discovery runs into early the following week. Do not let a Monday release quietly consume the notification window without a decision on record.
4. Escalate if no written answer. Your manager is away; go to the compliance lead or your manager's manager. A safety-of-data issue does not wait for a return date.
5. Do not send the pack as 'final and verified'. That label is factually wrong and the appendix would prove it.
2. The senior manager repeats the instruction to send it unchanged. Draft the substance of what you would say, and explain what you would not do.
Read the worked answer
Substance of the message.
- State the facts without adjectives: 12 of 8,000 records (0.15%) have mismatched settlement dates from a known upstream bug; compliance percentages are unaffected; the appendix record list will not reproduce the totals.
- State the consequence: releasing it as 'final and verified' would make a statement the pack itself contradicts, and the contract requires notification of material defects within two business days.
- Offer options with a recommendation: release Monday with a one-line data qualification and the appendix marked provisional, which preserves the deadline and the accuracy of the claim; or release totals only and issue the appendix Tuesday.
- Ask for a written decision, and say what you will do if none arrives: proceed with the qualified release and copy the compliance lead.
What I would not do. I would not send the pack unchanged, and I would not remove the appendix quietly to make the totals reconcile - that is worse, because it destroys the evidence. I would not amend the senior manager's client email myself; I do not own that correspondence, so I would propose the correction and let the sender issue it.
Why not just comply. The instruction comes from someone senior, but seniority does not transfer accuracy. The exposure is a demonstrably false 'verified' statement to a client, plus a missed contractual notification.
3. How do you respond to Maya's request to keep her name off the issue log?
Read the worked answer
Refuse the substance, address the fear. The log records the finding, the date, the scope and the owner of the fix. It does not record fault, and Maya did not create the upstream bug - she detected it. Removing her name would either leave the entry ownerless or attribute it to someone who did not find it, which damages the log's value as an audit trail. If the entry later surfaces, an altered record is far more damaging to a probationer than an accurate one.
What I would do instead.
- Keep the entry accurate and neutral in wording: 'Defect identified 15:00 Friday during routine reconciliation by data quality analyst.'
- Tell her, in writing, that she raised a valid issue, that this is the behaviour the team wants, and that it will be recorded as such in her probation review - early error-detection during probation is evidence of judgement, not a mark against her.
- Take the escalation onto myself: the entry names me as the person who decided the release treatment, so the risk sits with the decision-maker.
The general principle. A culture where finding problems is penalised produces reports that stop containing problems, and the next defect is found by the client instead. Protecting the analyst and keeping the record accurate are the same action, not competing ones.