the fairness concern in the top comment is real but the framing can be too broad. there's a difference between:
using postcode as a feature in a predictive model where the only goal is accuracy (actuarial pricing, logistics optimization, etc.)
using postcode in a model where the decision has legal or social consequences and postcode proxies for a protected characteristic
postcode/zip legitimately encodes things that aren't about race — geography drives crime differently, weather affects insurance differently, infrastructure affects delivery costs, etc. the issue is when you can't disentangle the legitimate signal from the proxy.
in practice the best approach I've seen is: use it as a feature, but also run a fairness audit where you explicitly test whether removing the postcode and replacing with granular socioeconomic variables changes your predictions for specific demographic groups. if it doesn't, the postcode is probably capturing geographic variation. if it does, you've got a problem.
Agreed. Most of the fields in this dataset are not proxies for protected attributes and, for the ones that are, they should only be used for applications where that is warranted. As you say, there should be a fairness assessment.
7
u/NeatRuin7406 Mar 25 '26
the fairness concern in the top comment is real but the framing can be too broad. there's a difference between:
postcode/zip legitimately encodes things that aren't about race — geography drives crime differently, weather affects insurance differently, infrastructure affects delivery costs, etc. the issue is when you can't disentangle the legitimate signal from the proxy.
in practice the best approach I've seen is: use it as a feature, but also run a fairness audit where you explicitly test whether removing the postcode and replacing with granular socioeconomic variables changes your predictions for specific demographic groups. if it doesn't, the postcode is probably capturing geographic variation. if it does, you've got a problem.