N/A: जब क्रिकेट की खबर खाली टेम्पलेट बनकर लौटी

मंगलवार सुबह जो फाइल खुली, उसमें शीर्षक की जगह सिर्फ तीन अक्षर लिखे थे — N/A। स्रोत: N/A। प्रकार: Unclassified। मुख्य दृष्टिकोण के खाने में एक-पंक्ति सारांश नहीं था, और जहाँ लेखक का रुख दर्ज होना चाहिए था वहाँ भी N/A। सूचना बिंदुओं की सूची खाली थी। संस्थाएँ, समय-संवेदनशीलता, स्रोत की गुणवत्ता — तीनों जगह केवल प्लेसहोल्डर टिप्पणियाँ छपी थीं, जैसे किसी फॉर्म में नाम लिखने की जगह कोई टेप चिपका दे। पूरे दस्तावेज में एक ही खाना भरा था: Domain Label — cricket_world। क्रिकेट की खबर क्रिकेट के आकार का खाली गड्ढा बनकर लौटी थी।

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

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

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

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

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

यहाँ असली बात यह है कि cricket_world एक श्रेणी है, दावा नहीं। श्रेणी बताती है कि दस्तावेज किस बक्से में रखा गया, दावा बताता है कि उसमें क्या लिखा है। एक भरा हुआ लेबल और पाँच खाली खाने — यह जानकारी नहीं है, यह जानकारी का भ्रम है। 2026 रूस विश्व कप में मैंने चौंसठ मैचों के दौरान 455 VAR चेक और बीस ऑन-फील्ड रिव्यू दर्ज किए थे, और उस काम का पूरा अनुशासन एक ही बात पर टिका था: हर घटना के लिए चार सवाल — रिव्यू का ट्रिगर क्या था, clear-and-obvious की सीमा पार हुई या नहीं, रिव्यू किस प्रकार का था, और अंतिम अनुशासनात्मक परिणाम क्या रहा। यही ढाँचा यहाँ भी काम करता है। ट्रिगर: क्या मूल पाठ मौजूद है? सीमा: क्या उसकी लंबाई और गुणवत्ता पर्याप्त है? प्रकार: विफलता किस चरण की है? परिणाम: डाउनस्ट्रीम को क्या भेजा गया?

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

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

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

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

यहाँ एक बात साफ कर देनी चाहिए, क्योंकि संदेह जल्दी ही सिनिसिज़्म में बदल जाता है। एक खराब आउटपुट यह साबित नहीं करता कि पूरी प्रणाली विफल है। सबूत का बोझ अभी उस सवाल पर है कि यह एक अलग घटना है या पैटर्न। इसीलिए तीसरा विकल्प सबसे उपयोगी है: अगर यह किसी बैच का हिस्सा है, तो यह बताइए कि उसी बैच की बाकी फाइलें सामान्य आईं या नहीं। अगर बाकी सामान्य हैं, तो समस्या एक दस्तावेज की है। अगर सब खाली हैं, तो समस्या पूरी श्रृंखला की है और उसे उसी स्तर पर ठीक करना होगा।

समाधान जटिल नहीं है, लेकिन उसे अनिवार्य होना पड़ेगा। Stage-1 में एक न्यूनतम-वैधता जाँच जोड़ी जाए: अगर सूचना बिंदुओं की सूची खाली है या सारांश खाली है, तो डाउनस्ट्रीम को टेम्पलेट भेजने के बजाय साफ त्रुटि फेंकी जाए। वह विफलता जो शोर करती है, उस विफलता से हमेशा बेहतर है जो चुपचाप आगे बढ़ जाती है। VAR ने बहस खत्म नहीं की थी; उसने बहस को एक धीमे कैमरे की ओर खिसका दिया था — और यही उसकी उपयोगिता थी। यहाँ भी मामला वही है: सिस्टम को निर्णय नहीं लेना है, उसे केवल यह बताना है कि उसने क्या देखा और क्या नहीं।

सवाल यह नहीं है कि खाली टेम्पलेट कैसे भरा जाए। सवाल यह है कि जिस सुबह आपकी पाइपलाइन खाली लौटती है, उस सुबह आपका पाठक किस पर भरोसा करे?