Jev के 7 उपयोग जो सॉफ़्टवेयर का वास्तविक काम कम करते हैं

किसी ने हमारी वेबसाइट से पूछा कि हमारे पास कितने इंटीग्रेशन हैं। जवाब में साइनअप फ़ॉर्म में कितने फ़ील्ड होने चाहिए, इस बारे में सलाह मिली।

जवाब तेज़ी से आया। लेकिन बेकार था।

दोनों सवालों में “कितने” था। हमारे खोज कोड ने स्वीकार किए गए FAQ मिलान को कम से कम 0.86 स्कोर दिया, जिससे कमजोर मिलान भरोसेमंद दिखने लगा। गति ने गलत निर्णय छिपा दिया।

Ship with Jev को देखते समय ऐसी ही विफलता पर सोचना ज़रूरी है। 26 सितंबर 2026 को डायरेक्टरी में समुदाय के बनाए 551 प्रोजेक्ट सूचीबद्ध थे। खेलों के साथ खोज के घटक, ब्राउज़र एजेंट, शोध टूल और रूटिंग के प्रयोग भी हैं। डायरेक्टरी प्रदर्शन के आँकड़े उनके लेखकों के नाम करती है; यह खोज का ज़रिया है, स्वतंत्र बेंचमार्क नहीं।

दिलचस्प सवाल यह है कि इनमें से कौन-सा तरीक़ा किसी असली प्रोडक्ट से काम कम करता है।

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

Jev किसी ऐप में क्या जोड़ता है

TypeSafe के अनुसार Jev स्पष्ट प्रकार वाले निर्णयों का मॉडल है। आप उसे प्रासंगिक स्थिति और एक सवाल देते हैं; बदले में एक विकल्प, संभावना या स्कोर मिलता है जिसे कोड इस्तेमाल कर सकता है। उसके उपयोग मानचित्र में रूटिंग, पुनर्प्राप्ति, सत्यापन और निष्कर्षण शामिल हैं।

इस भेद का हमारी इंगेस्ट की गई YouTube सामग्री में एक उपयोगी पूर्वरूप मिलता है। Diogo Almeida के AI Engineer व्याख्यान में TypeSafe के सह-संस्थापक ऐसे सॉफ़्टवेयर की वकालत करते हैं जिसके बुनियादी घटक अधिक बुद्धिमत्ता व्यक्त कर सकें। वे इस महत्वाकांक्षा की तुलना मौजूदा सॉफ़्टवेयर में एक असिस्टेंट जोड़ देने से करते हैं। यह AI की दिशा पर उनका तर्क है, Jev के मौजूदा प्रदर्शन का माप नहीं।

रेलवे के एक जंक्शन की कल्पना करें। उपयोगी नतीजा यह है कि ट्रेन को उपलब्ध पटरियों में से कौन-सी लेनी चाहिए। पटरियों का वर्णन करने वाला एक अनुच्छेद स्विच में कुछ नहीं जोड़ता।

आपत्ति वाजिब है: “एक सामान्य LLM भी तो JSON लौटा सकता है।” बिल्कुल। किसी अलग घटक के पक्ष में तर्क उस निर्णय के लिए मापी गई गुणवत्ता, लागत और विलंबता पर टिका है। केवल स्पष्ट प्रकार का उत्तर इनमें से कुछ भी साबित नहीं करता।

CLM की चुनौती को पहले समझना चाहिए

23 सितंबर को Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré और Azalia Mirhoseini ने Contrastive Language Models प्रकाशित किया। उनका काम इस धारणा को चुनौती देता है कि तेज़ अर्थ-संबंधी निर्णयों के लिए Jev ही एकमात्र व्यावहारिक रास्ता है।

लेखकों के अनुसार कंप्यूटर उपयोग, गेमिंग और टूल कॉल के कामों में बिना उदाहरण वाले परीक्षणों पर CLM के परिणाम Jev के तुलनीय थे, जबकि विलंबता अधिकतम 9 गुना कम थी। अलग से उन्होंने DeepSWE के 38 रोके गए कार्यों पर 81.6% और Terminal-Bench 2.1 के 30 कार्यों पर 87.6% बताया है। कोडिंग के इन परिणामों में बारीकी से ट्यून किए गए CLM सत्यापनकर्ता इस्तेमाल हुए, जो दूसरे मॉडलों के बनाए समाधानों में से चुनते हैं। वे यह भी बताते हैं कि इसी सत्यापनकर्ता व्यवस्था में Jev यादृच्छिक चयन की आधार रेखा से नीचे रहा। विलंबता H100 पर मापी गई। ये लेखकों के निष्कर्ष हैं; हमने इन्हें स्वतंत्र रूप से दोहराया नहीं है। मूल मूल्यांकन और पद्धति।

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

CLM स्थितियों और संभावित कार्रवाइयों को अलग-अलग एन्कोड करता है, जिससे बार-बार काम आने वाले कार्रवाई एम्बेडिंग कैश किए जा सकते हैं। इसका रिपॉज़िटरी TypeSafe के साथ संगत इंटरफ़ेस और स्थिति के लिए डिफ़ॉल्ट 2,048 टोकन की सीमा दर्ज करता है; अन्यथा कॉन्फ़िगर न करने पर लंबी स्थितियाँ काट दी जाती हैं। API सीमा पर संगतता से यह साबित नहीं होता कि निर्णय भी समान हैं।

जारी मॉडल कार्ड में Qwen3-8B एम्बेडिंग बताई गई हैं और चेतावनी दी गई है कि सत्यापनकर्ता के मज़बूत नतीजों के लिए बारीकी से ट्यून किए गए हेड चाहिए। यह भी स्पष्ट है कि CLM उसे दिए गए उम्मीदवारों को स्कोर करता है और स्वयं कोई समाधान नहीं बनाता। खुले वेट मूल्यांकन का एक विकल्प देते हैं; हार्डवेयर, सर्विंग और रखरखाव की लागत फिर भी है।

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

नीचे के सात वर्कफ़्लो अब भी मूल्यांकन के लिए उपयोगी उम्मीदवार हैं। उनका मूल्य इस पर निर्भर नहीं कि Jev हर तुलना जीते।

1. ऐसी खोज जो जाँचे कि परिणाम सवाल का जवाब देता है

यह मेरी पहली पसंद है क्योंकि विफलता दिखाई देती है और नतीजे पर लेबल लगाना आसान है। क्या लौटाए गए अंश ने वह जवाब दिया जो विज़िटर ने पूछा था?

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

1. पुनर्प्राप्ति

   कीवर्ड, एम्बेडिंग

   उम्मीदवारों का छोटा समूह

   जो छूटा वह नहीं जोड़ सकती
2. Jev

   स्पष्ट प्रकार का निर्णय

   क्या यह अंश

   तथ्य देता है?
3. उत्तर

   या कोई उत्तर नहीं

   सही या अनुत्तरित

   कुल विलंबता मापी जाती है

इंटीग्रेशन गिनने वाले हमारे उदाहरण में सबसे छोटा रास्ता इससे भी सरल है। प्रामाणिक कैटलॉग की प्रविष्टियाँ गिनें। बताएँ कि गिनती का मतलब क्या है। दस्तावेज़ीकृत कनेक्टर और किसी ग्राहक का कॉन्फ़िगर किया हुआ कनेक्शन दो अलग चीज़ें हैं।

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

Kyle McLaren का jevsearch कार्यान्वयन इस क्रम को ठोस बना देता है: पहले कीवर्ड परिणाम आते हैं, फिर Jev की रैंकिंग। उसका प्रकाशित बेंचमार्क अपने दस्तावेज़ों और लेबल किए प्रश्नों का उपयोग करता है। यह उस परीक्षण के बारे में उपयोगी साक्ष्य है, किसी दूसरी वेबसाइट या भाषा का वादा नहीं।

सही उत्तर, असमर्थित उत्तर, अनुत्तरित प्रश्न और कुल विलंबता मापें। वर्तनी की गलतियाँ और अनूदित प्रश्न शामिल करें। तेज़ पर अप्रासंगिक परिणाम फिर भी अप्रासंगिक हैं।

2. अनुरोध को सही पेज, कतार या एजेंट तक पहुँचाना

एक उपयोगकर्ता लिखता है: “अकाउंट बदलने के बाद कॉन्टैक्ट आना बंद हो गए।” आपके ऐप को कनेक्शन की समस्या के निवारण, बिलिंग, फ़ील्ड मैपिंग और नया सिंक बनाने के अनुरोध में फ़र्क़ करना है।

मौजूदा स्क्रीन, हाल की बातचीत और उस उपयोगकर्ता के लिए उपलब्ध गंतव्य दें। सबसे अच्छा गंतव्य माँगें, साथ में “कोई मेल नहीं” का स्पष्ट विकल्प भी। गंतव्यों के पहचानकर्ता ऐप के नियंत्रण में रखें।

कई निर्णय साथ मिलकर उपयोगी हो सकते हैं: मंशा, गंतव्य, तात्कालिकता, और यह कि संदेश में कार्रवाई योग्य अनुरोध है या नहीं। TypeSafe का फ़ैन-आउट पैटर्न स्वतंत्र प्रश्नों को एक ही अनुरोध साझा करने देता है। बाद में कोड प्रासंगिक उत्तर इस्तेमाल करता है।

एक हानिरहित नेविगेशन सुझाव और काम चलाने की अनुमति अलग निर्णय हैं। सही बिलिंग पेज ढूँढने से रिफ़ंड की अनुमति नहीं मिलती। सही एजेंट ढूँढने से उस एजेंट को क्रेडेंशियल नहीं मिलते।

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

3. उलझे डेटा को भरोसेमंद इंटीग्रेशन में बदलना

यह एक प्रस्तावित इंटीग्रेशन वर्कफ़्लो है। स्रोत के निर्यात में customer_email, billing_email और account_owner_email हैं। गंतव्य को कॉन्टैक्ट का ईमेल पता चाहिए।

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

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

1. कोड

   उम्मीदवार खोजना

   customer_email

   billing_email

   account_owner_email
2. Jev

   एक चुनना

   फ़ील्ड के विवरण

   नमूना मान, उद्देश्य
3. कोड

   मूल मान कॉपी करना

   प्रकार, अनिवार्य मान

   गंतव्य की बाध्यताएँ

CRM और ईमेल इंटीग्रेशन में स्रोत फ़ील्ड और मैपिंग का निर्णय साथ-साथ सुरक्षित रखें। प्रभावित रिकॉर्ड का पूर्वावलोकन दिखाएँ। अनिश्चित मैपिंग को समीक्षा तक अनसुलझा रखें।

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

अस्वीकृत रिकॉर्ड और गलत मैपिंग को समीक्षित नमूने के मुक़ाबले मापें। API अनुरोध का सफल होना साबित करता है कि पेलोड स्वीकार हुआ; यह साबित नहीं करता कि सही ईमेल सही कॉन्टैक्ट तक पहुँचा।

4. काम पूरा करने वाला सबसे छोटा मॉडल चुनना

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

पहले वे मॉडल तय करें जो कॉन्फ़िगर किए गए हों और जिन्हें उस काम का डेटा मिलने की अनुमति हो। उनके समर्थित टूल और देखा गया प्रदर्शन दर्ज करें। फिर एक संकीर्ण निर्णय उस समूह में से उपयुक्त विकल्प सुझा सकता है। TypeSafe इस पैटर्न को अपने मॉडल रूटिंग उदाहरणों में शामिल करता है।

OpenRouter का Jev Router यह पैटर्न चैट API के ज़रिए मॉडल आईडी typesafe/jev-router के रूप में देता है। लिस्टिंग के अनुसार बातचीत बदलने के साथ मॉडल और तर्क-प्रयास दोनों का चयन होता है। अपनाने से पहले उसके अनुमत डाउनस्ट्रीम मॉडल, वास्तविक शुल्क, डेटा हैंडलिंग और टूल कॉल के दौरान व्यवहार का मूल्यांकन करें। हमने लिस्टिंग की पुष्टि की; इस राउटर का बेंचमार्क नहीं किया।

हमारी सुझाई नीति सटीक नियमों और तथ्यों के लिए सामान्य कोड से शुरू होती है। सीमित अर्थ-संबंधी सवालों के लिए निर्णय मॉडल, लिखने या कार्यान्वयन के लिए उपयुक्त जेनरेटिव मॉडल, और जब साक्ष्य माँग करे तब ऊपर के स्तर पर भेजना।

काम को क्या चाहिए?

1. सटीक नियम और तथ्य

   सामान्य कोड

2. सीमित अर्थ-संबंधी सवाल

   निर्णय मॉडल

3. लिखना या कार्यान्वयन

   उपयुक्त जेनरेटिव मॉडल

4. साक्ष्य और अधिक की माँग करे

   ऊपर भेजें

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

हर स्वीकार्य परिणाम की लागत, दोबारा कोशिशें, ऊपर भेजने की दर और बाद में पकड़ी गई विफलताएँ ट्रैक करें। सस्ती पहली कॉल महँगा वर्कफ़्लो बन सकती है यदि किसी को उसका आउटपुट ठीक करना पड़े।

5. ग्राहक तक पहुँचने से पहले दावों की जाँच

उद्धरण मौजूद हो सकता है और फिर भी अपने बगल के वाक्य का समर्थन न करे। कोई स्रोत नियोजित फ़ीचर का वर्णन कर रहा हो सकता है जबकि उत्तर उसे आज उपलब्ध बताता हो।

TypeSafe की उद्धरण जाँच की कुकबुक दो जाँचों को अलग करती है। सामान्य स्ट्रिंग मिलान गायब उद्धरण पकड़ता है। अर्थ-संबंधी निर्णय देखता है कि आसपास का स्रोत दावे का समर्थन करता है या नहीं।

यही डिज़ाइन सहायता के जवाब, बनाई गई इंटीग्रेशन गाइड, या किसी एजेंट की प्रस्तावित समापन रिपोर्ट पर लागू करें। दावा, स्रोत का अंश और निर्णय समीक्षा के लिए उपलब्ध रखें।

पूर्णता को फिर भी सीधा साक्ष्य चाहिए। टेस्ट जाँचे गए व्यवहार को साबित करते हैं। डिप्लॉयमेंट रिकॉर्ड डिप्लॉयमेंट को साबित करता है। अर्थ-संबंधी निर्णय किसी रिपोर्ट और उसके साक्ष्य के बीच बेमेल की ओर इशारा कर सकता है; वह गायब साक्ष्य नहीं बना सकता।

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

6. ट्रांसक्रिप्ट और ग्राहक प्रतिक्रिया से उपयोगी छोटी सूचियाँ बनाना

ट्रांसक्रिप्ट संग्रह तब उपयोगी बनता है जब कोई ज़रूरी अंश ढूँढ सके। “इंटीग्रेशन शब्द शामिल है” यह “समझाता है कि ग्राहक ने सेटअप क्यों छोड़ा” के लिए कमज़ोर फ़िल्टर है।

एक तरीक़ा यह है कि संभावित अंश निकालें, फिर कुछ विशिष्ट गुण परखें: क्या यह सेटअप की बाधा बताता है, क्या इसमें ठोस उदाहरण है, क्या यह संदर्भ की कमी के बिना अपने आप में पूरा है?

हर चुने गए अंश के साथ स्रोत का URL और टाइमस्टैंप जुड़ा रखें। टाइमस्टैंप ट्रांसक्रिप्ट से आता है। मॉडल प्रासंगिकता का निर्णय करता है।

वीडियो एडिटर के लिए ये संकेत समीक्षा के लिए क्लिप की छोटी सूची बना सकते हैं। प्रोडक्ट टीम के लिए ये बार-बार आने वाली आपत्तियों को व्यवस्थित कर सकते हैं। मार्केटर के लिए ये ग्राहक के साक्ष्य को असमर्थित अभियान दावों से अलग कर सकते हैं।

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

JevQL एक संबंधित सामुदायिक कार्यान्वयन देता है: PostgreSQL की पंक्तियों पर अर्थ-संबंधी शर्तें, जिनका मूल्यांकन डेटाबेस के बाहर होता है। उसका दस्तावेज़ सामान्य फ़िल्टर को बिल के लिए अहम बना देता है। अर्थ-संबंधी निर्णय माँगने से पहले पात्र पंक्तियाँ घटाएँ।

समीक्षकों की स्वीकृति और काम की सामग्री खोजने में बचा समय मापें। हुक की मज़बूती का स्कोर व्यूज़ का पूर्वानुमान नहीं है।

7. अगली उपयोगी कार्रवाई चुनने वाले इंटरफ़ेस

सेटिंग स्क्रीन को “इस सिंक को कल तक रोक दें” मिल सकता है। ब्राउज़र एजेंट को मौजूदा पेज पर दिखने वाले नियंत्रणों में से चुनना पड़ सकता है।

हमारे प्रस्तावित इंटरफ़ेस में ऐप अनुमत कार्रवाइयाँ और वर्तमान स्थिति देता है। Jev उनमें से चुनता है। इंटरफ़ेस संबंधित नियंत्रण या समीक्षा योग्य प्रस्ताव दिखाता है।

Ship with Jev में Gregor Zunic का ब्राउज़र फ़्लाइट खोज डेमो है। उसका बताया समय और खर्च उसी प्रदर्शन के हैं। दूसरे काम में अपनाने योग्य विचार है हर चरण में उपलब्ध कार्रवाइयों से चुनना; दूसरे ब्राउज़र वर्कफ़्लो की अलग पुष्टि चाहिए।

स्थिति का ताज़ा होना अहम है। निर्णय लेते समय चुना हुआ खाता या पेज बदल जाए तो पुराने परिणाम को छोड़ दें। कार्रवाई को समीक्षा किए गए खाते और स्थिति से बाँधें।

इससे स्पष्ट प्रकार वाला UI कैटलॉग भी उपयोगी बन सकता है। मॉडल ज्ञात दृश्य और उसका सीमित डेटा चुनता है; सामान्य रेंडरिंग कोड इंटरफ़ेस बनाता है। काम की सफल पूर्णता और गलत कार्रवाइयाँ मापें, खासकर यह कि नियंत्रण समझ में आते रहें।

मैं कहाँ से शुरू करूँगा

ऐसा बार-बार आने वाला निर्णय चुनें जो पहले से दिखने वाला नुकसान करता हो। उसकी वास्तविक गलतियों से मूल्यांकन समूह बनाएँ।

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

डेमो का कॉन्फ़िडेंस थ्रेशोल्ड न अपनाएँ। TypeSafe के कॉन्फ़िडेंस दस्तावेज़ बताते हैं कि Choice और Score का कॉन्फ़िडेंस एक वितरण का सार है। यह इनपुट पूरा होने या चुनी गई कार्रवाई को अनुमति मिलने का प्रमाण नहीं।

ऐसे मामले शामिल करें जिनमें कोई उम्मीदवार सही न हो। अनुपलब्ध सेवा शामिल करें। हर वह भाषा शामिल करें जिसे आप समर्थन देना चाहते हैं। परिणामों के साथ मॉडल संस्करण और सवाल की परिभाषाएँ रखें ताकि बाद के बदलाव की निष्पक्ष तुलना हो सके।

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

आज आपका सॉफ़्टवेयर जो एक गलत जवाब देता है, उसे चुनें। उसे विश्वसनीय ढंग से अगला सही कदम उठाने दें।