खाली शेल: क्रिकेट डेटा पाइपलाइन में वह विफलता जो एरर नहीं देती

रात 11:04 बजे बेंगलुरु में स्क्रीन पर एक JSON फाइल खुली थी और वह पूरी तरह वैध थी। नौ फील्ड, नौ में से आठ खाली या N/A, और एक में सिर्फ एक शब्द — cricket_world। कोई एरर नहीं आया। कोई चेतावनी नहीं उठी। पार्सर खुश था, स्कीमा खुश था, डैशबोर्ड पर हरी बत्ती जल रही थी। और उस फाइल में एक भी तथ्य मौजूद नहीं था।

यहीं से मेरी आदत शुरू होती है। सैंसठ मैच, एक हॉस्टल का कमरा, और एक स्प्रेडशीट जिसे कोई नहीं देखेगा — 2026 में मैंने 1,584 शॉट्स हाथ से कोड किए थे, क्योंकि मुझे ब्लैक-बॉक्स इवेंट फीड पर भरोसा नहीं था। उस काम ने एक बात पक्की कर दी जो आज रात फिर लौटी: जो रिकॉर्ड खाली है, वह गलत भी हो सकता है, और वह गलती अपने आप कभी नहीं दिखती।

संदर्भ: स्टेज-1 से क्रिकेट न्यूज़रूम तक का सफर

किसी भी क्रिकेट न्यूज़रूम में स्टेज-1 एक्सट्रैक्शन का काम साफ है। कच्चे स्रोत से तथ्य-इकाइयाँ निकालना, हर इकाई के साथ यह दर्ज करना कि वह किससे आई है — बोर्ड का प्रेस रिलीज़, आईसीसी का सर्कुलर, मैच रेफरी की रिपोर्ट, या लेखक का अपना अनुमान — और हर इकाई पर एक टाइमस्टैम्प टाँगना। स्टेज-2 इन इकाइयों को जोड़कर तर्क बनाता है। अगर पहली मंजिल पर ईंटें नहीं हैं, तो दूसरी मंजिल पर जो बनेगा वह इमारत नहीं, मंच का सजावटी पर्दा होगा।

CricSultan जैसे प्रकाशन मानक इसीलिए ट्रेसेबिलिटी पर अड़ते हैं। हर दावे के साथ स्रोत, तारीख और इकाई का नाम चाहिए, ताकि पाठक खुद जाँच सके। यह मानक तब तक आसान लगता है जब तक पाइपलाइन चल रही होती है। जिस पल वह चुपचाप खाली लौटती है, वही मानक सबसे पहले टूटता है — क्योंकि जाँचने के लिए कुछ बचता ही नहीं।

यहाँ एक अंतर समझना जरूरी है। पाइपलाइन का क्रैश होना एक तोहफा है। क्रैश शोर मचाता है, लॉग छोड़ता है, किसी को जगाता है। खाली शेल कुछ नहीं करता। वह हर डैशबोर्ड पर सफलता जैसा दिखता है, क्योंकि तकनीकी रूप से वह सफल है — स्कीमा मैच हुआ, टाइप सही हैं, फाइल जगह पर पहुँच गई। संरचना का सही होना सामग्री के मौजूद होने का सबूत नहीं है, और हमारे उद्योग का बड़ा हिस्सा इन दोनों को एक ही चीज समझकर चलता है।

घरेलू क्रिकेट में यही समस्या दूसरे रूप में रोज खड़ी मिलती है। रणजी का कोई मैच खेला गया, नतीजा आ गया, लेकिन बॉल-बाय-बॉल रिकॉर्ड किसी सार्वजनिक डेटाबेस में नहीं है। रिकॉर्ड का न होना घटना के न होने की गवाही नहीं देता। उसी तरह, इस फाइल में Information Points का खाली होना यह नहीं कहता कि स्रोत में तथ्य नहीं थे। यह सिर्फ इतना कहता है कि तथ्य दर्ज नहीं हुए, और किसी ने पूछा नहीं।

मुख्य विश्लेषण: नौ फील्ड, तीन विफलता-हस्ताक्षर

आज रात जो कुछ भी मेरे पास है, वह यही दस्तावेज है। तो इलाज यही है — दस्तावेज को ही डेटा मान लेना।

पहला हस्ताक्षर: वैध लेकिन सामग्री-रहित JSON। Article Title N/A, Article Source N/A, Article Type Unclassified, Information Points खाली सूची। इनमें से कोई भी अकेला फाइल को रोकने के लिए काफी नहीं, और चारों मिलकर भी नहीं रोके, क्योंकि स्कीमा में कहीं यह लिखा ही नहीं था कि इनके खाली होने पर क्या होगा। स्कीमा ने आकार तय किया, गुणवत्ता नहीं।

दूसरा हस्ताक्षर: बिना सबूत का लेबल। पूरे दस्तावेज में एक ही फील्ड भरी है — Domain Label: cricket_world। बाकी सब खाली। यानी यह लेबल अपने अंदर की किसी सामग्री से समर्थित नहीं है; वह बाहर से आया एक पूर्वानुमान है। मेरे काम की भाषा में, डोमेन लेबल डेटा नहीं होता, वह डेटा के बारे में एक परिकल्पना होती है। और अगर वह परिकल्पना अकेली खड़ी हो, तो उसे निष्कर्ष की तरह इस्तेमाल करना ठीक वैसा है जैसा किसी पुराने स्कोरकार्ड से टीम की मंशा पढ़ लेना।

तीसरा हस्ताक्षर: खुद पर लौटता हुआ सत्यापन। एंटिटीज के सामने लिखा है — ऊपर दिए गए Information Points से पहचानें। ऊपर Information Points खाली है। स्रोत-गुणवत्ता के सामने लिखा है — स्रोत फील्ड से आँकें। स्रोत फील्ड मौजूद ही नहीं। यानी सत्यापन का निर्देश उसी खाली इनपुट की ओर इशारा कर रहा है जिसे उसे जाँचना था। इसका तकनीकी नाम सर्कुलर डिपेंडेंसी है और इसका व्यावसायिक नाम है — कोई जाँच नहीं हुई।

इन तीनों से एक बात निकलती है जो पाइपलाइन के डिज़ाइन से जुड़ी है, सिर्फ इस एक फाइल से नहीं। विफलता एक्सट्रैक्शन की मंजिल पर नहीं, असेर्शन की मंजिल पर हुई — जहाँ यह तय होना चाहिए था कि किस स्थिति में यह आउटपुट आगे नहीं जाएगा। उस मंजिल को किसी ने बनाया ही नहीं।

इसीलिए अब मैं हर पाइपलाइन के लिए एक फेल-क्लोज गेट लिखती हूँ, और उसे पाइपलाइन के बाहर रखती हूँ ताकि वह पाइपलाइन के मूड पर निर्भर न रहे। गेट सीधा है: Information Points में कम से कम तीन इकाइयाँ हों; हर इकाई के साथ claim और source_field दोनों हों; Title और Article Type भरे हों; published_at पूरी तारीख के रूप में मौजूद हो; हर एंटिटी कम से कम एक इकाई से जुड़ती हो; और Domain Label तभी स्वीकार्य हो जब उसे समर्थन देने वाली कम से कम एक इकाई मौजूद हो, वरना लेबल null कर दिया जाए। जहाँ कोई शर्त फेल हो, वहाँ आउटपुट आगे नहीं, पीछे जाता है — कच्चे फेच के साथ।

यह कठोरता दिखावटी नहीं है। 2026 के कोडबुक वाले प्रोजेक्ट में मैंने 10 प्रतिशत एंट्रीज़ दोबारा जाँची थीं। कल्पना कीजिए कि वह री-चेक खाली पंक्तियाँ लौटाता और कोई एरर न देता। 1,584 शॉट्स का पूरा ढाँचा खड़ा रहता, हर स्तंभ भरा दिखता, और नीचे कोई सच न होता। वह डेटासेट मिथक होता, विश्लेषण नहीं। री-चेक का पूरा मकसद यही है कि वह चुप न रहे।

पास कम्प्लीशन उद्धृत करने से पहले पूछिए कि पास किसने गिने थे। आज रात मेरे पास गिनने के लिए एक भी पास नहीं है — और इसलिए सही डिलीवरेबल मैच रिपोर्ट नहीं है। सही डिलीवरेबल यह डेटा ब्रीफ है, जो अनुपस्थिति का हिसाब देता है। खाली तथ्य-सूची पर लिखी गई रिपोर्ट पत्रकारिता नहीं होती; वह सजावट होती है, और सजावट को स्रोत नहीं माना जा सकता।

रिकवरी के तीन रास्ते हैं और उनका क्रम मायने रखता है। पहला — मूल पाठ। दूसरा — पूरा किया गया स्टेज-1 आउटपुट, जिसमें हर claim के साथ source_field और timestamp हो। तीसरा — कच्चा फेच या एरर लॉग, ताकि पता चले विफलता इनपुट की थी या एक्सट्रैक्शन की। मैं पहला रास्ता पहले लूँगी, क्योंकि वह खराब हो चुकी मंजिल को पूरी तरह बायपास कर देता है। बाकी दो रास्ते भी काम के हैं, पर वे उसी मंजिल से होकर जाते हैं जिसने आज रात धोखा दिया।

उलटा कोण: गलती पाइपलाइन में नहीं, माँग में भी है

सुविधाजनक कहानी यह है कि ऊपर की मंजिल पर एक बग था और उसे ठीक कर दिया जाएगा। मेरी आपत्ति यहाँ है।

आज रात मुझसे 1,649 शब्द माँगे गए। लंबाई की संख्या स्पष्ट थी। तथ्यों की न्यूनतम संख्या कहीं लिखी नहीं थी। यह असमानता ही असली बग है। जिस ब्रीफ में शब्द-गिनती तय हो और साक्ष्य की न्यूनतम सीमा तय न हो, वह खाली शेल को न्योता देती है — और फिर पाइपलाइन पर इल्ज़ाम डालना सुविधाजनक हो जाता है।

यहाँ एक गुणात्मक इनपुट है जिसे मेरा गेट नहीं देख सकता: संपादक का यह अनुमान कि आज रात इस विषय पर सामग्री जरूरी है। मॉडल के लिए वह अदृश्य है, और वह अदृश्यता ही खतरनाक है। मैं उसे साफ कहती हूँ — अगर संपादक बताए कि मूल लेख मौजूद है और दस मिनट में चिपका दिया जाएगा, तो मैं रुक जाऊँगी। उस हालत में बाधा सत्य की नहीं, ट्रांसपोर्ट की है, और ट्रांसपोर्ट की बाधा पर लिखा हुआ लेख कभी नहीं लिखा जाना चाहिए। बात सिर्फ इतनी है कि मूल लेख आए, तभी।

आगे का संकेत

असेर्शन को पहले से दर्ज कीजिए। जो पाइपलाइन यह नहीं बता सकती कि वह किस हालत में विफल मानी जाएगी, उसका परीक्षण हुआ ही नहीं — वह सिर्फ चली है। और इस हफ्ते के क्रिकेट-चक्र में कितने टुकड़े ऐसे लिखे गए जिनके नीचे Information Points की लंबाई शून्य थी, और कोई बता नहीं सकता, क्योंकि आउटपुट वैध JSON था?