Comment by avidiax
17 hours ago
You can look at airport security as an example. Bombs and guns are quite rare in carry-on luggage. It would be far too boring for most operators, which would mean that they tend to tune out of their screening job.
So what the x-ray interface does, is randomly insert guns and bombs into the scan at a relatively frequent rate. The operator must click on these problem areas. If it is a synthetic object, it then disappears and the operator can continue screening the bag. If it isn't synthetic, the bag gets shunted for manual inspection.
So for a self-driving car, if it must be monitored (it's not L5 within the driving mission), then you would perhaps need the car to randomly ask the driver to take over, even though it's unnecessary. Or randomly appear to be making a mistake, to see if the user reacts.
If the user doesn't react appropriately or in time, then self-driving is disabled for a time the next time the car starts.
For the queuing system, it perhaps makes sense to inject a certain number of duplicates by default. Say 0.1%. Enough that it simply can't be ignored during development of the clients. Then, when duplicates arise as a consequence of system failures, the code is already expecting this and there's no harm to the workload.
For software, you can often inject the "bad" data only during test time or in dev mode. E.g. a lot of Maps don't guarantee interaction order but in practice it's insertion order or alphabetical. I always feel a bit of sheudenfrued when someone gets bit by this and I get to tell them told you! It's in the spec! But anyway you can randomize the order at a performance loss during testing to prevent people depending on it. We do this, and for i18n strings too (which can of course change if something is retranslated or the format is modified)