खाली पंक्ति: जब टेनिस का रिकॉर्ड N/A लौटाता है

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

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

यह लेख उस घटना के बारे में नहीं है। यह उस स्थिति के बारे में है जो पच्चीस साल बाद दोहराई गई।

पिछले हफ़्ते मेरे सामने एक विश्लेषण-दस्तावेज़ आया। उसका शीर्षक N/A था। उसका स्रोत N/A था। उसकी श्रेणी Unclassified थी। उसका एक-वाक्य सारांश खाली था। Information Points का पूरा खंड खाली था। Entities के खाने में लिखा था 'ऊपर दिए गए सूचना-बिंदुओं से पहचानें' — जबकि ऊपर कोई सूचना-बिंदु था ही नहीं। Source Quality का निर्णय 'सूचना-बिंदुओं के स्रोत-फ़ील्ड से तय करें' पर छोड़ दिया गया था, जबकि सूचना-बिंदु मौजूद नहीं थे। समय-संवेदनशीलता का मूल्यांकन हुआ ही नहीं।

पूरे दस्तावेज़ में जीवित एकमात्र चीज़ थी Domain Label: tennis। बाक़ी सब टेम्पलेट था।

संदर्भ: हाथ से लिखा रिकॉर्ड, और उसका स्रोत-नियम

डेटा के काम में मैंने जो सबसे पहला सबक़ सीखा, वह मैच के बारे में नहीं था। वह रिकॉर्ड के बारे में था। 2026 में जब मैंने रिपोर्टिंग और सब-एडिटिंग शुरू की, तब फ़ाइल काग़ज़ की थी। 2026 में चेन्नई ओपन के 31 मैचों की 3,142 पॉइंट्स मैंने हाथ से लिखीं, और हर पॉइंट के साथ तीन बातें दर्ज कीं: सर्विस कहाँ गई, रैली कितनी लंबी चली, और अंक किस तरह का एरर था। यह मेहनत का काम था। एक मैच में 200 से ज़्यादा पॉइंट्स होते हैं, और अगर स्कोरबोर्ड पर बारह सेकंड में एक अंक लिखा जाता है, तो उसे तीन ख़ानों में तोड़ने में तीन गुना समय लगता है।

मैंने हर पॉइंट हाथ से की-इन किया, और स्कोरबोर्ड ने मेरा नाम कभी नहीं जाना।

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

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

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

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

जनवरी 2026 में चेन्नई ओपन का इक्कीसवाँ और आख़िरी संस्करण खेला गया। इक्कीस संस्करणों में से सत्रह पर मेरे पास फ़ाइलें थीं। आख़िरी संस्करण मैंने मीडिया बॉक्स से कोड किया, जहाँ फ़ाइनल में रॉबर्टो बाउटिस्टा अगुट ने बीस साल के दानील मेदवेदेव को हराया — 8 जनवरी 2026, स्कोर 6-3, 6-4। यह तारीख़, यह स्कोर, यह दो नाम, इस पूरे लेख में वह एक ठोस तथ्य है जिसे मैं अपने ही रिकॉर्ड से लिख रहा हूँ, किसी सारांश से उठाकर नहीं।

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

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

यह सारा संदर्भ इसलिए ज़रूरी था, क्योंकि पिछले हफ़्ते के खाली दस्तावेज़ को पढ़ने के लिए आपको पता होना चाहिए कि एक भरा हुआ रिकॉर्ड कैसा दिखता है। जब आपको पता हो कि पूरा रिकॉर्ड कैसा दिखता है, तब खाली ढाँचा पहचान में आ जाता है।

कोर: एक खाली दस्तावेज़ की पंक्ति-दर-पंक्ति जाँच

अब असली काम। मैं उस दस्तावेज़ को उसी तरह खोलता हूँ जैसे एक लेजर खोला जाता है। कोई शिकायत नहीं, कोई आरोप नहीं। सिर्फ़ यह देखना है कि कौन-सा ख़ाना किस कारण खाली है।

पहला ख़ाना: शीर्षक। मान N/A। यह सबसे बड़ा सुराग़ है, और सबसे आसानी से नज़र से ओझल होने वाला। शीर्षक किसी दस्तावेज़ का सबसे ऊपरी ख़ाना होता है, और वह पहले भरा जाता है। अगर शीर्षक खाली है, तो इसका मतलब है कि दस्तावेज़ को किसी वाक्य से नहीं, किसी नाम से नहीं, बल्कि किसी फ़ॉर्म से बनाया गया। शीर्षक का खाली होना यह बताता है कि ऊपर की ओर जाने वाली सारी प्रक्रिया विफल रही।

दूसरा ख़ाना: स्रोत। मान N/A। यह चोट ज़्यादा गहरी है। स्रोत का नाम खो जाने का मतलब है कि जिस चीज़ का विश्लेषण होना था, वह चीज़ किसी टेबल में नहीं पहुँची। एक डेटा-पाइपलाइन में स्रोत वह पहली ईंट है जिस पर बाक़ी सब टिकता है। स्रोत नहीं, तो उद्धरण नहीं। उद्धरण नहीं, तो सत्यापन नहीं।

तीसरा ख़ाना: प्रकार। मान Unclassified। यहाँ एक असामान्य बात दिखती है। श्रेणी निर्धारक ने खाली नहीं छोड़ा, उसने 'वर्गीकृत नहीं' लिखा। यानी उसे कुछ मिला, पर वह उसे किसी पहचाने हुए ख़ाने में डाल नहीं पाया। जबकि उसी दस्तावेज़ में Domain Label: tennis मौजूद है। दो वर्गीकरण इंजन, एक ही दस्तावेज़ पर, दो अलग नतीजे। क्षेत्र-वर्गीकरण चला, प्रकार-वर्गीकरण नहीं चला। मेरे अनुभव में इसका सबसे सीधा कारण यह होता है कि दोनों इंजनों को अलग-अलग स्रोत से टेक्स्ट मिल रहा है, और उनमें से एक को खाली या कटा हुआ टेक्स्ट मिला है।

चौथा ख़ाना: एक-वाक्य सारांश। खाली। यह वह ख़ाना है जहाँ सारी विफलताएँ इकट्ठी होकर दिखती हैं। सारांश तभी बनता है जब पाठ मौजूद हो। पाठ नहीं, तो सारांश नहीं।

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

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

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

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

नौवाँ ख़ाना: लेखक की स्थिति। N/A। यानी कोई नहीं जानता कि दस्तावेज़ शैली की रिपोर्टिंग है, विश्लेषण है, या भविष्यवाणी। टेनिस के रिकॉर्ड में यह अंतर सब कुछ बदल देता है। 'मेदवेदेव 2026 में बाउटिस्टा से हारे' एक दर्ज बात है। 'मेदवेदेव 2026 में टॉप-5 में पहुँचेंगे' एक भविष्यवाणी है। इन दोनों को एक ही टाइप में लिख देना, किसी भी रिकॉर्ड को बेकार करने का सबसे तेज़ तरीक़ा है।

अब इस लेजर को पढ़कर मैं एक बात साफ़ कह सकता हूँ, और वही इस पूरे लेख का मुख्य निष्कर्ष है:

यह एक टेनिस-ज्ञान की समस्या नहीं है। यह एक स्रोत-शासन की समस्या है।

चीज़ें इसलिए नहीं टूटीं कि किसी को टेनिस नहीं आती। चीज़ें इसलिए टूटीं कि मशीन का कोई हिस्सा यह बताने की जगह खो बैठा कि उसे कुछ मिला ही नहीं।

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

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

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

यही उस खाली दस्तावेज़ से ग़ायब है — यह बताने वाला कि कहाँ देरी है, कहाँ गड़बड़ है, कहाँ अभी कुछ नहीं है।

विरोधाभास: खाली पंक्ति ईमानदार है, भरी पंक्ति संदिग्ध है

अब वह हिस्सा जहाँ मुझे अपनी ही बात से बहस करनी है।

इस दस्तावेज़ को पढ़कर पहली प्रतिक्रिया यही होती है कि सिस्टम ने धोखा दिया। मशीन चली ही नहीं। सारा श्रम बेकार गया। और यह सच भी है, लेकिन सिर्फ़ आधा सच। दूसरा आधा यह है कि इस पूरे दस्तावेज़ ने एक ऐसी ईमानदारी निभाई जो ज़्यादातर डेटा-उत्पाद कभी नहीं निभाते: उसने अपनी अज्ञानता पर N/A लिखा।

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

खाली दस्तावेज़ ने कम से कम इतना बता दिया कि वहाँ कुछ नहीं है। उसने मुझे बेकार होने से नहीं बचाया, लेकिन उसने मुझे गुमराह होने से बचा लिया। और खेल-पत्रकारिता की दुनिया में, गुमराह होना बेकार होने से कहीं ज़्यादा महँगा पड़ता है।

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

इसलिए यह शिकायत — कि स्टेज-1 खोखला निकला — दरअसल एक अच्छी ख़बर है। बुरी ख़बर वह होती जिसमें स्टेज-1 खोखला होता और दिखता नहीं।

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

मेरे पचास साल से ज़्यादा के अनुभव में मैंने यह देखा है कि जो लोग दर्ज करने पर ज़ोर देते हैं, उन्हें बोरिंग माना जाता है, और जो भविष्यवाणी करते हैं, उन्हें दूरदर्शी। अच्छा, और यह भी देखा है कि बीस साल बाद पुराने अंक निकालने पर किसका काम टिकता है।

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

टेकअवे: अगली बार की जाँच-सूची

तो अब आगे क्या।

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

इस लेख में मैंने हर आंकड़ा दो बार टाइप किया: एक बार हाथ से, एक बार याद से। 8 जनवरी 2026 का फ़ाइनल, 6-3 और 6-4, 31 मुख्य-ड्रॉ मैच, 3,142 पॉइंट्स, तीन सीज़न, चौसठ मैच — ये सब उसी तरह लिखे गए हैं जैसे मैंने 2026 में लिखे थे।

अगली बार जब कोई सिस्टम मुझे एक साफ़-सुथरा सारांश थमाए, तो मैं सबसे पहले तीन सवाल पूछूँगा। एक: इस वाक्य का पता क्या है — किस पैराग्राफ़ से, किस दस्तावेज़ से, किस तारीख़ को? दो: जो ख़ाना खाली था, उसे अनुमान से भरा गया, या खाली छोड़ा गया? तीन: अगर दो अलग इंजन एक ही टेक्स्ट पढ़ रहे थे, तो उन्होंने एक-दूसरे को क्यों नहीं टोका?

ये तीन सवाल टेनिस के कोर्ट पर भी वही हैं, और किसी भी डेटा-प्रणाली में भी। और अगर इन तीनों का जवाब न मिले, तो सबसे समझदारी का काम यह है कि हम एक खाली पंक्ति स्वीकार कर लें, बजाय इसके कि हम उसे किसी सुंदर, दृढ़, और झूठी संख्या से भर दें।