بناء طبقة السياق: من مخزن عامل واحد إلى مجموعة مصادر القوى العاملة كلها — دورة مكثفة

15 مفهوما · Onyx وMCP وأربع فئات من المصادر · يبنيها وكيلك، لا تبنيها يدويا

بنت دورة السياق القابل للبحث بالذكاء الاصطناعي مخزنا خاصا بعامل واحد. تبني هذه الدورة مجموعة المصادر التي تقرأ منها القوى العاملة كلها.

في دورة السياق القابل للبحث بالذكاء الاصطناعي منحت عاملا واحدا مخزنه الخاص: مستنداتك مجزأة ومضمنة وقابلة للبحث بالمعنى، داخل قاعدة Neon Postgres واحدة تتحكم فيها. بل غلفتها أداة MCP حتى تستدعيها وكلاء أخرى.

لكنها بقيت مخزنا واحدا محدودا، بحد رسمته أنت. اخترت كل مستند فيه، وقررت من يصل إليه، ولم يدخله شيء لم تضعه بنفسك.

والآن ادخل مبنى عميل.

أوراق العمل التي تمتد عشرين عاما في SharePoint. خطابات التكليف في البريد. سبب قرار ما في محادثة وفي ذهن مدير مسافر. الأرصدة الحالية في نظام يتغير كل ساعة. لا شيء من ذلك مخزنك، لكنك تحتاج إليه كله لإتمام العمل.

تبني هذه الدورة الطبقة التي تصل إلى ذلك كله، وتبنيها حول سؤال حقيقي قد تطرحه شركة فعلية:

تريد Northstar Services خصما بنسبة عشرين في المئة، وتريد إصدار الفاتورة الآن، وتريد إثبات إيراد التنفيذ في هذا الربع. هل يمكنها ذلك؟

هذه جملة واحدة من عميل واحد، لكنها ليست سؤالا واحدا. إنها سؤال مبيعات، وسؤال محاسبة، وسؤال حالة حية، وادعاء منقول في رسالة بريد. وتتطلب الإجابة الصحيحة إبقاء الأربعة منفصلة. في نهاية الدورة سيجيب عامل عنها بطريقة سليمة، مع الاستشهادات، والحقائق الحالية المستخرجة لحظيا، والبريد موسوما دليلا لا سلطة، والقرارين المهنيين منفصلين بدلا من دمجهما في نعم مبهجة واحدة.

ثلاث كلمات أولا إن كانت جديدة. الموصل هو الجزء الذي يقرأ نظام مصدر ويحافظ على نسخة حديثة من محتواه. الفهرسة تخزن تلك النسخة كي يمكن البحث فيها. وتوريث الأذونات ينقل قواعد الوصول لكل مستند من نظامه الأصلي إلى كل نتيجة بحث، فلا يرى القارئ إلا ما كان يستطيع فتحه أصلا.

فكرة واحدة تجعل الدورة كلها واضحة. كان للدورة السابقة سؤال واحد: هل المقطع الصحيح داخل نافذة السياق؟ لهذه الدورة ثلاثة أسئلة، وكل مفهوم يخدمها. لكل ما تعيده الطبقة:

من أين أتى؟ هل يجوز لهذا الشخص رؤيته؟ هل ما زال حاكما؟

لا يجيب مربع بحث عن أي منها. تجيب طبقة السياق عن الثلاثة، لكل عنصر وفي كل مرة. هذا هو الفرق كله، وهو سبب كون هذا دورة لا ملف إعداد.

عشرون مصطلحا تستخدمها الدورة

المصطلح	معناه ببساطة
System of Record	النظام الذي يحتفظ بالشيء رسميا. إذا خالفته نسخة، فالنسخة خاطئة
Vertical	مهنة أو صناعة واحدة مثل المحاسبة أو القانون أو هندسة المبيعات، بعكس الأغراض العامة
Authority class	نوع العبارة، وبالتالي وزنها: قانون أو معيار أو عقد أو سياسة أو معاملة أو إرشاد أو رسالة أو مثال
Working context	مواد الشركة اليومية: البريد والمحادثات والمسودات والملفات. حقيقية ومفيدة، لكنها ليست القاعدة أبدا
Connector	الجزء الذي يقرأ نظام مصدر ويحافظ على نسخة حديثة من محتواه
Sync	تشغيل واحد للموصل يجلب ما تغير منذ آخر مرة
Index	النسخة القابلة للبحث التي تحتفظ بها الطبقة كي تجد الأشياء سريعا
Corpus	كل المحتوى الذي تستطيع الطبقة البحث فيه عبر المصادر المتصلة
Fixture	ملف وهمي واقعي تنشئه للتدريب حتى لا تعرض بيانات حقيقية للخطر
Document Set	مجموعة مسماة من الموصلات تحدد المصادر التي يجوز للبحث النظر فيها
Onyx Agent	مساعد معد داخل Onyx، له تعليمات ومعرفة وأدوات
Action	أداة قد يستدعيها Onyx Agent، مثل بحثك أو lookup حي
Canonical	النسخة الأصلية الرسمية، لا نسخة مأخوذة عنها
Projection	نسخة قابلة للبحث من محتوى محكوم، تحفظ فقط كي يجد العامل الأصل
Stable ID	اسم دائم لقاعدة واحدة، كي تشير نسخة إلى أصلها
Superseded	استبدلتها نسخة أحدث، ولم تعد القاعدة المطبقة
Gateway	شفرتك أمام Onyx، تقرر ما يجوز لهذا الشخص البحث فيه
Packet	حزمة القواعد والحقائق والأدلة المجمعة لسؤال واحد
Envelope	الوسوم الملحقة بعنصر: من أين أتى، نسخته، ولماذا يجوز لك رؤيته
Provenance	القصة الكاملة لمصدر المعلومة

يشرح كل مصطلح جديد آخر عند أول ظهور له.

المتطلبات السابقة

تفترض الدورة إتمام السياق القابل للبحث بالذكاء الاصطناعي. ينبغي أن يكون لديك RAG عامل على Neon مع pgvector، وأن تعرف التجزئة وembedding worker، وأن تكون مرتاحا في تقييم جودة الاسترجاع بمجموعة eval. احتفظ بمشروع Neon ذاك. ستعيد استخدام بنيته ومهارات الاسترجاع هنا. لكن كن واضحا بشأن ما بناه وما لم يبنه، لأن الفرق هو موضوع هذه الدورة.

بنت تلك الدورة مخزن استرجاع واحدا محدودا: مستندات ومقاطع وتضمينات ودالة بحث ودالة إجابة ومجموعة eval. علمتك كيف تصبح المستندات معرفة قابلة للبحث. لكنها لم تمنح المخزن سلطة مهنية. لا توجد فيه authority classes ولا jurisdictions ولا effective periods ولا supersession links. لذلك تضيف في المفهوم 10 مخططا محكوما صغيرا بجانب الموجود، والمفهوم 10 هو الذي يصل إليه. وتفترض أيضا البرمجة الوكيلية لتوجيه Claude Code أو OpenCode في plan mode، والمهارات والموصلات من أجل MCP.

صفحة المفهوم خلف هذا البناء هي نظام السياق. اقرأها أولا إن أردت الحجة. هذه الدورة أرض المصنع، وNorthstar هو المثال نفسه الذي تفككه تلك الصفحة.

---

إليك النظام كله في صفحة واحدة، الخريطة التي ستنمو إليها مع كل مفهوم:

ما تغطيه هذه الدورة

الجزء	الموضوع	ما ستتعلمه
1	الأسس	قفزة النطاق، وأربع فئات مصادر، وOnyx Standard، ونموذج واحد، وخط أساس للبحث
2	مجموعة مصادرك الأولى	الكتاب كمنهج مشترك، وNorthstar fixtures، وDocument Sets، والمجزئ، وبوابة الأذونات
3	النصف المحكوم	سجل Neon عبر MCP، والاكتشاف مقابل التأكيد، والحالة الحية
4	التوجيه والاستشهاد	خريطة السلطة قبل الموجه، والحزمة ذات الأقسام السبعة، والتعارضات التي لا يجوز دمجها
5	حالة Northstar	البناء كاملا من البداية إلى النهاية، ثم أربع طرق لكسره عمدا
6	أثبته	ثمانية أبعاد eval، ولماذا لا ينبغي للنموذج الذي أجاب أن يصحح نفسه
7	قدمه وشغله	بوابة واحدة لكل عامل خارجي، ثم صحة الموصلات والترقيات وتعريف الاكتمال

ما ستبنيه

نشر عامل من Onyx Standard مع أربع فئات مصادر متصلة ومنفصلة. كتاب Agent Factory نفسه مفهرسا بوصفه المنهج المشترك. سجلان رأسيان لNorthstar، المبيعات والمحاسبة، يختلفان بطريقة مفيدة. خادم MCP حي للحالة الحالية. سجل Neon الخاص بك، يقدم عبر MCP ولا يزحف إليه crawler أبدا. ملف authority-map.yaml بإصدارات، وهو الذي يحدد السجل الحاكم لكل سؤال. Context Router يعيد الأقسام السبعة نفسها كل مرة مع الاستشهادات. بوابة أذونات كتبتها واختبرتها بدور تكون إجابته الصحيحة لا شيء. مجموعة eval تقيم على ثمانية أبعاد. ونقطة Context Gateway MCP تتيح للعاملين الخارجيين المصرح لهم الاستعلام من مجموعة المصادر المشتركة عبر حد الهوية والأذونات نفسه.

طريقة القراءة. الجزآن 1 و2 مع بناء Northstar في الجزء 5 هما النظام الكامل: نحو ساعتين قراءة وبضع ساعات على لوحة المفاتيح. الجزآن 3 و4 يجعلان النظام جديرا بالثقة لا عاملا فحسب، ولا يمكن حذف أي منهما: الجزء 5 يشغلهما جميعا فعليا. أتريد البناء أولا وقراءة السبب لاحقا؟ ابدأ من الجزء 5.

---

📚 وسيلة تعليمية

افتح العرض الكامل

يجري إعداد عرض شرائح لهذه الدورة.

---

إعداد البيئة مرة واحدة

كل ما ستبنيه داخل مجلد واحد موصول مسبقا.

تنزيل context-layer-base.zip

فك الضغط. ستجد حالة Northstar جاهزة للتوصيل، وملفات governance جاهزة للملء، وثلاثة هياكل لخوادم 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

ستة أسرار، ومكان واحد لحفظها

تتعامل هذه الدورة مع بيانات اعتماد أكثر من السابقة، وكل واحد منها قد يهدم ثقة عميل في commit واحد.

السر	ما الذي يفتحه
Neon pooled connection string	سجلك المحكوم
Model provider API key	إنفاق النموذج
Onyx admin login	مجموعة المصادر كلها
Onyx API key	البحث بصلاحيات ذلك المفتاح
Onyx MCP token	اختياري، لمقارنة native endpoint في الجزء 7 فقط
Context Gateway tokens	واحد لكل دور، ويربطه الخادم من جهته. هذه هي حدود الأذونات

تعيش كلها في .env الذي يستبعده .gitignore مسبقا، باستثناء Onyx admin login الذي مكانه password manager. لا ينتمي أي منها إلى ملف تلتزم به، أو موجه تلصقه، أو terminal output تصوره لزميل.

قل لوكيلك صراحة: اقرأ credentials من البيئة، ولا تكتبها في ملف سنلتزم به، ولا تطبعها. ثم افحص diff قبل الموافقة.

التكلفة قبل البداية. لا شيء إن أنجزت الدورة السابقة.

الشيء	التكلفة
Onyx Community Edition	مجاني، MIT core
Neon	free tier، بلا بطاقة ائتمان
Model provider	free tier يكفي للدورة

الوقت المطلوب. الجزآن 1 و2 نحو ساعتين قراءة وساعتين أو ثلاث على لوحة المفاتيح. تثبيت المفهوم 4 يستغرق عشرين دقيقة انتظار، معظمها لسحب الصور. بناء Northstar في الجزء 5 يوم طويل، وأكثر إن كان أول خادم MCP لك. لا تحاول إنجازه كله في جلسة. قسم جيد: Onyx والموصلات أولا، ثم السجل المحكوم وخادما MCP، ثم البوابة وRouter. كل واحد درس مستقل، وحشر الثلاثة في مساء واحد هو ما يجعل الناس يظنون أنهم سيئون في هذا.

تحتاج على الجهاز إلى ثلاثة أشياء غير المجلد: Docker لأن Onyx يعمل كمجموعة containers، وuv لجانب Python، ووكيلك. افتحه داخل المجلد:

cd context-layer-base
claude

cd context-layer-base
opencode

تحذير واحد قبل البدء، لأنه يحدد أين تشغل هذا.

Onyx بنية تحتية حقيقية. يطلق نشر Standard نحو اثنتي عشرة container معا: web frontend، وAPI backend، وnginx proxy، وPostgres، وفهرس البحث، وRedis، وobject storage، وخادمي model، أحدهما للفهرسة والآخر للاستدلال، وcode interpreter، وعمال sync في الخلفية.

يحتاج ذلك عدة gigabytes من RAM، ولا يرتاح على laptop متواضع مع كل ما فتحته. لذلك لديك ثلاث طرق، بترتيب الأفضل للفصل:

الطريقة	الأنسب	التكلفة
Lab instance مشترك تديره المؤسسة	cohort كامل يتصل بOnyx واحد متاح للجميع	جهاز واحد مرة واحدة
نشر محلي محدود، موصل واحد فقط	أسبوع رؤية التفاصيل الداخلية وقراءة الشفرة	RAM جهازك
Onyx Cloud trial	أسبوع cohort واحد، أو laptop لا يشغله	تجربة 14 يوما بلا بطاقة

نفذ أسبوع التفاصيل الداخلية محليا حتى إن استخدمت lab instance للبقية. قراءة شفرة موصل أثناء sync درس لا تقدمه خدمة مستضافة.

---

الجزء 1: الأسس

ببساطة

قبل تثبيت أي شيء، أربع أفكار.

كان مخزنك الأخير صغيرا وآمنا لأنك تحكمت في كل ما فيه. مصادر الشركة ليست كذلك. تأتي في أربع فئات، وخلطها أغلى خطأ في هذا البناء. Onyx هو الأداة التي ستستخدمها؛ تجيد العثور على الأشياء ولا تجيد تقرير ما هو صحيح. ولOnyx طريقتا تثبيت، إحداهما تعطل بصمت الأجزاء التي تتناولها الدورة.

1. قفزة النطاق: من مخزن واحد إلى مصادر الجميع

احتفظ بسؤال Northstar في ذهنك؛ فهو سؤال لم يكن بناءك السابق قادرا حتى على لمسه.

هل يمكن أن تحصل Northstar على خصم عشرين في المئة، وتصدر لها الفاتورة الآن، ويثبت إيرادها هذا الربع؟

لا يعرف مخزن Postgres عندك ما Northstar. ولا يعرف من وافق على ماذا، أو متى وصل القبول، أو ما قاله مدير مبيعات في بريد الثلاثاء الماضي. ليس هذا نقصا في بنائك، بل نوع مختلف من الأنظمة.

كان لمخزنك أربع خصائص ربما لم تلاحظها لأنك لم تضطر إلى التفكير فيها.

كتبت كل ما فيه. جاء كل مستند من مجلد docs/، ولم يصل شيء لم تضعه. كان له قارئ واحد. ما سمح به تطبيقك سمح به المخزن. كان له نوع واحد من الحقيقة. كل ما فيه مستند كتبته، وله الوزن نفسه. لم يكن فيه رصيد حي ولا التزام موقع ولا رأي شخص في بريد، ولم تستبدل شيئا فيه نسخة أحدث لم ترها. وكان حاليا بحكم البناء لأن عاملك وحده يكتب فيه.

تختفي الخصائص كلها لحظة توصيل شركة.

المحتوى لهم الآن، وبعضه خاطئ وبعضه مستبدل. يسأل junior في سنته الأولى وpartner السؤال نفسه ويجب أن يتلقيا إجابتين مختلفتين. تحمل المجموعة عقدا موقعا ومذكرة سياسة ورسالة محادثة وحالة فاتورة حية، ولها أوزان مختلفة جذريا. والمستند الذي فهرسته الثلاثاء ربما استبدله الأربعاء شخص لن يخبرك.

تجسد Northstar الأربعة. العقد وCRM لهما. ويجب أن يتلقى account executive وVP إجابتين مختلفتين عن الخصم. للعقد الموقع ومذكرة السياسة والبريد وحالة الموافقة الحية أوزان متباينة. وقد تتغير حالة الموافقة بينما يصوغ العامل إجابته.

هذه هي قفزة النطاق، ولهذا يأخذ البناء شكلا مختلفا.

كانت الدورة السابقة مشكلة استرجاع. هذه مشكلة حوكمة ترتدي ثياب مشكلة استرجاع.

مهمتك كما هي: توجه الوكيل وتحكم على ما ينتجه. لكن معيار الحكم يتغير. لم تعد تسأل أساسا: هل وجد المقطع الصحيح؟ بل: هل يذكر كل عنصر مصدره، وهل يجوز لهذا القارئ رؤيته، وهل أكد شيء أنه ما زال ساريا؟

2. أربع فئات من المصادر، ولماذا تصل بطرق مختلفة

أغلى خطأ في هذا البناء أن تعامل كل نظام متصل ككومة واحدة بلا تمييز. صنفها إلى أربع فئات قبل توصيل أي شيء، لأن الفئة تحدد طريقة جلب المحتوى وما يجوز للعامل فعله به.

الفئة	أمثلة	كيف تصل	هل يجوز للعامل الاستشهاد بها؟
نظام سجل Agent Factory	المنهج والمعايير المشتركة	مفهرس عبر الويب للاكتشاف، ويستشهد بالصفحة الأصلية	نعم، بوصفه المنهج المشترك
أنظمة السجل الرأسية	قواعد Northstar للمبيعات والمحاسبة داخل سجل Neon	تفهرس للاكتشاف، ثم تؤكد عبر MCP	نعم، بوصفها القاعدة الحاكمة
سجلات العميل التشغيلية	ERP وCRM وledger ونظام العقود	استعلام typed حي، ولا تفهرس أبدا	نعم لحالتها الخاصة مع طابع زمني
سياق عمل العميل	البريد والمحادثات والملفات ومتتبعات المشاريع	فهرسة تراعي الأذونات	بوصفه دليلا على ما قيل أو فعل، لا بوصفه القاعدة

احتفظ بأمرين من الجدول.

الفئات الثلاث الأولى كلها ذات سلطة، لكن على أسئلة مختلفة. تقول عبارة شائعة لدى الموردين إن السجل التقليدي «يخزن البيانات فقط» بينما تفسرها طبقة السياق. لا تكرر ذلك أمام مدير مالي. يفرض ERP سلامة المعاملة وحدود الموافقة ومسار التدقيق، وهذه الضوابط هي ما يسمح للشركة بالعمل. الفجوة في النطاق لا الجدية: السجل كامل في مجاله وصامت عن المهنة المحيطة به.

الفئة الرابعة وحدها تفتقر إلى السلطة المهنية الحاكمة. لاحظ الدقة. يخضع البريد والمحادثات غالبا لضوابط أخرى: الوصول والاحتفاظ والخصوصية وlegal holds ومتطلبات إدارة السجلات. ما ينقصهما هو سلطة حسم سؤال مهني.

وهي أيضا الفئة التي يوجه إليها الجميع أداة البحث أولا، ولهذا تنتج تجارب كثيرة إجابات طليقة بلا أساس.

في Glean

يقدم Glean موصلات أصلية للفئة الرابعة ولكثير من الثالثة، إضافة إلى Indexing API لما لا يغطيه. تعرف custom datasource وتدفع المستندات بمحتواها وmetadata وأذوناتها ثم تنشطها من admin console.

لكن Glean لا يقرر فئاتك الأربع نيابة عنك. يوسم كل datasource بفئة مثل KNOWLEDGE_HUB وEMAIL وMESSAGING وCRM وTICKETS وغيرها، إلا أن تلك الفئات تضبط الترتيب وطريقة عرض النتيجة. لا يقرر أي منها هل يجوز الاستشهاد بالمصدر بوصفه القاعدة الحاكمة. فئة كل مصدر، وبالتالي الصفة التي يجوز للعامل الاستشهاد به فيها، تبقى قرارك التصميمي. يجعلك Onyx تشعر بذلك لأنك تبني الفصل يدويا. ويتيح لك Glean تجاوزه، ولهذا تنتهي عمليات نشر كثيرة بكومة مسطحة أيضا.

الحجة الكاملة للفئات الأربع، ولماذا تملك الثلاث الأولى سلطة على أسئلة مختلفة، في السلطة محددة النطاق عبر سجلات كثيرة.

أيا كانت مهنتك، اكتب هذا الجدول لمصادرك الفعلية قبل تشغيل أول موصل. سيصبح خريطة التوجيه في المفهوم 12.

3. ما Onyx، وما ليسه

يصف Onyx نفسه بأنه محادثة ذكاء اصطناعي مفتوحة المصدر متصلة بمستنداتك وتطبيقاتك وأفرادك. تتعامل معه الدورة بوصفه التطبيق المرجعي المفتوح لنظام السياق، وهذا تأطيرنا لا تأطيرهم. يتصل بمصادر كثيرة ويحافظ على نسخ متزامنة ويبحث فيها بالمعنى والكلمات المفتاحية ويعيد إجابات مستشهدة ويعرض agents وactions. النواة مرخصة MIT ويمكن استضافتها ذاتيا حقا، وهذا سبب استخدامها هنا. تستطيع قراءة شفرة الموصل ومشاهدة sync ورؤية موضع فحص الأذونات. كما يعمل في شركات حقيقية وعلى نطاق فعلي، فما تتعلمه معروف في المقابلات.

ثلاثة أشياء ليسها، وكل منها يقابل شيئا ستبنيه بنفسك.

ليس نظام سجلك. يحتفظ Onyx بنسخ للعثور؛ ويحتفظ سجلك المحكوم بالأصول للاستشهاد. ذلك هو القانون الواحد: تحمل الطبقة السلطة ولا تملكها. إن عكست ذلك قد تكون المجموعة حديثة بينما يقتبس عامل قاعدة العام الماضي من index لم تصله رسالة الاستبدال.

ليس نظام أذونات. يرث الأذونات حيث يدعم الإصدار ذلك، ولا يفرض من نفسه شيئا عن ضوابط مهنتك. في الجزء 2 يصبح هذا جديا.

ليس الإجابة. نتيجة الاسترجاع مؤشر يقول: انظر هنا. تحويل المؤشر إلى إجابة يحتاج خطوة ثانية، والمفهوم 10 هو ذلك الاستدعاء.

وهناك شيء ليس Onyx أصلا، لكنه قد يهدم البناء أسرع من أي شيء يفعله Onyx:

النموذج ليس مصدرا أيضا

يعمل عاملك على language model، وسيجيب عن سؤال مهني من معرفته إن لم يعطه الاسترجاع شيئا. يبدو output مطابقا لإجابة grounded، ولا يظهر أي error.

لا يملك النموذج مصدرا بل weights. لا توجد خلف إجابته register row: لا ناشر ولا authority class ولا jurisdiction ولا version ولا effective period ولا طريقة لتصحيح عبارة داخله. المعقولية ليست provenance.

راقب ثلاثة تسربات هادئة أثناء البناء:

• ملء الفجوة. لا يعيد الاسترجاع شيئا مفيدا فيجيب النموذج مع ذلك.
• إعادة الصياغة المنحرفة. يسترجع القاعدة الصحيحة ثم يعيد صياغتها ويفقد threshold أو شرطا.
• الذاكرة الدائمة. النموذج الذي يحمل حقائق بين الجلسات صار مخزنا بلا version ولا owner.

العلاج بنيوي لا prompt. نقص الدليل حقل داخل الحزمة، والعامل الذي لا يجد مصدره الحاكم يصعد الأمر بدلا من المتابعة. الحجة الكاملة في صفحة المفهوم.

يكتمل عندما: تستطيع تسمية ما يعالج كل واحد من الثلاثة من دون نظر: أيها يصلحه confirmation call، وأيها تصلحه permission gate، وأيها يفسر بقاء سجل Neon خارج index.

Onyx هو ما ستبنيه، وGlean هو ما ستسأل عنه

Glean أشهر نظام سياق تجاري، ويستحق ساعة من انتباهك رغم أنك لن تنشره هنا.

سببان. أولا، نشر Glean تعبير system of context في سوق الذكاء الاصطناعي المؤسسي الحالي بوصفه اسم طبقة بياناته. يتبنى الكتاب التعبير عمدا كي يدخل الخريج مكتب المشتري بلغة يعرفها. أما هل اخترعه Glean فمسألة أخرى لا تستحق الادعاء. ثانيا، هو المكان الذي وضع فيه السوق سعرا لهذه الطبقة. قد تطلب شركة «enterprise AI search» أو «work assistant» أو «AI knowledge layer» أو «enterprise context platform». كلها تعني هذه الفئة، ومن أمامك رأى غالبا Glean demo.

لذلك اقرأ product pages بوصفها diagnostic لا doctrine. اسأل سؤالا واحدا:

أي أجزاء من architecture هذه الدورة ينفذها المنتج فعلا، وأي أجزاء يتركها لك بهدوء؟

طبق السؤال على connector list وpermission model وcitation format وaction surface. ستجد الفئات الأربع ومشكلة الأذونات وفجوة discovery مقابل confirmation التي ستبني حولها.

وعادة أثناء القراءة: أعيدت تسمية الفئة مرارا وبأسماء متزامنة من محللين مختلفين: insight engines وcognitive search وenterprise AI search وgenerative AI knowledge management. تعلم الطبقة لا الشعار. أسئلة البداية الثلاثة تعيش بعد كل اسم منتج، وهي أداة حكمك على السوق عند التخرج.

لهذا تنتهي معظم المفاهيم التالية بملاحظة في Glean: كيف تظهر الفكرة في المنتج التجاري، والأهم ما يفعله Glean عنك وما يبقى عملك التصميمي في الحالتين. لا يتوقع منك حساب Glean، بل أن تدخل اجتماعا وتشرح المشترك والاختلاف.

لماذا Onyx لا Glean؟

للإجابة الصريحة ثلاثة أسباب، واحد فقط منها عن المنتجين.

أولا، لا تتعلم control بقراءة أن المنتج يملكه. Permission model في Glean أفضل مما ستبنيه في المفهوم 9، لكنه غير مرئي. تعده فيعمل، وتنهي الأسبوع وأنت تعرف أن permissions حدثت من دون فهم ما يحدث إن لم تحدث. بناء المسار مرة، بصورة ناقصة، مع role لا يحصل على شيء، يعلم أكثر من إعداد مسار جيد عشر مرات.

ثانيا، الصندوق المغلق لا يعلم architecture. كل مفهوم هنا شيء يمكنك رؤيته في Onyx: قراءة connector code، ومشاهدة chunker يحذف اثني عشر control، وتوجيه البحث إلى branch قديم ورؤية جواب خاطئ يصل باستشهادات مثالية. لا يظهر ذلك في product page.

ثالثا، وهذه النقطة التي يفوتها الطلاب: معظم الدورة ليس عن المنتج أصلا. انظر إلى العمود الذهبي. سبعة أمور تبنيها لا يقررها Onyx ولا Glean، لأنها أحكام مهنية لا platform features: فئة المصدر، والسجل الحاكم، وهل القاعدة سارية، وماذا تفعل عند التعارض. ستعلم دورة مبنية على Glean الأمور السبعة نفسها، لكن برؤية أقل للثلاثة الواقعة تحتها.

ومتى ينبغي للعميل استخدام Glean؟

كثيرا. قل ذلك بوضوح، لأن خلافه يفقدك ثقة العميل في أول اجتماع.

إن احتاجت شركة permission inheritance عبر اثني عشر SaaS system في الربع القادم، فالشراء أفضل بكثير من البناء. وإن لم يكن لديها platform team فالاستضافة أفضل من self-hosting. وإن اشترت Glean فعلا فعملك ليس اقتراح migration. عملك توصيل سجلها المحكوم به وإخبارها أي أسئلة من الثلاثة يجيب عنها الإعداد الحالي فعلا. هذه محادثة أولى أفضل من rebuild، ولا يستطيعها إلا من يفهم الطبقة.

إذن قاعدة الدورة كلها:

نعلمك المنتج الذي تستطيع فتحه. وستنشر المنتج الذي اشتراه العميل بالفعل. Architecture واحدة في الحالتين، وهي الجزء الوحيد الذي تملكه.

4. ثبت Standard لا Lite

يقدم Onyx وضعي نشر: Lite وStandard، واختيار الخطأ يكلف يوما.

Lite واجهة chat صغيرة تعطل vector index وعمال connector في الخلفية والبنية التي جاءت الدورة لتعليمها. اختر Standard.

ينشر installer عبر Docker Compose ويسألك عن الوضع. يتغير script الدقيق، لذلك اطلب من وكيلك قراءة documentation الحالية بدلا من التخمين:

اقرأ صفحتي Onyx Quickstart وResourcing الرسميتين الحاليتين. قارن CPU وRAM والمساحة الحرة لDocker على هذا الجهاز بمتطلباتهما. ثبت أحدث Onyx Community Edition مستقر في وضع Standard ومربوطا بlocalhost لهذه الدورة. سجل version وطريقة التثبيت وports ومكان البيانات الدائمة بدقة في README.md. لا تختر Lite. اعرض الخطة وفحص الموارد قبل تشغيل أي container.

لا توافق حتى تقول الخطة Standard وتحدد مكان البيانات الدائمة. وبعد التشغيل:

افحص containers وlogs العاملة في Onyx. اذكر الخدمات السليمة وport واجهة UI وأي errors متكررة. لا تعد تشغيل أو إنشاء شيء قبل شرح السبب وعرض command الدقيق.

فشل الموارد يبدو فشل software

عندما لا تمنح Docker ذاكرة كافية، تعيد خدمات البحث والفهرسة في Onyx Standard التشغيل أو تتوقف أو تفشل health checks، وتبدو الأعراض كأنها config bug.

لا تقض ساعة في debugging config على جهاز منح Docker أربعة GB.

لlocal lab، الحد الأدنى المفيد لوضع Standard هو 4 virtual CPUs و10 GB RAM. وثمانية CPUs و16 GB مريحة. أكد الموارد أولا، دائما.

اقرأ الخطة. طلب container list ليس trivia. ينبغي أن تنهي الخطة قادرا على تسمية ثلاث containers: vector index الذي يلتهم الذاكرة، وmodel server البطيء في أول تشغيل، وعمال sync في الخلفية حيث يختبئ connector الذي يفشل بصمت. هذه الثلاثة ستفاجئك لاحقا.

راقب: يسحب أول تشغيل عدة gigabytes من images ويحتاج model server دقائق ليصبح ready. هذا متوقع لا hang. إن اشتغل stack لكن search لم يعد شيئا، فالسبب غالبا أن أول sync لم يكتمل، لا أن النظام مكسور. وإن أعادت container التشغيل في loop، افحص الذاكرة قبل config.

يكتمل عندما: تفتح web interface وتسجل الدخول كأول admin user وتعرف command الواحد الذي يهدم stack ويستعيد disk.

في Glean

لا يوجد install تنفذه. يعمل Glean خدمة مدارة، إما على بنيته أو كنشر single-tenant داخل حساب GCP أو AWS، وحتى في الحالة الثانية ينشره Glean ويرقعه. لذلك يختفي المفهوم كله، ومعه container list وحساب الذاكرة ومراقبة disk في الجزء 7.

هذه هي المقايضة. تشتري إزالة operations، وتشتري معها إزالة القدرة على قراءة code. من ثبت Onyx مرة يعرف تكلفة vector index وموضع فشل sync الصامت. ومن استخدم hosted product فقط لا يعرفهما وقد يصدق موردا يقول إن الأمر بسيط.

نموذج واحد مختار عن قصد

يفصل Onyx منصة السياق عن language model. اضبط provider قادرا واحدا في Admin Panel واجعل القائمة قصيرة: أنت هنا لتقيم طبقة السياق، لا لتقارن عشرة chat models. ثم اطلب من وكيلك كتابة governance/model-register.md، ويسجل provider وmodel والتاريخ وافتراض data processing ومن يستطيع رؤيته وسبب الاختيار، إضافة إلى حقل آخر:

اختبار الاستبدال. يحسن model أقوى tool use وصياغة الإجابة، لكنه لا يصلح connector مفقودا أو authority routing خاطئا أو operational facts قديمة أو permission boundary مكسورة. هذه إخفاقات طبقة السياق ولا يمسها model upgrade. اكتب الجملة في register حتى لا تنساها تحت الضغط.

خط أساس للبحث قبل أي tuning

علمتك الدورة السابقة آلية retrieval كي تحكم عليها. يحزم Onyx الآلية الآن. لا تبدل embedding models ولا تفعل كل experimental option مباشرة، لأن تغيير embedding model يفرض re-index كاملا وليس cosmetic toggle. ابدأ بالdefaults المستقرة وسجل في governance/search-baseline.md: Onyx version وembedding model وreranking configuration وتاريخ baseline وeval set version والسبب.

تستمر قاعدة الدورة السابقة بصيغة طبقة السياق: تقيم تغييرات retrieval ولا تعجب بها. يخفي Onyx SQL، لكنه لا يلغي الحاجة إلى evidence.

ملف القواعد

شغل /init واختصره إلى أربعة أسطر: Onyx instance المقصود؛ كل credentials في البيئة لا repo؛ لا توصل أي real customer data أثناء الدورة؛ وقاعدة صارمة تستحق الكتابة كاملة:

لا توصل مصدرا لم أوافق عليه صراحة في هذه الجلسة.

الموصل تعليمة دائمة لنسخ بيانات شخص. يستحق review مثل destructive SQL.

---

الجزء 2: مجموعة مصادرك الأولى

ببساطة

الآن توصل محتوى حقيقيا وتشاهد ما يحدث له.

تبدأ بهذا الكتاب لأنه عام ولا يحتاج إذنا. ثم تنشئ عميلا وهميا اسمه Northstar وتوصل ملفاته. تنظر بدقة إلى ما حفظه search index وما حذفه بصمت. ثم تبني أهم شيء في الدورة: فحصا يقرر ما يجوز لكل شخص العثور عليه.

سنبني شركة synthetic صغيرة: سجلين محكومين ولقطتين تشغيليتين ومجلد working-context للبريد والمحادثات. هي synthetic عن قصد، ويشرح المفهوم 8 لماذا ليس ذلك اختصارا.

5. صل المنهج المشترك، ثم العميل

ابدأ بالمصدر الذي لا يحتاج أي إذن. يزحف موصل Web في Onyx إلى الصفحات تحت base URL، ويتبع الروابط المتاحة وينظف النص ويحفظ source metadata للاستشهاد.

الحقل	القيمة
Connector type	Web
Name	AF-SOR-PUBLIC
Base URL	https://agentfactory.panaversity.org/docs/getting-started
Source class	Agent Factory System of Record
Permission basis	Public

نعم، أنت تفهرس هذا الكتاب. ذلك هو المقصود. نظام سجل Agent Factory مصدر حقيقي عام ومحكوم، وهو الفئة الوحيدة التي تستطيع توصيلها في اليوم الأول بلا سؤال إذن واحد.

ملاحظة تنطبق على كل مصدر محكوم: يساعد index العامل في إيجاد المنهج، لكن citation يجب أن يعيد فتح الصفحة الأصلية.

المقطع المفهرس عبر Web مؤشر إلى عنوان web ثابت، لا بديل عنه. هذا هو نمط find-then-confirm نفسه الذي ستبنيه فعليا في المفهوم 10.

والآن العميل. تأتي Northstar fixtures داخل base folder، لذلك تصلها بدلا من إنشائها. افتح fixtures/ واقرأ الموجود قبل توصيل شيء:

المجلد	ما يحمله
sales-sor/	ثلاث قواعد مبيعات محكومة، لكل منها stable ID وversion وeffective date. تسمح قاعدة الخصم لaccount executive حتى 15%
accounting-sor/	أربع قواعد محاسبة محكومة، بينها ملف مستبدل عمدا يقول إن الإيراد يثبت عند الفوترة لا القبول
operational/	سجلا JSON: الموافقة معلقة والقبول لم يستلم. لا يفهرسان أبدا
working-context/	ثلاث رسائل بريد ومحادثتان، تزعم إحداها موافقة finance على شيء لا يدعمه مصدر محكوم

يسرد fixtures/PLANTED.md التناقضات الأربعة المزروعة. لا تفهرس هذا الملف، وحاول ألا تقرأه بدقة قبل الجزء 5. إنه مفتاح الإجابة.

إن أردت إنشاء corpus خاص بك أو corpus ثان للاختبار، ينتج هذا prompt مثيلا:

أنشئ مجلد fixtures/ لعميل synthetic اسمه Northstar Services.

تحت fixtures/sales-sor/ أنشئ سجل مبيعات محكوما صغيرا: قاعدة discount-authority تقول إن الخصم فوق خمسة عشر في المئة يحتاج موافقة VP Sales، ومعها qualification method وproposal policy. أعط كل قاعدة stable ID وversion وeffective date في front matter.

تحت fixtures/accounting-sor/ أنشئ سجل محاسبة محكوما صغيرا: قاعدة implementation-revenue تقول إن الإيراد يثبت عند قبول العميل، ومعها مدخلان داعمان وبنفس front matter. ثم أضف ملفا مستبدلا يقول إن الإيراد يثبت عند الفوترة، بتاريخ effective أقدم ورابط superseded-by.

تحت fixtures/operational/ أنشئ سجلين JSON: opportunity يبين طلب خصم عشرين في المئة والموافقة معلقة، وعقدا يبين اكتمال التوقيع وعدم استلام القبول.

تحت fixtures/working-context/ أنشئ ثلاث رسائل بريد ومحادثتين. ينبغي أن تقول رسالة من sales manager إن "finance is fine with booking it this quarter"، وهو ادعاء لا يدعمه مصدر محكوم.

أخيرا اكتب fixtures/PLANTED.md بكل تناقض أنشأته عمدا حتى أتحقق من أن النظام وجده لاحقا. لا تفهرس ذلك الملف.

صل المجلدات كموصلات منفصلة، لا كموصل واحد:

Connector	Source class	سبب الفصل
VERTICAL-SALES-SOR	Vertical record	يحكم سلطة الخصم
VERTICAL-ACCOUNTING-SOR	Vertical record	يحكم إثبات الإيراد
CUSTOMER-WORKING-CONTEXT	Working context	دليل فقط، لا سلطة

ما تصله لا يصبح ملكك

أنت على وشك فهرسة مواد عميل. وتبقى ملكه.

رسائل Northstar ومحادثاتها وحتى قواعدها المحكومة محتوى عميل داخل instance العميل. لا تنتقل إلى السجل الرأسي المشترك الذي تحمله بين العملاء. ذلك تلوث: سينتهي سجل مهنتك حاملا مواد شركة خاصة، ولن تستطيع أخذه إلى أي مكان.

لا تتحرك المواد إلى أعلى إلا عبر قانون الترقية: يتكرر pattern عبر ثلاثة عملاء أو أكثر، وينزع تعريفه، ويمر promotion review، ثم تعيد الخبيرة كتابته بصوتها. هذه authorship لا copying.

احتفظ بالقاعدة أثناء التوصيل: يتدفق عالم العميل إلى الداخل، ولا يتدفق شيء إلى الخارج.

لاحظ ما ليس في الجدول. لا يوصل operational JSON مطلقا، بل يقدم حيا في المفهوم 11، والسبب هو ذلك المفهوم كله.

راقب: ما الذي يحمله connector لكل مستند غير النص. يرى file connector لمجلد محلي path وmodified time ولا يعرف شيئا عمن يجوز له القراءة. أما connector حقيقي إلى SharePoint أو Drive فيرى أكثر، ومنها access rules. هذا التفاوت موضوع المفهوم 8، ومواجهته هنا في folder أرخص طريقة لمواجهته.

وراقب أيضا: sync يقول complete بينما search لا يعيد شيئا، وغالبا تكون indexing ما زالت تعمل خلفه؛ انتظر وابحث ثانية. Connector يعرض error بينما search يعمل ترك محتواه القديم مكانه، وهذا فخ الجزء 7. ويحتاج تغير permission لحظة لينتشر، فقد يبقى المستند مرئيا ثوان بعد تقييده.

Document Sets: نطاق بحث لا سلم قانوني

يقول connector من أين أتى المحتوى. وDocument Set هو اسم Onyx لمجموعة مسماة من connectors، تستخدمها لتحدد المصادر التي يجوز لبحث أو Agent النظر فيها.

Document Set	ما يتضمنه	الغرض
AF Shared Method	AF-SOR-PUBLIC	Architecture وdoctrine
Sales Authority	VERTICAL-SALES-SOR	قواعد المبيعات المحكومة
Accounting Authority	VERTICAL-ACCOUNTING-SOR	قواعد المحاسبة المحكومة
Customer Working Context	CUSTOMER-WORKING-CONTEXT	دليل داعم
Northstar Cross-Domain	الأربعة كلها	corpus المختبر الكامل

تفعل ثلاثة أشياء: تجعل النطاق مرئيا؛ وتتيح لAgent البحث فقط فيما يحتاجه task؛ وتتيح الاختبار داخل domain واحد قبل الاختبار عبر domains، فتفرق routing bug من retrieval bug. تحذير واحد:

Document Set نطاق بحث لا hierarchy للسلطة. يقول ما يجوز النظر فيه، ولا يقول ما يحكم.

الذي يقول ما يحكم ملف آخر يأتي في المفهوم 12.

يكتمل عندما: تشغل بحثا محدودا بSales Authority وحده ولا تحصل على شيء عن revenue recognition. هكذا يعمل scope، وهكذا ستفرق routing bug من retrieval bug لاحقا.

6. راقب sync، وانظر ما ألقاه المجزئ

تعرف chunking من الدورة الماضية، حين كانت المقابض size وoverlap والمخاطرة recall. هنا مخاطرة ثانية وأكبر.

يحمل المدخل في السجل المحكوم اثني عشر شيئا: stable ID، وdomain، وauthority class، وjurisdiction، وversion، وeffective date، وapproval status، وapplicability conditions، وowner، وsuperseded-by link، وrequired checker، وpermission boundary.

يحفظ generic indexing pipeline الجملة:

Revenue may be recognised when control transfers.

تبقى الكلمات وتضيع الضوابط الاثنا عشر، ولا شيء في النص المسترجع يعلن غيابها.

لم يعد العامل يستطيع معرفة ستة أشياء: المعيار الحاكم، وهل ينطبق على نوع العقد، وهل هو حالي، وهل ينطبق في هذه الدولة، وهل هو سلطة أم شرح، وأي exceptions تغير الإجابة.

شاهد ذلك على corpusك:

خذ قاعدة من fixtures/accounting-sor/ لها version وeffective date في front matter. اعرض المستند الخام، ثم شكل chunk واحد منها داخل index بالضبط: نص المقطع وكل field مخزن بجانبه. حدد بدقة أي حقائق على مستوى المستند لم تبق في المقطع.

يكتمل عندما: ترفع مقطعا واحدا وتسمي حقيقة صحيحة عن parent document لا يمكن لعامل يقرأ ذلك المقطع فقط معرفتها. ليست الفجوة bug في Onyx، بل سبب confirmation step في المفهوم 10.

في Glean

تتيح Indexing API في Glean إرفاق structured metadata بالمستندات، وتحمل knowledge graph علاقات بين الناس والمحتوى والعمليات يلقيها plain chunker. لذلك الفجوة أضيق من Onyx.

الأضيق ليس مغلقا. لا يعرف أي منتج أن قاعدتك لها effective date وjurisdiction وsuperseded-by link إلا إذا وضعت تلك الحقول وعلمت العامل فحصها. الضوابط الاثنا عشر مسؤوليتك في الحالتين.

7. ابحث، ولاحظ ما عاد

ابحث في corpus عن سؤال تمتد إجابته عبر مستندين. اعرض النتائج مع scores وsources، ثم أجب السؤال نفسه عبر chat في Onyx حتى أرى citations التي يرفقها.

والآن الانضباط. اسأل ثلاثة أسئلة عن كل نتيجة بصوت مرتفع حتى تصبح reflex:

من أين أتت؟ يجيد Onyx ذلك، وcitation أمامك. تحقق أنه يشير إلى مستند تعرفه.

هل يجوز لهذا الشخص رؤيتها؟ الإجابة الصريحة الآن: الجميع يرى كل شيء، لأنك المستخدم الوحيد والمصدر folder. احتفظ بالفكرة أربع دقائق.

هل ما زالت تحكم؟ لا يستطيع Onyx إخبارك. وجد مستندا يطابق كلماتك. أما هل هو الحالي فسؤال لا تجيب عنه similarity score. جرب: ابحث عن موضوع ملف المحاسبة المستبدل القادم مع fixtures التي وصلتها في المفهوم 5، وانظر أي version يعود.

نتيجة الاسترجاع مؤشر لا إجابة. كل ما في الجزأين 3 و4 يحول المؤشرات إلى إجابات يمكنك الدفاع عنها.

كن دقيقا في العناصر التي ينطبق عليها ذلك. للمعرفة المحكومة أصل يرجع إليه، فالنتيجة مؤشر. أما working context فلا نسخة canonical لما قاله مدير الثلاثاء، والبريد المسترجع هو العنصر نفسه. وما يحفظ صدقه هما السؤالان الآخران: هل يجوز لهذا الشخص رؤيته، وهل يحمل بوصفه دليلا لا قاعدة.

يكتمل عندما: تبحث عن موضوع ملف المحاسبة المستبدل وترى أي version عاد أولا. أيا كان، تعرف الآن أن Onyx لم يختره على أساس كونه current.

8. توريث الأذونات، وأين يتوقف Community Edition

هذا أهم مفهوم في الدورة وأكثرها تخطيا، لأن تخطيه يجعل كل شيء أسهل لنحو ستة أسابيع.

تعيش access rules للمستند في نظامه الأصلي. القناة الخاصة خاصة، والمجلد المقيد مقيد. عندما تنسخ الطبقة المستند يجب أن تنسخ معه access rules وتعيد فحصها لحظة كل query للشخص المحدد. تورث الأذونات ولا تخترع. تشرح الأذونات تسبق النموذج لماذا هذه مسألة control لا privacy فقط.

إن أخطأت فقد بنيت أسوأ من leak: نظاما مفيدا في التسريب. يسأل junior سؤالا معقولا فيتلقى أولا، مع summary لطيف، compensation memo لم يكن مسموحا له فتحها. لم يهاجم أحد شيئا؛ أدت الطبقة عملها وفق القواعد الخطأ.

ما لا يستطيع Community Edition إثباته

يكفي Onyx Community Edition لتعلم connectors وindexing وretrieval وcitations وagents وactions. لكنه لا يكفي وحده لإثبات production permission fidelity عبر المستخدمين.

تسرد documentation في Onyx permission-sync connectors التي ترث user permissions من الأنظمة الخارجية، إلى جانب user groups وRBAC وgroup-based permissions، بوصفها features في Onyx Cloud وEnterprise Edition لا Community Edition المستضاف ذاتيا. وتذكر deployments التي تحتاج permission inheritance سببا للانتقال إلى Enterprise.

لذلك في lab يعتمد Community Edition فقط، يرى كل طالب corpus نفسه. لا تستطيع عرض demo يسأل فيه restricted role ويحصل بحق على nothing. أما إن استخدم cohort تجربة Onyx Cloud من جدول الإعداد فيمكنك ذلك، ويستحق أسبوعا لترى access-control sync حقيقيا ينفذ آليا العمل الذي ستبنيه يدويا.

في Glean

هذا المفهوم يتقدم فيه المنتج التجاري بوضوح، ويستحق قول ذلك بلا دفاعية.

يقرأ Glean access-control list من كل نظام متصل مع المحتوى ويفرض الأذونات الموجودة عند المصدر. إن لم تستطع فتح file في Drive أو قراءة channel في Slack، فلا يظهر في نتائجك ولا يصل إلى إجابة لك. وتعرض Indexing API النموذج نفسه لمحتواك مع أذونات per-user وper-group لكل مستند وendpoint باسم checkdocumentaccess للتحقق.

لذلك تعد هذا في Glean، وتبنيه في Onyx Community Edition، وهو المفهوم 9.

بناؤه مرة أفضل للتعلم، وشراؤه غالبا أفضل للإنتاج. معرفة أي الجملتين تنطبق على الموقف هي المهارة.

ثلاث طرق للتعامل، والأولى طريق الدورة.

افرض فحص الأذونات بنفسك عند boundary الخاصة بك. تكتب الكود فتتحكم فيه تماما. كما يعلم تنفيذ access check أكثر من إعداده. هذا المفهوم 9.

اقرأ شفرة ee/. هي source-available وإن لم تكن MIT. ادرس تطبيق ACL inheritance من مصدر حقيقي من دون نشرها.

استخدم trial أو licence لمختبر واحد. أسبوع واحد وعرض واحد، ثم عد إلى Community Edition.

تنتج قاعدة غير قابلة للتفاوض أثناء التعلم:

بيانات synthetic أو عامة أو مصرح بها للفصل فقط

حتى يجتاز deployment مجموعة permission tests في المفهوم 9، لا توصل corpus حقيقيا: لا drive صاحب العمل ولا client ولا inboxك. الطبقة التي لم تختبر للأذونات ليست نظاما ناقصا، بل نظام سريع موجه إلى القواعد الخطأ.

9. ابن البوابة بنفسك، واختبرها بدور لا يحصل على شيء

لن يقيد Community Edition المستندات لكل user، لذلك تبني gate طبقة أعلى أمام retrieval. وهو المكان الصحيح إنتاجيا أيضا: عند boundary الخاصة بك تستطيع إثبات ما حدث.

ملاحظة صريحة قبل الكتابة. أنت على وشك اختراع أذونات fixtures، وهو عكس القاعدة التي تعلمتها. هذه خاصية lab لا design. لا يحمل local folder access rules لوراثتها، لذلك يجب أن يعلنها أحد، وفي production يكون ذلك source system. Tagging هنا بديل عن inheritance لا تستطيع عرضه على 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

الترتيب غير الآمن هو ما يبدو طبيعيا: استرجع كل شيء، وأعطه للنموذج، ثم اطلب منه ألا يذكر ما لا يجوز للقارئ رؤيته.

المقطع المخفي داخل model context ليس مخفيا.

ابنها:

يأتي governance/permission-matrix.csv بصف لكل مصدر. هذا الملف تفرضه gate وتسلمه لاحقا للمراجع.

أضف access layer أمام Onyx retrieval. عرف ثلاثة أدوار لدى Northstar: account_executive وsales_manager وvp_sales. وسم كل fixture بأدنى role يجوز له قراءتها. يقرأ الثلاثة قاعدة discount-authority. ولا يقرأ pricing-approval thread ورسالة المدير "book it this quarter" إلا sales_manager فما فوق. ثم اكتب دالة search(query, role). ترشح document set المؤهلة حسب role قبل استدعاء Onyx، لا بعده. وتعيد كل result مع source وسبب السماح لذلك الدور. اعرض code path الذي يحدث فيه filtering وأثبت أن أي مستند غير مؤهل لا يصل إلى model.

ثم الاختبار الأهم من أي retrieval benchmark:

ابن permission test set: صف لكل role ولكل question، يسجل ما يجوز للدور رؤيته عند المصدر وما أعادته الطبقة وpass/fail. أضف حالة Northstar المهمة: اسأل ماذا قال sales manager عن booking هذا الربع؟ بدور account_executive، حيث الإجابة الصحيحة لا شيء إطلاقا. شغله واعرض الجدول.

يكتمل عندما: تعيد الأدوار الثلاثة ما يجوز لها بالضبط، ويحصل account_executive الذي يسأل عن رسالة المدير على nothing. الطبقة التي لا تعيد nothing لم تختبر.

لاحظ ما حماه الاختبار: بريد المدير هو hearsay الذي تدور حوله حالة Northstar. إن استطاع account executive استرجاعه فقد يقتبس رأي مديره كما لو كان finance decision.

ثم سجل شيئين: ما هو صحيح في lab اليوم، وما لا يزال production يحتاجه.

أولا governance/permission-matrix.csv، صف لكل مصدر يسجل من يقرأ وكيف يفرض الإذن وهل هو production-ready:

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، القائمة التي تسلمها لمراجع security:

# 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 بوابة مفتوحة صراحة لا افتراضا مخفيا. ذلك الفرق بين lab وliability.

لماذا هذه مسألة control لا privacy فقط

في معظم domains، failure الأذونات مشكلة privacy. وفي مهنة regulated تصل أبعد، ويجب الدقة لأن الحجة الفضفاضة خاطئة.

Segregation of duties يتعلق بمجموعات القدرة لا الرؤية: إنشاء journal entry والموافقة عليه، أو بدء transaction ومطابقته. Read access وحده ليس غالبا هذا الجمع، والقول إن context layer «تكسر segregation of duties» يفقدك النقاش مع controller.

الخطر الحقيقي أدنى بطبقة. Access control هو الأساس الذي تقوم عليه control environment. لذلك يعتبر auditors ضعف IT general controls سببا للشك في application controls فوقها. تصدق periodic access review في الشركة أن مستخدما معينا يحمل entitlements محددة، ثم تسلمه طبقتك محتوى لم تمنحه تلك entitlements. لم يسرق شيء ولم تكسر قاعدة موثقة رسميا، لكن review صار يصدق صورة غير صحيحة.

هذه هي الحجة الصحيحة والأقوى: طبقة سياق تمنح effective access خارج entitlement model لا تكسر control واحدا، بل تبطل بهدوء المراجعة التي تصدقها كلها.

---

الجزء 3: النصف المحكوم

ببساطة

يعطيك البحث مؤشرا، لا إجابة.

تضيف هنا النصف الثاني. تحصل قاعدة Neon الخاصة بك على جدول صغير محكوم للقواعد، لكل قاعدة version وdate. ثم تقدمه كأداة، فيأخذ العامل قاعدة وجدها في index ويسأل الأصل: هل ما زالت القاعدة؟ أما الأرقام الحية، مثل وصول approval، فيسأل عنها من جديد كل مرة.

10. قدم سجلك عبر MCP، ونمط الاستدعاءين

كل ما سبق كان نصف الاكتشاف المفهرس. وهو يتضمن معرفة محكومة، إذ فهرست سجلين رأسيين والكتاب. لكن كل ذلك وصل نسخة قابلة للبحث، والنسخة مؤشر.

والآن يأتي النصف الأصلي والحي، ولا يتصرف بالطريقة نفسها.

أولا، امنح السجل سلطته

يحمل مشروع Neon مستندات ومقاطع وتضمينات. لكنه لا يحمل بعد قاعدة يمكنك الاستشهاد بها أمام controller، لأن الدورة السابقة لم تحتج إلى ذلك. أضف مخططا محكوما صغيرا بجانب الموجود. هذا هو bootstrap الذي يعتمد عليه باقي الجزء:

يحمل scripts/ في base folder المخطط المطلوب؛ اقرأه قبل تشغيل prompt حتى توافق على شيء رأيته.

في مشروع Neon الموجود وعلى branch باسم dev، أنشئ schema باسم governed وجدول rule. الأعمدة: stable_id، وdomain (sales أو accounting)، وauthority_class، وjurisdiction، وversion، وeffective_from، وeffective_to، وapproval_status، وsuperseded_by، وowner، وbody. حمل قواعد Northstar للمبيعات والمحاسبة من fixtures/، ومنها قاعدة المحاسبة المستبدلة مع رابط superseded_by إلى الحالية. اعرض الصفوف قبل commit الbranch.

تسعة من هذه الأعمدة هي الضوابط الاثنا عشر من المفهوم 6، وقد أصبحت حقيقية لا موصوفة.

تعيش المهنتان كلتاهما في جدول واحد يفصلهما عمود domain. يبسط ذلك demonstration server ويجعل routing في المفهوم 12 يؤدي عملا مرئيا، لأن العامل يجب أن يختار domain قبل التأكيد.

ثم قدمه

تقول قاعدة Northstar المحاسبية إن implementation revenue يثبت عند قبول العميل. للقاعدة version وeffective date، ويوجد في fixtures ملف مستبدل يقول غير ذلك. كل ما هنا يجعل العامل يستشهد بالصحيح.

مخزنك من الدورة السابقة يعمل: Postgres صغير على Neon مع pgvector ومستنداتك وbranch باسم dev. لا يتغير شيء فيه، بل يتغير من يصل إليه.

ليس folder للزحف. لا توجه إليه connector أبدا. هو source يجب أن تسأله، كما فعلت في الجزء 6 من الدورة السابقة:

يحمل mcp/vertical_sor/ هيكل FastMCP بثلاث أدوات stub ومواضع TODO. اقرأه، ثم اطلب من وكيلك إكماله.

غلف سجلنا المحكوم المستضاف على Neon في FastMCP server اسمه vertical-sor. تأخذ كل tool حجة domain، sales أو accounting، كي يعرض server واحد المهنتين. ثلاث أدوات read-only، وانتبه إلى أن live customer state ليست منها:

• search_rules(domain, query) تعيد candidate rules مع stable IDs
• confirm_rule(domain, stable_id) تعيد current entry كاملة مع authority class وjurisdiction وversion وeffective period وapproval status وsuperseded-by link
• validate_action(domain, action) تفحص proposed action مقابل قواعد domain وتعيد approved أو refused مع blocking rule استخدم pooled Neon connection string من البيئة، واتصل بدور read-only، وقدم عبر Streamable HTTP في stateless mode، أي لا يحتفظ MCP session بين requests ويمكن لأي request أن تجاب من دون السابقة. اعرض tool list وdocstrings قبل كتابة code.

لماذا server واحد لا اثنان؟ في production قد يكون سجل كل مهنة نظاما منفصلا يملكه طرف مختلف، وdomain هو مكان الفصل. في crash course يحافظ server واحد على وضوح المسار. هناك مكان واحد فقط لتأكيد قاعدة لأي مهنة. النسخ المفهرسة في Onyx projections منه: نسخ قابلة للبحث تحفظ فقط ليجد العامل الأصل. يحتفظ كل chunk projected بstable_id وdomain وversion كي يملك confirmation call ما يبحث عنه.

تفصيلان في Neon يجب فحصهما في الخطة. يجب أن يستخدم server connection string pooled، أي host الذي يحوي -pooler، لأن context layer تفتح connections قصيرة كثيرة، وdirect endpoint لم يبن لذلك. ويجب أن يتصل بدور read-only لا role مالك الجداول، فلا تغير tool argument السجل الذي تستشهد به.

ثبت هذه surface بدلا من ترك وكيلك يتذكرها

Stateless HTTP حجة run-time في FastMCP، لا constructor. كان FastMCP("vertical-sor", stateless_http=True) صالحا في FastMCP 2.x، لكنه يثير TypeError في 3.x، والصيغة القديمة أرجح ما يستحضره model. الصيغة الحالية:

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)

يجيب server عند /mcp لا bare host، وهذا التفصيل يكلف ساعة حين لا يتصل client. اطلب من وكيلك التحقق من الاثنين في FastMCP documentation الحالية قبل الموافقة على الخطة.

واحتفظ بعادة branch. عندما تغير schema السجل في الدورة، افعل ذلك على Neon branch وعاينه كما سبق. والbranch أرخص طريقة لعرض stale copy أدناه: fork السجل، ودع fork يصبح قديما عمدا، ووجه discovery إليه، ثم ارم branch.

انظر إلى tool list. search_rules وconfirm_rule استدعاءان حيث يصمم الساذج واحدا، والفصل هو الفكرة.

يسأل discovery: أين قد توجد معلومة ذات صلة؟ يحسن recall وsimilarity وspeed، وoutput مؤشر.

يسأل confirmation: أي مصدر رسمي ينطبق على القرار؟ يفحص domain وauthority class وjurisdiction وversion وeffective date وapproval status، وoutput إجابة.

إذن التسلسل ثابت ولا يعكس:

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

يجوز فهرسة الصفحات المحكومة للاكتشاف، وهو مفيد. الطالب الذي لا يجد القاعدة أسوأ ممن يجد نسخة. الممنوع هو الاعتماد على النسخة. المبدأ في الاكتشاف ليس تأكيدا.

صل الاستدعاءين. اكتب governing_rule(question) يستدعي search_rules، ويأخذ stable ID لأول candidate، ثم يستدعي confirm_rule ويعيد entry المؤكدة. إن كانت مستبدلة يتبع link ويؤكد successor. ثم اعرض failure الذي يمنعه باستخدام القاعدة التي تعتمد عليها الحالة: أنشئ Neon branch لسجلنا، وغير implementation-revenue rule على default branch من acceptance إلى billing كي يصبح branch قديما، ووجه search_rules إلى branch القديم مع بقاء confirm_rule على الحالي، واسأل متى يثبت إيراد Northstar. اعرض الإجابتين جنبا إلى جنب، ثم احذف branch.

يكتمل عندما: تشاهد branch القديم يجيب بثقة عند الفوترة، ويصححه confirmation call إلى عند القبول.

تسمح إحدى الإجابتين لNorthstar بإثبات الإيراد هذا الربع ولا تسمح الأخرى، وهذا الفرق سبب الدورة. ذلك العرض أثمن شيء فيها.

في Glean

هنا لا ينجز المنتج العمل نيابة عنك، وهذه أهم ملاحظة في الصفحة.

يفهرس Glean ويسترجع بصورة ممتازة ويحمل currency signal واحدا: يستطيع owner تأكيد page فتظهر badge بمن أكدها ومتى، ويمكن deprecate الصفحة الميتة. هذا تذكير بشري ملحق بمستند، لا authority classes وjurisdictions وeffective periods وsupersession links لمهنتك، لأنها خصائص سجلك المحكوم لا منصة بحث. لذلك قد يعيد Glean القاعدة المستبدلة باستشهادات مثالية وpermissions صحيحة وbadge خضراء، ويكون مخطئا.

Confirmation call مسؤوليتك في المنتجين. تستطيع Glean Agents الوصول إلى confirm_rule عبر remote MCP server كما يستطيع Onyx Agent، وإن كان المسار وقت الكتابة beta وداخل plan-and-execute step. ولا يتغير شيء في design.

11. تسأل عن الحالة الحية كل مرة

الأرصدة وحالة الموافقة والعناصر المفتوحة والversions الحالية: لم يؤلفها أحد وليست مستقرة لكنها دقيقة. إن فهرستها صنعت نسخة تقريبية تشيخ من الشيء الذي تكمن قيمته كلها في حداثته.

القاعدة جملة واحدة، وتستحق مكانا في design record لكل engagement:

إن كانت قيمة قديمة قد تغير النتيجة أو الإذن أو payment أو filing أو customer action، فاجلبها حية.

هذه أنماط الاسترجاع الثلاثة، خلاصة مبدأ الطبقة:

المعلومة	طريقة الوصول
Working context	Permission-aware indexing
Governed knowledge	Discovery index، ثم تأكيدها قبل الاعتماد
Current records and actions	Live typed query عبر MCP أو API

افهرس سياق العمل. اكتشف المعرفة المحكومة. استعلم عن الحقيقة الحالية حية.

قد يحتاج source واحد إلى نمطين. يفهرس contract document كي تجد clauses، ثم يستعلم من contract system حيا لتأكيد أن version التي وجدتها ما زالت active.

لا يقرر format ولا length شيئا. Freshness risk يقرر كل شيء.

في Glean

يستطيع Glean جلب fresh data وقت query لبعض الأنظمة بدلا من الاعتماد على النسخة المفهرسة فقط، فيغطي جزءا آليا.

لكن الجزء ليس الكل. أي fields ذات freshness حرجة في مهنتك حكم لا منصة تقرره، وهو ما كتبته في design record. تنتقل قاعدة القرار معك بين المنتجات.

قدم سجلي Northstar التشغيليين عبر server باسم customer-state منفصل عن vertical-sor: يعيد get_opportunity approval status ويعيد get_contract_state acceptance status. الفصل يجعل الفئات الأربع مادية، فالسجل الرأسي يحكم القواعد والسجل التشغيلي يملك الحالة. ثم اسأل هل يجوز إثبات الإيراد؟ مرتين: مرة من indexed snapshot ومرة من live call، وبدل acceptance من not-received إلى received بينهما. اعرض الإجابتين مع timestamps.

يكتمل عندما: تختلف الإجابة المفهرسة والحية، وتشرح بدقة أيهما تضع أمام controller.

---

الجزء 4: التوجيه والاستشهاد

ببساطة

سؤال واحد من العميل يخفي غالبا أسئلة مهنية كثيرة.

يعلم هذا الجزء العامل تفكيكها وإرسال كل منها إلى السجل الحاكم ووسم كل ما يعود. ويعلم أصعب عادة: عندما تختلف مصادر اعرض الاثنين، ولا تمهدهما في جملة مريحة واحدة.

12. توجيه السلطة: أي سجل يحكم السؤال

يسأل العمل المهني أنواعا كثيرة: ما القرار، وما action المسموح، وما checker المطبق، وما evidence الناقص. لكن لأجل تجميع السياق تختزل معظم طلبات الدليل إلى ثلاث صور، لكل منها مسار.

السؤال	المصدر	المسار	ما يعود
ما القاعدة؟	System of Record	Discovery ثم confirmation	حقيقة محكومة مع class وjurisdiction وversion
ما الرقم؟	النظام المالك له	Typed query	قيمة حالية دقيقة مع timestamp
ماذا قيل عن الحالة؟	Working context	Permission-aware retrieval	دليل، لا القاعدة الحاكمة

العامل الذي لا يميز نوع السؤال يجيب عن الثلاثة بالطريقة نفسها، ويبتلع المسار الثالث الأولين بهدوء.

تسبقها خطوة أخرى حين يشغل العميل أكثر من governed record. قد تملك firm متوسطة accounting record وsales record وHR record بناها ثلاثة أشخاص مختلفين ولا تملك أيا منها. لذلك يحل routing أولا أي مهنة تملك السؤال، ثم source داخلها. سؤال إثبات revenue محاسبي حتى إن جاءت كلماته من sales conversation.

اكتب الخريطة قبل prompt

يجب ألا يخترع model المصدر الحاكم من chunk الذي تصدر الترتيب. Routing table artifact له version تكتبه وتراجعه وتحفظه أولا. يأتي governance/authority-map.yaml في base folder والroutes فارغة. املأه:

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

كل اسم فيه اسم أنشأته: connectors من المفهوم 5، وtools من المفهومين 10 و11. هذا مقصود. Routing map لا تحل sources فيه إلى شيء يستطيع النظام callه رسم لا router.

الملف بسيط لأن عمله بسيط: يحول سؤال شركة مبهما إلى قرارات مهنية مسماة، ولكل قرار مصدر حاكم مسمى. قد تعيش الخريطة إنتاجيا في governed registry أو Vertical SoR. تستخدم الدورة YAML ليكون القرار inspectable وversioned من أول ساعة.

ابن دالة route(question) تقرأ governance/authority-map.yaml، وتصنف السؤال إلى قراراته المهنية وتسمي governing source وcurrent-state source لكل واحد. أعد routing decision كstructured data مع السبب ولا تستدع tool مباشرة. ثم شغلها على سؤال Northstar واعرض routing table حتى أراجع reasoning لا الإجابات فقط.

راقب: إعادة القرار بدلا من العمل فورا هي ما تجعل الأمر reviewable. Router لا ينتج إلا answers لا يمكن auditه.

يكتمل عندما: ينتج سؤال Northstar قرارين routed على الأقل، sales وaccounting، ويسمي كل منهما governing source قبل retrieval.

13. Provenance وغلاف الاستشهاد

يحمل كل عنصر مادي تعيده الطبقة غلافا: labels تسافر مع النص وتقول من أين أتى وهل يجوز الاعتماد عليه. من دونه الحزمة كومة نص، ومعه تصبح evidence قابلة للمراجعة.

الحقل	أهميته
Source system	يحدد مالك المعلومة
Stable ID	يتيح للمراجع جلب العنصر نفسه ثانية
Authority class	قانون أو معيار أو عقد أو سياسة أو معاملة أو إرشاد أو رسالة أو مثال
Scope	السؤال والعميل وjurisdiction والحالة التي يحكمها
Version and effective period	يمنع القواعد المتقاعدة من العودة بصمت
Retrieved or synchronised at	يبين حداثة العنصر
Permission basis	يبين سبب السماح للقارئ باستلامه

والقاعدة التي تحفظ صدق الإجابة الطليقة:

يجوز للعامل قراءة supporting context مسموح ومرتبط بالمهمة، ولا يجوز له عرضه كقاعدة تحكم الإجابة.

يجوز الاستشهاد بالبريد دليلا أن العميل طلب شيئا، وبworking paper سابق دليلا على معالجة الشركة العام الماضي. ولا يصبح أيهما requirement.

الحزمة output contract

Onyx Agent مساعد معد: instructions لسلوكه، وknowledge يجوز بحثها، وActions أي tools يستدعيها. أنشئ واحدا اسمه Northstar Context Router.

والآن الجزء السهل الخطأ الذي قد يلغي المفهوم 9 بصمت.

لا تلحق Document Set بالAgent

الخطوة الواضحة إلحاق Northstar Cross-Domain مباشرة بالAgent، وهي تعمل فورا. لكنها تنشئ مساري retrieval أحدهما يلتف حول gate:

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

تصبح knowledge الملحقة بالAgent نطاق بحثه. إن ألحقت cross-domain set استطاع قراءة كل ما فيها لأي شخص، مهما قالت gate.

لذلك لا تلحق بالRouter أي role-sensitive knowledge. يحصل على Actions فقط.

أعطه خمسة Actions بالضبط ولا غير:

Action	ما يفعله
search_permitted_context(query)	بوابتك. تحل role من credential وتحصر Document Sets أو tags المسموحة ثم تستدعي Onyx search
confirm_rule(domain, stable_id)	Confirmation الأصلية من vertical-sor
get_opportunity(id)	حالة opportunity الحية مع timestamp من customer-state
get_contract_state(id)	حالة contract الحية مع timestamp من server نفسه
validate_action(domain, action)	يفحص proposal مقابل القواعد الحاكمة

ابن Action باسم search_permitted_context يغلف Onyx search API. يقرأ role من credential المهيأ معه، لا من tool argument، ويشتق permitted Document Sets وtags، ويطبقها كsearch filters، ثم يصدر query. أعد results مع سبب السماح بكل منها. ثم أنشئ Northstar Context Router بلا Document Set ملحقة، وإنما هذا Action وأربع MCP tools.

مكان مقارنة roles مهم. يحمل Action credential واحدا معدا وبالتالي role واحدا، فلا يستطيع Router واحد سؤال الشيء نفسه كشخصين. هذه خاصية wiring لا gap في design. لذلك أثبت gate عند gateway حيث تحل identity فعلا:

اسأل gateway عن شيء لا يراه إلا vp_sales مرة بtoken vp_sales ومرة بtoken account_executive واعرض النتيجتين. ثم اعرض Router يجيب السؤال عبر Action واذكر role الذي يتكلم باسمه وكيف عرفت.

القاعدة تحت ذلك جملة واحدة:

يمر كل indexed retrieval عبر gateway. إن استطاع component البحث من دونها فالgate زينة.

في Glean

يعمل Glean agent افتراضيا بهوية user الذي استدعاه، فلا يرى ويفعل إلا ما يراه ويفعله ذلك user، ولا ينشأ bypass نفسه. كما يقدم agent identity يشغل agent على scoped service credentials يمنحها admin بدلا من استعارة user. لاحظ الاتجاه: يضيق reach لعامل unattended إلى ما حدده admin، ولا يوسعه.

يبقى شيئان لك: output contract ذو سبعة أقسام لأن الشكل الثابت قرار design لا يفرضه منتج، وauthority routing لأن تقرير أن revenue question محاسبي لا sales معرفة مهنية لا platform feature.

أعط Router instruction file في prompts/context-router.md ينتهي بهذا الشكل الثابت:

Return exactly these sections:

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

الأقسام السبعة هي context packet، والشكل الثابت يفعل أكثر مما يبدو.

لا يملك Onyx database object اسمه Context Packet. تنفذه output contract مستقرا لمهمة واحدة. وبثبات الشكل تحدث ثلاثة أمور: يراجع أي شخص الإجابة في ثوان؛ يستطيع eval harness فحص كل section؛ ويظهر section الناقص بدلا من غيابه بصمت. فراغ Conflicts and gaps يعني أن router فحص ولم يجد. غياب heading يعني أنه لم ينظر.

والحزمة مؤقتة عمدا. قد تتحرك current facts وتتغير permissions وتستبدل applicable version، لذلك يعاد بناؤها كل مرة ولا تخزن cache.

ابن assembler خلف contract. لسؤال routed، اجمع confirmed rules وlive values وpermitted supporting context، واملأ كل section بعناصر لها envelope كاملة مع فصل governed truth بصريا عن evidence. اعرض الإجابة مرتين: structured object ثم prose يقرأه الإنسان.

يكتمل عندما: تظهر كل heading حتى إن كان محتواها فارغا، وتستطيع تتبع claim إلى source وversion وpermission basis.

الضغط هو مكان موت provenance

يعمل assembler ضمن budget لأن context windows محدودة وكل token في رسالة stale ليس في governing rule. selection وcompression عمل مشروع، لكنه مكان كسر provenance غالبا. Compression يسقط version stamp أو يدمج مصدرين في جملة أو يحذف authority class لم يوفر tokens، بل حول evidence إلى text.

اضغط prose ولا تضغط provenance أبدا.

14. التعارض نتيجة لا فشل استرجاع

هذا ما يفصل System of Context عن أداة بحث جيدة. لا رأي لأداة البحث في الخلاف، ويجب أن يكون للنظام المهني رأي.

تذكر inconsistencies المزروعة في fixtures من المفهوم 5، وابحث عنها.

للتعارض ثلاث نتائج بالضبط:

• يحل بالنطاق. تجيب المصادر أسئلة مختلفة، وكلاهما صحيح في نطاقه. تقول sales إن deal أغلق في يونيو، وتقول accounting إن revenue لا يثبت حتى acceptance، ولا يخطئ أحدهما.
• يحل بالسلطة. يحكم source منطبق، ويحدد hierarchy أيه.
• غير محلول. يصعد العامل، مع evidence المتعارضة منظمة.

الممنوع هو النتيجة الرابعة التي يفعلها summariser عادي افتراضيا: دمج المصادر في جملة ناعمة لم يقلها أي source.

أضف conflict detection إلى assembler. عندما يختلف عنصران retrieved في نقطة مادية، لا تلخص عبرهما. افصلهما مع envelopes، وقرر هل يحل التعارض بالنطاق أو السلطة، وإن لم يحل فأنتج escalation يسمي المصادر وما يقوله كل منها وauthority test وما بقي مفتوحا. شغله على inconsistencies في fixtures/PLANTED.md واعرض ما إذا أمسك بكل منها.

يكتمل عندما: يجد النظام superseded memo وchat message المتناقضة وحده، ويقرأ escalation كشيء ترسله إلى partner بلا تعديل.

لا يجعل الخلاف يختفي، بل يجعله قابلا للمراجعة.

في Glean

لا يطبق Onyx ولا Glean authority map المهنية أو conflict rules آليا. يعيد retrieval المقاطع المطابقة، أما هل تتناقض وأيها يحكم فحكم مهني في authority map وتعليمات router.

وقد يجعل retrieval engine الأقوى ملاحظة ذلك أصعب لأنه يعطي جوابا أنعم وأكثر ثقة فوق الخلاف نفسه.

النتائج الثلاث وسبب تقديم يحل بالنطاق في التعارض نتيجة لا فشل استرجاع.

15. اعمل وسجل: إغلاق الحلقة

العثور ليس الفعل، وبينهما خمس وظائف.

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

يسقط الجميع الخطوة الثالثة.

يفحص discount approval مقابل sales record قبل أن يكتبه CRM. ويفحص journal entry مقابل accounting record قبل أن يمسك ERP draft.

السجل الحاكم ليس مكان قراءة rule فقط، بل مكان فحص proposed action مقابلها. ذلك الفحص يجعل rule حقيقية لا advisory.

قاعدتان مطلقتان:

يجب ألا تصبح context layer transaction system ثانيا، ولا طريقا للكتابة حول governed record.

Read وrecommend وprepare وexecute منح منفصلة. قد يكون العامل ممتازا في retrieval ولا يملك execution authority. Access ليس permission.

صل tool validate_action(domain, action) في Router بمسار recommendation. تأخذ proposed action وتفحصه مقابل قواعد domain في governed record وتعيد approved draft أو refusal يسمي blocking rule. يجب ألا تنفذ. ثم اعرض حالة كان retrieval فيها صحيحا وreasoning صحيحا لكن action رفض.

في Glean

يدعم Glean actions مع human-in-the-loop checkpoints، فيحتاج step approval قبل التنفيذ، وتحترم actions أذونات user.

يغطي ذلك نصف approval لا نصف validation: فحص proposed action مقابل قواعد المهنة قبل طلب الموافقة. validate_action لك في المنتجين لأن سجلك المحكوم وحده يحمل rule.

يكتمل عندما: ترفض sales record توصية الخصم وفق approval rule، ويسمي refusal القاعدة بدلا من قول إن model غير متأكد.

---

الجزء 5: حالة Northstar من البداية إلى النهاية

ببساطة

الآن تبني النظام كله بالترتيب ثم تكسره عمدا.

الكسر ليس تمرينا إضافيا. النظام الذي يفشل بصوت مرتفع آمن. والذي يفشل بصمت بإجابة خاطئة طليقة وواثقة خطر. يريك الجزء شكل failure الهادئ كي تعرفه لاحقا.

هذه الدورة كلها في بناء واحد: من instance فارغ إلى إجابة مستشهدة ومرفوضة على نحو صحيح.

الحالة. طلب account executive خصما عشرين في المئة. يقول CRM إن approval معلقة. يسمح العقد الموقع بالفوترة عند التوقيع. يثبت Accounting SoR implementation revenue عند قبول العميل. يقول operational contract record إن acceptance لم يصل. وتقول رسالة sales manager إن finance موافق على إثباته هذا الربع.

السؤال.

هل يمكن أن تحصل Northstar على خصم عشرين في المئة، وتصدر لها الفاتورة الآن، ويثبت implementation revenue هذا الربع؟

الخطوة 1. خطط. ادخل plan mode بنموذج قوي:

ابن طبقة سياق Northstar كاملة: Onyx Standard مع فئات المصادر الأربع متصلة ومنفصلة، وschema باسم governed في مشروع Neon يحوي قواعد domainين، وMCP server باسم vertical-sor بأدوات search وconfirm وvalidate وlive-state، وخمس Document Sets، وgovernance/authority-map.yaml، وcontext-gateway يحل identity ويطبق permitted sets قبل أي Onyx search، وContext Router بلا Document Set ملحقة بل Actions فقط. اعرض الخطة وcomponent boundaries وtool list قبل كتابة code.

الخطوة 2. اقرأ الخطة قبل الموافقة. ستة فحوص، وهي سبب الدورة.

1. هل permission filtering قبل retrieval لا بعده؟
2. هل يمر كل retrieval path عبر gateway، بما فيه Router؟ لا Document Set ملحقة مباشرة بالAgent ولا role يصل كtool argument.
3. هل discovery وconfirmation استدعاءان منفصلان؟
4. هل تجلب operational state حية بلا path يفهرسها؟
5. هل يحفظ router العناصر المتعارضة بدلا من التلخيص عبرها؟
6. هل يصل إلى سجل Neon عبر MCP ولا connector قريب منه؟

إن كانت إجابة واحدة لا، أعد الخطة قبل وجود سطر code.

الخطوات 3 إلى 7. نفذ على checkpoints. انتقل إلى model أرخص للبناء الروتيني.

شغل Onyx Standard، وصل AF-SOR-PUBLIC، واعرض إجابة مستشهدة مأخوذة من الكتاب.

صل fixtureي Vertical SoR وworking-context كconnectors منفصلة. اعرض document counts وأكد أن operational JSON لم يوصل.

أنشئ schema governed في Neon وحمل قواعد domainين، ومنها accounting rule المستبدلة. شغل vertical-sor وcustomer-state server، وأثبت أن confirm_rule يعيد شيئا لا يعيده search_rules وحده.

أنشئ Document Sets الخمس واكتب authority-map.yaml وابن context-gateway وأنشئ Context Router بلا knowledge ملحقة، بل Actions الخمس فقط.

شغل permission test set عبر gateway، صف لكل role، ومنها السؤال الذي إجابته الصحيحة لaccount_executive هي nothing. ثم شغل السؤال نفسه مباشرة على Onyx search لتري ما تحجبه gateway، ومرة عبر Router لتؤكد أن Router يصل إلى Onyx عبر ذلك المسار فقط.

الخطوة 8. اسأل السؤال. تفعل الحزمة الناجحة خمسة أشياء: تستدعي live tools كلتيهما؛ وتستشهد بVertical SoRs بعد confirmation؛ وتوسم بريد المدير supporting evidence فقط؛ وتفصل قراري sales وaccounting؛ وتصل إلى رفضيْن منفصلين لا yes مدمجة.

الرفضان: لا يوافق account executive على الخصم ما دامت approval معلقة، ولا يثبت revenue ما دام acceptance غائبا. أما billing عند signature فمسموح، وذكر ذلك بدقة جزء من pass. رفض كل شيء خطأ مثل الموافقة على كل شيء.

هذا مثال مختصر لما يعود. قد تختلف الصياغة، ولا يجوز أن يختلف الشكل.

## 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

اقرأ ما يفعله الشكل. لكل governed claim version وconfirmation time. تسمى superseded rule ويقال صراحة إنها لم تطبق. يظهر البريد موسوما في section خاص، ثم في Conflicts and gaps لأنه يدعي ما لا يدعمه source محكوم. وتبقى verdicts الثلاثة منفصلة: رفض، إذن، رفض.

الخطوة 9. اكسره عمدا. خمسة failure tests، والسلوك المتوقع هو الدرس:

الاختبار	السلوك المتوقع
عدل البريد ليزعم approval الخصم مع بقاء CRM pending	يظهر conflict ويحفظ CRM كcurrent operational state
وجه search_rules إلى Neon branch قديم	يصحح confirmation ويظهر خطأ الإجابة القديمة
أوقف customer-state MCP server	يقول إن current state لا يمكن تأكيدها ويرفض conclusion يعتمد عليها
أزل sales rules من permitted scope للgateway	يسمي governing authority الناقصة بدلا من إحلال بريد المدير
ألحق cross-domain Document Set مباشرة بالRouter	تتجاوز gate ويرى restricted role محتوى مقيدا. افصلها وشاهد الإجابة الصحيحة

يكتمل عندما: ترى إجابة واثقة وطليقة ومستشهدة وخاطئة تماما من نظام تخطى confirmation call واحدا. لا ينسى أحد ذلك.

الخطوة 10. احفظ baseline. شغل كل case من evals/questions.yaml واحفظ raw responses وcitations وtool-call evidence وpass/fail لكل dimension وقيد permission المعروف في Community Edition وversions الدقيقة لOnyx وmodel.

---

الجزء 6: أثبت ذلك

ببساطة

سألت دورتك السابقة سؤال اختبار واحدا: هل وجد search النص الصحيح؟

لا يكفي ذلك هنا. تفشل الطبقة بطرق لا يراها search test: قد تجد passage صحيحا من قاعدة العام الماضي، أو تعرض لشخص ما لا يحق له، أو تجيب من نسخة قديمة لرقم. لذلك تختبر ثمانية أشياء، وكل failure يسمي الجزء المكسور.

سألت RAG eval set: هل أعاد retrieval المقاطع الصحيحة؟ معظم failures طبقة السياق ليست retrieval failures، لذلك تحتاج set وscorecard مختلفين.

يأتي evals/questions.yaml بعشر حالات. اقرأ الست التالية لأنها تختبر stages مختلفة:

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

قيم كل run على ثمانية dimensions، لا على جمال prose:

البعد	سؤال النجاح
Inventory	هل وجد كل source classes ذات الصلة؟
Routing	هل حدد كل professional decision وdomain؟
Authority	هل اعتمد governing source الصحيح مؤكدا عند المصدر؟
Freshness	هل استدعى live tool حين كانت current state مهمة؟
Permission	هل بقي داخل corpus وaction authority المسموحة؟
Conflict	هل أظهر الخلاف بدلا من دمجه؟
Gaps	هل ذكر الناقص بدلا من التخمين؟
Citation	هل يستطيع reviewer إعادة فتح كل rule وsupporting item؟

شغل baseline الأول يدويا عبر Agent واحفظ outputs. ثم automate:

ابن eval harness مقابل Onyx instance العامل باستخدام official API الحالية. اقرأ evals/questions.yaml وأرسل كل question إلى Northstar Context Router واحفظ raw response وcitations وtool-call evidence، ثم أنتج Markdown scorecard عبر dimensions الثمانية. استخدم deterministic checks متى أمكن. لا تجعل النموذج نفسه الذي أجاب يصحح professional correctness آليا. اترك authority وconclusion checks كمقارنات expected-value صريحة.

دافع عن التعليمة الأخيرة. قد يساعد model يحكم model في تلخيص failures، لكنه لا يحل محل expected rules والfacts التي كتبتها بنفسك.

تعريف الاكتمال: تجتاز cross-domain case كل dimension عدا production permission fidelity، التي تبقى gate مفتوحة صراحة.

---

الجزء 7: قدمها للقوى العاملة كلها وشغلها

ببساطة

الطبقة التي تعمل داخل chat window واحدة غير مكتملة.

تفتحها خطوة البناء الأخيرة لتصل الأدوات التي يستخدمها الزملاء إلى corpus نفسها مع القواعد نفسها لمن يرى ماذا. ثم يأتي الجزء الذي لا يكتبه أحد: ما يلزم لإبقائها عاملة حين يعتمد عليها بشر.

استخدم البشر وOnyx Agents المجموعة حتى الآن داخل Onyx interface. ولا تصبح architecture ما يعد به اسمها إلا عندما تستعلم Workers خارجية من corpus نفسها بدلا من بناء نسخ خاصة.

يعمل Onyx في الاتجاهين، وهذا الجزء الذي لا تصل إليه معظم البنى:

هناك طريقان، وواحد فقط يحفظ permission boundary.

Native Onyx MCP server هو الطريق السريع. فعله في self-hosted configuration وأنشئ token ووجه client إليه. تأخذ search tool query مع filters لنوع المصدر وDocument Set وtime cutoff، ويسرد resource مصاحب sets التي يصل إليها token.

اقرأ القائمة بدقة، فهي عكس الطمأنينة. يوجد Document Set filter لكن client يختاره. لا يشتق server scope من caller role، فيستطيع client تسمية scope مختلف أو تركه كليا.

لذلك يبحث Worker المتصل مباشرة بnative Onyx MCP خارج gate. وفي Community Edition بلا source-permission inheritance تحته، يعني ذلك البحث في كل شيء.

ما يستطيع native endpoint ادعاءه وما لا يستطيع

استخدم native Onyx MCP endpoint على حقيقته: أداة administrator، أو demo على corpus عامة، أو production route لكن بعد إثبات permission fidelity بنشر Enterprise أو authorization layer مكافئة من عندك.

لا تصف direct Community Edition MCP access بأنه يحمل user permission boundary نفسها. لا يفعل.

Context Gateway MCP server هو الطريق الذي يصمد. إنه gateway نفسها التي بنيتها، معروضة للخارج:

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

غلف gateway كMCP server مستقل اسمه context-gateway. اعرض search_permitted_context وconfirm_rule وget_opportunity وget_contract_state وvalidate_action حتى لا يحتاج Worker خارجي إلى server آخر. قدمه عبر Streamable HTTP.

للهوية استخدم bearer tokens مربوطة server-side بالأدوار. أصدر token لكل role وضع mapping في environment الخادم واقرأ role من token في كل request. يجب ألا يصل role كtool argument أبدا.

عمليا، mapping ثلاثة أسطر configuration وعليه permission boundary كلها:

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

يرسل client bearer token في MCP transport ويربطه server بدور. لا يسمي client دوره أبدا، لأن من يستطيع ذلك لا يملك boundary.

Token هو الحد، فلا ترسله مكشوفا

عمل كل ما سبق على http:// لأنه على جهازك. لحظة وصول gateway من مكان آخر يصبح bearer token هو permission boundary كلها ويسافر plain text. ضع TLS أمامه، وأصدر token لكل شخص لا role، واجعل له expiry. Token بشكل role لا ينتهي shared password بمسمى وظيفي.

يجيب FastMCP HTTP server عند /mcp ما لم تغير path، فسجل ذلك لا bare host. ثم صله كما تصل أي HTTP MCP server:

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

أضف remote block إلى 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
    }
  }
}

لا تلتزم token أبدا. يستبدل OpenCode environment variables بصيغة {env:NAME}، فيبقى token داخل shell ولا يدخل الملف إلا اسمه. ثم من خارج Onyx:

استخدم MCP server باسم context-gateway للعثور على rule الحاكمة لخصم Northstar عشرين في المئة. أعد source title وcanonical link وconfirmed version والمقطع الدقيق. لا تجب من ذاكرتك.

شغل سؤالا ثانيا يحتاج sales وaccounting. قد تجري Worker الخارجية searches كثيرة وتجمع packet بنفسها، ويختلف clients. هذا ليس المقصود.

ثم الاختبار المهم: اسأل السؤال نفسه عبر gateway كaccount_executive وكvp_sales وأكد حصول العاملين على نتيجتين مختلفتين. إن لم يحدث فgateway تحل identity من شيء يتحكم فيه client، وقد بنيت boundary يمكنه تخطيها.

في Glean

هذه أقوى إجابة من Glean لمشكلة الجزء. لا يتجاوز MCP server فيه native identity وpermission model. يعمل protocol adapter رقيقا: يصادق end user ويربط identity بمستخدم Glean وينفذ كل tool call بوصفه ذلك المستخدم، فيفحص كل search وchat وdocument call كما لو شغلها الشخص داخل Glean. ويختار admins الأدوات المعروضة.

هذه boundary هي ما تعيد context-gateway بناءه يدويا. ابنها مرة لأنك حين لا تقدم platform العميل ذلك ستعرف الناقص وما يلزم لتوفيره.

اختبار القوى العاملة

لا تكتمل context layer لأن chat interface واحدة تبحث فيها. تكتمل حين يصل كل إنسان وعامل AI مصرح له إلى governed inventory نفسها من working surface الخاصة به، مع source identity وpermission boundary نفسيهما.

ذلك الفرق بين application وshared infrastructure. هنا تتوقف الطبقة عن كونها product feature وتصبح شيئا تعمل عليه الشركة.

تشغيلها

تتغير context layer يوميا لأن systems حولها تتغير يوميا. لذلك production work ليس «انشر مرة». إنه connector health وpermission fidelity وfreshness وmeasurement وupgrades مضبوطة.

عمليات الموصلات

سجل لكل connector تسعة أمور: owner، وsource class، ومن يملك credentials، ومعدل refresh وprune، ومتى بدأ indexing، وexpected document count، وآخر sync ناجح، وstaleness المقبولة، وescalation path.

يعرض Onyx connectors بحالات indexed وscheduled وindexing وpaused وerror، ويحفظ attempt history. الفخ: connector في error لا يزيل بالضرورة محتوى فهرسه سابقا. هذا جيد availability وخطر freshness، لأن search يبقى عاملا وcorpus تشيخ بصمت. يجب أن تفرق alerts بين search يعمل وcorpus حالية، فهما alarmان مختلفان.

انضباط version والترقية

يستطيع installer ترقية deployment. لا تعامل one-command upgrade كno-review upgrade. ثماني خطوات بالترتيب:

1. سجل version الحالية.
2. اقرأ release notes.
3. انسخ persistent volumes وconfiguration احتياطيا.
4. صدر settings الخاصة بالconnectors وmodel وAgent وAction وpermissions.
5. شغل eval baseline.
6. رق instance غير production أولا.
7. أعد evals نفسها.
8. قارن connector counts وcitations وtool calls وlatency.

تغييرات embedding وindex

يحتاج تغيير embedding model إلى re-indexing. عامله مثل schema migration: clone deployment حيث يمكن؛ افهرس corpus ممثلة؛ شغل authority وretrieval evals؛ قارن recall وcitation quality وlatency وcost وstorage؛ ولا توافق إلا على تحسن مقاس.

تخطيط الموارد

لlocal lab، 4 virtual CPUs و10 GB RAM حد Standard المفيد، و8 CPUs و16 GB أو أكثر أفضل. يعتمد production sizing أساسا على indexed volume وquery concurrency وخيارات embedding/reranking وrefresh load. راقب disk بدقة لأن search index قد يمنع writes قرب disk flood thresholds.

تعريف اكتمال production

لا تصبح الطبقة جاهزة لبيانات شركة حقيقية إلا إذا صح الآتي كله:

• صنف كل source إلى shared method أو Vertical authority أو operational state أو working context.
• لكل connector owner وcanonical source وrefresh expectation وfailure alert.
• Authority routing له version ويراجعه domain experts.
• تؤكد governed knowledge عند المصدر قبل الاعتماد.
• تؤكد current operational facts حية حيث يلزم.
• تزامن source permissions أو تفرض قبل retrieval.
• تحفظ MCP وAPI actions الهوية الفردية وleast privilege.
• تبقى conflicts وmissing evidence مرئية.
• تعيد citations فتح canonical source أو record.
• تجتاز cross-domain evals كل release.
• اختبرت backups وrestoration.
• يوجد rollback path للupgrades وتغييرات retrieval.
• لا يستطيع System of Context الكتابة حول System of Record المنطبق.

الجسر إلى Digital FTE

لديك الآن نصفا الشيء نفسه. منحت الدورة السابقة Worker معرفة يملكها. ومنحته هذه الدورة وصولا إلى معرفة تملكها الشركة، مع permission وprovenance وconfirmation.

Digital FTE هو الناتج حين تضع contract of success حول Worker وتوجهه إلى outcome واحد. Retrieval هو ما بنيته هنا، وauthority ما يقوله governed record، وtrustworthiness ليست property للنموذج أصلا.

---

إلى أين بعد ذلك

• الحجة خلف البناء: نظام السياق
• السجل الذي تصله الطبقة: تصميم Vertical SoR
• اجعله موثوقا: التطوير المدفوع بالتقييم
• اجعله وحدة عمل: بناء Digital FTE
• ضعه بجانب الناس: فرق الإنسان والوكيل

القواعد الثماني في مكان واحد

بنيت الآن كل هذه. تصح لأي مهنة وعميل ومنتج، حتى ما لم يوجد بعد.

#	القاعدة
1	السلطة لا تنتقل. تحمل الطبقة citations إلى record، ولا تصبح هي أو model المصدر المستشهد به
2	الصلة ليست السلطة. يحسم routing قبل الاعتماد على passage
3	تورث الأذونات ولا تخترع وتفرض قبل model
4	تقرر freshness لكل field. افهرس working context واكتشف governed knowledge واستعلم current truth حية
5	يسافر provenance مع كل item ولا يزيله compression
6	يحفظ conflict ويصعد ولا يدمج
7	لا يصبح working context سلطة حاكمة بصمت. Promotion authorship مراجع ومسجل
8	الاكتشاف ليس تأكيدا. Search hit مؤشر ويؤكد governing record

اطبع الجدول. هذا الجزء يعيش بعد Onyx وGlean وما يستبدلهما.

---

لا يتغير الخيط بل يزداد صرامة. قالت الدورة السابقة: المعلومة الصحيحة في اللحظة الصحيحة وإخراج غير المرتبط. تضيف هذه الأسئلة الثلاثة التي تجعل الأمر قابلا للدفاع:

من أين أتى؟ هل يجوز لهذا الشخص رؤيته؟ هل ما زال يحكم؟

أجب الثلاثة لكل item كل مرة، وقد بنيت شيئا تستطيع مهنة الوقوف خلفه.

---

وسيلة مراجعة بالبطاقات

---

اختبر فهمك

Checking access...