Nothing found isn't the same as nothing checked

One of the checks in my first UK company screening tool looked for directors who had been disqualified. Looking at its reports, you could easily think it was doing a thorough job. It kept coming back clean.

I followed one lookup through the code. The tool took a director’s identifier from the company’s list of officers and sent it to a different Companies House service, the disqualified-directors register. That service uses a different identifier. It answered 404: no record found under that ID.

At that point the program already knew the most important thing: the lookup had failed. Then my code threw that away and treated the missing record as evidence that the person was clear. It would have done the same for a director who really was disqualified. The check could never fire.

Two searches that look alike on a report

Imagine handing a colleague one of these notes:

• “I searched the register for this director, checked the matches and found no disqualification.”
• “I couldn’t look this director up with the ID I had.”

The first tells them what you did. The second tells them what is still outstanding. My program turned both into the same answer, so the person reading the report had no reason to check by hand or try again.

Once I knew what to look for, I found other ways a report could make the same mistake. A list can stop after the first page. A search can stop at fifteen people when the firm has 336 partners, as Linklaters did. A news search can return articles, but the step that reads them can fail. In each case, a program that only counts the warnings it raised reports zero.

How a check now earns “clear”

In the rebuild, which became the UK Company Pre-Screen, every check answers three questions in order.

For directors, the rebuilt check searches the register by name and compares the date of birth. If a name matches but there’s no date of birth to compare, it says it can’t confirm the match and asks for one. Either way, the gap is on the case page, and a reviewer can decide how to close it.

The same idea caught a different fault on another report: My AI agent called a fined bank “medium risk”. No model made that call. is about a rating that no model chose.

The test I’d run on another system

Pick a lookup whose result might persuade somebody to stop looking. Run a case where the search completes and finds no match, and save what the user sees. Then repeat with a deliberately wrong identifier, or with the source switched off. Compare the two screens, including any summary a colleague might receive by email.

If both say “clear”, you’ve reproduced the defect. Fix the point where the two outcomes become one value, then test the exported report too. A log can describe the failure perfectly while the sentence a person acts on still says everything is fine.

Limits

• Every gap that becomes visible is work for someone. A “couldn’t check” only helps if somebody owns the queue it lands in and closes it.
• Matching on name and date of birth can still miss a person who changed their name, or flag a different person with the same name and birth month. That’s why a match asks a person to confirm.
• This was found by reading the code after a run, not by a test. The rebuild has tests that withhold a source and check the result says so.

First published 19 May 2026. Updated 8 Nov 2026: retold around the lookup that used the wrong ID, with a test you can run on your own system.