Tag Archives: false positive matching

Police Untelligence

From The Register comes this wonderful example of the problems that can arise where data is used for unintended purposes, resulting in poor quality outcomes for all involved.

The NYPD have been regularly raiding the home of an elderly Brooklyn couple. They’ve been hit 50 times over the past 4 years, which might mark them out as leading crime kingpins but for the fact that their address has wound up included in police data used to test notification systems. The Reg tags this as “a glitch in one of the department’s computers”, but Information Quality trainwreck observers will immediately recognise that the problem isn’t with the technology but with the Information.

The trainwreck is compounded by two facts which emerge in the article:

  1. NYPD believed that they had removed the couple’s address from the system back in 2007, but it appears to have not been the case (or perhaps it was restored from a backup)
  2. The solution the NYPD have now implemented is to put a flag on the couple’s address advising officers NOT to respond to calls to that address.

The latter “solution” echoes many of the pitfalls information quality professionals encounter on a daily basis where a “quick fix” is put in to address a specific symptom which then triggers (as el Reg puts it) “the law of unintended consequences”.  To cut through implication and suggestion, let’s pose the question – what happens if there is an actual incident at this couple’s home which requires a police response?

What might the alternative approaches or solutions be to this?

(And are the NYPD in discussions with the Slovak Border police about the perils of using live data or live subjects for testing?)

I am who I am, except when I’m not.

Steve Tuck, writing over at SmartDataCollective, shares a tale of an embarassing IQTrainwreck involving his brother. The root cause of Steve’s tale is ‘false positives’ in matching, but it goes to show how simple assumptions or errors in the management of the quality of information can lead to unforeseen and undesired consequences.

Steve’s brother had checked into a hotel for a trade conference. He went and had a shower and was quite surprised to come out of the bathroom to find another man standing in his room. It turned out that they both had the same name and were both attending the same event and the hotel had (despite all the other evidence to the contrary, like different companies and different credit card details) decided to merge the two reservations so two people wound up being booked into the same room.

The second Mr Tuck had to take his bags and go to a different hotel in the end, causing unnecessary aggravation for him (it is always nice to be staying in the hotel a conference is on in… the more relaxed pace over breakfast can help ease you into the day). Steve’s brother had the embarassment of being caught in little more than a towel.

For the embarassment factor and customer service impacts, this meets the criteria for an IQ Trainwreck. 

Thanks Steve.

This isn’t the first time we’ve covered this type of false positive IQ Trainwreck though. A scan of our archives brings up this story from 2007.