حقیقی دنیا کے کسی کام (ٹاسک) میں ایک ایسا ہدف ہوتا ہے جس کی جانچ کی جا سکے، ایسی حدود (constraints) ہوتی ہیں جو یہ طے کرتی ہیں کہ کیا چیز قابلِ قبول ہے، اور ایسی بیرونی حالت (external state) ہوتی ہے جو سسٹم کے چلنے کے دوران تبدیل ہو سکتی ہے۔ بغیر جانچ کے ہدف ایک ایسی بات چیت بن جاتا ہے جو کبھی ختم نہیں ہوتی، کیونکہ سسٹم میں کوئی بھی چیز یہ ثابت نہیں کر سکتی کہ کام مکمل ہو گیا ہے۔
اس کا دائرہ کار اس چھوٹے ترین لوپ تک محدود ہے جو عمل کر سکے، تصدیق کر سکے اور رک سکے۔
ہدف تب ہی قابلِ عمل بنتا ہے جب اس میں تکمیل کا کوئی ایسا اشارہ (signal) موجود ہو جس کا پروگرام جائزہ لے سکے، مثلاً کوئی فائل لکھی جانا، اسٹیٹس (status) کا اپ ڈیٹ ہونا، یا فیلڈز کے ایک سیٹ کا پُر ہونا۔ حدود قابلِ قبول نتائج کے دائرہ کار کو محدود کرتی ہیں، جیسے کہ ڈیڈ لائن، API کالز کا بجٹ، مطلوبہ فارمیٹ، یا کوئی ایسی پالیسی جو مخصوص اقدامات کو روکتی ہو۔
بیرونی حالت (external state) سے مراد ماڈل کال سے باہر کی کوئی بھی انحصار (dependency) ہے، جیسے کہ ڈیٹا بیس کی کوئی قطار (row)، ٹکٹ کی قطار (queue)، ویب پیج، یا کیلنڈر کا ایونٹ۔ جب بیرونی حالت تبدیل ہوتی ہے، تو پہلے سے درست منصوبہ غلط ثابت ہو سکتا ہے حالانکہ کوڈ میں کوئی خرابی یا ناکامی نہیں ہوئی ہوتی۔
اصول اگر آپ کام کی تکمیل کے لیے کوئی حتمی اور یقینی جانچ (deterministic check) نہیں لکھ سکتے، تو اس کام کو ‘اوپن اینڈڈ’ (غیر متعین مدت والا) سمجھیں اور اس میں رکنے کے لیے ایک بجٹ (stop budget) اور انسانی جائزے کا مرحلہ شامل کریں۔
کم سے کم درکار ڈھانچہ (minimal architecture) ایک ایسا لوپ ہے جو ڈیٹا کو مقررہ مراحل سے گزارتا ہے اور ہر مرحلے پر ہونے والی تبدیلیوں کو ریکارڈ کرتا ہے۔ یہ لوپ ان پٹ سے شروع ہوتا ہے، حالت (state) کو پڑھتا اور اپ ڈیٹ کرتا ہے، اگلے اقدام کی تجویز کے لیے ماڈل کو کال کرتا ہے، بیرونی حالت پر اثر انداز ہونے والی ٹول کالز (tool calls) کو چلاتا ہے، اور پھر دوبارہ دہرانے سے پہلے رکنے کی شرط (stop condition) کا جائزہ لیتا ہے۔
پائپ لائن ڈایاگرام کے ساتھ تعامل کریں اور دیکھیں کہ ہر مرحلے میں کون سا ڈیٹا داخل ہوتا ہے اور وہ مرحلہ کیا نتیجہ (آؤٹ پٹ) واپس دیتا ہے۔
جب ایک بار ‘لوپ’ (loop) قائم ہو جاتا ہے، تو ہر ناکامی کی نشاندہی ممکن ہو جاتی ہے۔ معلومات کی بازیابی میں ناکامی (retrieval miss) ماڈل کال کے لیے درکار ان پٹس کی کمی کی صورت میں ظاہر ہوتی ہے، ٹول کی خرابی ایک ‘ایکسپشن’ (exception) یا ‘نان-200 رسپانس’ (non-200 response) کے طور پر سامنے آتی ہے، اور ‘اسٹاپ کنڈیشن’ (stop condition) میں خرابی بار بار دہرائے جانے والے ایسے عمل (iterations) کی صورت میں ظاہر ہوتی ہے جن میں حالت (state) میں کوئی پیش رفت نہیں ہو رہی ہوتی۔
تحقیقی رپورٹ کا کام عام طور پر تب مکمل ہوتا ہے جب دستاویز فارمیٹ اور حوالہ جات (citations) کے تقاضوں کو پورا کر لے اور تصدیقی مرحلے سے گزر جائے—مثلاً یہ کہ نوٹس فائل میں ہر دعوے کے ساتھ اس کا ماخذ (source URL) موجود ہو۔ اس عمل میں استعمال ہونے والے ٹولز میں اکثر تلاش (search)، دستاویز کی پارسنگ (parsing)، اور فائل لکھنا شامل ہوتے ہیں، جبکہ لاگت پر قابو پانے کے لیے عام طور پر براؤزنگ اور سیاق و سباق (context) کے پھیلاؤ کو محدود کرنے پر توجہ دی جاتی ہے۔
ٹکٹ کی درجہ بندی اور تقسیم (triage) کا کام تب مکمل ہوتا ہے جب ہر ٹکٹ پر لیبل لگایا جائے، اسے متعلقہ شعبے تک پہنچایا جائے (routed)، مختصر وجہ کے ساتھ تبصرہ شامل کیا جائے، اور ٹکٹ سسٹم اس اپ ڈیٹ کی تصدیق کر دے۔ اس عمل میں اکثر ٹکٹ API، پالیسی چیکر، اور بعض اوقات اندرونی نالج بیس (knowledge base) سے معلومات تلاش کرنے کا عمل شامل ہوتا ہے، اور اس میں بھروسہ مندی (reliability) کو یقینی بنانے کے لیے غلط اپ ڈیٹس سے بچنے پر توجہ دی جاتی ہے۔
پابندیوں، ٹولز اور تکمیل کے اشاروں کا انتخاب کرتے ہوئے ان دونوں کاموں کا موازنہ کریں اور مشاہدہ کریں کہ ‘اسٹاپ کنڈیشن’ کس طرح تبدیل ہوتی ہے۔