A finding should enable the next decision
“The report is wrong” can be a useful first signal, but it is not yet a clear analytical conclusion. The next person needs to know which output, period and expectation to investigate. In my proposed approach, a finding connects a rule, observation, evidence, significance and required decision. It should make the next step possible without forcing the reader to reconstruct the entire conversation.
The aim is neither impressive language nor premature blame. A specialist should be able to repeat the check, while a decision maker should understand its consequence. These readers need different levels of detail, but they must receive the same underlying account. Technical evidence can accompany the core explanation without burying it or quietly expanding the claim beyond what was actually examined.
Documented case: TSB in the United Kingdom
On 20 December 2022, the FCA and PRA announced action against TSB concerning its April 2018 systems migration. Their public account distinguishes successful data migration from technical platform failures and disruption to banking services. [1] This distinction illustrates precise description: success in one part of a change does not establish that the whole customer service is working.
I did not participate in that investigation, and I am not treating its wording as a universal reporting template. My limited inference is that verified component outcomes and customer effects should be expressed separately. Saying only “the migration failed” loses useful information. A broad shorthand can direct investigation towards the wrong area even when it conveys something generally true about an unsuccessful programme.
Hypothetical example: missing export records
Imagine a fictional bank whose monthly export contains 988 unique identifiers against 1,000 in an approved input population for the same period. The observation is a difference of twelve identifiers. A filter causing the difference is initially a hypothesis. Financial harm to customers would require further evidence. I would keep those three levels distinct from the beginning of the account.
I would first check comparability: reference date, inclusion rules, uniqueness and approved exclusions. If the export intentionally excludes closed contracts while the input list includes them, the difference may follow an agreed rule. The figures illustrate a proposed method only. They are not findings about TSB, another actual bank or a real group of customers, and they do not establish an acceptable error rate.
Write an opening that can be checked
My opening would name the output and period: comparison of the September export with the agreed input list found twelve identifiers absent despite the applicable inclusion rule. I would add the output version and evidence reference. That describes the departure without automatically attributing it to software, a team or an individual. The reader can identify both the object and basis of the check.
The next sentence would state scope. Perhaps the review compared identifiers but did not validate amounts or accounting consequences. Such limitations belong near the conclusion rather than in a remote footnote. Otherwise readers may extend confidence to areas that were never examined. Precision includes explaining what the available evidence does not yet support, particularly when a short management statement will circulate separately from detailed working papers.
Establish where the expectation comes from
A difference becomes a finding relative to a criterion. I would identify whether that expectation comes from an approved requirement, internal rule, contract or another source. “We have always done it this way” can describe practice without conclusively defining correctness. If the criterion is unclear, resolving it is a separate task before presenting an unequivocal conclusion that someone failed to meet it.
Where the rule changed, I would retain its version and effective date. The fictional export might comply with an old specification and conflict with a new requirement not yet implemented. That distinction changes the explanation and remedy. The team might need an implementation fix, clarified requirements or an agreed transition. Without a precise criterion, these possibilities collapse into an unhelpful instruction to fix the report.
Separate impact from the worst possibility
I would distinguish established consequences from plausible dependencies. If twelve identifiers are absent, the account can identify subsequent processes using the export. It should not claim that all subsequent operations were already incorrect without checking. The next investigation should establish or bound actual reach. A possible impact is useful when it identifies a concrete pathway and a way to verify whether it occurred.
Numbers require equal care. Twelve out of one thousand is 1.2% of the compared population. That percentage does not automatically apply to the portfolio or other months. A deliberately selected set of suspicious cases cannot establish ordinary prevalence. Numerical precision without a correctly described denominator can create more misunderstanding than a restrained explanation of the known boundary of the review.
Make causal hypotheses testable
If a filter is suspected, I would explain the basis and proposed test. Perhaps all missing identifiers share one category. We still need to check whether that category also appears among included records. A shared feature alone does not prove a mechanism. The hypothesis should organise a focused investigation while leaving competing explanations open until the evidence distinguishes them.
Once tested, I would update the account and preserve evidence supporting the revised conclusion. A rejected hypothesis should not survive as an insinuation in the final report. Google SRE offers further reading on incident accounts and learning without premature blame. [2] I interpret this as supporting precise accountability, including decisions and failed safeguards, rather than a reason to avoid describing how responsibility operated.
Match recommendations to the mechanism
For the fictional export, I would separate correcting the present file, removing the cause and verifying future operation. Each needs an owner and observable result. “Improve data quality” is too broad if the evidence identifies one selection condition. Correcting twelve records is too narrow if that condition affects other periods. The remedy's scope should follow the demonstrated mechanism rather than the easiest task to assign.
I would ask whether the recommendation addresses the cause, can be implemented and has a clear success criterion. Training will not necessarily repair an ambiguous rule or defective system filter. An automated check can help only when its expectation is correct and somebody acts on its findings. Accurate wording therefore affects the quality of the next decision, rather than serving only presentation or record-keeping needs.
Review whether the explanation stands alone
Before closure, I would ask a colleague unfamiliar with the analysis to read the core account. Can they explain what happened, what supports the conclusion and what should happen next? If every sentence needs verbal interpretation, the text is unfinished. Detailed appendices can remain technical while the main finding independently preserves the right boundaries of evidence, uncertainty and responsibility.
Summary and recommendations
A clear finding connects expectation, observed condition, evidence, significance and action. I recommend separating observation from hypothesis and demonstrated impact from possible consequences, while naming the population and period behind every percentage. My proposed contribution is an account that another person can verify, use to select a proportionate remedy and later revisit to establish whether that remedy actually worked in normal operation.