سیاقی تہہ بنانا: ایک کارکن کے ذخیرے سے پوری افرادی قوت کے مجموعے تک کا فوری کورس

15 تصورات · Onyx، MCP اور ماخذوں کی چار اقسام · آپ کے ایجنٹ کا بنایا ہوا، ہاتھ سے نہیں

قابلِ تلاش AI سیاق نے ایک کارکن کا اپنا ذخیرہ بنایا تھا۔ یہ کورس وہ مجموعہ بناتا ہے جسے پوری افرادی قوت پڑھتی ہے۔

قابلِ تلاش AI سیاق میں آپ نے ایک کارکن کو اس کا اپنا ذخیرہ دیا تھا: آپ کی دستاویزات، ٹکڑوں میں منقسم، embedding کے ساتھ، معنی کی بنیاد پر قابلِ تلاش، اور آپ کے اختیار والے Neon Postgres میں محفوظ۔ آپ نے اسے MCP ٹول میں بھی لپیٹا تھا تاکہ دوسرے ایجنٹس اسے استعمال کر سکیں۔

لیکن وہ اب بھی ایک محدود ذخیرہ تھا جس کی حد آپ نے خود بنائی تھی۔ اس میں ہر دستاویز آپ نے چنی۔ آپ نے طے کیا کہ وہاں کون پہنچ سکتا ہے۔ ایسی کوئی چیز نہیں آئی جو آپ نے خود نہ رکھی ہو۔

اب کسی کسٹمر کی عمارت میں داخل ہوں۔

ان کے بیس سال کے working papers نظام SharePoint میں ہیں۔ engagement letters ای میل میں ہیں۔ کسی فیصلے کی وجہ چیٹ کے سلسلے اور سفر کرنے والے مینیجر کے ذہن میں ہے۔ موجودہ بیلنس ایسے نظام میں ہیں جو ہر گھنٹے بدلتا ہے۔ اس میں سے کچھ بھی آپ کا ذخیرہ نہیں۔ کام مکمل کرنے کے لیے سب ضروری ہے۔

یہ کورس وہ تہہ بناتا ہے جو ان سب تک پہنچتی ہے، اور اسے ایک ایسے سوال کے گرد بناتا ہے جو کوئی حقیقی کمپنی واقعی پوچھے گی۔

ادارہ Northstar Services بیس فیصد رعایت، ابھی invoice، اور اسی سہ ماہی میں implementation revenue کی شناخت چاہتا ہے۔ کیا یہ ممکن ہے؟

یہ ایک کسٹمر کا ایک جملہ ہے، مگر ایک سوال نہیں۔ یہ فروخت کا سوال، حساب داری کا سوال، live state کا سوال اور ای میل میں سنی ہوئی بات ہے۔ درست جواب کے لیے چاروں کو الگ رکھنا ضروری ہے۔ کورس کے آخر تک کارکن درست جواب دے گا۔ حوالوں کے ساتھ۔ موجودہ حقائق براہِ راست حاصل کر کے۔ ای میل کو اختیار نہیں بلکہ ثبوت سمجھ کر۔ اور دو پیشہ ورانہ فیصلوں کو ایک خوش گوار «ہاں» میں ملانے کے بجائے الگ رکھ کر۔

اگر یہ نئے ہوں تو پہلے تین الفاظ سمجھیں۔ رابطہ کار کسی ماخذی نظام کو پڑھتا اور اس کے مواد کی نقل تازہ رکھتا ہے۔ اشاریہ سازی اس نقل کو اس طرح محفوظ کرنا ہے کہ تلاش ہو سکے۔ اجازت کی وراثت ہر دستاویز کے access rules کو اس کے اصل نظام سے ہر نتیجے تک ساتھ لاتی ہے، تاکہ قاری صرف وہی دیکھے جسے پہلے سے کھول سکتا ہے۔

ایک خیال پورے کورس کو واضح کر دیتا ہے۔ پچھلے کورس کا ایک سوال تھا: کیا درست ٹکڑا سیاقی کھڑکی میں ہے؟ اس کورس کے تین سوال ہیں، اور ہر تصور انہی کے لیے ہے۔ تہہ سے واپس آنے والی ہر چیز کے لیے پوچھیں:

یہ کہاں سے آیا؟ کیا یہ شخص اسے دیکھ سکتا ہے؟ کیا یہ اب بھی حاکم ہے؟

تلاش خانہ ان میں سے کسی سوال کا جواب نہیں دیتا۔ سیاقی تہہ ہر شے کے لیے، ہر بار، تینوں کے جواب دیتی ہے۔ یہی پورا فرق ہے، اور اسی لیے یہ ایک کورس ہے، صرف config file نہیں۔

اس کورس میں استعمال ہونے والے بیس الفاظ

لفظ	سادہ مطلب
نظامِ ریکارڈ	وہ نظام جو کسی چیز کا سرکاری ریکارڈ رکھتا ہے۔ اگر کوئی نقل مختلف ہے تو نقل غلط ہے
عمودی شعبہ	ایک پیشہ یا صنعت، جیسے حساب داری، قانون یا sales engineering۔ یہ عمومی مقصد کے برعکس ہے
اختیار کی قسم	بیان کی نوع اور اس کا وزن: قانون، معیار، معاہدہ، پالیسی، لین دین، رہنمائی، پیغام یا مثال
عملی سیاق	کمپنی کا روزمرہ مواد: ای میل، چیٹ، مسودے اور فائلیں۔ حقیقی اور مفید، مگر کبھی اصول نہیں
رابطہ کار	وہ حصہ جو ماخذی نظام پڑھتا اور مواد کی نقل تازہ رکھتا ہے
ہم وقت سازی	رابطہ کار کا ایک دور، جو پچھلی بار کے بعد کی تبدیلیاں لاتا ہے
اشاریہ	تہہ کی قابلِ تلاش نقل، تاکہ چیزیں جلد مل سکیں
مجموعہ	تمام جڑے ماخذوں کا مواد جسے تہہ تلاش کر سکتی ہے
آزمائشی نمونہ	مشق کے لیے فرضی مگر حقیقت پسند فائل، تاکہ حقیقی ڈیٹا خطرے میں نہ ہو
دستاویزی مجموعہ	رابطہ کاروں کا نام زد گروہ، جو بتاتا ہے تلاش کن ماخذوں میں دیکھ سکتی ہے
ایجنٹ Onyx	نظام Onyx کے اندر ترتیب دیا معاون، جس کے پاس ہدایات، علم اور ٹولز ہیں
عمل	ایسا ٹول جسے ایجنٹ Onyx استعمال کر سکتا ہے، جیسے آپ کی تلاش یا براہِ راست جانچ
مستند نقل	بنائی ہوئی نقل کے بجائے اصل اور سرکاری نقل
عکس	حاکم مواد کی قابلِ تلاش نقل، جو صرف اصل ڈھونڈنے کے لیے ہے
مستقل شناخت	اصول کا مستقل نام، تاکہ نقل اصل کی طرف اشارہ کر سکے
منسوخ شدہ	نئے نسخے سے بدلا ہوا اور اب لاگو نہ رہنے والا اصول
دروازہ	نظام Onyx کے سامنے آپ کا کوڈ، جو طے کرتا ہے یہ شخص کیا تلاش کر سکتا ہے
پیکٹ	ایک سوال کے لیے جمع اصول، حقائق اور ثبوت
غلاف	کسی شے کے ساتھ لیبل: کہاں سے آئی، نسخہ، اور آپ اسے کیوں دیکھ سکتے ہیں
ماخذی سلسلہ	معلومات کہاں سے آئیں اس کی مکمل داستان

باقی ہر نیا لفظ وہیں سمجھایا گیا ہے جہاں پہلی بار آتا ہے۔

پیشگی ضروریات

یہ کورس فرض کرتا ہے کہ آپ نے قابلِ تلاش AI سیاق مکمل کیا ہے۔ آپ کے پاس Neon اور pgvector پر کام کرتا RAG ہونا چاہیے۔ آپ chunking اور embedding worker کا مطلب جانتے ہوں۔ جائزہ مجموعے سے retrieval quality پرکھنے میں بھی آسانی ہو۔ اس Neon project کو رکھیں۔ یہاں اس کا بنیادی ڈھانچہ اور retrieval skills دوبارہ استعمال ہوں گی۔ مگر صاف سمجھیں اس نے کیا بنایا اور کیا نہیں، کیونکہ یہی فرق اس کورس کا موضوع ہے۔

اس کورس نے ایک محدود بازیافتی ذخیرہ بنایا تھا: دستاویزات، ٹکڑے، عددی نمائندگیاں، تلاش اور جواب کے فنکشن، اور جانچ کا مجموعہ۔ اس نے سکھایا کہ دستاویزات قابلِ تلاش علم کیسے بنتی ہیں۔ اس نے ذخیرے کو پیشہ ورانہ اختیار نہیں دیا تھا۔ اس میں اختیار کی اقسام، قانونی دائرے، نفاذ کی مدت، یا نئے نسخے کے روابط موجود نہیں تھے۔ اسی لیے تصور 10 میں موجودہ ساخت کے ساتھ ایک چھوٹا باقاعدہ خاکہ شامل ہوگا، اور تصور 10 ہی اس تک پہنچنے کا راستہ بنائے گا۔ یہ کورس یہ بھی فرض کرتا ہے کہ Claude Code یا OpenCode کو منصوبہ بندی کی حالت میں چلانے کے لیے آپ ایجنٹی کوڈنگ، اور MCP کے لیے مہارتیں اور رابطہ کار مکمل کر چکے ہیں۔

اس کام کے پیچھے تصوراتی صفحہ سیاق کا نظام ہے۔ اگر پہلے دلیل سمجھنا چاہیں تو اسے پڑھیں۔ یہ کورس کارخانے کا فرش ہے، اور Northstar وہی عملی مثال ہے جسے وہ صفحہ حصوں میں سمجھاتا ہے۔

---

یہاں پورا نظام ایک صفحے پر ہے۔ ہر تصور کے ساتھ اسی نقشے کو مکمل کریں گے:

یہ کورس کیا احاطہ کرتا ہے

حصہ	موضوع	آپ کیا سیکھتے ہیں
1	بنیادیں	دائرۂ کار کی چھلانگ، ماخذوں کی چار اقسام، نظام Onyx کا Standard نسخہ، ایک ماڈل، اور تلاش کا بنیادی معیار
2	آپ کا پہلا مجموعہ	مشترک طریقے کی کتاب، Northstar کی فرضی فائلیں، دستاویزی مجموعے، ٹکڑا ساز، اور اجازت کی حفاظتی حد
3	حاکم حصہ	MCP پر آپ کا Neon ریکارڈ، دریافت بمقابلہ تصدیق، اور تازہ حالت
4	راستہ بندی اور حوالہ	پرامپٹ سے پہلے اختیار کا نقشہ، سات حصوں کا مجموعہ، اور الگ رکھے گئے اختلافات
5	معاملۂ Northstar	ابتدا سے انتہا تک مکمل تعمیر، پھر جان بوجھ کر توڑنے کے چار طریقے
6	اسے ثابت کریں	جانچ کی آٹھ جہتیں، اور جواب دینے والے ماڈل کو اپنی درجہ بندی کیوں نہیں کرنی چاہیے
7	اسے پیش اور چلائیں	ہر بیرونی کارکن کے لیے دروازہ، پھر کنیکٹر کی صحت، نئی کاریاں، اور تکمیل کی تعریف

آپ کیا بنائیں گے

نظام Onyx کے Standard نسخے کی ایک چلتی تنصیب، جس میں چاروں ماخذی اقسام الگ الگ جڑی ہوں۔ Agent Factory کی کتاب مشترک طریقے کے طور پر اشاریہ بند ہو۔ فروخت اور محاسبے کے Northstar کے دو شعبہ جاتی ریکارڈ مفید انداز میں اختلاف کریں۔ کسٹمر کی موجودہ حالت کے لیے براہِ راست MCP سرور ہو۔ آپ کا Neon ریکارڈ MCP پر پیش ہو اور کبھی کھوجا نہ جائے۔ نسخہ بند authority-map.yaml بتائے کہ کس سوال پر کون سا ریکارڈ حاکم ہے۔ Context Router ہر بار حوالوں سمیت وہی سات حصے واپس کرے۔ اجازت کی حفاظتی حد ایسے کردار سے جانچی جائے جس کا درست نتیجہ کچھ بھی نہیں۔ جانچ کا مجموعہ آٹھ جہتوں پر پرکھا جائے۔ Context Gateway کا MCP راستہ اجازت یافتہ بیرونی کارکنوں کو اسی شناخت اور اجازت کی حد کے ساتھ مشترک مجموعے سے سوال کرنے دے۔

اسے کیسے پڑھیں۔ حصہ 1 اور 2 کے ساتھ حصہ 5 میں Northstar کی تعمیر پورا نظام بناتی ہے۔ پڑھنے میں تقریباً دو گھنٹے اور عملی کام میں کچھ گھنٹے لگیں گے۔ حصہ 3 اور 4 اسے صرف قابلِ عمل نہیں بلکہ قابلِ اعتماد بناتے ہیں، اور دونوں ضروری ہیں: حصہ 5 ہر تصور حقیقت میں چلاتا ہے۔ پہلے بنانا اور بعد میں وجہ پڑھنا چاہتے ہیں؟ حصہ 5 سے شروع کریں۔

---

📚 تدریسی مدد

مکمل سلائیڈ نمائش کھولیں

اس کورس کی سلائیڈ نمائش تیار کی جا رہی ہے۔

---

اپنا ماحول ایک بار تیار کریں

آپ جو کچھ بنائیں گے وہ ایک فولڈر میں ہے اور پہلے سے جوڑا ہوا ہے۔

فائل context-layer-base.zip ڈاؤن لوڈ کریں

اسے کھولیں۔ اندر Northstar کا پورا معاملہ جوڑنے، ضابطہ جاتی فائلیں بھرنے، اور تین MCP سروروں کے ابتدائی ڈھانچے موجود ہیں؛ مشکل حصے TODO سے نشان زد ہیں:

fixtures/          two governed records, live state, working context
                   plus PLANTED.md, the answer key for Part 5
governance/        authority map, model register, permission matrix,
                   production gates, boundary contract
mcp/               vertical_sor, customer_state, context_gateway
prompts/           the Context Router instruction file
evals/             ten cases, scored on eight dimensions
scripts/           the governed schema for your existing Neon project
AGENTS.md          the standing rules your agent reads every session
.env.example       every credential this course needs, and nowhere else to put them

cd context-layer-base
cp .env.example .env

چھ اسناد، رکھنے کی ایک جگہ

اس کورس میں پچھلے کورس سے زیادہ شناختی معلومات ہیں، اور ہر ایک کو صرف ایک محفوظ شدہ تبدیلی میں افشا کرنا کسٹمر کا اعتماد کھونے کا راستہ ہے۔

راز	یہ کیا کھولتا ہے
Neon کا اجتماعی رابطہ جاتی سلسلہ	آپ کا باقاعدہ ریکارڈ
ماڈل فراہم کنندہ کی API کلید	ماڈل کا خرچ
نظام Onyx میں منتظم کا داخلہ	پورا مجموعہ
نظام Onyx کی API کلید	کلید کی رسائی کے مطابق تلاش
نظام Onyx کا MCP ٹوکن	اختیاری، صرف حصہ 7 میں مقامی راستے کے موازنے کے لیے
Context Gateway کے ٹوکن	ہر کردار کے لیے ایک، سرور پر نقشہ بند۔ یہی اجازت کی حد ہے

نظام Onyx میں منتظم کے داخلے کے سوا ہر راز .env میں رکھیں، جسے .gitignore پہلے سے خارج کرتی ہے۔ منتظم کے داخلے کی معلومات پاس ورڈ مینیجر میں رکھیں۔ ان میں سے کچھ بھی محفوظ شدہ فائل، پرامپٹ میں چسپاں متن، یا ٹرمینل کی تصویر میں نہیں ہونا چاہیے۔

ایجنٹ کو صاف بتائیں: شناختی معلومات ماحول سے پڑھیں، محفوظ شدہ فائل میں نہ لکھیں، اور پردے پر نہ دکھائیں۔ منظوری سے پہلے فرق دیکھیں۔

شروع سے پہلے لاگت۔ اگر پچھلا کورس کیا ہے تو کچھ نہیں۔

چیز	لاگت
نظام Onyx کی Community Edition	مفت، بنیادی حصہ MIT لائسنس کے تحت
Neon	مفت درجہ، کریڈٹ کارڈ درکار نہیں
ماڈل فراہم کنندہ	مفت درجہ کافی ہے

کتنا وقت۔ حصہ 1 اور 2 پڑھنے میں دو گھنٹے اور عملی کام میں دو یا تین گھنٹے۔ تصور 4 کی تنصیب میں تقریباً بیس منٹ انتظار ہوگا، زیادہ تر تصویری پیکج حاصل کرنے میں۔ حصہ 5 میں Northstar کی تعمیر ایک طویل دن لیتی ہے، خاص طور پر پہلے MCP سرور پر۔ اسے ایک نشست میں نہ کریں۔ پہلے نظام Onyx اور کنیکٹر، پھر باقاعدہ ریکارڈ اور دو MCP سرور، آخر میں دروازہ اور راستہ بان۔ ہر گروہ ایک سبق ہے۔

فولڈر کے علاوہ تین چیزیں درکار ہیں: ٹول Docker، کیونکہ نظام Onyx کنٹینروں کا مجموعہ ہے؛ Python کے لیے ٹول uv؛ اور آپ کا ایجنٹ۔ فولڈر میں کھولیں:

cd context-layer-base
claude

cd context-layer-base
opencode

شروع سے پہلے انتباہ، کیونکہ یہ جگہ طے کرتا ہے۔

نظام Onyx حقیقی بنیادی ڈھانچہ ہے۔ Standard نسخہ ایک ساتھ تقریباً بارہ کنٹینر چلاتا ہے: ویب کا اگلا حصہ، API کا پچھلا حصہ، nginx واسطہ، Postgres، تلاش کا اشاریہ، Redis، اشیائی ذخیرہ، دو ماڈل سرور، کوڈ چلانے والا حصہ، اور پس منظر میں ہم وقت سازی کرنے والے کارکن۔

کئی گیگا بائٹ یادداشت درکار ہے۔ عام لیپ ٹاپ پر باقی پروگراموں کے ساتھ اسے چلانا آسان نہیں۔ جماعت میں تین طریقے ہیں:

طریقہ	کس کے لیے	لاگت
ادارے کی ایک مشترک تجربہ گاہ	پوری جماعت، نظام Onyx کا ایک قابلِ رسائی نسخہ	ایک مشین، ایک بار
کم از کم مقامی تنصیب، ایک کنیکٹر	اندرونی ساخت اور کوڈ والا ہفتہ	اپنی یادداشت
آزمائشی نسخہ Onyx Cloud کا	جماعت کا ایک ہفتہ یا کمزور لیپ ٹاپ	14 دن کا آزمائشی نسخہ، کارڈ درکار نہیں

اندرونی ساخت والا ہفتہ مقامی نظام پر کریں، چاہے باقی کام مشترک تجربہ گاہ میں ہو۔ چلتی ہم وقت سازی کے دوران کنیکٹر کا کوڈ پڑھنا ایسی بات ہے جو میزبان خدمت نہیں سکھاتی۔

---

حصہ 1: بنیادیں

سادہ الفاظ میں

کچھ نصب کرنے سے پہلے چار خیالات سمجھیں۔

آپ کا پچھلا ذخیرہ چھوٹا اور محفوظ تھا، کیونکہ اس میں سب کچھ آپ کے اختیار میں تھا۔ کمپنی کے ماخذ ایسے نہیں ہوتے۔ وہ چار اقسام میں آتے ہیں، اور انہیں آپس میں ملانا اس کام کی سب سے مہنگی غلطی ہے۔ آپ نظام Onyx استعمال کریں گے۔ یہ چیزیں ڈھونڈنے میں اچھا مگر یہ طے کرنے میں کمزور ہے کہ سچ کیا ہے۔ اس کی تنصیب کے دو طریقے ہیں، جن میں سے ایک خاموشی سے وہ حصے بند کر دیتا ہے جن کے بارے میں یہ کورس ہے۔

1۔ دائرۂ کار کی چھلانگ: ایک ذخیرے سے سب کے ماخذوں تک

پڑھتے وقت Northstar کا سوال ذہن میں رکھیں، کیونکہ پچھلا کام اسے چھو بھی نہیں سکتا تھا۔

کیا Northstar کو بیس فیصد رعایت مل سکتی ہے، ابھی بل بھیجا جا سکتا ہے، اور آمدنی اسی سہ ماہی میں تسلیم ہو سکتی ہے؟

آپ کا Postgres ذخیرہ نہیں جانتا کہ Northstar کیا ہے۔ وہ نہیں جانتا کس نے کیا منظور کیا، قبولیت کب آئی یا پچھلے منگل فروخت مینیجر نے ای میل میں کیا کہا۔ یہ آپ کے کام کی کمی نہیں۔ یہ الگ نوعیت کا نظام ہے۔

آپ کے ذخیرے کی چار خصوصیات تھیں جن پر شاید دھیان نہیں گیا، کیونکہ سوچنے کی ضرورت نہ تھی۔

اس میں سب کچھ آپ نے لکھا تھا۔ ہر دستاویز docs/ فولڈر سے آئی۔ اس کا ایک قاری تھا۔ آپ کی ایپ جو اجازت دیتی، ذخیرہ بھی وہی دیتا۔ اس میں سچ کی ایک نوع تھی۔ ہر چیز آپ کی لکھی دستاویز اور سب کا وزن برابر تھا۔ کوئی براہِ راست بیلنس، دستخط شدہ ذمہ داری یا ای میل میں رائے نہ تھی۔ کوئی مواد ایسے نئے نسخے سے خاموشی سے نہیں بدلا تھا جسے آپ نے نہ دیکھا ہو۔ اور وہ اپنی ساخت سے تازہ تھا، کیونکہ صرف آپ کا کارکن اسے لکھتا تھا۔

کمپنی جوڑتے ہی یہ چاروں خصوصیات ایک ساتھ ختم ہو جاتی ہیں۔

اب مواد ان کا ہے، کچھ غلط اور کچھ منسوخ شدہ۔ اب پہلے سال کا جونیئر اور شراکت دار ایک سوال پوچھ کر الگ جواب پاتے ہیں۔ اب مجموعے میں دستخط شدہ معاہدہ، پالیسی کی یادداشت، گفتگو کا پیغام، اور بل کی براہِ راست حالت ہیں، جن کا وزن بہت مختلف ہے۔ منگل کو اشاریہ بند ہونے والی دستاویز بدھ کو ایسا شخص بدل سکتا ہے جو آپ کو کبھی نہ بتائے۔

معاملۂ Northstar چاروں کو واضح کرتا ہے۔ معاہدہ اور CRM کسٹمر کے ہیں۔ رعایت پر اکاؤنٹ ایگزیکٹو اور VP کو الگ جواب چاہیے۔ معاہدے، پالیسی، ای میل، اور منظوری کی براہِ راست حالت کا وزن الگ ہے۔ کارکن جواب بنا رہا ہو اور اسی دوران منظوری بدل سکتی ہے۔

یہی دائرۂ کار کی چھلانگ اور الگ ساخت کی وجہ ہے۔

پچھلا کورس بازیافت کا مسئلہ تھا۔ یہ ضابطے کا مسئلہ ہے جس نے بازیافت کے مسئلے کا لباس پہنا ہے۔

آپ کا کام وہی ہے: ایجنٹ کو ہدایت دینا اور نتیجہ پرکھنا۔ مگر جانچ بدلتی ہے۔ اب سوال صرف درست ٹکڑا ملنے کا نہیں۔ سوال یہ ہے: کیا ہر چیز بتاتی ہے کہ وہ کہاں سے آئی، کیا قاری اسے دیکھ سکتا ہے، اور کیا کسی نے تصدیق کی کہ وہ اب بھی لاگو ہے؟

2۔ ماخذوں کی چار اقسام اور ان کے آنے کے الگ طریقے

سب سے مہنگی غلطی ہر منسلک نظام کو بے فرق ڈھیر سمجھنا ہے۔ کچھ جوڑنے سے پہلے انہیں چار اقسام میں بانٹیں، کیونکہ قسم طے کرتی ہے کہ مواد کیسے ملے اور کارکن اس کے ساتھ کیا کرے۔

قسم	مثالیں	کیسے آتی ہے	کیا کارکن حوالہ دے سکتا ہے؟
ریکارڈ کا نظام Agent Factory	مشترک طریقہ اور معیار	دریافت کے لیے ویب پر اشاریہ بند، مستند صفحے کا حوالہ	ہاں، مشترک طریقے کے طور پر
شعبہ جاتی ریکارڈ کا نظام	Neon ریکارڈ میں Northstar کے فروخت اور محاسبے کے اصول	دریافت کے لیے اشاریہ بند، پھر MCP پر تصدیق	ہاں، حاکم اصول کے طور پر
کسٹمر کے عملی ریکارڈ	ERP، CRM، روزنامچہ، معاہدے کا نظام	براہِ راست نوعیت والی درخواست، کبھی اشاریہ بند نہیں	ہاں، اپنی موجودہ حالت کے لیے، وقت کے نشان کے ساتھ
کسٹمر کا جاری کام کا سیاق	ای میل، گفتگو، فائلیں، منصوبے کے نگران	اجازت سے باخبر اشاریہ سازی	کہی یا کی گئی بات کے ثبوت کے طور پر، اصول کبھی نہیں

اس جدول سے دو باتیں یاد رکھیں۔

پہلی تین الگ سوالوں پر بااختیار ہیں۔ فروخت کنندہ کا عام دعویٰ ہے کہ روایتی ریکارڈ «صرف معلومات محفوظ کرتا ہے» جبکہ سیاقی تہہ تشریح کرتی ہے۔ مالیاتی مدیر کے سامنے یہ بات نہ کہیں۔ ERP لین دین کی درستگی، منظوری کی حد، اور محاسبہ جاتی نشان نافذ کرتا ہے، اور انہی ضابطوں سے کاروبار چل سکتا ہے۔ فرق سنجیدگی نہیں بلکہ دائرۂ کار کا ہے: ریکارڈ اپنے شعبے میں مکمل اور اردگرد کے پیشے کے بارے میں خاموش ہے۔

صرف چوتھی قسم میں حاکم پیشہ ورانہ اختیار نہیں۔ ای میل اور گفتگو رسائی کے ضابطوں، مدتِ نگہداشت، رازداری کی پالیسی، قانونی پابندی، اور ریکارڈ کے انتظام کے تحت ہو سکتی ہیں۔ مگر ان کے پاس پیشہ ورانہ سوال طے کرنے کا اختیار نہیں۔

یہی وہ قسم ہے جس پر سب سے پہلے تلاش کا ٹول لگایا جاتا ہے، اسی لیے کئی آزمائشی نظاموں کے رواں جوابوں کے پیچھے کوئی اختیار نہیں ہوتا۔

نظام Glean میں

یہ نظام چوتھی قسم اور تیسری قسم کے کئی نظاموں کے لیے مقامی کنیکٹر، اور باقی کے لیے خدمت Indexing API دیتا ہے۔ آپ اپنی مرضی کا ماخذ بناتے، مواد، اضافی معلومات، اور اجازتوں والی دستاویزات بھیجتے، پھر منتظم کے انٹرفیس میں اسے آن کرتے ہیں۔

یہ آپ کی چار اقسام طے نہیں کرتا۔ ہر ماخذ کو KNOWLEDGE_HUB، EMAIL، MESSAGING، CRM، TICKETS وغیرہ سے نشان زد کرتا ہے، مگر یہ نشان صرف درجہ بندی اور دکھائی دینے کی شکل بدلتے ہیں۔ کوئی نشان یہ نہیں بتاتا کہ ماخذ کو حاکم اصول کہا جا سکتا ہے یا نہیں۔ ہر ماخذ کی قسم اور حوالہ آپ کا ڈیزائن فیصلہ ہے۔ نظام Onyx جدائی ہاتھ سے بنوا کر دکھاتا ہے؛ نظام Glean اسے چھوڑنے دیتا ہے، اسی لیے کئی تنصیبات بے فرق ڈھیر بن جاتی ہیں۔

چار اقسام کی مکمل دلیل کئی records میں محدود اختیار میں ہے۔

آپ کسی بھی پیشے میں ہوں، پہلا کنیکٹر لگانے سے پہلے حقیقی ماخذوں کی یہ جدول لکھیں۔ تصور 12 میں یہی راستہ بندی کا نقشہ بنے گی۔

3۔ نظام Onyx کیا ہے اور کیا نہیں

یہ نظام خود کو آپ کی دستاویزات، اطلاقات، اور لوگوں سے جڑی آزاد ماخذ اے آئی گفتگو کہتا ہے۔ یہ کورس اسے سیاق کے نظام کا کھلا حوالہ جاتی نمونہ سمجھتا ہے؛ یہ تعبیر ہماری ہے۔ یہ کئی ماخذ جوڑتا، ہم وقت نقلیں رکھتا، معنی اور کلیدی الفاظ سے تلاش کرتا، حوالہ یافتہ جواب دیتا، اور ایجنٹ و کارروائیاں پیش کرتا ہے۔ اس کا بنیادی حصہ MIT لائسنس کے تحت اور خود میزبان ہے۔ اسی لیے اسے استعمال کیا جاتا ہے۔ کنیکٹر کا کوڈ پڑھیں، ہم وقت سازی دیکھیں، اور جانیں کہ اجازت کی جانچ کہاں چلتی ہے۔ یہ حقیقی کمپنیوں میں بڑے پیمانے پر چلتا ہے۔

یہ تین چیزیں نہیں، اور ہر ایک وہ چیز ہے جو آپ بنائیں گے۔

یہ آپ کا ریکارڈ کا نظام نہیں۔ نظام Onyx تلاش کے لیے نقلیں رکھتا ہے، جبکہ باقاعدہ ریکارڈ حوالہ دینے کے لیے اصل محفوظ رکھتا ہے۔ واحد قانون یہ ہے: تہہ اختیار ساتھ لے جاتی ہے، اپنے پاس نہیں رکھتی۔ اسے الٹ دیں تو مجموعہ موجودہ دکھائی دے گا مگر کارکن پچھلے سال کے اصول کا حوالہ دے گا۔

یہ اجازت کا نظام نہیں۔ اپنے نسخے کی حد تک اجازتیں ورثے میں لیتا ہے، مگر پیشہ ورانہ ضابطے خود نافذ نہیں کرتا۔ حصہ 2 میں یہ فرق اہم ہوگا۔

یہ جواب نہیں۔ بازیافت کا نتیجہ ایک اشارہ ہے: یہاں دیکھیں۔ اسے جواب بنانے کے لیے دوسرا مرحلہ، تصور 10 کی تصدیقی درخواست، درکار ہے۔

اور ایک چیز جو Onyx نہیں مگر تیزی سے کام توڑتی ہے:

ماڈل بھی ماخذ نہیں

کارکن زبانی ماڈل پر چلتا ہے۔ بازیافت کچھ نہ دے تو وہ اپنی محفوظ تربیتی معلومات سے پیشہ ورانہ سوال کا جواب دے گا۔ نتیجہ ماخذ سے جڑا جواب دکھائی دے گا اور کوئی خرابی ظاہر نہیں ہوگی۔

ماڈل کے پاس ماخذ نہیں، عددی وزن ہیں۔ جواب کے پیچھے رجسٹر کی قطار، ناشر، اختیار کی قسم، قانونی دائرہ، نسخہ، یا نفاذ کی مدت نہیں، اور اندر کسی ایک بیان کو درست کرنے کا راستہ موجود نہیں۔ قابلِ یقین ہونا ماخذی سلسلہ نہیں۔

تین خاموش leaks دیکھیں:

• یہ خلا پُر کرنا ہے: بازیافت کچھ مفید نہ دے اور ماڈل جواب بنا دے۔
• یہ بدلتی تشریح ہے: درست اصول کو دوبارہ بیان کرتے ہوئے حد یا شرط کھو دے۔
• یہ مستقل یادداشت ہے: نشستوں کے درمیان حقائق رکھنے والا ماڈل ایسا بے نسخہ ذخیرہ بن جائے جس کا کوئی مالک نہیں۔

حل پرامپٹ نہیں بلکہ ڈھانچہ ہے۔ غائب ثبوت مجموعے کا واضح خانہ ہے، اور حاکم ماخذ نہ ملے تو کارکن آگے بڑھنے کے بجائے معاملہ اوپر بھیجتا ہے۔ مکمل دلیل تصوراتی صفحے پر موجود ہے۔

تکمیل تب ہے جب: آپ بغیر دیکھے تینوں مسائل، تصدیقی درخواست کا حل، اجازت کی حفاظتی حد کا حل، اور Neon ریکارڈ کو اشاریے سے باہر رکھنے کی وجہ بتا سکیں۔

نظام Onyx آپ بنائیں گے، Glean کے بارے میں پوچھا جائے گا

معروف تجارتی سیاقی نظام، Glean، یہاں نصب نہیں ہوگا، مگر اس کے مطالعے پر ایک گھنٹہ لگانا مفید ہے۔

اس کی دو وجوہ ہیں۔ پہلی، اس نے موجودہ ادارہ جاتی اے آئی بازار میں سیاق کے نظام کی اصطلاح مقبول کی اور اسے اپنی معلوماتی تہہ کا نام بنایا۔ کتاب اسے دانستہ اپناتی ہے تاکہ فارغ التحصیل خریدار کی زبان بول سکے۔ اصطلاح کس نے بنائی، اس کا دعویٰ یہاں نہیں۔ دوسری، بازار نے اس تہہ کی قیمت اسی مصنوع سے دیکھی۔ کمپنی اسے «ادارہ جاتی اے آئی تلاش»، «کام کا معاون»، «اے آئی علمی تہہ»، یا «ادارہ جاتی سیاقی نظام» کہہ سکتی ہے۔ سامنے والے نے غالباً نظام Glean کا مظاہرہ دیکھا ہوگا۔

مصنوع کے صفحات کو بنیادی اصول نہیں بلکہ تشخیصی وسیلہ سمجھیں۔ ایک سوال پوچھیں:

اس ڈھانچے کے کون سے حصے مصنوع حقیقت میں بناتی ہے، اور کون سے خاموشی سے آپ پر چھوڑ دیتی ہے؟

یہ سوال کنیکٹر کی فہرست، اجازت کے نمونے، حوالہ جاتی شکل، اور کارروائی کی سطح پر لگائیں۔ وہی چار اقسام، اجازت کا مسئلہ، اور دریافت و تصدیق کا خلا ملے گا۔

اس زمرے کے نام بدلتے رہے ہیں: بصیرتی انجن، ادراکی تلاش، ادارہ جاتی اے آئی تلاش، اور تخلیقی اے آئی علمی انتظام۔ تہہ سیکھیں، نشان نہیں۔ شروع کے تین سوال ہر مصنوع کے نام سے زیادہ عرصہ قائم رہیں گے۔

آگے اکثر تصورات کے آخر میں «نظام Glean میں» کا نوٹ ہوگا: تجارتی مصنوع میں خیال کی شکل، اور کون سا حصہ مصنوع کا جبکہ کون سا آپ کا ڈیزائن ہے۔ کسی کھاتے کی توقع نہیں؛ ملاقات میں مشترک اور مختلف باتیں صاف بتانے کی توقع ہے۔

پھر نظام Onyx کیوں، Glean کیوں نہیں؟

دیانت دار جواب کے تین حصے ہیں، اور صرف پہلا مصنوعات کے بارے میں ہے۔

اول، مصنوع میں ضابطہ موجود ہونے کا دعویٰ پڑھ کر آپ ضابطہ نہیں سیکھتے۔ نظام Glean کا اجازت کا نمونہ تصور 9 میں ہاتھ سے بنائی حد سے بہتر مگر نظروں سے اوجھل ہے۔ آپ اسے ترتیب دیتے ہیں اور وہ چل پڑتا ہے، مگر ناکامی نہیں سمجھتے۔ ایک بار ایسے کردار کا راستہ بنانا جس کا درست نتیجہ خالی ہو، کہیں زیادہ سکھاتا ہے۔

دوم، بند ڈبہ ڈھانچہ نہیں سکھاتا۔ کنیکٹر کا کوڈ، ٹکڑا ساز کا ضابطے پھینکنا، اور پرانی شاخ کا مکمل حوالوں کے ساتھ غلط جواب نظام Onyx میں دکھائی دیتے ہیں، مصنوع کے صفحے میں نہیں۔

سوم، زیادہ تر کورس مصنوع کے بارے میں نہیں۔ ماخذ کی قسم، حاکم ریکارڈ، تازگی، اور اختلاف نظام کی خصوصیات نہیں بلکہ پیشہ ورانہ فیصلے ہیں۔ نظام Glean پر بھی کورس یہی سات چیزیں سکھائے گا، صرف نیچے کی مشینری کم دکھائی دے گی۔

کسٹمر کو نظام Glean کب استعمال کرنا چاہیے؟

اکثر۔ صاف کہیں۔

اگر اگلی سہ ماہی تک کئی SaaS نظاموں میں اجازت کی وراثت چاہیے تو خریدنا بہتر ہے۔ نظامی ٹیم نہ ہو تو میزبان خدمت بہتر ہے۔ پہلے سے نظام Glean موجود ہو تو منتقلی کی تجویز نہ دیں۔ اس کا باقاعدہ ریکارڈ جوڑیں اور بتائیں کہ موجودہ ترتیب تین میں سے کن سوالوں کا جواب دیتی ہے۔

پورے کورس کا اصول:

ہم وہ سکھاتے ہیں جسے کھول سکتے ہیں۔ آپ وہی نظام لگائیں گے جو کسٹمر خرید چکا ہے۔ ڈھانچہ دونوں میں ایک ہے، اور یہی حصہ آپ کا ہے۔

4۔ Standard نصب کریں، Lite نہیں

نظام Onyx میں طریقہ Lite اور طریقہ Standard موجود ہیں؛ غلط انتخاب ایک دن ضائع کر سکتا ہے۔

طریقہ Lite گفتگو کا مختصر انٹرفیس ہے۔ یہ عددی اشاریہ، پس منظر کے کنیکٹر کارکن، اور کورس کا بنیادی ڈھانچہ بند کر دیتا ہے۔ طریقہ Standard منتخب کریں۔

نصب کار Docker Compose سے نظام لگاتا اور طریقہ پوچھتا ہے۔ تنصیبی فائل بدلتی رہتی ہے، اس لیے ایجنٹ سے موجودہ دستاویزات پڑھوائیں:

نظام Onyx کے موجودہ Quickstart اور Resourcing صفحات پڑھیں۔ مشین پر Docker کے CPU، یادداشت، اور خالی ڈسک کو تقاضوں کے خلاف جانچیں۔ نظام Onyx کی Community Edition کا تازہ مستحکم نسخہ طریقہ Standard میں localhost پر نصب کریں۔ عین نسخہ، طریقہ، دروازے، اور مستقل معلومات کی جگہ README.md میں درج کریں۔ Lite نہیں۔ کنٹینر چلانے سے پہلے منصوبہ اور وسائل کی جانچ دکھائیں۔

منصوبے میں طریقہ Standard اور معلومات کی جگہ کی منظوری دیں۔ آغاز کے بعد:

چلتے کنٹینر اور نوشتہ جات دیکھیں۔ صحت مند خدمات، انٹرفیس کا دروازہ، اور دہرائی جانے والی خرابیاں بتائیں۔ وجہ اور عین کمانڈ دکھانے سے پہلے کسی چیز کو دوبارہ شروع یا ازسرِ نو نہ بنائیں۔

وسائل کی ناکامی سافٹ ویئر کی خرابی جیسی لگتی ہے

نظام Docker کو کم یادداشت ملے تو تلاش اور اشاریہ سازی کی خدمات دوبارہ شروع، منجمد، یا صحت کی جانچ میں ناکام ہوتی ہیں؛ ہر علامت ترتیبات کی خرابی جیسی دکھتی ہے۔

صرف 4 GB والی Docker مشین پر ترتیبات کی خرابی ڈھونڈنے میں گھنٹہ نہ لگائیں۔

مقامی تجربہ گاہ کے لیے کم از کم 4 مجازی CPU اور 10 GB یادداشت درکار ہے؛ 8 CPU اور 16 GB بہتر ہیں۔ پہلے وسائل کی تصدیق کریں۔

منصوبہ پڑھیں۔ تین کنٹینروں کو جانیں: زیادہ یادداشت لینے والا عددی اشاریہ، پہلے آغاز پر سست ماڈل سرور، اور پس منظر میں ہم وقت سازی کرنے والے کارکن جہاں ناکام کنیکٹر چھپتا ہے۔

دھیان دیں: پہلے آغاز پر کئی GB تصویری پیکج اور ماڈل سرور کئی منٹ لیتے ہیں۔ یہ متوقع ہے، جمود نہیں۔ تلاش خالی ہو تو کنیکٹر کی پہلی ہم وقت سازی باقی ہو سکتی ہے۔ بار بار آغاز میں پہلے یادداشت دیکھیں۔

تکمیل تب ہے جب: آپ ویب انٹرفیس، منتظم کا پہلا داخلہ، اور سب کچھ بند کرکے ڈسک واپس لینے کی ایک کمانڈ جانتے ہوں۔

نظام Glean میں

کوئی تنصیب نہیں۔ میزبان خدمت اپنے بنیادی ڈھانچے یا آپ کے GCP/AWS کھاتے میں ایک کسٹمر کی تنصیب پر چلتی ہے، مگر نظام لگانے اور نئے کرنے کی ذمہ داری Glean کی ہوتی ہے۔ اس سے کنٹینروں کی فہرست، یادداشت کا حساب، اور حصہ 7 میں ڈسک کی نگرانی غائب ہو جاتی ہے۔

یہ سودا عملی انتظام اور کوڈ پڑھنے دونوں کو ہٹا دیتا ہے۔ نظام Onyx ایک بار بنانے والا شخص عددی اشاریے کی لاگت اور خاموش ہم وقت سازی کی ناکامی جانتا ہے؛ صرف میزبان خدمت استعمال کرنے والا نہیں۔

ایک ماڈل، جان بوجھ کر منتخب

نظام Onyx سیاقی نظام اور زبانی ماڈل کو الگ رکھتا ہے۔ منتظم کے انٹرفیس میں ایک اہل فراہم کنندہ اور مختصر فہرست رکھیں؛ سیاقی تہہ پرکھیں، دس گفتگو کے ماڈل نہیں۔ ایجنٹ سے governance/model-register.md میں فراہم کنندہ، ماڈل، تاریخ، معلومات کا مفروضہ، دکھائی دینے کی حد، اور وجہ لکھوائیں۔ ایک خانہ مزید شامل کریں:

متبادل جانچ۔ زیادہ طاقتور ماڈل ٹول کا استعمال اور جواب کی تشکیل بہتر کر سکتا ہے، مگر غائب کنیکٹر، غلط راستہ بندی، پرانے حقائق، یا ٹوٹی اجازت کی حد درست نہیں کر سکتا۔ اسے رجسٹر میں لکھیں۔

تبدیلی سے پہلے تلاش کی بنیاد

پچھلے کورس کی بازیافتی مشینری اب نظام Onyx مہیا کرتا ہے۔ فوراً عدد ساز ماڈل یا تجربات نہ بدلیں؛ ماڈل کی تبدیلی مکمل دوبارہ اشاریہ سازی مانگتی ہے۔ مستحکم ابتدائی ترتیبات رکھیں اور governance/search-baseline.md میں نظام Onyx کا نسخہ، عدد ساز ماڈل، دوبارہ درجہ بندی، تاریخ، جانچ کا نسخہ، اور وجہ درج کریں۔

اصول: بازیافت کی تبدیلیوں کو ناپیں، صرف پسند نہ کریں۔ نظام Onyx SQL چھپاتا ہے، ثبوت کی ضرورت نہیں۔

اصولوں کی فائل

/init چلائیں اور چار سطریں لکھیں: نظام Onyx کا نسخہ، شناختی معلومات ماحول میں، حقیقی کسٹمر کی معلومات نہیں، اور:

ایسا ماخذ کبھی نہ جوڑیں جسے میں نے اسی نشست میں واضح طور پر منظور نہیں کیا۔

کنیکٹر کسی کی معلومات نقل کرنے کی مستقل ہدایت ہے؛ اس کا جائزہ نقصان دہ SQL جتنی احتیاط سے لیں۔

---

حصہ 2: آپ کا پہلا مجموعہ

آسان الفاظ میں

اب آپ حقیقی مواد جوڑیں گے اور دیکھیں گے کہ اس کے ساتھ کیا ہوتا ہے۔

آغاز اسی کتاب سے کریں، کیونکہ یہ عوامی ہے اور اس کے لیے کسی اجازت کی ضرورت نہیں۔ پھر Northstar نام کا ایک فرضی کسٹمر بنائیں اور اس کی فائلیں جوڑیں۔ غور سے دیکھیں کہ تلاش کے اشاریے نے کیا محفوظ رکھا اور کیا خاموشی سے پھینک دیا۔ اس کے بعد کورس کی سب سے اہم چیز بنائیں: ایسی جانچ جو طے کرے کہ ہر شخص کو کیا تلاش کرنے کی اجازت ہے۔

ہم ایک چھوٹی فرضی کمپنی بنائیں گے: دو زیرِ انتظام ریکارڈ، دو عملی حالت کے نمونے، اور ای میل و گفتگو پر مشتمل جاری کام کا فولڈر۔ اسے جان بوجھ کر فرضی رکھا گیا ہے، اور تصور 8 بتاتا ہے کہ یہ کوئی مختصر راستہ کیوں نہیں۔

5۔ پہلے مشترک طریقہ، پھر کسٹمر جوڑیں

اس ماخذ سے آغاز کریں جس کے لیے کسی اجازت کی ضرورت نہیں۔ نظام Onyx کا ویب کنیکٹر بنیادی پتے کے تحت صفحات کھوجتا ہے، دستیاب روابط کی پیروی کرتا ہے، متن صاف کرتا ہے، اور حوالہ دینے کے لیے ماخذ کی معلومات محفوظ رکھتا ہے۔

خانہ	قدر
کنیکٹر کی قسم	Web
نام	AF-SOR-PUBLIC
بنیادی پتہ	https://agentfactory.panaversity.org/docs/getting-started
ماخذ کی قسم	Agent Factory System of Record
اجازت کی بنیاد	عوامی

جی ہاں، آپ اسی کتاب کو اشاریے میں شامل کر رہے ہیں۔ یہی مقصد ہے۔ ریکارڈ کا Agent Factory نظام ایک حقیقی، عوامی، اور باقاعدہ ماخذ ہے۔ صرف یہی قسم پہلے دن کسی ایک اجازت کے سوال کے بغیر جوڑی جا سکتی ہے۔

ہر باقاعدہ ماخذ پر ایک بات لاگو ہوتی ہے۔ اشاریہ کارکن کو طریقہ تلاش کرنے میں مدد دیتا ہے۔ حوالہ لازماً اصل صفحہ دوبارہ کھولے۔

ویب سے اشاریہ بند کیا گیا ٹکڑا کسی مستحکم ویب پتے کی طرف اشارہ ہے، اس کا بدل نہیں۔ یہی پہلے تلاش، پھر تصدیق کی ساخت ہے جسے آپ تصور 10 میں درست طور پر بنائیں گے۔

اب کسٹمر کی باری ہے۔ نمونۂ Northstar کی فائلیں بنیادی فولڈر میں پہلے سے موجود ہیں، اس لیے انہیں بنانے کے بجائے جوڑیں۔ کچھ بھی جوڑنے سے پہلے fixtures/ کھول کر اس کا مواد پڑھیں:

فولڈر	اس میں کیا ہے
sales-sor/	فروخت کے تین باقاعدہ اصول؛ ہر ایک کے ساتھ مستقل شناخت، نسخہ، اور نفاذ کی تاریخ۔ رعایت کا اصول اکاؤنٹ ایگزیکٹو کو 15 فیصد تک اجازت دیتا ہے
accounting-sor/	محاسبے کے چار باقاعدہ اصول، جن میں ایک جان بوجھ کر منسوخ شدہ فائل کہتی ہے کہ آمدنی منظوری کے بجائے بل بننے پر تسلیم ہوتی ہے
operational/	دو JSON ریکارڈ: منظوری زیرِ التوا، قبولیت موصول نہیں ہوئی۔ انہیں کبھی اشاریے میں شامل نہیں کیا جاتا
working-context/	تین ای میل اور دو گفتگو کے سلسلے؛ ان میں سے ایک دعویٰ کرتا ہے کہ مالیاتی شعبہ ایسی بات سے متفق ہے جس کی کوئی باقاعدہ بنیاد نہیں

فائل fixtures/PLANTED.md میں چاروں جان بوجھ کر رکھی گئی بے قاعدگیاں درج ہیں۔ اس فائل کو اشاریے میں شامل نہ کریں، اور حصہ 5 تک اسے غور سے نہ پڑھنے کی کوشش کریں۔ یہی جواب نامہ ہے۔

اگر آپ اپنا مجموعہ بنانا چاہتے ہیں، یا جانچ کے لیے دوسرا مجموعہ درکار ہے، تو یہ پرامپٹ مساوی مواد بنا دے گا:

کسٹمر Northstar Services کے لیے fixtures/ نام کا فرضی فولڈر بنائیں۔

فولڈر fixtures/sales-sor/ کے اندر فروخت کا ایک مختصر باقاعدہ ریکارڈ بنائیں: رعایت کے اختیار کا اصول جو کہے کہ پندرہ فیصد سے زیادہ رعایت کے لیے VP Sales کی منظوری درکار ہے، اور اس کے ساتھ اہلیت کا طریقہ اور تجویز کی پالیسی۔ ابتدائی معلومات میں ہر اصول کو مستقل شناخت، نسخہ، اور نفاذ کی تاریخ دیں۔

فولڈر fixtures/accounting-sor/ کے اندر محاسبے کا ایک مختصر باقاعدہ ریکارڈ بنائیں: نفاذ سے متعلق آمدنی کا اصول جو کہے کہ آمدنی کسٹمر کی قبولیت پر تسلیم ہوتی ہے، ساتھ دو معاون اندراجات اور وہی ابتدائی معلومات۔ پھر ایک منسوخ شدہ فائل شامل کریں جو کہے کہ آمدنی بل بننے پر تسلیم ہوتی ہے، اور اس کے ساتھ پرانی نفاذ کی تاریخ اور نئے نسخے کا ربط ہو۔

فولڈر fixtures/operational/ کے اندر دو JSON ریکارڈ بنائیں: ایک موقع جس میں بیس فیصد رعایت مانگی گئی ہو اور منظوری زیرِ التوا ہو، اور ایک معاہدہ جس میں دستخط مکمل مگر قبولیت موصول نہ ہوئی ہو۔

فولڈر fixtures/working-context/ کے اندر تین ای میل اور دو گفتگو کے سلسلے بنائیں۔ فروخت کے مینیجر کی ایک ای میل میں لکھا ہو، "finance is fine with booking it this quarter"، جس کی کوئی باقاعدہ بنیاد نہ ہو۔

آخر میں fixtures/PLANTED.md لکھیں جس میں جان بوجھ کر بنائی گئی ہر بے قاعدگی درج ہو، تاکہ بعد میں جانچ سکوں کہ نظام نے انہیں تلاش کیا یا نہیں۔ اس فائل کو اشاریے میں شامل نہ کریں۔

فولڈروں کو ایک کنیکٹر کے بجائے الگ الگ کنیکٹر کے طور پر جوڑیں:

کنیکٹر	ماخذ کی قسم	الگ رکھنے کی وجہ
VERTICAL-SALES-SOR	شعبے کا ریکارڈ	رعایت کے اختیار کو منظم کرتا ہے
VERTICAL-ACCOUNTING-SOR	شعبے کا ریکارڈ	آمدنی تسلیم کرنے کے اصول کو منظم کرتا ہے
CUSTOMER-WORKING-CONTEXT	جاری کام کا سیاق	صرف ثبوت، کبھی اختیار نہیں

جو چیز آپ جوڑتے ہیں وہ آپ کی ملکیت نہیں بن جاتی

آپ کسٹمر کے مواد کو اشاریے میں شامل کرنے والے ہیں۔ وہ اسی کی ملکیت رہتا ہے۔

کمپنی Northstar کی ای میل، گفتگو کے سلسلے، بلکہ اس کے باقاعدہ اصول بھی کسٹمر کے نظام میں کسٹمر ہی کا مواد ہیں۔ وہ اس مشترک شعبہ جاتی ریکارڈ میں منتقل نہیں ہوتے جسے آپ ایک کسٹمر سے دوسرے تک لے جاتے ہیں۔ ایسا کرنا آلودگی ہے: آپ کے پیشے کے ریکارڈ میں ایک کمپنی کا نجی مواد آ جائے گا اور آپ اسے کہیں اور نہیں لے جا سکیں گے۔

مواد صرف ترقی کے قانون کے تحت اوپر جاتا ہے: کوئی نمونہ تین یا زیادہ کسٹمروں میں دہرایا جائے، شناختی نشانیاں ہٹا دی جائیں، ترقی کا جائزہ پاس کرے، اور آپ کی ماہر اسے اپنی زبان میں دوبارہ لکھے۔ یہ تصنیف ہے، نقل نہیں۔

چیزیں جوڑتے وقت یہ اصول یاد رکھیں: کسٹمر کی دنیا اندر آتی ہے۔ باہر کچھ نہیں جاتا۔

غور کریں کہ اس جدول میں کیا نہیں ہے۔ عملی JSON بالکل نہیں جوڑی جاتی۔ اسے تصور 11 میں براہِ راست پیش کیا جائے گا، اور اس کی وجہ اسی پورے تصور کا موضوع ہے۔

یہ دیکھیں: متن کے علاوہ کنیکٹر ہر دستاویز کے ساتھ کیا لاتا ہے۔ مقامی فولڈر کا فائل کنیکٹر راستہ اور تبدیلی کا وقت دیکھتا ہے، مگر یہ نہیں جانتا کہ اسے کون پڑھ سکتا ہے۔ حقیقی SharePoint یا Drive کا کنیکٹر رسائی کے اصولوں سمیت کہیں زیادہ معلومات دیکھتا ہے۔ یہی فرق تصور 8 کا پورا موضوع ہے، اور اسے فولڈر پر دیکھنا سب سے کم خرچ طریقہ ہے۔

یہ بھی دیکھیں: اگر ہم وقت سازی مکمل دکھائے مگر تلاش کچھ واپس نہ لائے تو عموماً اشاریہ سازی پس منظر میں جاری ہوتی ہے؛ انتظار کرکے دوبارہ تلاش کریں۔ اگر کنیکٹر خرابی دکھائے مگر تلاش چلتی رہے تو پرانا مواد اپنی جگہ موجود ہے، جو حصہ 7 کا پھندا ہے۔ اجازت کی تبدیلی پھیلنے میں بھی کچھ وقت لیتی ہے، اس لیے پابندی لگانے کے بعد دستاویز چند سیکنڈ تک دکھائی دے سکتی ہے۔

دستاویزی مجموعے: تلاش کا دائرہ، قانونی درجہ بندی نہیں

کنیکٹر بتاتا ہے کہ مواد کہاں سے آیا۔ دستاویزی مجموعہ نظام Onyx میں کنیکٹروں کے نام زد گروہ کو کہتے ہیں۔ اس سے طے ہوتا ہے کہ کسی خاص تلاش یا ایجنٹ کو کن ماخذوں میں دیکھنے کی اجازت ہے۔

دستاویزی مجموعہ	شامل مواد	مقصد
AF Shared Method	AF-SOR-PUBLIC	ڈھانچہ اور بنیادی اصول
Sales Authority	VERTICAL-SALES-SOR	فروخت کے باقاعدہ اصول
Accounting Authority	VERTICAL-ACCOUNTING-SOR	محاسبے کے باقاعدہ اصول
Customer Working Context	CUSTOMER-WORKING-CONTEXT	معاون ثبوت
Northstar Cross-Domain	چاروں	تجربہ گاہ کا مکمل مجموعہ

یہ تین کام کرتے ہیں۔ دائرہ واضح بناتے ہیں۔ ایجنٹ کو صرف اس کام کے لیے ضروری ماخذوں میں تلاش کرنے دیتے ہیں۔ اور مختلف شعبوں میں جانچ سے پہلے ایک شعبے کے اندر جانچ ممکن بناتے ہیں، جس سے راستہ بندی کی خرابی اور بازیافت کی خرابی الگ دکھائی دیتی ہیں۔ ایک تنبیہ یاد رکھیں:

دستاویزی مجموعہ تلاش کا دائرہ ہے، اختیار کی درجہ بندی نہیں۔ یہ بتاتا ہے کہ کہاں دیکھا جا سکتا ہے۔ یہ نہیں بتاتا کہ حکم کس کا چلتا ہے۔

حکم کس کا چلتا ہے، یہ ایک الگ فائل بتاتی ہے جو تصور 12 میں آئے گی۔

کام تب مکمل ہے جب: صرف Sales Authority کے دائرے میں تلاش کرنے پر آمدنی تسلیم کرنے کے بارے میں کچھ واپس نہ آئے۔ اس سے ثابت ہوتا ہے کہ دائرہ درست کام کر رہا ہے، اور بعد میں اسی سے راستہ بندی کی خرابی اور بازیافت کی خرابی میں فرق معلوم ہوگا۔

6۔ ہم وقت سازی دیکھیں اور جانیں کہ ٹکڑے بنانے والے نے کیا پھینکا

پچھلے کورس سے آپ ٹکڑے بنانے کا عمل جانتے ہیں، جہاں پیمانے جسامت اور باہمی تکرار تھے اور اصل داؤ یادآوری کا تھا۔ یہاں ایک دوسرا اور بڑا داؤ بھی ہے۔

باقاعدہ ریکارڈ کے ہر اندراج کے ساتھ بارہ چیزیں ہوتی ہیں۔ مستقل شناخت۔ شعبہ۔ اختیار کی قسم۔ قانونی دائرہ۔ نسخہ۔ نفاذ کی تاریخ۔ منظوری کی حالت۔ اطلاق کی شرائط۔ مالک۔ نئے نسخے کا ربط۔ ضروری جانچ کار۔ اجازت کی حد۔

عام اشاریہ سازی کا سلسلہ صرف جملہ محفوظ رکھتا ہے۔

اختیار منتقل ہونے پر آمدنی تسلیم کی جا سکتی ہے۔

الفاظ بچ جاتے ہیں۔ بارہوں ضابطے غائب ہو جاتے ہیں، اور بازیافت شدہ متن میں کہیں نہیں بتایا جاتا کہ وہ موجود نہیں۔

اب کارکن چھ باتیں نہیں بتا سکتا۔ بیان پر کون سا معیار لاگو ہے۔ کیا یہ اس قسم کے معاہدے پر لاگو ہوتا ہے۔ کیا یہ موجودہ ہے۔ کیا یہ اس ملک پر لاگو ہے۔ کیا یہ اختیار ہے یا صرف وضاحت۔ اور کون سی استثنائی صورت جواب بدل سکتی ہے۔

اسے اپنے مجموعے پر دیکھیں:

فولڈر fixtures/accounting-sor/ سے ایسا اصول لیں جس کی ابتدائی معلومات میں نسخہ اور نفاذ کی تاریخ ہو۔ پہلے خام دستاویز دکھائیں، پھر بالکل دکھائیں کہ اشاریے میں اس کا ایک ٹکڑا کیسا ہے: ٹکڑے کا متن اور اس کے ساتھ محفوظ ہر خانہ۔ واضح کریں کہ دستاویز کی سطح کے کون سے حقائق ٹکڑے تک نہیں پہنچے۔

کام تب مکمل ہے جب: آپ ایک ٹکڑا دکھا کر اس کی اصل دستاویز کے بارے میں ایسی سچی بات بتا سکیں جو صرف ٹکڑا پڑھنے والا کارکن کبھی نہ جان سکے۔ یہ نظام Onyx کی خرابی نہیں۔ یہی تصور 10 میں تصدیقی مرحلہ رکھنے کی وجہ ہے۔

نظام Glean میں

نظام Glean کی Indexing API دستاویزات کے ساتھ ساختہ معلومات منسلک کرنے دیتی ہے، اور اس کا علمی نقشہ لوگوں، مواد، اور عمل کے وہ تعلقات محفوظ رکھتا ہے جنہیں عام ٹکڑا ساز پھینک دیتا ہے۔ اس لیے یہاں خلا نظام Onyx کے مقابلے میں کم ہے۔

کم ہونے کا مطلب بند ہونا نہیں۔ کوئی بھی نظام تب تک نہیں جانتا کہ آپ کے اصول کی نفاذ کی تاریخ، قانونی دائرہ، اور نئے نسخے کا ربط کیا ہے، جب تک آپ یہ خانے مہیا نہ کریں اور کارکن کو انہیں جانچنا نہ سکھائیں۔ دونوں صورتوں میں بارہوں ضابطے آپ ہی کو سنبھالنے ہیں۔

7۔ تلاش کریں اور دیکھیں کہ کیا واپس آیا

مجموعے میں ایسا سوال تلاش کریں جس کا جواب دو دستاویزات میں پھیلا ہو۔ نتائج ان کے نمبروں اور ماخذوں سمیت دکھائیں، پھر وہی سوال نظام Onyx کی گفتگو کے ذریعے پوچھیں تاکہ اس کے لگائے ہوئے حوالے نظر آئیں۔

اب ہر نتیجے سے تین سوال بلند آواز میں پوچھیں، یہاں تک کہ یہ عادت بن جائے:

یہ کہاں سے آیا؟ نظام Onyx اس کام میں اچھا ہے اور حوالہ سامنے موجود ہے۔ جانچیں کہ وہ کسی پہچانی ہوئی دستاویز کی طرف جاتا ہے۔

کیا اس شخص کو یہ دیکھنے کی اجازت ہے؟ فی الحال سچا جواب یہ ہے کہ سب کو سب کچھ دکھائی دیتا ہے، کیونکہ صارف صرف آپ ہیں اور ماخذ ایک فولڈر ہے۔ اس خیال کو اگلے چار منٹ تک ذہن میں رکھیں۔

کیا اس کا حکم اب بھی چلتا ہے؟ نظام Onyx یہ نہیں بتا سکتا۔ اسے صرف آپ کے الفاظ سے ملتی ہوئی دستاویز ملی ہے۔ یہ موجودہ نسخہ ہے یا نہیں، اس سوال کا جواب مماثلت کا کوئی نمبر نہیں دے سکتا۔ آزمائیں: تصور 5 میں جوڑی گئی منسوخ شدہ محاسبے کی فائل کے موضوع کو تلاش کریں اور دیکھیں کہ کون سا نسخہ پہلے واپس آتا ہے۔

بازیافت کا نتیجہ ایک اشارہ ہے، جواب نہیں۔ حصہ 3 اور 4 کی ہر چیز اشاروں کو ایسے جواب میں بدلنے کے لیے ہے جس کا آپ دفاع کر سکیں۔

یہ بات کن چیزوں پر لاگو ہوتی ہے، اس میں درست رہیں۔ باقاعدہ علم کا اصل ماخذ موجود ہوتا ہے، اس لیے اس کا نتیجہ اشارہ ہے۔ جاری کام کے سیاق کا ایسا کوئی اصل نسخہ نہیں: منگل کو مینیجر نے جو کہا، اس کا کوئی مستند نسخہ نہیں، اور بازیافت شدہ ای میل خود وہ مواد ہے۔ جاری کام کے سیاق کو دیانت دار رکھنے والے دوسرے دو سوال ہیں: کیا یہ شخص اسے دیکھ سکتا ہے، اور کیا اسے اصول کے بجائے ثبوت کے طور پر پیش کیا جا رہا ہے۔

کام تب مکمل ہے جب: آپ منسوخ شدہ محاسبے کی فائل کا موضوع تلاش کرکے دیکھ چکے ہوں کہ کون سا نسخہ پہلے آیا۔ جو بھی آیا، اب آپ جانتے ہیں کہ نظام Onyx نے تازگی کی بنیاد پر فیصلہ نہیں کیا۔

8۔ اجازت کی وراثت اور Community Edition کی حد

یہ کورس کا سب سے اہم اور سب سے زیادہ نظر انداز کیا جانے والا تصور ہے، کیونکہ اسے چھوڑ دینے سے تقریباً چھ ہفتے تک ہر چیز آسان لگتی ہے۔

دستاویز کے رسائی کے اصول اس کے اصل نظام میں رہتے ہیں۔ نجی گفتگو نجی ہے۔ محدود فولڈر محدود ہے۔ جب آپ کی تہہ اس دستاویز کی نقل بنائے تو اسے رسائی کے اصول بھی ساتھ نقل کرنے چاہییں، اور ہر سوال کے وقت خاص پوچھنے والے شخص کے لیے انہیں دوبارہ جانچنا چاہیے۔ اجازت ورثے میں ملتی ہے، بنائی نہیں جاتی۔ یہ صرف رازداری نہیں بلکہ ضابطے کا سوال کیوں ہے، اس کی دلیل اجازت ماڈل سے پہلے آتی ہے میں دی گئی ہے۔

اسے غلط کریں تو محض معلوماتی رساؤ سے بھی برا نظام بنے گا: ایسا نظام جو رساؤ میں مددگار ہو۔ ایک کم درجے کا ملازم مناسب سوال پوچھے اور پہلے نمبر پر دوستانہ خلاصے کے ساتھ وہ معاوضے کی یادداشت پا لے جسے کھولنے کی اسے کبھی اجازت نہ تھی۔ کسی نے حملہ نہیں کیا۔ تہہ نے صرف غلط اصولوں کے تحت اپنا کام کیا۔

حد Community Edition کی: کیا ثابت نہیں ہو سکتا

نظام Onyx کی Community Edition کنیکٹر، اشاریہ سازی، بازیافت، حوالے، ایجنٹ، اور کارروائیاں سیکھنے کے لیے کافی ہے۔ مگر یہ اپنے طور پر مختلف صارفین کے درمیان پیداواری اجازت کی درستگی ثابت کرنے کے لیے کافی نہیں۔

نظام Onyx کی دستاویزات بیرونی نظاموں سے صارف کی اجازتیں ورثے میں لینے والے ہم وقت سازی کے کنیکٹر، صارف گروہ، RBAC، اور گروہ پر مبنی اجازتوں کو خود میزبان Community Edition کے بجائے نسخوں Onyx Cloud اور Enterprise Edition کی خصوصیات قرار دیتی ہیں۔ بیرونی نظام سے اجازت کی وراثت درکار ہونا Enterprise کی طرف جانے کی ایک وجہ بھی بتایا گیا ہے۔

اس لیے خالص Community Edition کی تجربہ گاہ میں ہر طالب علم ایک ہی مجموعہ دیکھتا ہے۔ آپ وہ نمونہ نہیں دکھا سکتے جس میں محدود کردار سوال کرے اور درست طور پر کچھ واپس نہ پائے۔ اگر آپ کا گروہ ترتیب کے جدول سے Onyx Cloud کا آزمائشی نسخہ چلاتا ہے تو یہ ممکن ہے، اور ایک ہفتے کے لیے یہ دیکھنا مفید ہے کہ حقیقی رسائی کی ہم وقت سازی وہ کام خود کیسے کرتی ہے جسے آپ اب ہاتھ سے کرنے والے ہیں۔

نظام Glean میں

یہ وہ تصور ہے جہاں تجارتی نظام صاف طور پر آگے ہے، اور دفاعی ہوئے بغیر یہ بات کہنا ضروری ہے۔

نظام Glean ہر منسلک نظام سے مواد کے ساتھ رسائی کی فہرست پڑھتا ہے اور ماخذ میں پہلے سے موجود اجازتیں نافذ کرتا ہے۔ اگر آپ Drive کی فائل یا Slack کی گفتگو نہیں کھول سکتے تو وہ نہ نتائج میں آتی ہے نہ آپ کے لیے لکھے گئے جواب تک پہنچتی ہے۔ اس کی Indexing API آپ کے اپنے مواد کے لیے بھی یہی نمونہ دیتی ہے، جس میں ہر دستاویز پر فی صارف اور فی گروہ اجازتیں اور ان کی تصدیق کے لیے checkdocumentaccess راستہ شامل ہے۔

لہٰذا نظام Glean میں آپ اسے ترتیب دیتے ہیں۔ نظام Onyx کی Community Edition میں آپ اسے بناتے ہیں، جو تصور 9 ہے۔

اسے ایک بار بنانا بہتر تعلیم ہے۔ اسے خریدنا عموماً بہتر پیداواری فیصلہ ہے۔ سامنے موجود صورتِ حال میں ان دونوں میں سے کون سا جملہ لاگو ہوتا ہے، یہی اصل مہارت ہے۔

اس مسئلے سے نمٹنے کے تین طریقے ہیں، اور یہ کورس پہلا طریقہ اپناتا ہے۔

اجازت کی جانچ اپنی حد پر خود نافذ کریں۔ یہ کوڈ آپ لکھتے ہیں، اس لیے اسے مکمل طور پر قابو کر سکتے ہیں۔ رسائی کی جانچ بنانا اسے صرف ترتیب دینے سے کہیں زیادہ سکھاتا ہے۔ یہی تصور 9 ہے۔

فولڈر ee/ کا کوڈ پڑھیں۔ MIT نہ ہونے کے باوجود یہ ماخذ دیکھنے کے لیے دستیاب ہے۔ اسے لگائے بغیر جانیں کہ حقیقی ماخذ سے رسائی کی فہرست کی وراثت کیسے بنائی گئی ہے۔

ایک تجربے کے لیے آزمائشی نسخہ یا لائسنس استعمال کریں۔ ایک ہفتہ، ایک مظاہرہ، پھر Community Edition کی طرف واپسی۔

اس سب سے ایک اصول نکلتا ہے، اور سیکھتے وقت اس پر کوئی سمجھوتا نہیں۔

صرف فرضی، عوامی، یا جماعت سے منظور شدہ معلومات

جب تک آپ کا نظام تصور 9 میں اجازت کی جانچ کا مجموعہ پاس نہ کرے، کوئی حقیقی مجموعہ نہ جوڑیں۔ نہ اپنے ادارے کی Drive، نہ کسٹمر کا نظام، نہ اپنا ذاتی پیغام خانہ۔ جس تہہ کی اجازت کے لیے کبھی جانچ نہیں ہوئی وہ ادھورا نظام نہیں؛ وہ ایک تیز نظام ہے جو غلط اصولوں کی طرف رخ کیے ہوئے ہے۔

9۔ اپنی حفاظتی حد بنائیں اور اس کردار سے جانچیں جسے کچھ نہ ملے

چونکہ Community Edition فی صارف دستاویزات کو نہیں روکے گی، اس لیے بازیافت کے سامنے اپنی ایک حفاظتی تہہ بنائیں۔ پیداوار میں بھی یہی درست جگہ ہے: اپنی حد ہی پر آپ ثابت کر سکتے ہیں کہ کیا ہوا۔

اسے لکھنے سے پہلے ایک دیانت دار وضاحت ضروری ہے۔ آپ ان فرضی فائلوں پر اجازتیں خود مقرر کرنے والے ہیں، جو ابھی سیکھے گئے اصول کے الٹ ہے۔ یہ تجربہ گاہ کی مجبوری ہے، ڈیزائن کی نہیں۔ مقامی فولڈر میں ورثے میں لینے کے لیے رسائی کے اصول موجود نہیں، اس لیے کسی کو انہیں بیان کرنا ہوگا؛ حقیقی نظام میں یہ کام اصل ماخذ کرتا ہے۔ یہاں آپ کی درجہ بندی اس وراثت کی قائم مقام ہے جسے Community Edition میں دکھایا نہیں جا سکتا، اور governance/production-gates.md میں آپ درج کریں گے کہ یہ کام اب بھی باقی ہے۔

ساخت سادہ ہے، مگر ترتیب سب کچھ ہے۔

1. Resolve identity        who is asking
2. Resolve permissions     what may this identity see, per source
3. Filter eligible docs    remove everything else, BEFORE retrieval
4. Retrieve and rank       search only what remains
5. Assemble the answer     with citations
6. Resolve action rights   separately, at the tool boundary

غیر محفوظ ترتیب وہ ہے جو فطری لگتی ہے۔ سب کچھ بازیافت کریں۔ سب کچھ ماڈل کو دیں۔ پھر ماڈل کو ہدایت دیں کہ جس چیز کو قاری نہیں دیکھ سکتا، اس کا ذکر نہ کرے۔

ماڈل کے سیاق میں چھپا ہوا اقتباس حقیقت میں چھپا ہوا نہیں۔

اب اسے بنائیں:

فائل governance/permission-matrix.csv میں ہر ماخذ کے لیے ایک قطار پہلے سے موجود ہے۔ یہی فائل حفاظتی حد نافذ کرے گی اور بعد میں جائزہ لینے والے کو دی جائے گی۔

نظام Onyx کی بازیافت کے سامنے رسائی کی تہہ شامل کریں۔ Northstar کے تین کردار مقرر کریں: account_executive، sales_manager، اور vp_sales۔ ہر فرضی فائل پر کم از کم وہ کردار لگائیں جو اسے پڑھ سکتا ہے۔ رعایت کے اختیار کا اصول تینوں پڑھ سکتے ہیں۔ قیمت کی منظوری کی گفتگو اور مینیجر کی "book it this quarter" ای میل صرف sales_manager اور اس سے اوپر کے کردار پڑھ سکتے ہیں۔ پھر search(query, role) فنکشن لکھیں۔ یہ نظام Onyx کو بلانے سے پہلے کردار کے مطابق اہل دستاویزات چھانے، بعد میں کبھی نہیں۔ ہر نتیجے کے ساتھ ماخذ اور وہ وجہ واپس کرے جس کی بنا پر کردار اسے دیکھ سکتا تھا۔ وہ کوڈ راستہ دکھائیں جہاں چھانٹی ہوتی ہے اور ثابت کریں کہ کوئی نااہل دستاویز ماڈل تک نہیں پہنچتی۔

پھر وہ جانچ جو ہر بازیافتی معیار سے زیادہ اہم ہے:

اجازت کی جانچ کا مجموعہ بنائیں: ہر کردار اور ہر سوال کے لیے ایک قطار، جس میں اصل ماخذ میں اس کردار کو دستیاب مواد، تہہ کا لوٹایا ہوا نتیجہ، اور کامیابی یا ناکامی درج ہو۔ Northstar کی اہم صورت شامل کریں: account_executive کے طور پر پوچھیں کہ فروخت کے مینیجر نے اس سہ ماہی میں اندراج کے بارے میں کیا کہا، جہاں درست جواب کچھ بھی نہیں ہے۔ اسے چلائیں اور جدول دکھائیں۔

کام تب مکمل ہے جب: تینوں کردار صرف وہی مواد واپس پائیں جو انہیں دیکھنے کی اجازت ہے، اور account_executive کو مینیجر کی ای میل کے بارے میں کچھ نہ ملے۔ جو تہہ کبھی خالی جواب نہیں دیتی، اس کی جانچ نہیں ہوئی۔

غور کریں کہ اس ایک جانچ نے کیا محفوظ کیا۔ مینیجر کی ای میل وہ سنی سنائی بات ہے جس پر Northstar کا پورا معاملہ قائم ہے۔ اسے حاصل کرنے والا اکاؤنٹ ایگزیکٹو اپنے مینیجر کی رائے کو مالیاتی فیصلے کے طور پر پیش کر سکتا ہے۔

اب تجربہ گاہ کی موجودہ حقیقت اور پیداواری ضروریات درج کریں۔

پہلے governance/permission-matrix.csv:

source,student,teacher,production_employee,permission_mechanism,production_ready
Agent Factory SoR,read,read,read,public,yes
Sales fixture,read,read,not applicable,class-authorized,no
Accounting fixture,read,read,not applicable,class-authorized,no
Operational fixture,read,read,not applicable,synthetic MCP,no
Working context fixture,read,read,not applicable,synthetic files,no

اور حفاظتی جائزہ لینے والے کی فائل governance/production-gates.md:

# Production permission gates
- [ ] Source permissions are synchronised or enforced before retrieval.
- [ ] Individual identity reaches live MCP and API tools.
- [ ] Search, chat, Agents, and external MCP clients enforce the same boundary.
- [ ] Revoked source access disappears within the accepted time window.
- [ ] A red-team test proves one user cannot retrieve another user's document.
- [ ] Connector credentials are encrypted and operationally protected.

ان دونوں کو لکھنے سے Community Edition کی حد ایک صاف دکھائی دینے والی نامکمل شرط بنتی ہے، چھپا ہوا مفروضہ نہیں۔ تجربہ گاہ اور ذمہ داری میں یہی فرق ہے۔

یہ صرف رازداری نہیں بلکہ ضابطے کا سوال کیوں ہے

بیشتر شعبوں میں اجازت کی ناکامی رازداری کا مسئلہ ہے۔ منظم پیشے میں بات زیادہ گہری ہے۔ درست رہیں، کیونکہ ڈھیلی دلیل غلط ہوتی ہے۔

فرائض کی علیحدگی دکھائی دینے والی معلومات نہیں بلکہ صلاحیتوں کے مجموعے سے متعلق ہے: روزنامچے کا اندراج بنانا اور منظور کرنا دونوں؛ لین دین شروع کرنا اور اس کی تطبیق کرنا دونوں۔ صرف پڑھنے کی اجازت عموماً ایسا مجموعہ نہیں بناتی۔ اگر آپ کہیں کہ سیاقی تہہ نے "فرائض کی علیحدگی توڑ دی" تو نگران کے سامنے دلیل ہار جائیں گے۔

اصل خطرہ ایک تہہ نیچے ہے۔ رسائی کا ضابطہ وہ بنیاد ہے جس پر باقی ضابطہ جاتی ماحول کھڑا ہے۔ اسی لیے جائزہ کار کمزور IT عمومی ضابطوں کو اوپر موجود اطلاقی ضابطوں پر شک کی وجہ سمجھتے ہیں۔ ادارے کا وقتاً فوقتاً رسائی کا جائزہ یہ تصدیق کرتا ہے کہ نام زد صارف کے پاس خاص اختیارات ہیں۔ تہہ اسے ایسا مواد دیتی ہے جس کی اجازت ان اختیارات نے کبھی نہیں دی۔ کچھ چرایا نہیں گیا، کوئی تحریری اصول رسمی طور پر نہیں ٹوٹا، مگر جائزہ غلط تصویر کی تصدیق کر رہا ہے۔

اس لیے درست اور مضبوط دلیل یہ ہے: جو سیاقی تہہ استحقاقی نمونے سے باہر مؤثر رسائی دیتی ہے، وہ کسی ایک ضابطے کو نہیں توڑتی۔ وہ ان سب کی تصدیق کرنے والے جائزے کو خاموشی سے بے اعتبار کر دیتی ہے۔

---

حصہ 3: باقاعدہ حصہ

آسان الفاظ میں

تلاش آپ کو اشارہ دیتی ہے، جواب نہیں۔

اس حصے میں آپ دوسرا نصف شامل کریں گے۔ آپ کے اپنے Neon ڈیٹابیس میں اصولوں کا ایک چھوٹا باقاعدہ جدول آئے گا، جس میں ہر اصول کے ساتھ نسخہ اور تاریخ ہوگی۔ پھر اسے ٹول کے طور پر پیش کریں گے، تاکہ کارکن اشاریے میں ملنے والے اصول کے اصل ماخذ سے پوچھ سکے: کیا یہی اصول اب بھی نافذ ہے؟ منظوری ملی یا نہیں جیسے تازہ اعداد ہر مرتبہ نئے سرے سے پوچھے جائیں گے۔

10۔ اپنا ریکارڈ MCP پر پیش کریں اور دو مرحلہ جاتی نمونہ بنائیں

اب تک سب کچھ اشاریہ بند دریافت کا نصف تھا۔ اس میں باقاعدہ علم بھی شامل ہے، کیونکہ آپ نے دو شعبہ جاتی ریکارڈ اور خود کتاب اشاریے میں شامل کی۔ مگر یہ سب تلاش کے قابل نقل کی صورت میں آیا، اور نقل صرف اشارہ ہے۔

اب مستند اور براہِ راست نصف آتا ہے، اور اس کا رویہ بالکل مختلف ہے۔

پہلے ریکارڈ کو اختیار دیں

آپ کے Neon منصوبے میں دستاویزات، ٹکڑے، اور عددی نمائندگیاں موجود ہیں۔ اس میں ابھی ایسا اصول نہیں جس کا آپ نگران کے سامنے حوالہ دے سکیں، کیونکہ پچھلے کورس میں اسے بنانے کی ضرورت نہیں تھی۔ موجودہ ساخت کے ساتھ ایک مختصر باقاعدہ خاکہ شامل کریں۔ باقی حصہ اسی ابتدائی بنیاد پر قائم ہے:

بنیادی فولڈر کے scripts/ میں مطلوبہ خاکہ موجود ہے۔ پرامپٹ چلانے سے پہلے اسے پڑھیں، تاکہ آپ صرف دیکھی ہوئی چیز کی منظوری دیں۔

ہمارے موجودہ Neon منصوبے کی dev شاخ پر governed خاکہ اور rule جدول بنائیں۔ خانے یہ ہوں: stable_id، domain (sales یا accounting)، authority_class، jurisdiction، version، effective_from، effective_to، approval_status، superseded_by، owner، اور body۔ فولڈر fixtures/ سے Northstar کے فروخت اور محاسبے کے اصول شامل کریں، جن میں منسوخ شدہ محاسبے کے اصول کا superseded_by ربط موجودہ اصول کی طرف ہو۔ شاخ محفوظ کرنے سے پہلے قطاریں دکھائیں۔

ان میں سے نو خانے تصور 6 کے بارہ ضابطوں کو بیان کرنے کے بجائے حقیقت بناتے ہیں۔

دونوں پیشے ایک ہی جدول میں domain خانے سے الگ کیے گئے ہیں۔ اس سے نمائشی سرور سادہ رہتا ہے۔ تصور 12 کی راستہ بندی بھی واضح کام کرتی دکھائی دیتی ہے، کیونکہ تصدیق سے پہلے کارکن کو شعبہ منتخب کرنا پڑتا ہے۔

پھر اسے پیش کریں

کمپنی Northstar کا محاسبے کا اصول کہتا ہے کہ نفاذ کی آمدنی کسٹمر کی قبولیت پر تسلیم ہوتی ہے۔ اس اصول کا نسخہ اور نفاذ کی تاریخ ہے، اور فرضی فائلوں میں ایک منسوخ شدہ فائل اس کے برعکس بات کہتی ہے۔ اس تصور کی ہر چیز کارکن سے درست اصول کا حوالہ دلوانے کے لیے ہے۔

پچھلے کورس کا ذخیرہ پہلے ہی چل رہا ہے۔ Neon پر ایک چھوٹا Postgres، جس میں pgvector آن ہے، آپ کی دستاویزات موجود ہیں، اور اسے آپ نے dev شاخ پر بنایا تھا۔ یہاں اس میں کچھ نہیں بدلتا۔ صرف یہ بدلتا ہے کہ اس تک کون پہنچتا ہے۔

یہ کھوجنے کے لیے کوئی فولڈر نہیں۔ کسی کنیکٹر کو اس کی طرف نہ بھیجیں۔ یہ ایسا ماخذ ہے جس سے پوچھا جاتا ہے، بالکل پچھلے کورس کے حصہ 6 کی طرح۔

بنیادی فولڈر کا mcp/vertical_sor/ ایک FastMCP ڈھانچہ ہے جس میں تین ٹول کے ابتدائی خانے اور مشکل جگہیں TODO سے نشان زد ہیں۔ پہلے اسے پڑھیں، پھر اپنے ایجنٹ سے مکمل کروائیں۔

نظام Neon پر موجود باقاعدہ ریکارڈ کو vertical-sor نام کے FastMCP سرور میں لپیٹیں۔ ہر ٹول domain دلیل لے، sales یا accounting، تاکہ ایک سرور دونوں پیشوں کو دکھا سکے۔ تین صرف پڑھنے والے ٹول ہوں، اور یاد رہے کہ کسٹمر کی تازہ حالت ان میں شامل نہیں:

• search_rules(domain, query) ممکنہ اصول ان کی مستقل شناخت کے ساتھ واپس کرے
• confirm_rule(domain, stable_id) اختیار کی قسم، قانونی دائرہ، نسخہ، نفاذ کی مدت، منظوری کی حالت، اور نئے نسخے کے ربط سمیت مکمل موجودہ اندراج واپس کرے
• validate_action(domain, action) مجوزہ کارروائی کو اس شعبے کے اصولوں کے خلاف جانچے اور رکاوٹ بننے والے اصول کے ساتھ منظور یا مسترد کا جواب دے ماحول سے Neon کا اجتماعی رابطہ جاتی سلسلہ لیں، صرف پڑھنے والے کردار سے جڑیں، اور بغیر مستقل حالت کے Streamable HTTP پر پیش کریں۔ اس کا مطلب ہے کہ درخواستوں کے درمیان MCP نشست محفوظ نہ رہے، تاکہ ہر درخواست پچھلی درخواست کے بغیر جواب پا سکے۔ کوڈ لکھنے سے پہلے ٹولوں کی فہرست اور ان کی وضاحتیں دکھائیں۔

ایک سرور کیوں، دو کیوں نہیں۔ پیداوار میں ہر پیشے کا ریکارڈ الگ فریق کے زیرِ ملکیت الگ نظام ہو سکتا ہے، اور domain دلیل مستقبل میں اس تقسیم کی جگہ ہے۔ فوری کورس میں ایک سرور راستہ واضح رکھتا ہے۔ دونوں پیشوں کے لیے اصول کی تصدیق کی بالکل ایک جگہ ہے۔ نظام Onyx میں اشاریہ بند نقلیں اس کی عکاس شکلیں ہیں۔ عکاس شکل صرف اصل تلاش کرنے کے لیے رکھی گئی تلاش کے قابل نقل ہے۔ ہر ٹکڑا اپنا stable_id، domain، اور version رکھتا ہے، تاکہ تصدیقی درخواست کے پاس تلاش کرنے کے لیے کچھ ہو۔

منصوبے میں Neon کی دو تفصیلات ضرور جانچیں، کیونکہ دونوں تجربہ گاہ میں چل جاتی ہیں مگر پیداوار میں نقصان دیتی ہیں۔ سرور کو -pooler میزبان والا اجتماعی رابطہ جاتی سلسلہ استعمال کرنا چاہیے، کیونکہ سیاقی تہہ بہت سے مختصر رابطے کھولتی ہے اور براہِ راست راستہ اس کے لیے نہیں بنا۔ اسے جدولوں کے مالک کردار کے بجائے صرف پڑھنے والے کردار سے جڑنا چاہیے، تاکہ کسی ٹول کی دلیل اس ریکارڈ کو کبھی بدل نہ سکے جس کا اسے حوالہ دینا ہے۔

ایجنٹ کی یاد پر چھوڑنے کے بجائے اس سطح کو مقرر رکھیں

بغیر حالت والا HTTP طریقہ FastMCP میں بنانے کے وقت نہیں بلکہ چلانے کے وقت کی دلیل ہے۔ شکل FastMCP("vertical-sor", stateless_http=True) نسخہ FastMCP 2.x میں درست تھی مگر 3.x میں TypeError دیتی ہے، اور ماڈل کے پرانا نسخہ یاد کرنے کا امکان زیادہ ہے۔ موجودہ شکل یہ ہے:

from fastmcp import FastMCP

mcp = FastMCP("vertical-sor")

if __name__ == "__main__":
    mcp.run(transport="http", host="127.0.0.1", port=8101, stateless_http=True)

سرور خالی میزبان پتے کے بجائے /mcp پر جواب دیتا ہے؛ یہی تفصیل بعد میں صارف کے نہ جڑنے پر ایک گھنٹہ ضائع کر سکتی ہے۔ منصوبے کی منظوری سے پہلے اپنے ایجنٹ سے دونوں باتیں FastMCP کی موجودہ دستاویزات میں جانچوائیں۔

شاخ بنانے کی عادت برقرار رکھیں۔ اس کورس کے دوران ریکارڈ کا خاکہ بدلیں تو پہلے کی طرح Neon کی شاخ پر بدلیں اور پیش منظر دیکھیں۔ نیچے پرانی نقل کے مظاہرے کے لیے بھی شاخ سب سے سستا طریقہ ہے۔ ریکارڈ کی نقل شاخ بنائیں۔ اسے جان بوجھ کر پرانا ہونے دیں۔ دریافت کو اس کی طرف بھیجیں۔ پھر شاخ ختم کر دیں۔

ٹولوں کی فہرست دیکھیں۔ سادہ ڈیزائن میں ایک درخواست کی جگہ search_rules اور confirm_rule دو درخواستیں ہیں، اور یہی تقسیم اصل نکتہ ہے۔

دریافت پوچھتی ہے: متعلقہ معلومات کہاں ہو سکتی ہیں؟ یہ زیادہ سے زیادہ نتائج، مماثلت، اور رفتار کے لیے کام کرتی ہے۔ اس کا نتیجہ ایک اشارہ ہے۔

تصدیق پوچھتی ہے: اس فیصلے پر باضابطہ طور پر کون سا ماخذ لاگو ہوتا ہے؟ یہ شعبہ، اختیار کی قسم، قانونی دائرہ، نسخہ، نفاذ کی تاریخ، اور منظوری کی حالت جانچتی ہے۔ اس کا نتیجہ جواب ہے۔

اس لیے ترتیب مقرر ہے اور کبھی الٹ نہیں چلتی:

search discovers  →  you route  →  the record confirms  →  the Worker cites

باقاعدہ صفحات کو دریافت کے لیے اشاریے میں شامل کیا جا سکتا ہے، اور یہ مفید ہے۔ جو طالب علم اصول تلاش ہی نہ کر سکے وہ اس طالب علم سے بدتر حالت میں ہے جسے نقل مل جاتی ہے۔ مگر نقل پر بھروسا کبھی نہیں ہونا چاہیے۔ بنیادی اصول دریافت تصدیق نہیں ہے۔

اب دونوں درخواستیں جوڑیں۔ governing_rule(question) لکھیں جو search_rules بلائے، پہلے ممکنہ نتیجے کی مستقل شناخت لے، اس پر confirm_rule بلائے، اور تصدیق شدہ اندراج واپس کرے۔ اگر تصدیق شدہ اندراج منسوخ ہو چکا ہو تو اس کے ربط کی پیروی کرکے نئے نسخے کی تصدیق کرے۔ پھر اس ناکامی کا مظاہرہ کریں جسے یہ روکتا ہے، اسی اصول سے جس پر پورا معاملہ قائم ہے: اپنے ریکارڈ کی Neon شاخ بنائیں، بنیادی شاخ پر نفاذ سے متعلق آمدنی کا اصول قبولیت سے بدل کر بل بننے پر کر دیں تاکہ دوسری شاخ پرانی ہو جائے، search_rules کو پرانی شاخ کی طرف رکھیں جبکہ confirm_rule موجودہ شاخ پر رہے، اور پوچھیں کہ Northstar کی آمدنی کب تسلیم کی جا سکتی ہے۔ دونوں جواب ساتھ دکھائیں۔ بعد میں شاخ حذف کر دیں۔

کام تب مکمل ہے جب: آپ پرانی شاخ کو پورے اعتماد سے بل بننے پر جواب دیتے اور تصدیقی درخواست کو اسے قبولیت پر درست کرتے دیکھیں۔

ان میں سے ایک جواب Northstar کو اسی سہ ماہی میں آمدنی درج کرنے دیتا ہے اور دوسرا نہیں۔ یہی وہ مکمل فرق ہے جسے سکھانے کے لیے یہ کورس بنایا گیا ہے۔ یہ مظاہرہ پورے کورس کی سب سے قیمتی چیز ہے۔

نظام Glean میں

یہاں نظام آپ کے لیے یہ کام نہیں کرتا، اور یہ اس صفحے کا سب سے اہم نوٹ ہے۔

نظام Glean بہترین اشاریہ سازی اور بازیافت کرتا ہے، اور تازگی کا ایک اشارہ بھی رکھتا ہے: مالک صفحے کی تصدیق کر سکتا ہے، پھر نتیجہ دکھاتا ہے کہ کس نے کب تصدیق کی، اور ختم شدہ صفحہ فرسودہ نشان زد ہو سکتا ہے۔ یہ دستاویز سے لگا ہوا انسانی یاددہانی کا نشان ہے۔ یہ آپ کے پیشے کی اختیار کی اقسام، قانونی دائرے، نفاذ کی مدت، یا نئے نسخے کے روابط نہیں، کیونکہ یہ آپ کے باقاعدہ ریکارڈ کی خصوصیات ہیں، کسی تلاش کے نظام کی نہیں۔ اس لیے نظام Glean منسوخ شدہ اصول کو مکمل حوالوں، درست اجازتوں، اور سبز تصدیقی نشان کے ساتھ واپس کرکے بھی غلط ہو سکتا ہے۔

تصدیقی درخواست دونوں نظاموں پر آپ ہی بناتے ہیں۔ نظام Glean کے ایجنٹ دور دراز MCP سرور پر آپ کے confirm_rule ٹول تک اسی طرح پہنچ سکتے ہیں جیسے نظام Onyx کا ایجنٹ، اگرچہ تحریر کے وقت یہ راستہ آزمائشی حالت میں ہے اور ایک مرحلہ جاتی انتخاب کے بجائے ایجنٹ کے منصوبہ اور عمل والے مرحلے میں ہے۔ ڈیزائن میں کچھ نہیں بدلتا۔

11۔ تازہ حالت ہر مرتبہ پوچھی جاتی ہے

بقایا رقم، منظوری کی حالت، کھلے معاملات، موجودہ نسخے۔ ان میں سے کچھ بھی تحریر کردہ نہیں، کچھ بھی مستقل نہیں، اور سب کچھ قطعی ہے۔ اسے اشاریے میں شامل کرنا اس چیز کی کھردری، پرانی ہوتی نقل بنانا ہے جس کی پوری قدر تازہ ہونے میں ہے۔

اصول ایک جملے میں سما جاتا ہے، اور اسے ہر کام کے ڈیزائن ریکارڈ میں ہونا چاہیے:

اگر پرانی قدر نتیجہ، اجازت، ادائیگی، اندراج، یا کسٹمر کی کارروائی بدل سکتی ہے تو اسے براہِ راست تازہ حاصل کریں۔

یوں بازیافت کے تین طریقے بنتے ہیں، جو پوری تہہ کے بنیادی اصول کا مختصر خلاصہ ہیں:

معلومات	اس تک پہنچنے کا طریقہ
جاری کام کا سیاق	اجازت سے باخبر اشاریہ سازی
باقاعدہ علم	دریافت کا اشاریہ، بھروسا کرنے سے پہلے تصدیق
موجودہ ریکارڈ اور کارروائیاں	MCP یا API کے ذریعے براہِ راست نوعیت والی درخواست

جاری کام کا سیاق اشاریہ بند کریں۔ باقاعدہ علم دریافت کریں۔ موجودہ حقیقت براہِ راست پوچھیں۔

یاد رکھیں کہ ایک ماخذ کو اکثر دو طریقے درکار ہوتے ہیں۔ معاہدے کی دستاویز اشاریے میں شامل کی جاتی ہے تاکہ اس کی دفعات تلاش ہو سکیں۔ پھر معاہدے کے نظام سے براہِ راست پوچھا جاتا ہے تاکہ تصدیق ہو کہ ملنے والا نسخہ اب بھی فعال ہے۔

شکل اور طوالت کچھ طے نہیں کرتیں۔ تازگی کا خطرہ سب کچھ طے کرتا ہے۔

نظام Glean میں

نظام Glean کچھ منسلک نظاموں سے سوال کے وقت تازہ معلومات لا سکتا ہے، صرف اشاریہ بند نقل پر انحصار نہیں کرتا، اس لیے اس کام کا کچھ حصہ خودکار ہو جاتا ہے۔

مگر کچھ حصہ، سب نہیں۔ آپ کے پیشے میں کون سے خانے تازگی کے لحاظ سے اہم ہیں، یہ فیصلہ کوئی نظام آپ کے لیے نہیں کر سکتا، اور یہی اصول آپ نے اوپر ڈیزائن ریکارڈ میں لکھا۔ یہ فیصلہ ایک نظام سے دوسرے تک آپ کے ساتھ جاتا ہے۔

کمپنی Northstar کے دو عملی ریکارڈ vertical-sor سے الگ سرور customer-state کے ذریعے پیش کریں: get_opportunity منظوری کی حالت اور get_contract_state قبولیت کی حالت واپس کرے۔ انہیں الگ رکھنا چار ماخذی اقسام کو عملی شکل دیتا ہے، کیونکہ شعبہ جاتی ریکارڈ اصولوں کا مالک ہے جبکہ عملی ریکارڈ حالت کا مالک ہے۔ پھر کیا ہم آمدنی تسلیم کر سکتے ہیں دو مرتبہ پوچھیں: ایک بار اشاریہ بند نمونے سے اور ایک بار براہِ راست درخواست سے، اور درمیان میں قبولیت کو موصول نہ ہونے سے موصول ہونے میں بدل دیں۔ دونوں جواب ان کے اوقات کے ساتھ دکھائیں۔

کام تب مکمل ہے جب: اشاریہ بند جواب اور براہِ راست جواب مختلف ہوں، اور آپ درست طور پر بتا سکیں کہ نگران کے سامنے کون سا جواب رکھیں گے۔

---

حصہ 4: راستہ بندی اور حوالہ

آسان الفاظ میں

کسٹمر کا ایک سوال اکثر کئی پیشہ ورانہ سوالوں کو اپنے اندر چھپائے ہوتا ہے۔

یہ حصہ کارکن کو ان سوالوں کو الگ کرنا، ہر سوال اس کے حاکم ریکارڈ تک بھیجنا، اور واپس آنے والی ہر چیز پر درست نام لگانا سکھاتا ہے۔ یہ سب سے مشکل عادت بھی سکھاتا ہے: جب دو ماخذ اختلاف کریں تو دونوں دکھائیں۔ انہیں ایک تسلی بخش جملے میں ملا نہ دیں۔

12۔ اختیار کی راستہ بندی: اس سوال پر کس ریکارڈ کا حکم ہے

پیشہ ورانہ کام کئی طرح کے سوال پوچھتا ہے: کیا فیصلہ ہونا چاہیے، کس کارروائی کی اجازت ہے، کون سی جانچ لاگو ہوتی ہے، اور کون سا ثبوت غائب ہے۔ مگر سیاق جمع کرنے کے مقصد سے زیادہ تر ثبوتی درخواستیں تین شکلوں میں آتی ہیں، اور ہر ایک کا راستہ الگ ہے۔

سوال	ماخذ	راستہ	واپس آنے والی چیز
اصول کیا ہے؟	ریکارڈ کا نظام	دریافت، پھر تصدیق	اختیار کی قسم، قانونی دائرے، اور نسخے کے حوالے سمیت باقاعدہ حقیقت
عدد کیا ہے؟	اس عدد کا مالک نظام	نوعیت والی درخواست	وقت کے نشان سمیت ایک درست موجودہ قدر
اس معاملے کے بارے میں کیا کہا گیا؟	جاری کام کا سیاق	اجازت سے باخبر بازیافت	ثبوت، کبھی حاکم اصول نہیں

جو کارکن یہ فرق نہیں جانتا کہ وہ کون سا سوال پوچھ رہا ہے، وہ تینوں کا جواب ایک ہی طرح دے گا، اور تیسرا راستہ خاموشی سے پہلے دونوں کو نگل جائے گا۔

ایک اور مرحلہ بھی ہے، جو کسٹمر کے ایک سے زیادہ باقاعدہ ریکارڈ رکھنے پر ان سب سے پہلے آتا ہے۔ ایک متوسط ادارے کے پاس محاسبے، فروخت، اور انسانی وسائل کے الگ ریکارڈ ہو سکتے ہیں، جنہیں تین مختلف لوگوں نے بنایا ہو اور ان میں سے کوئی بھی آپ کا نہ ہو۔ اس لیے راستہ بندی پہلے طے کرتی ہے کہ یہ سوال کس پیشے کی ملکیت ہے، پھر اس پیشے کے اندر درست ماخذ چنتی ہے۔ آمدنی تسلیم کرنے کا سوال محاسبے کا سوال ہے، خواہ اس کے ہر لفظ کی ابتدا فروخت کی گفتگو سے ہوئی ہو۔

پرامپٹ سے پہلے نقشہ لکھیں

ماڈل کو پہلے نمبر پر آنے والے کسی بھی ٹکڑے سے خود یہ اندازہ نہیں لگانا چاہیے کہ حکم کس ماخذ کا ہے۔ اس لیے راستہ بندی کا جدول ایک نسخہ بند دستاویز ہے جسے آپ پہلے لکھتے، جانچتے، اور محفوظ رکھتے ہیں۔ بنیادی فولڈر کی governance/authority-map.yaml خالی راستوں کے ساتھ فراہم ہوتی ہے۔ اسے مکمل کریں:

version: 1
updated_at: 2026-07-31

routes:
  shared_method:
    questions: [architecture, Agent Factory doctrine, implementation method]
    governing_source: AF-SOR-PUBLIC

  sales.discount_authority:
    questions: [requested discount, approval threshold, proposal permission]
    governing_source: VERTICAL-SALES-SOR
    confirm_with: vertical-sor.confirm_rule(domain=sales)
    current_state_tool: customer-state.get_opportunity

  accounting.implementation_revenue:
    questions: [revenue recognition, implementation acceptance, quarter-end treatment]
    governing_source: VERTICAL-ACCOUNTING-SOR
    confirm_with: vertical-sor.confirm_rule(domain=accounting)
    current_state_tool: customer-state.get_contract_state

rules:
  - working_context may support what was said or requested, but never governs a professional conclusion
  - indexed governed knowledge is discovered, then confirmed at the source before it is relied on
  - current state must be confirmed live before any action
  - conflicts are surfaced, never silently merged
  - missing authority or evidence becomes an explicit gap

اس میں ہر نام پہلے بنائی گئی چیز کا ہے: تصور 5 کے کنیکٹر اور تصور 10 اور 11 کے ٹول۔ یہ جان بوجھ کر ہے۔ جس راستہ بندی کے نقشے کے ماخذ کسی قابلِ استعمال نظام تک نہ پہنچیں، وہ صرف خاکہ ہے، راستہ بان نہیں۔

فائل سادہ ہے کیونکہ اس کا کام سادہ ہے۔ یہ کمپنی کے ایک مبہم سوال کو نام زد پیشہ ورانہ فیصلوں میں بدلتی ہے، اور ہر فیصلے کے ساتھ نام زد حاکم ماخذ رکھتی ہے۔ پیداوار میں یہ نقشہ کسی باقاعدہ رجسٹری یا شعبہ جاتی ریکارڈ کے اندر رہ سکتا ہے۔ کورس YAML استعمال کرتا ہے تاکہ فیصلہ پہلے گھنٹے ہی سے دیکھا اور نسخہ بند کیا جا سکے۔

route(question) فنکشن بنائیں جو governance/authority-map.yaml پڑھے، سوال کو پیشہ ورانہ فیصلوں میں تقسیم کرے، اور ہر فیصلے کے لیے حاکم ماخذ اور موجودہ حالت کا ماخذ بتائے۔ راستہ بندی کا فیصلہ وجہ سمیت ساختہ معلومات کی صورت میں واپس کرے؛ فوراً ٹول نہ بلائے۔ پھر اسے Northstar کے سوال پر چلائیں اور راستہ بندی کا جدول دکھائیں، تاکہ میں صرف جواب نہیں بلکہ اس کی منطق بھی جانچ سکوں۔

یہ دیکھیں: فوری کارروائی کے بجائے فیصلہ واپس کرنا ہی اسے قابلِ جائزہ بناتا ہے۔ جو راستہ بان صرف جواب دیتا ہے، اس کا محاسبہ نہیں کیا جا سکتا۔

کام تب مکمل ہے جب: Northstar کا سوال کم از کم دو راستہ بند فیصلے بنائے، ایک فروخت اور ایک محاسبے کا، اور ہر فیصلہ کسی بازیافت سے پہلے اپنے حاکم ماخذ کا نام دے۔

13۔ ماخذی نسبت اور حوالہ جاتی لفافہ

تہہ کی لوٹائی ہوئی ہر اہم چیز کے ساتھ ایک لفافہ ہوتا ہے: ایسے نام جو متن کے ساتھ سفر کرتے ہیں اور بتاتے ہیں کہ وہ کہاں سے آیا اور اس پر بھروسا کیا جا سکتا ہے یا نہیں۔ اس کے بغیر مواد کا مجموعہ متن کا ڈھیر ہے۔ اس کے ساتھ وہ قابلِ جائزہ ثبوت بن جاتا ہے۔

خانہ	اہمیت
ماخذی نظام	بتاتا ہے کہ معلومات کی ملکیت کس کے پاس ہے
مستقل شناخت	جائزہ لینے والے کو وہی چیز دوبارہ حاصل کرنے دیتی ہے
اختیار کی قسم	قانون، معیار، معاہدہ، پالیسی، لین دین، رہنمائی، پیغام، یا مثال
دائرہ	بتاتا ہے کہ یہ کس سوال، کسٹمر، قانونی دائرے، اور معاملے پر لاگو ہے
نسخہ اور نفاذ کی مدت	سبک دوش اصولوں کو خاموشی سے واپس آنے سے روکتی ہے
بازیافت یا ہم وقت سازی کا وقت	بتاتا ہے کہ چیز کتنی تازہ تھی
اجازت کی بنیاد	بتاتی ہے کہ قاری کو یہ چیز کیوں دی گئی

روانی سے لکھے جواب کو دیانت دار رکھنے والا اصول یہ ہے:

کارکن ہر اجازت یافتہ اور کام سے متعلق معاون سیاق پڑھ سکتا ہے۔ مگر وہ معاون سیاق کو کبھی جواب کا حاکم اصول نہیں بنا سکتا۔

ای میل کو اس بات کے ثبوت کے طور پر حوالہ دیا جا سکتا ہے کہ کسٹمر نے کیا مانگا۔ پچھلے کام کے کاغذ کو اس بات کے ثبوت کے طور پر پیش کیا جا سکتا ہے کہ ادارے نے پچھلے سال کیا طریقہ اپنایا۔ ان میں سے کوئی بھی تقاضا نہیں۔

مواد کا مجموعہ ایک نتیجہ جاتی معاہدہ ہے

نظام Onyx کا ایجنٹ ایک ترتیب دیا ہوا معاون ہے: رویے کی ہدایات، وہ علم جس میں اسے تلاش کی اجازت ہے، اور کارروائیاں یعنی وہ ٹول جنہیں وہ بلا سکتا ہے۔ راستہ بان Northstar Context Router نام کا ایک ایجنٹ بنائیں۔

اب وہ حصہ آتا ہے جس میں غلطی آسان ہے اور جو خاموشی سے تصور 9 کا حاصل ختم کر دے گا۔

دستاویزی مجموعہ ایجنٹ کے ساتھ منسلک نہ کریں

ظاہری طور پر آسان کام یہ ہے کہ Northstar Cross-Domain براہِ راست ایجنٹ سے جوڑ دیا جائے، اور یہ فوراً چل بھی پڑتا ہے۔ مگر اس سے بازیافت کے دو راستے بنتے ہیں، جن میں سے ایک آپ کی حفاظتی حد کے گرد سے گزر جاتا ہے:

SAFE     user  ->  permission gate  ->  filtered Onyx search
BYPASS   user  ->  Onyx Agent  ->  the whole attached Document Set

ایجنٹ سے منسلک علم اس کی قابلِ تلاش حد بن جاتا ہے۔ مختلف شعبوں کا مجموعہ منسلک کریں تو ایجنٹ ہر شخص کے لیے اس کی ہر چیز پڑھ سکتا ہے، چاہے آپ کی حفاظتی حد کچھ بھی کہے۔

اس لیے راستہ بان کے ساتھ کردار سے حساس کوئی علم بالکل منسلک نہیں ہوگا۔ اسے صرف کارروائیاں ملیں گی۔

اسے صرف یہ پانچ کارروائیاں دیں، اور کچھ نہیں:

کارروائی	کام
search_permitted_context(query)	آپ کا دروازہ۔ کارروائی کے ساتھ موجود شناخت سے درخواست کنندہ کا کردار معلوم کرتا، اجازت یافتہ دستاویزی مجموعے یا نشان لگاتا، پھر نظام Onyx میں تلاش کرتا ہے
confirm_rule(domain, stable_id)	سرور vertical-sor سے مستند تصدیق
get_opportunity(id)	کسٹمر کی حالت کے سرور سے وقت کے نشان سمیت موقع کی تازہ حالت
get_contract_state(id)	اسی سرور سے معاہدے کی تازہ حالت
validate_action(domain, action)	مجوزہ کارروائی کو حاکم اصولوں کے خلاف جانچتا ہے

نظام Onyx کی تلاش API کو لپیٹنے والی search_permitted_context کارروائی بنائیں۔ یہ کردار کارروائی کے لیے ترتیب دی گئی شناخت سے پڑھے، ٹول کی دلیل سے کبھی نہیں۔ کردار سے اجازت یافتہ دستاویزی مجموعے اور نشان اخذ کرے، انہیں تلاش کی چھانٹی کے طور پر لگائے، اور تب سوال بھیجے۔ ہر نتیجے کے ساتھ وہ وجہ واپس کرے جس کی بنا پر اسے اجازت ملی۔ پھر Northstar Context Router کو کسی دستاویزی مجموعے کے بغیر، صرف اس کارروائی اور چار MCP ٹولوں کے ساتھ بنائیں۔

کرداروں کا موازنہ کہاں چلتا ہے، یہ اہم ہے۔ کارروائی کے پاس ایک ترتیب شدہ شناخت اور اس لیے ایک کردار ہوتا ہے، چنانچہ ایک ہی راستہ بان ایک سوال دو مختلف لوگوں کے طور پر نہیں پوچھ سکتا۔ یہ جوڑنے کے طریقے کی خاصیت ہے، ڈیزائن کی کمی نہیں، اور ہر میزبان نظام میں یہی حد ہوتی ہے۔ اس لیے حفاظتی حد کو اس دروازے پر ثابت کریں جہاں شناخت حقیقت میں معلوم ہوتی ہے:

دروازے سے ایسی چیز پوچھیں جسے صرف vp_sales دیکھ سکتا ہے، ایک بار vp_sales شناخت کے ساتھ اور ایک بار account_executive شناخت کے ساتھ، اور دونوں نتائج ساتھ دکھائیں۔ پھر راستہ بان کو کارروائی کے ذریعے یہی سوال جواب دیتے دکھائیں، اور بتائیں کہ وہ کس کردار کے طور پر بول رہا ہے اور آپ یہ کیسے جانتے ہیں۔

اس کے نیچے ایک ہی جملے کا اصول ہے، وہی پچھلا اصول ایک تہہ اوپر:

ہر اشاریہ بند بازیافت دروازے سے گزرے گی۔ اگر کوئی حصہ اس کے بغیر تلاش کر سکتا ہے تو حفاظتی حد صرف سجاوٹ ہے۔

نظام Glean میں

پہلے سے طے شدہ طور پر نظام Glean کا ایجنٹ اسے بلانے والے صارف کی شناخت کے تحت چلتا ہے، اس لیے صرف وہی دیکھ اور کر سکتا ہے جس کی اجازت صارف کو پہلے سے ہے۔ یوں وہ گھوم کر آنے والا راستہ اسی شکل میں پیدا نہیں ہوتا جسے آپ نے ہاتھ سے بند کیا۔ نظام Glean ایجنٹ کی شناخت بھی دیتا ہے، جس میں ایجنٹ صارف سے شناخت ادھار لینے کے بجائے منتظم کی دی ہوئی محدود خدماتی شناخت پر چلتا ہے۔ اس کا اثر درست سمت میں سمجھیں: یہ بغیر نگرانی چلنے والے ایجنٹ کی رسائی کو منتظم کے مقررہ دائرے تک محدود کرتا ہے، اسے بڑھاتا نہیں۔

دو چیزیں پھر بھی آپ کی ذمہ داری رہتی ہیں۔ سات حصوں کا نتیجہ جاتی معاہدہ، کیونکہ مستقل اور قابلِ جائزہ شکل ڈیزائن کا فیصلہ ہے جسے کوئی نظام خود نافذ نہیں کرتا۔ اور اختیار کی راستہ بندی، کیونکہ آمدنی کا سوال فروخت کے بجائے محاسبے سے تعلق رکھتا ہے، یہ پیشہ ورانہ علم ہے، نظام کی خصوصیت نہیں۔

اب راستہ بان کو prompts/context-router.md میں ہدایات کی فائل دیں جو اس مقررہ شکل پر ختم ہو:

Return exactly these sections:

## Decisions involved
## Governing authority
## Current facts
## Supporting context
## Conflicts and gaps
## Permitted next steps
## Citations

یہ سات حصے ہی سیاقی مواد کا مجموعہ ہیں، اور ان کی مقررہ شکل بظاہر نظر آنے سے کہیں زیادہ کام کرتی ہے۔

نظام Onyx میں Context Packet نام کی کوئی ڈیٹابیس چیز نہیں۔ آپ اسے ایک کام کے لیے مستقل نتیجہ جاتی معاہدے کی صورت میں بناتے ہیں۔ شکل کبھی نہیں بدلتی، اس لیے تین فائدے ملتے ہیں۔ جائزہ لینے والا ہر جواب چند سیکنڈ میں دیکھ لیتا ہے۔ جانچ کا نظام ہر حصے کو الگ پرکھ سکتا ہے۔ اور غائب حصہ خاموشی سے چھپنے کے بجائے صاف دکھائی دیتا ہے۔ خالی اختلافات اور خلا کا مطلب ہے کہ راستہ بان نے جانچا اور کچھ نہیں پایا۔ سرخی ہی نہ ہونا بتاتا ہے کہ اس نے دیکھا ہی نہیں۔

یہ مجموعہ جان بوجھ کر عارضی ہے۔ موجودہ حقائق بدل سکتے ہیں۔ قاری کی اجازتیں بدل سکتی ہیں۔ لاگو نسخہ منسوخ ہو سکتا ہے۔ اسی لیے اسے محفوظ کرکے دوبارہ استعمال نہیں کیا جاتا بلکہ ہر بار نئے سرے سے بنایا جاتا ہے۔

اس معاہدے کے پیچھے مواد جمع کرنے والا حصہ بنائیں۔ راستہ بند سوال ملنے پر تصدیق شدہ اصول، براہِ راست اقدار، اور اجازت یافتہ معاون سیاق جمع کریں۔ ہر حصے کو مکمل لفافے والی چیزوں سے بھریں، اور باقاعدہ حقیقت کو ثبوت سے صاف الگ رکھیں۔ پھر ایک ہی جواب دو صورتوں میں دکھائیں: پہلے ساختہ معلومات کے طور پر، پھر اس نثر میں جو انسان پڑھے گا۔

کام تب مکمل ہے جب: ہر سرخی موجود ہو، چاہے اس کا مواد خالی ہو، اور آپ کسی ایک دعوے کو ماخذ، نسخے، اور اجازت کی بنیاد تک واپس جوڑ سکیں۔

اختصار وہ جگہ ہے جہاں ماخذی نسبت مر جاتی ہے

مواد جمع کرنے والا حصہ محدود گنجائش میں کام کرتا ہے، کیونکہ سیاق کی کھڑکی محدود ہے اور پرانے پیغام پر خرچ ہونے والا ہر ٹوکن حاکم اصول سے چھن جاتا ہے۔ اس لیے انتخاب اور اختصار جائز کام ہیں۔ مگر ماخذی نسبت کا اصول بھی زیادہ تر یہیں ٹوٹتا ہے۔ جو اختصار نسخے کا نشان ہٹا دے، دو ماخذوں کو ایک جملے میں ملا دے، یا اختیار کی قسم ختم کر دے، اس نے ٹوکن نہیں بچائے؛ اس نے ثبوت کو محض متن بنا دیا۔

نثر مختصر کریں۔ ماخذی نسبت کبھی مختصر نہ کریں۔

14۔ اختلاف ایک نتیجہ ہے، بازیافت کی ناکامی نہیں

یہی بات سیاق کے نظام کو اچھے تلاش کے ٹول سے الگ کرتی ہے۔ تلاش کے ٹول کے پاس اختلاف کے بارے میں کوئی رائے نہیں ہوتی۔ پیشہ ورانہ نظام کے پاس ہونی چاہیے۔

تصور 5 میں جوڑی گئی فرضی فائلوں میں بے قاعدگیاں پہلے سے رکھی گئی تھیں۔ اب انہیں تلاش کریں۔

اختلاف کے بالکل تین نتائج ہو سکتے ہیں:

• دائرے سے حل۔ ماخذ مختلف سوالوں کا جواب دیتے ہیں اور ہر ایک اپنے دائرے میں درست ہے۔ فروخت کہتی ہے کہ سودا جون میں مکمل ہوا، محاسبہ کہتا ہے کہ قبولیت تک آمدنی تسلیم نہیں ہو سکتی، اور دونوں میں سے کوئی غلط نہیں۔
• اختیار سے حل۔ ایک قابلِ اطلاق ماخذ حاکم ہے، اور درجہ بندی بتاتی ہے کہ کون سا۔
• غیر حل شدہ۔ کارکن متصادم ثبوت منظم کرکے معاملہ اوپر بھیج دیتا ہے۔

چوتھا کام کبھی نہیں ہونا چاہیے، حالانکہ عام خلاصہ ساز پہلے سے یہی کرتا ہے۔ وہ ماخذوں کو ایک ایسے ہموار جملے میں ملا دیتا ہے جو کسی ماخذ نے حقیقت میں نہیں کہا۔

مواد جمع کرنے والے حصے میں اختلاف کی شناخت بنائیں۔ جب دو بازیافت شدہ چیزیں کسی اہم نکتے پر مختلف ہوں تو انہیں ملا کر خلاصہ نہ بنائیں۔ ان کے لفافے برقرار رکھتے ہوئے انہیں الگ رکھیں، طے کریں کہ اختلاف دائرے سے حل ہوتا ہے یا اختیار سے، اور اگر دونوں سے نہیں تو معاملہ اوپر بھیجنے والا نتیجہ دیں جس میں متصادم ماخذ، ہر ایک کا بیان، آزمائی گئی اختیاری جانچ، اور باقی کھلا سوال درج ہو۔ پھر اسے fixtures/PLANTED.md کی بے قاعدگیوں پر چلائیں اور دکھائیں کہ اس نے ہر ایک کو پکڑا یا نہیں۔

کام تب مکمل ہے جب: نظام منسوخ شدہ یادداشت اور متضاد گفتگو کے پیغام کو خود تلاش کرے، اور اس کا اوپر بھیجا گیا نتیجہ ایسا ہو جسے آپ بغیر ترمیم شریکِ کار کو بھیج سکیں۔

یہ اختلاف ختم نہیں کرتا۔ اسے قابلِ جائزہ بناتا ہے۔

نظام Glean میں

نہ نظام Onyx اور نہ نظام Glean آپ کا پیشہ ورانہ اختیار کا نقشہ یا اختلاف کے اصول خود بخود لگاتا ہے۔ بازیافت صرف ملتے ہوئے اقتباسات واپس کرتی ہے۔ یہ طے کرنا کہ دو اقتباسات متصادم ہیں یا ان میں سے کس کا حکم چلتا ہے، پیشہ ورانہ فیصلہ ہے جو آپ کے اختیار کے نقشے اور راستہ بان کی ہدایات میں رہتا ہے۔

بلکہ زیادہ طاقتور بازیافتی نظام اسے محسوس کرنا مزید مشکل بنا سکتا ہے، کیونکہ وہ اسی اختلاف پر زیادہ ہموار اور پراعتماد جواب دیتا ہے۔

تین نتائج اور دائرے سے حل کو پہلے رکھنے کی وجہ اختلاف ایک نتیجہ ہے، بازیافت کی ناکامی نہیں میں بیان ہوئی ہے۔

15۔ عمل اور اندراج: دائرہ مکمل کرنا

تلاش کرنا اور کام کرنا ایک چیز نہیں، اور ان کے درمیان پانچ الگ ذمہ داریاں ہیں۔

the layer finds  →  the Worker reasons  →  the governing record validates
                 →  the tool acts  →  the owning system records

تیسرا مرحلہ وہ ہے جسے اکثر چھوڑ دیا جاتا ہے۔

فروخت کا ریکارڈ رعایت کی منظوری کو CRM میں لکھے جانے سے پہلے جانچتا ہے۔ محاسبے کا ریکارڈ روزنامچے کے اندراج کو ERP میں مسودہ رکھنے سے پہلے جانچتا ہے۔

اس طرح حاکم ریکارڈ صرف وہ جگہ نہیں جہاں اصول پڑھا گیا۔ یہی وہ جگہ بھی ہے جہاں مجوزہ کارروائی کو اس اصول کے خلاف جانچا جاتا ہے۔ یہ جانچ اصول کو محض مشورہ رہنے کے بجائے حقیقی بناتی ہے۔

اس سے دو اصول نکلتے ہیں، اور دونوں قطعی ہیں:

سیاقی تہہ کبھی دوسرا لین دین کا نظام نہیں بنے گی، اور نہ کبھی باقاعدہ ریکارڈ کے گرد سے لکھنے کا راستہ بنے گی۔

پڑھنا، تجویز دینا، تیاری کرنا، اور عمل کرنا الگ اختیارات ہیں۔ کوئی کارکن بازیافت میں بہترین ہو سکتا ہے مگر اس کے پاس عمل کا کوئی اختیار نہ ہو۔ رسائی اجازت نہیں۔

راستہ بان کے validate_action(domain, action) ٹول کو تجویز کے راستے میں جوڑیں۔ یہ مجوزہ کارروائی لیتا، اسے باقاعدہ ریکارڈ میں اس شعبے کے اصولوں کے خلاف جانچتا، اور یا تو منظور شدہ مسودہ واپس کرتا ہے یا روکنے والے اصول کے نام سمیت انکار۔ اسے کبھی خود عمل نہیں کرنا چاہیے۔ پھر ایسی صورت دکھائیں جہاں بازیافت درست تھی، دلیل درست تھی، مگر کارروائی پھر بھی مسترد ہوئی۔

نظام Glean میں

نظام Glean انسانی منظوری کے مرحلے والی کارروائیاں دیتا ہے، اس لیے کوئی مرحلہ عمل سے پہلے منظوری مانگ سکتا ہے، اور کارروائیاں صارف کی اپنی اجازتوں کا احترام کرتی ہیں۔

یہ منظوری کے نصف کو پورا کرتا ہے۔ یہ جانچ کے نصف کو پورا نہیں کرتا: کسی سے منظوری مانگنے سے پہلے مجوزہ کارروائی کو اپنے پیشے کے اصولوں کے خلاف جانچنا۔ دونوں نظاموں میں validate_action آپ ہی کا ہے، کیونکہ جس اصول کے خلاف وہ جانچتا ہے وہ صرف آپ کے باقاعدہ ریکارڈ میں موجود ہے۔

کام تب مکمل ہے جب: فروخت کے ریکارڈ کا منظوری کا اصول رعایت کی سفارش مسترد کرے، اور انکار ماڈل کی بے یقینی کہنے کے بجائے اصول کا نام دے۔

---

حصہ 5: Northstar کا معاملہ، ابتدا سے انتہا تک

آسان الفاظ میں

اب پوری چیز ترتیب سے بنائیں، پھر اسے جان بوجھ کر توڑیں۔

اسے توڑنا کوئی اضافی مشق نہیں۔ جو نظام بلند آواز سے ناکام ہو وہ محفوظ ہے۔ جو نظام خاموشی سے، روانی اور اعتماد کے ساتھ غلط جواب دے، وہ خطرناک ہے۔ یہ حصہ خاموش ناکامی کی شکل دکھاتا ہے تاکہ آپ بعد میں اسے پہچان سکیں۔

یہ پورا کورس ایک ہی تعمیر کی صورت میں ہے: خالی نظام سے درست حوالہ یافتہ اور درست طور پر مسترد جواب تک۔

معاملہ۔ اکاؤنٹ ایگزیکٹو نے بیس فیصد رعایت مانگی۔ CRM کہتا ہے منظوری زیرِ التوا ہے۔ دستخط شدہ معاہدہ دستخط کے وقت بل بنانے کی اجازت دیتا ہے۔ محاسبے کا ریکارڈ نفاذ کی آمدنی کو کسٹمر کی قبولیت پر تسلیم کرتا ہے۔ عملی معاہدے کا ریکارڈ کہتا ہے کہ قبولیت موصول نہیں ہوئی۔ فروخت کے مینیجر کی ای میل کہتی ہے کہ مالیاتی شعبہ اسی سہ ماہی میں اندراج سے متفق ہے۔

سوال۔

کیا Northstar بیس فیصد رعایت لے سکتا ہے، اسے ابھی بل بھیجا جا سکتا ہے، اور نفاذ کی آمدنی اسی سہ ماہی میں تسلیم کی جا سکتی ہے؟

مرحلہ 1۔ منصوبہ بنائیں۔ طاقتور ماڈل کے ساتھ منصوبہ بندی کی حالت میں جائیں:

کمپنی Northstar کی مکمل سیاقی تہہ بنائیں: نظام Onyx کا Standard نسخہ جس میں چاروں ماخذی اقسام الگ الگ منسلک ہوں، ہمارے Neon منصوبے میں دونوں شعبوں کے اصول رکھنے والا governed خاکہ، تلاش، تصدیق، جانچ، اور تازہ حالت کے ٹولوں والا vertical-sor MCP سرور، پانچ دستاویزی مجموعے، governance/authority-map.yaml، ایسا context-gateway جو نظام Onyx میں کسی بھی تلاش سے پہلے شناخت معلوم کرکے اجازت یافتہ مجموعے لگائے، اور کسی دستاویزی مجموعے کے بغیر صرف کارروائیوں والا Context Router۔ کوڈ لکھنے سے پہلے منصوبہ، حصوں کی حدود، اور ٹولوں کی فہرست دکھائیں۔

مرحلہ 2۔ منظوری سے پہلے منصوبہ پڑھیں۔ چھ باتیں جانچیں، کیونکہ پورا کورس آپ کو یہی چھ باتیں دیکھنا سکھاتا ہے۔

1. کیا اجازت کی چھانٹی بازیافت سے پہلے ہوتی ہے، بعد میں نہیں؟
2. کیا ہر بازیافتی راستہ، راستہ بان کے اپنے راستے سمیت، دروازے سے گزرتا ہے؟ ایجنٹ کے ساتھ کوئی دستاویزی مجموعہ براہِ راست منسلک نہ ہو، اور کردار ٹول کی دلیل سے نہ آئے۔
3. کیا دریافت اور تصدیق دو الگ درخواستیں ہیں؟
4. کیا عملی حالت براہِ راست تازہ حاصل ہوتی ہے، اور اسے اشاریے میں شامل کرنے کا کوئی راستہ نہیں؟
5. کیا راستہ بان متصادم چیزوں کو الگ محفوظ رکھتا ہے، انہیں ملا کر خلاصہ نہیں بناتا؟
6. کیا Neon ریکارڈ تک رسائی رابطہ MCP کے ذریعے ہے، اور کوئی کنیکٹر اس کے قریب نہیں؟

اگر کسی سوال کا جواب نفی میں ہو تو ایک سطر کوڈ لکھے جانے سے پہلے منصوبہ واپس بھیجیں۔

مرحلہ 3 سے 7۔ وقفہ وار مکمل کریں۔ معمول کی تعمیر کے لیے کم قیمت ماڈل استعمال کریں۔

نظام Onyx کا Standard نسخہ چلائیں، AF-SOR-PUBLIC جوڑیں، اور کتاب سے اخذ شدہ حوالہ یافتہ جواب دکھائیں۔

دونوں شعبہ جاتی ریکارڈ کی فرضی فائلیں اور جاری کام کے سیاق کی فائلیں تین الگ کنیکٹروں سے جوڑیں۔ دستاویزات کی تعداد دکھائیں، اور تصدیق کریں کہ عملی JSON نہیں جوڑی گئی۔

منصوبے کے Neon حصے میں governed خاکہ بنائیں اور منسوخ شدہ محاسبے کے اصول سمیت دونوں شعبوں کے اصول شامل کریں۔ vertical-sor اور کسٹمر کی حالت کا سرور چلائیں، اور ثابت کریں کہ confirm_rule ایسی چیز واپس کرتا ہے جو صرف search_rules نہیں دیتا۔

پانچ دستاویزی مجموعے بنائیں، authority-map.yaml لکھیں، context-gateway بنائیں، اور Context Router کو کسی منسلک علم کے بغیر صرف پانچ کارروائیوں کے ساتھ بنائیں۔

دروازے کے ذریعے ہر کردار کے لیے اجازت کی جانچ چلائیں، جس میں وہ سوال بھی شامل ہو جس کا account_executive کے لیے درست جواب کچھ نہیں ہے۔ پھر وہی سوال براہِ راست نظام Onyx کی تلاش سے پوچھ کر دکھائیں کہ دروازہ کیا روک رہا ہے، اور ایک بار راستہ بان سے پوچھ کر تصدیق کریں کہ وہ نظام Onyx تک صرف اسی راستے سے پہنچتا ہے۔

مرحلہ 8۔ سوال پوچھیں۔ کامیاب مواد کا مجموعہ پانچ کام کرتا ہے۔ یہ دونوں تازہ ٹول بلاتا ہے۔ دونوں شعبہ جاتی ریکارڈوں کا حوالہ تصدیق کے بعد دیتا ہے۔ مینیجر کی ای میل کو صرف معاون ثبوت کہتا ہے۔ فروخت اور محاسبے کے فیصلے الگ حصوں میں رکھتا ہے۔ اور ایک ملے جلے ہاں کے بجائے دو الگ انکار تک پہنچتا ہے۔

دونوں انکار یہ ہیں: منظوری زیرِ التوا ہو تو اس درجے پر رعایت منظور نہیں کی جا سکتی، اور قبولیت باقی ہو تو آمدنی تسلیم نہیں کی جا سکتی۔ دستخط کے وقت بل بنانا جائز ہے، اور اسے درست طور پر کہنا بھی کامیاب جواب کا حصہ ہے۔ ہر چیز مسترد کرنا اتنا ہی غلط ہے جتنا ہر چیز منظور کرنا۔

تقریباً یہ مختصر نتیجہ آئے گا۔ آپ کے الفاظ مختلف ہوں گے، شکل مختلف نہیں ہونی چاہیے۔

## Decisions involved
1. Sales: may an account executive grant 20 percent?
2. Accounting: may implementation revenue be recognised this quarter?
3. Contract: are the billing terms enforceable now?

## Governing authority
- SALES-DISC-001 v2, effective 2026-01-01, approved. Discounts above 15 percent
  require VP Sales approval. [Vertical Sales SoR, confirmed 14:22]
- ACC-REV-001 v3, effective 2026-04-01, approved. Implementation revenue is
  recognised at customer acceptance. [Vertical Accounting SoR, confirmed 14:22]
  Supersedes ACC-REV-002, which said billing. Not applied.

## Current facts
- Opportunity NS-4471: discount 20 percent, approval PENDING. [CRM, read 14:22]
- Contract NS-2026-11: signed, acceptance NOT RECEIVED. [Contract system, read 14:22]

## Supporting context
- Email, sales manager, 2026-07-28: "finance is fine with booking it this quarter."
  Evidence of what was said. Not authority. [Working context, permitted: vp_sales]

## Conflicts and gaps
- The email asserts a finance position no governed accounting source supports.
  Unresolved by authority: escalate. Nothing in the corpus records a finance decision.

## Permitted next steps
- Route the 20 percent discount to VP Sales for approval.
- Bill at signature. Permitted by the signed contract.
- Do not recognise implementation revenue until acceptance is recorded.

## Citations
- SALES-DISC-001 v2 · ACC-REV-001 v3 · NS-4471 · NS-2026-11 · email 2026-07-28

غور کریں کہ یہ شکل کیا کر رہی ہے۔ ہر باقاعدہ دعوے کے ساتھ نسخہ اور تصدیق کا وقت ہے۔ منسوخ شدہ اصول کو خاموشی سے غائب کرنے کے بجائے نام لے کر واضح کیا گیا ہے کہ وہ لاگو نہیں ہوا۔ ای میل اپنے الگ حصے میں درست نام کے ساتھ آتی ہے، اور اختلافات اور خلا میں دوبارہ آتی ہے کیونکہ وہ ایسی بات کہتی ہے جس کی کوئی باقاعدہ بنیاد نہیں۔ تینوں فیصلے الگ رہتے ہیں: ایک انکار، ایک اجازت، ایک انکار۔

مرحلہ 9۔ اسے جان بوجھ کر توڑیں۔ ناکامی کی پانچ جانچیں ہیں، اور متوقع رویہ ہی اصل سبق ہے:

جانچ	متوقع رویہ
CRM میں منظوری زیرِ التوا رکھتے ہوئے ای میل کو بدل کر رعایت منظور شدہ لکھیں	اختلاف سامنے آئے، CRM کو موجودہ عملی حالت مانا جائے
search_rules کو Neon کی پرانی شاخ کی طرف کریں	تصدیق اسے درست کرے، اور پرانا جواب صاف غلط دکھائی دے
کسٹمر کی حالت کا MCP سرور روک دیں	بتایا جائے کہ موجودہ حالت کی تصدیق نہیں ہو سکتی، اور اس پر مبنی نتیجہ دینے سے انکار ہو
دروازے کے اجازت یافتہ دائرے سے فروخت کے اصول ہٹا دیں	مینیجر کی ای میل کو بدل نہ بنایا جائے بلکہ غائب حاکم اختیار کا نام لیا جائے
مختلف شعبوں کا دستاویزی مجموعہ راستہ بان سے براہِ راست منسلک کریں	حفاظتی حد کے گرد راستہ بن جائے اور محدود کردار ممنوع مواد دیکھ لے۔ اسے الگ کریں اور درست جواب واپس آتا دیکھیں

کام تب مکمل ہے جب: آپ ایسے نظام سے ایک پراعتماد، رواں، مکمل حوالہ یافتہ، مگر سراسر غلط جواب دیکھ چکے ہوں جس نے صرف ایک تصدیقی درخواست چھوڑ دی تھی۔ یہ تجربہ کوئی نہیں بھولتا۔

مرحلہ 10۔ بنیادی معیار محفوظ کریں۔ فائل evals/questions.yaml کے ہر معاملے کو چلائیں اور خام جواب، حوالے، ٹول درخواست کے ثبوت، ہر جہت کی کامیابی یا ناکامی، Community Edition کی معلوم اجازت کی حد، اور نظام Onyx و ماڈل کے عین نسخے محفوظ کریں۔

---

حصہ 6: اسے ثابت کریں

آسان الفاظ میں

پچھلے کورس میں جانچ کا ایک سوال تھا: کیا تلاش نے درست متن ڈھونڈا؟

یہاں اتنا کافی نہیں۔ یہ تہہ ایسے طریقوں سے ناکام ہو سکتی ہے جنہیں تلاش کی جانچ نہیں دیکھتی۔ یہ پچھلے سال کے اصول کا درست اقتباس ڈھونڈ سکتی ہے۔ کسی شخص کو وہ چیز دکھا سکتی ہے جو اسے نہیں دیکھنی چاہیے۔ کسی عدد کی پرانی نقل سے جواب دے سکتی ہے۔ اس لیے آپ آٹھ الگ باتیں جانچیں گے، اور ہر ناکامی کو بتانا ہوگا کہ کون سا حصہ ٹوٹا۔

آپ کی RAG جانچ صرف یہ پوچھتی تھی کہ کیا بازیافت نے درست ٹکڑے واپس کیے۔ سیاقی تہہ کی بیشتر ناکامیاں بازیافت کی ناکامیاں نہیں، اس لیے اسے الگ مجموعہ اور الگ معیارنامہ درکار ہے۔

فائل evals/questions.yaml میں دس معاملات پہلے سے لکھے ہیں۔ اسے کھولیں اور ان چھ کو غور سے پڑھیں، کیونکہ ہر ایک الگ مرحلہ جانچتا ہے:

version: 1
cases:
  - id: inventory-01
    question: What sources contain Northstar discount information?
    expected:
      must_find: [Sales SoR, CRM, draft proposal]
      must_not_treat_as_authority: [draft proposal]

  - id: sales-01
    question: Can the account executive approve a 20 percent discount?
    expected:
      governing_source: Sales SoR
      live_tool: get_opportunity
      conclusion: no, VP Sales approval is required and remains pending

  - id: accounting-01
    question: Can implementation revenue be recognised this quarter?
    expected:
      governing_source: Accounting SoR
      live_tool: get_contract_state
      conclusion: no, acceptance has not been received

  - id: stale-01
    question: When is implementation revenue recognised?
    expected:
      prefers_current_version: true
      flags_superseded: true

  - id: conflict-01
    question: Finance should be fine with booking it, right?
    expected:
      working_context_is_not_authority: true
      conflict_visible: true

  - id: gap-01
    question: Which executive approved the discount?
    expected:
      answer: not established
      no_guess: true

ہر بار کے نتیجے کو نثر کی روانی پر نہیں، ان آٹھ جہتوں پر پرکھیں:

جہت	کامیابی کا سوال
ماخذوں کی فہرست	کیا اس نے کام سے متعلق تمام ماخذی اقسام تلاش کیں؟
راستہ بندی	کیا اس نے ہر پیشہ ورانہ فیصلے اور اس کے شعبے کو پہچانا؟
اختیار	کیا اس نے درست حاکم ماخذ پر بھروسا کیا، اور اصل ماخذ سے تصدیق کی؟
تازگی	جہاں موجودہ حالت اہم تھی، کیا اس نے براہِ راست ٹول بلایا؟
اجازت	کیا وہ صارف کے اجازت یافتہ مجموعے اور عملی اختیار کے اندر رہا؟
اختلاف	کیا اس نے اختلاف کو ملانے کے بجائے سامنے رکھا؟
خلا	کیا اس نے اندازہ لگانے کے بجائے غائب معلومات بتائیں؟
حوالہ	کیا جائزہ لینے والا ہر اصول اور معاون چیز دوبارہ کھول سکتا ہے؟

پہلا بنیادی معیار ایجنٹ کے ذریعے ہاتھ سے چلائیں اور نتائج محفوظ کریں۔ پھر اسے خودکار بنائیں:

موجودہ سرکاری API استعمال کرکے ہمارے چلتے نظام Onyx کے لیے جانچ کا ڈھانچہ بنائیں۔ evals/questions.yaml پڑھیں، ہر سوال Northstar Context Router کو بھیجیں، خام جواب، حوالے، اور ٹول درخواستوں کے ثبوت محفوظ کریں، پھر آٹھوں جہتوں کا Markdown معیارنامہ بنائیں۔ جہاں ممکن ہو قطعی جانچ استعمال کریں۔ پیشہ ورانہ درستگی کو اسی ماڈل سے خودکار طور پر نہ پرکھوائیں جس نے جواب دیا تھا۔ اختیار اور نتیجے کی جانچ کو واضح متوقع اقدار سے موازنہ رہنے دیں۔

آخری ہدایت کا دفاع ضروری ہے۔ ایک ماڈل دوسرے ماڈل کی ناکامیاں مختصر کرنے میں مدد دے سکتا ہے۔ مگر اسے کبھی خاموشی سے ان متوقع اصولوں اور حقائق کی جگہ نہیں لینی چاہیے جو آپ نے خود لکھے ہیں۔

تکمیل کی تعریف: مختلف شعبوں والا معاملہ پیداواری اجازت کی درستگی کے سوا ہر جہت میں کامیاب ہو، اور اجازت کی کمی صاف طور پر نامکمل شرط رہے۔

---

حصہ 7: پوری افرادی قوت کے لیے پیش کریں اور اسے چلائیں

آسان الفاظ میں

جو تہہ صرف ایک گفتگو کی کھڑکی میں کام کرے، وہ مکمل نہیں۔

آخری تعمیری مرحلہ اسے کھول دیتا ہے، تاکہ آپ کے ساتھیوں کے پہلے سے استعمال ہونے والے دوسرے ٹول اسی مجموعے تک پہنچ سکیں، اور اس پر بھی یہی اصول لاگو ہوں کہ کون کیا دیکھ سکتا ہے۔ پھر وہ حصہ آتا ہے جسے کوئی درج نہیں کرتا: جب حقیقی لوگ اس پر منحصر ہوں تو اسے مسلسل چلانے کے لیے کیا درکار ہے۔

اب تک انسانوں اور نظام Onyx کے ایجنٹوں نے مجموعہ اسی نظام کے انٹرفیس کے اندر استعمال کیا ہے۔ ڈھانچہ اپنے نام کا وعدہ تب پورا کرتا ہے جب بیرونی کارکن اس کی نجی نقلیں بنانے کے بجائے اسی مجموعے سے سوال کریں۔

نظام Onyx دونوں سمتوں میں چلتا ہے، اور زیادہ تر تعمیرات اس مرحلے تک نہیں پہنچتیں:

یہ کام دو طریقوں سے ہو سکتا ہے، مگر صرف ایک طریقہ آپ کی اجازت کی حد برقرار رکھتا ہے۔

نظام Onyx کا مقامی MCP سرور فوری راستہ ہے۔ اسے خود میزبان ترتیبات میں آن کریں، ٹوکن بنائیں، اور صارف کو اس کی طرف بھیجیں۔ اس کا تلاش کا ٹول سوال کے ساتھ ماخذ کی قسم، دستاویزی مجموعے کے نام، اور وقت کی حد کی چھانٹیاں لیتا ہے، جبکہ ایک معاون وسیلہ ان مجموعوں کی فہرست دیتا ہے جن تک ٹوکن پہنچ سکتا ہے۔

اس فہرست کو غور سے پڑھیں، کیونکہ یہ اطمینان کے بالکل برعکس ہے۔ دستاویزی مجموعے کی چھانٹی موجود ہے، مگر اسے صارف چنتا ہے۔ سرور بلانے والے کے کردار سے کوئی دائرہ اخذ نہیں کرتا، اس لیے جو صارف اپنا دائرہ خود نام زد کر سکتا ہے وہ کوئی دوسرا دائرہ بھی چن سکتا ہے، یا اسے بالکل چھوڑ سکتا ہے۔

اس طرح نظام Onyx کے مقامی MCP سے براہِ راست جڑا کارکن آپ کی حفاظتی حد سے باہر تلاش کرتا ہے۔ Community Edition میں، جہاں نیچے ماخذی اجازت کی وراثت نہیں، اس کا مطلب ہر چیز میں تلاش ہے۔

مقامی راستہ کیا دعویٰ کر سکتا ہے اور کیا نہیں

نظام Onyx کے مقامی MCP راستے کو صرف اس کام کے لیے استعمال کریں جو وہ حقیقتاً ہے: منتظم کا ٹول، عوامی مجموعے پر مظاہرہ، یا پیداواری راستہ مگر صرف اجازت کی درستگی ثابت ہونے کے بعد، Enterprise نظام یا آپ کی مساوی اختیاری تہہ کے ساتھ۔

نسخہ Community Edition کے براہِ راست MCP راستے کو صارف کی وہی اجازت کی حد رکھنے والا نہ کہیں۔ یہ حد اس میں موجود نہیں۔

سرور Context Gateway MCP وہ راستہ ہے جو حد برقرار رکھتا ہے۔ یہی پہلے بنایا گیا دروازہ اب باہر کی طرف پیش ہوتا ہے:

Claude Code  ·  OpenCode  ·  your Digital FTE
                     |
          Context Gateway MCP
          resolves identity
          applies permitted sets and tags
          routes authority, confirms, fetches live
                     |
                   Onyx

ہمارے دروازے کو context-gateway نام کے الگ MCP سرور میں لپیٹیں۔ search_permitted_context، confirm_rule، get_opportunity، get_contract_state، اور validate_action پیش کریں، تاکہ بیرونی کارکن کو کسی دوسرے سرور تک براہِ راست پہنچنے کی ضرورت نہ ہو۔ اسے Streamable HTTP پر چلائیں۔

شناخت کے لیے bearer token کو سرور پر کرداروں سے ملائیں۔ ہر کردار کے لیے ایک ٹوکن جاری کریں، نقشہ سرور کے ماحول میں رکھیں، اور ہر درخواست پر کردار ٹوکن سے پڑھیں۔ کردار کبھی ٹول کی دلیل کے طور پر نہ آئے۔

عملی طور پر نقشہ صرف تین سطروں کی ترتیب ہے، مگر پوری اجازت کی حد اسی پر قائم ہے:

ACCOUNT_EXECUTIVE_TOKEN  ->  account_executive
SALES_MANAGER_TOKEN      ->  sales_manager
VP_SALES_TOKEN           ->  vp_sales

صارف MCP رابطے میں bearer token دیتا ہے۔ سرور اس ٹوکن کو کردار سے ملاتا ہے۔ صارف کبھی اپنے کردار کا نام خود نہیں دیتا، کیونکہ جو صارف ایسا کر سکے اس کے سامنے کوئی حد باقی نہیں رہتی۔

ٹوکن ہی حد ہے، اس لیے اسے کھلے متن میں نہ بھیجیں

یہاں تک سب کچھ http:// پر چلا، کیونکہ سب کچھ آپ کی اپنی مشین پر تھا۔ جس لمحے دروازہ کہیں اور سے قابلِ رسائی ہو، وہ bearer token سادہ متن میں سفر کرتے ہوئے پوری اجازت کی حد بن جاتا ہے۔ اس کے سامنے TLS لگائیں، ہر کردار کے بجائے ہر شخص کو الگ ٹوکن دیں، اور ٹوکن کی میعاد مقرر کریں۔ کردار کے نام والا کبھی ختم نہ ہونے والا ٹوکن عہدے کے نام سے بنا مشترک پاس ورڈ ہے۔

نظام FastMCP کا HTTP سرور راستہ نہ بدلنے پر /mcp پر جواب دیتا ہے، اس لیے خالی میزبان کے بجائے یہی راستہ درج کریں۔ پھر اسے دوسرے HTTP MCP سرور کی طرح جوڑیں:

claude mcp add --transport http context-gateway http://YOUR_GATEWAY_HOST:8102/mcp \
  --header "Authorization: Bearer $ACCOUNT_EXECUTIVE_TOKEN"

فائل opencode.json میں دور دراز سرور کا یہ حصہ شامل کریں:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "context-gateway": {
      "type": "remote",
      "url": "http://YOUR_GATEWAY_HOST:8102/mcp",
      "headers": { "Authorization": "Bearer {env:ACCOUNT_EXECUTIVE_TOKEN}" },
      "enabled": true
    }
  }
}

ٹوکن کبھی محفوظ شدہ کوڈ میں شامل نہ کریں۔ OpenCode میں {env:NAME} ماحول کی قدر رکھتا ہے، اس لیے ٹوکن آپ کے شیل میں رہتا ہے اور فائل میں صرف اس کا نام آتا ہے۔ پھر نظام Onyx سے مکمل طور پر باہر یہ کہیں:

context-gateway MCP سرور استعمال کرکے بیس فیصد Northstar رعایت کا حاکم اصول تلاش کریں۔ ماخذ کا عنوان، مستند ربط، تصدیق شدہ نسخہ، اور عین اقتباس واپس کریں۔ اپنی یاد سے جواب نہ دیں۔

ایک دوسرا سوال چلائیں جسے فروخت اور محاسبے دونوں کی ضرورت ہو۔ بیرونی کارکن کئی تلاشیں کرکے اپنا مجموعہ بنا سکتا ہے، اور مختلف صارف الگ رویہ دکھائیں گے۔ یہ فرق اصل نکتہ نہیں۔

پھر اہم جانچ چلائیں: دروازے کے ذریعے ایک ہی سوال account_executive اور vp_sales کے طور پر پوچھیں، اور تصدیق کریں کہ دونوں کارکنوں کو مختلف نتائج ملتے ہیں۔ اگر ایسا نہ ہو تو آپ کا دروازہ شناخت ایسی چیز سے معلوم کر رہا ہے جسے صارف قابو کرتا ہے، اور آپ نے ایسی اجازت کی حد بنائی ہے جسے ہر صارف پھلانگ سکتا ہے۔

نظام Glean میں

اس حصے کے مسئلے کے لیے یہ نظام Glean کا سب سے مضبوط جواب ہے۔ اس کا MCP سرور مقامی شناخت اور اجازت کے نمونے کے گرد سے کبھی نہیں گزرتا۔ وہ صرف رابطے کا ہلکا واسطہ ہے: آخری صارف کی تصدیق کرتا، شناخت کو نظام Glean کے صارف سے ملاتا، اور ہر ٹول درخواست اسی صارف کے طور پر چلاتا ہے۔ یوں ہر تلاش، گفتگو، اور دستاویز کی درخواست کی اجازت اسی طرح جانچی جاتی ہے جیسے شخص نے اسے نظام Glean کے اندر چلایا ہو۔ منتظم طے کرتے ہیں کہ ہر سرور کون سے ٹول پیش کرے گا۔

یہی وہ حد ہے جسے آپ کا context-gateway ہاتھ سے دوبارہ بنا رہا ہے۔ پھر بھی اسے ایک بار بنائیں، کیونکہ جس دن کسٹمر کا نظام یہ سہولت نہ دے، آپ بالکل جانیں گے کہ کیا غائب ہے اور اسے فراہم کرنے کے لیے کیا درکار ہے۔

افرادی قوت کی جانچ

سیاقی تہہ صرف اس لیے مکمل نہیں کہ ایک گفتگو کا انٹرفیس اسے تلاش کر سکتا ہے۔ یہ تب مکمل ہے جب ہر اجازت یافتہ انسان اور اے آئی کارکن اپنے کام کے وسیلے سے اسی باقاعدہ فہرست تک، اسی ماخذی شناخت اور اسی اجازت کی حد کے ساتھ پہنچے۔

یہ کسی اطلاق اور مشترک بنیادی ڈھانچے کا فرق ہے۔ یہی وہ لمحہ ہے جب آپ کی تہہ کسی مصنوع کی خصوصیت رہنے کے بجائے کمپنی کے چلنے کی بنیاد بن جاتی ہے۔

اسے چلانا

سیاقی تہہ ہر روز بدلتی ہے، کیونکہ اس کے گرد موجود نظام ہر روز بدلتے ہیں۔ اس لیے پیداواری کام صرف "ایک بار لگانا" نہیں۔ اس میں کنیکٹر کی صحت، اجازت کی درستگی، تازگی، پیمائش، اور قابو شدہ نئی کاری شامل ہیں۔

کنیکٹر کا انتظام

ہر کنیکٹر کے لیے نو باتیں درج کریں۔ مالک۔ ماخذ کی قسم۔ شناختی معلومات کا مالک۔ تازہ کاری اور صفائی کی رفتار۔ اشاریہ سازی شروع ہونے کا وقت۔ متوقع دستاویزی تعداد۔ آخری کامیاب ہم وقت سازی۔ قابلِ قبول پرانا پن۔ اور مسئلہ اوپر بھیجنے کا راستہ۔

نظام Onyx کنیکٹروں کو اشاریہ بند، مقررہ وقت پر، زیرِ اشاریہ، رکا ہوا، یا خرابی میں دکھاتا ہے اور کوششوں کی تاریخ رکھتا ہے۔ یہاں ایک پھندا ہے۔ خرابی میں موجود کنیکٹر ضروری نہیں کہ پہلے اشاریہ بند مواد کو ہٹا دے۔ دستیابی کے لیے یہ بہترین مگر تازگی کے لیے خطرناک ہے، کیونکہ تلاش چلتی رہتی ہے جبکہ مجموعہ خاموشی سے پرانا ہوتا جاتا ہے۔ آپ کی اطلاع رسانی کو تلاش اب بھی چلتی ہے اور مجموعہ موجودہ ہے میں فرق کرنا چاہیے؛ یہ ایک ہی خطرے کی گھنٹی نہیں۔

نسخے اور نئی کاری کا نظم

نصب کار موجودہ نظام کو نیا کر سکتا ہے۔ ایک کمانڈ کی نئی کاری کو کبھی بے جائزہ نئی کاری نہ سمجھیں۔ ترتیب سے آٹھ مرحلے ہیں:

1. موجودہ نسخہ درج کریں۔
2. اجرا کی تفصیلات پڑھیں۔
3. مستقل ذخائر اور ترتیبات کی نقل محفوظ کریں۔
4. کنیکٹر، ماڈل، ایجنٹ، کارروائی، اور اجازت کی ترتیبات برآمد کریں۔
5. جانچ کا بنیادی معیار چلائیں۔
6. پہلے غیر پیداواری نظام نیا کریں۔
7. وہی جانچیں دوبارہ چلائیں۔
8. کنیکٹر کی تعداد، حوالے، ٹول درخواستیں، اور تاخیر کا موازنہ کریں۔

عددی نمائندگی اور اشاریے کی تبدیلیاں

عدد ساز ماڈل بدلنے کے لیے دوبارہ اشاریہ سازی ضروری ہے۔ اسے بالکل خاکے کی منتقلی کی طرح لیں۔ جہاں ممکن ہو نظام کی نقل بنائیں۔ نمائندہ مجموعہ اشاریے میں شامل کریں۔ اختیار اور بازیافت کی جانچیں چلائیں۔ یادآوری، حوالوں کے معیار، تاخیر، لاگت، اور ذخیرے کا موازنہ کریں۔ صرف ناپی ہوئی بہتری منظور کریں۔

وسائل کی منصوبہ بندی

مقامی تجربہ گاہ کے لیے 4 مجازی CPU اور 10 GB یادداشت Standard نسخے کی کم از کم مفید حد ہے، جبکہ 8 CPU اور 16 GB یا زیادہ بہتر ہیں۔ پیداوار کی جسامت زیادہ تر اشاریہ بند مقدار، بیک وقت سوالوں، عددی نمائندگی اور دوبارہ درجہ بندی کے انتخاب، اور تازہ کاری کے بوجھ پر منحصر ہے۔ ڈسک پر گہری نظر رکھیں، کیونکہ تلاش کا اشاریہ بھرنے کی خطرناک حد کے قریب نئی تحریر روک سکتا ہے۔

پیداوار میں تکمیل کی تعریف

تہہ حقیقی کمپنی کی معلومات کے لیے تبھی تیار ہے جب یہ سب درست ہوں:

• ہر ماخذ کو مشترک طریقہ، شعبہ جاتی اختیار، عملی حالت، یا جاری کام کا سیاق قرار دیا گیا ہو۔
• ہر کنیکٹر کا مالک، مستند ماخذ، تازہ کاری کی توقع، اور ناکامی کی اطلاع موجود ہو۔
• اختیار کی راستہ بندی نسخہ بند ہو اور ماہرینِ شعبہ اس کا جائزہ لے چکے ہوں۔
• باقاعدہ علم پر بھروسا کرنے سے پہلے اصل ماخذ سے تصدیق ہوتی ہو۔
• جہاں ضروری ہو، موجودہ عملی حقائق براہِ راست تصدیق ہوتے ہوں۔
• ماخذ کی اجازتیں بازیافت سے پہلے ہم وقت یا نافذ ہوتی ہوں۔
• MCP اور API کارروائیاں ہر شخص کی شناخت اور کم از کم اختیار برقرار رکھتی ہوں۔
• اختلافات اور غائب ثبوت دکھائی دیتے رہیں۔
• حوالے مستند ماخذ یا ریکارڈ دوبارہ کھولیں۔
• ہر اجرا پر مختلف شعبوں کی جانچیں کامیاب ہوں۔
• محفوظ نقل اور بحالی کی جانچ ہو چکی ہو۔
• نئی کاری اور بازیافتی تبدیلیوں کے لیے واپسی کا راستہ موجود ہو۔
• سیاق کا نظام قابلِ اطلاق ریکارڈ کے نظام کے گرد سے تحریر نہ کر سکے۔

پل Digital FTE تک

اب آپ کے پاس ایک ہی چیز کے دو نصف ہیں۔ پچھلے کورس نے کارکن کو وہ علم دیا جس کی ملکیت اسی کے پاس ہے۔ اس کورس نے اسے کمپنی کے علم تک اجازت، ماخذی نسبت، اور تصدیق کے ساتھ رسائی دی۔

Digital FTE تب بنتا ہے جب آپ اس کارکن کے گرد کامیابی کا معاہدہ رکھ کر اسے ایک نتیجے کی طرف بھیجتے ہیں۔ اس کی بازیافت وہ ہے جو آپ نے یہاں بنائی۔ اس کا اختیار وہ ہے جو آپ کا باقاعدہ ریکارڈ کہتا ہے۔ اور اس کی قابلِ اعتماد ہونے کی صلاحیت ماڈل کی خصوصیت بالکل نہیں۔

---

اگلا مرحلہ

• اس تعمیر کے پیچھے دلیل: سیاق کا نظام
• وہ ریکارڈ جس سے یہ تہہ جڑتی ہے: شعبہ جاتی ریکارڈ کا ڈیزائن
• اسے قابلِ اعتماد بنائیں: جانچ پر مبنی تیاری
• اسے کام کی اکائی بنائیں: Digital FTE بنانا
• اسے لوگوں کے ساتھ رکھیں: انسان اور ایجنٹ کی ٹیمیں

آٹھ اصول، ایک جگہ

آپ یہ سب بنا چکے ہیں۔ یہ ہر پیشے، ہر کسٹمر، اور ہر مصنوع پر لاگو ہوتے ہیں، ان پر بھی جو ابھی وجود میں نہیں آئے۔

#	اصول
1	اختیار کبھی منتقل نہیں ہوتا۔ تہہ ریکارڈ کے حوالے ساتھ رکھتی ہے۔ نہ تہہ اور نہ ماڈل کبھی حوالہ دیا گیا ماخذ بنتے ہیں
2	متعلق ہونا اختیار نہیں۔ کسی اقتباس پر بھروسا کرنے سے پہلے راستہ بندی طے ہوتی ہے
3	اجازت ورثے میں ملتی ہے، بنائی نہیں جاتی، اور ماڈل سے پہلے نافذ ہوتی ہے
4	تازگی ہر خانے کے لیے الگ طے ہوتی ہے۔ جاری کام کا سیاق اشاریہ بند کریں، باقاعدہ علم دریافت کریں، موجودہ حقیقت براہِ راست پوچھیں
5	ماخذی نسبت ہر چیز کے ساتھ سفر کرتی ہے، اور اختصار اسے کبھی نہیں ہٹاتا
6	اختلاف محفوظ کرکے اوپر بھیجا جاتا ہے، کبھی ملایا نہیں جاتا
7	جاری کام کا سیاق خاموشی سے حاکم اختیار نہیں بنتا۔ ترقی جائزہ شدہ اور درج شدہ تصنیف ہے
8	دریافت تصدیق نہیں۔ تلاش کا نتیجہ اشارہ ہے، اور حاکم ریکارڈ تصدیق کرتا ہے

اس جدول کو چھاپ لیں۔ یہ نظام Onyx، نظام Glean، اور ان دونوں کی جگہ آنے والی چیزوں سے زیادہ عرصہ چلے گا۔

---

مرکزی سلسلہ کبھی نہیں بدلتا، صرف زیادہ سخت ہوتا جاتا ہے۔ پچھلے کورس نے کہا تھا: درست معلومات، درست وقت، غیر متعلقہ معلومات باہر۔ اس کورس میں وہ تین سوال شامل ہوئے جو اسے قابلِ دفاع بناتے ہیں۔

یہ کہاں سے آیا؟ کیا یہ شخص اسے دیکھ سکتا ہے؟ کیا اس کا حکم اب بھی چلتا ہے؟

ہر چیز پر، ہر مرتبہ، تینوں سوالوں کا جواب دیں، اور آپ نے ایسی چیز بنائی ہے جس کے پیچھے ایک پیشہ کھڑا ہو سکتا ہے۔

---

فلیش کارڈ مطالعہ معاون

---

اپنی سمجھ جانچیں

Checking access...