I'm not sure exactly what you mean. Do you mean that foreign keys just make sure that a value is one of a proscribed list and don't guarantee that the chosen value is the correct choice from that list?

Larry English used to give the example where call centre staff predominantly selected "Broken Leg" from a list of complaints because they were bonussed on the number of claims entered. Data quality did not benefit them and "Broken Leg" was the first entry on the drop down list so choosing it let them enter data faster.

If that is the type of problem you are describing then that is a business process problem. I'd sooner have such a glaringly obvious data problem than a random data entry problem.

Foreign keys, unique constraints and check constraints complete with a well designed application that works in harmony with the DB certainly increases the probability of good data but I have yet to see the truly idiot proof app. I've seen the harmonious DB/app partnership perhaps twice in my career and that was because the DBA and developers worked exceptionally well together and held each other in high esteem.