खाली शीट, भरा हुआ फ़ॉर्म: जब डेटा पाइपलाइन चुपचाप फ़ेल हो, तो स्कोरकार्ड क्या बताता है

बारह फ़ील्ड। सब जगह मौजूद। article_type से लेकर source_quality तक हर पंक्ति के आगे बराबर का निशान, और उसके बाद या तो N/A या वही टेम्पलेट वाक्य जो फ़ॉर्म में पहले से छपा आता है। information_points के आगे खाली ब्रैकेट — [ ]। entities_involved के आगे निर्देश लिखा है: "identify from the information points above"। यानी फ़ाइल ख़ुद मान रही है कि ऊपर कुछ है, जबकि ऊपर कुछ भी नहीं है। सिस्टम ने इस फ़ाइल को रिजेक्ट नहीं किया। उसने इसे अगले चरण में भेज दिया।

ग्यारह नाम प्रिंट हैं, ग्यारहों के आगे "बल्लेबाज़ी: —" छपा है, और नीचे पारी का टोटल जहाँ होना चाहिए वहाँ सफ़ेद जगह है। कोई दर्शक उसे स्कोरकार्ड नहीं कहेगा। पर डेटा डेस्क पर ठीक ऐसी शीट हर दिन पास हो जाती है, क्योंकि उसका स्कीमा सही है। मैं पैंतालीस साल से स्कोरकार्ड पढ़ रहा हूँ, और मैंने सीखा है कि सबसे ख़तरनाक काग़ज़ वह नहीं जो फटा हो — सबसे ख़तरनाक वह है जो पूरा दिखे और ख़ाली हो।

यह कोई तकनीकी शिकायत नहीं है। यह उसी बीमारी का दूसरा नाम है जिससे क्रिकेट का रिकॉर्ड-कीपिंग दशकों से जूझ रहा है: संरचना का सही होना, और सामग्री का ग़ायब होना। क्रिकेट में हमने हमेशा दूसरे को ज़्यादा तवज्जो दी — कॉलम बने रहे, नंबर भरते रहे। जब नंबर नहीं भरे, तो किसी ने शोर नहीं मचाया।

विषय-वस्तु का यह संकट तीन जगहों पर एक जैसा दिखता है, और तीनों जगह मैंने अपनी बही खोलकर देखी है।

मार्च 2026, ईडन गार्डन्स। स्कोरकार्ड पूरा था। श्रीलंका 251/8, भारत 120/8, मैच डिफ़ॉल्ट में श्रीलंका को। अख़बारों ने अगली सुबह जो छापा वह सही था और अपूर्ण था। उसमें यह नहीं था कि 98/1 से 120/8 तक का सफ़र किन पाँच-ओवर खंडों में हुआ, किस ओवर में रन-रेट 5.4 से 2.1 पर आ गिरा, और किस प्रकार की गेंदों पर आठ विकेट गिरे। मैं उस दिन प्रेस बॉक्स में स्टॉपवॉच और हार्डबैक बही लेकर बैठा था, क्योंकि मुझे लगा था कि अगर मैंने खंड-दर-खंड दर्ज नहीं किया, तो कोई और नहीं करेगा। मैंने पतन को ओवर-दर-ओवर चार्ट किया, और ख़ामोशी को एक आँकड़ा मिल गया। वही आँकड़ा आज भी उस मैच की असली रिपोर्ट है — 120/8 कोई कहानी नहीं है, 98/1 से 120/8 तक का ढलान कहानी है।

उस रात मैंने एक नियम बनाया जो अब तक चल रहा है: मेरी किसी भी रिपोर्ट में दूसरा पैराग्राफ़ चरण-वार आँकड़े के बिना नहीं जाएगा। सब-एडिटर सीख गए थे कि मेरी कॉपी में तालिका के लिए जगह छोड़नी पड़ती है।

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

यही अंतर है एक खोज और एक आरोप के बीच। स्कोरकार्ड स्कैंडल से बच गया; रसीदें हाशिये में बची रहीं। जिस इकतीस को मैंने रद्द किया, वे शायद सही थे — पर "शायद सही" मेरी बही में दर्ज नहीं होता।

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

अब उस खाली JSON पर लौटिए। वहाँ एक ही फ़ील्ड भरी थी — domain_label: cricket_world। यह सबसे शिक्षाप्रद बात है पूरे मामले में। शेष आठ फ़ील्ड जब खाली थीं, तब उस एक लेबल के पास कोई सबूत नहीं था। यह पता नहीं चल रहा था कि लेबल मूल पाठ से निकला था या बाहर से थोपा गया था। डेटा डेस्क की भाषा में इसे कहते हैं — ऐसा दावा जिसका स्रोत-फ़ील्ड ख़ाली है।

यहीं मुझे अपनी ही एक ग़लती याद आती है। सालों पहले मैंने एक बड़े रिकॉर्ड-चेज़ के दौरान पाँच-ओवर खंडों का औसत निकालकर लिख दिया था कि "दबाव बढ़ने पर रन-रेट गिरा"। बाद में बही खोलने पर पता चला कि गिरावट विकेट गिरने के बाद शुरू हुई थी, दबाव बढ़ने से पहले नहीं। सहसंबंध कारण नहीं होता, और जब तक आप अनुक्रम नहीं देखते, आपके पास सिर्फ़ एक साथ घटी दो घटनाएँ हैं। उस सुधार के साथ मैंने अपनी ग़लत भविष्यवाणियों की सूची भी छापी, क्योंकि आँकड़े के साथ ईमानदारी एक-तरफ़ा सौदा नहीं है।

दिक्कत यह है कि खाली जगह भरने का लोभ हमेशा रहता है। एक पाइपलाइन में N/A देखकर भी सिस्टम आगे बढ़ता रहा, क्योंकि आगे बढ़ना सस्ता था और रुकना महँगा। क्रिकेट में यही लोभ टिप्पणीकार की शक्ल में बैठता है: "ईडन गार्डन्स में जो उस दिन वहाँ थे, वे जानते हैं" — बिना तारीख़, बिना गवाह, बिना दस्तावेज़। वह वाक्य स्कीमा से मेल खाता है और सामग्री से ख़ाली है।

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

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

इस मामले में तरीक़ा साफ़ है। Stage-1 में एक assertion बैठे — title == "N/A" या information_points == [] होने पर पाइपलाइन लाउड फ़ेल करे। एक पंक्ति का नियम, जो आगे की हर उस रिपोर्ट को रोक देता है जो पूरी दिखेगी और ख़ाली होगी। यह तकनीकी सुझाव से ज़्यादा संपादकीय आदत है: दूसरा चरण शुरू होने से पहले पहला चरण अपना हिसाब मिलाए।

मुझसे इस खाली रिपोर्ट पर "विश्लेषण" माँगा गया था। मैं वह नहीं दे सकता, क्योंकि जो मौजूद नहीं है उसका विश्लेषण करने का एक ही तरीक़ा है — उसे गढ़ लेना। और जिस पेशे में मैं पैंतालीस साल से हूँ, वहाँ गढ़ना शब्द नहीं है; वह दुर्घटना है।

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

जो रिपोर्ट खाली थी, वह अब तकनीकी घटना है। सवाल यह है कि उसके बाद सिस्टम बदला या रिपोर्टर ने बही खोल दी।