सवालों का जवाब देने वाले किसी भी सिस्टम में यह वास्तविक प्रलोभन होता है कि यह मानने के बजाय कि किसी सवाल का भरोसेमंद जवाब नहीं दिया जा सकता, हमेशा कुछ न कुछ लौटाया जाए। खास तौर पर लोकेशन डेटा के लिए, इस प्रलोभन में आना सक्रिय रूप से नुकसानदेह है, क्योंकि विश्वसनीय दिखने वाला लेकिन गलत जवाब, जिस भी फ़ैसले में वह इस्तेमाल होता है, उसके लिए आम तौर पर इस ईमानदार स्वीकारोक्ति से कहीं ज़्यादा नुकसानदेह होता है कि डेटा किसी भरोसेमंद जवाब का समर्थन नहीं करता।
सीधे शब्दों में कहें तो तर्क साफ़ है। एक खाली (null) परिणाम, या ऐसा परिणाम जिस पर स्पष्ट रूप से कम भरोसे का निशान लगा हो, ऐसी चीज़ है जिसे एक अच्छी तरह डिज़ाइन किया गया एप्लिकेशन पहचान सकता है और सोच-समझकर संभाल सकता है: उपयोगकर्ता से स्पष्टीकरण माँगना, कोई व्यापक डिफ़ॉल्ट लागू करना, या रिकॉर्ड को मैन्युअल समीक्षा के लिए चिह्नित करना। लेकिन गढ़ा गया अनुमान, जो हर दूसरे भरोसेमंद परिणाम जैसा ही दिखता है और जिसमें कोई दिखने वाला संकेत नहीं होता कि यह असल में कमज़ोर या अस्पष्ट मिलान था, उसे न तो पहचाना जा सकता है और न ही अलग से संभाला जा सकता है, क्योंकि बाहर से वह एक सचमुच ठोस उत्तर से बिल्कुल अलग नहीं दिखता, तब तक जब तक वह आगे कहीं कोई असली, दिखने वाली समस्या पैदा न कर दे, जिसे उसके असली स्रोत तक वापस खोज पाना अक्सर मुश्किल होता है।
इसीलिए किसी अस्पष्ट या हल न हो सकने वाली क्वेरी को या तो कोई परिणाम नहीं लौटाना चाहिए, या ऐसा परिणाम लौटाना चाहिए जिसका confidence स्कोर उसमें शामिल असली अनिश्चितता को ईमानदारी और स्पष्टता से दिखाए, बजाय इसके कि जियोकोडर चुपचाप कई संभावित उम्मीदवारों में से एक चुन ले और उसे उसी दिखावटी निश्चितता के साथ पेश करे जो एक स्पष्ट मिलान की होती है। यही सिद्धांत सटीकता (precision) पर भी लागू होता है: किसी परिणाम को कभी भी उस सटीकता स्तर से बारीक स्तर का दावा नहीं करना चाहिए जिसका डेटा असल में समर्थन करता है, भले ही हमेशा कुछ ज़्यादा विशिष्ट दिखने वाला लौटाने का दबाव हो। अनुमान के आधार पर house बताने से ईमानदारी से city बताना बेहतर नतीजा है।
इस तरह के डेटा पर कुछ भी बनाने वाले किसी भी व्यक्ति के लिए व्यावहारिक निष्कर्ष यह है कि अपने एप्लिकेशन को ऐसे डिज़ाइन करें कि वह null और कम भरोसे वाले परिणामों की सचमुच उम्मीद करे और उन्हें सहजता से संभाले, रिस्पॉन्स का एक सामान्य, रोज़मर्रा का हिस्सा मानकर, न कि किसी दुर्लभ अपवाद की तरह जिसके लिए बाद में सोचकर अलग से विशेष हैंडलिंग जोड़ दी जाए। जिस फ़ॉर्म में केवल उच्च भरोसे वाले, पूरी तरह हल हुए परिणामों के लिए ही सुखद रास्ता हो और बाकी किसी भी चीज़ के लिए कोई सोचा-समझा व्यवहार न हो, वह आखिरकार उलझन भरे तरीके से टूटेगा, जब उसका सामना ऐसी क्वेरी से होगा जिसे डेटा सचमुच भरोसे के साथ हल नहीं कर सकता, और ऐसा ज़्यादातर शुरुआती डिज़ाइनों के अनुमान से कहीं ज़्यादा बार होता है।
हर परिणाम पर precision और confidence दोनों की जाँच करना, और जब इनमें से कोई भी आपके विशिष्ट उपयोग के लिए ज़रूरी सीमा से नीचे चला जाए तब के लिए एक सोचा-समझा फ़ॉलबैक व्यवहार रखना, यही फ़र्क है उस एप्लिकेशन में जो कठिन मामलों पर सहजता से कमज़ोर पड़ता है और उस एप्लिकेशन में जो चुपचाप खराब डेटा फैलाता रहता है, क्योंकि उसे कभी भी एक साफ़, स्पष्ट उत्तर के अलावा किसी और चीज़ की उम्मीद करने के लिए डिज़ाइन ही नहीं किया गया था।