name: deploy-production
description: التحقق من التطبيق ونشره إلى بيئة الإنتاج.

ما وراء الاستدلال: منهج أنثروبيك في ذاكرة الوكلاء والأحلام وسير عمل الرسوم البيانية

1. اقرأ checklist.md.
2. شغّل مجموعة الاختبارات الكاملة.
3. تأكد من خطة الترحيل.
4. شغّل scripts/verify-release.sh.
5. أوقف التنفيذ واطلب موافقة بشرية قبل النشر.

الآلية المهمة هي الكشف التدريجي.

يرى Claude وصفًا قصيرًا يساعده في تحديد ما إذا كانت المهارة ذات صلة. لا يتم تحميل النص الكامل للمهارة والملفات الداعمة إلا عند الحاجة إلى تلك العملية.

تشبّه "مكتا" هذا برفّ الكتب.

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

تساعد المهارات في حل مشكلة "ملف السياق المتزايد":

• يمكن الاحتفاظ بالحقائق المستقرة عالية المستوى في CLAUDE.md.
• يمكن نقل العمليات التفصيلية إلى المهارات.
• يمكن إبقاء المواد الداعمة خارج سياق النشاط حتى الحاجة إليها.

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

المهارات لا تزال بحاجة إلى إدارة بشرية

المهارات قابلة لإعادة الاستخدام، لكن لا يزال هناك من يقرر:

• أي سير عمل يستحق إنشاء مهارة له
• كيف يجب بناء العملية
• ما الملفات التي يجب تضمينها
• متى تصبح المهارة قديمة
• من لديه صلاحية تعديلها

يمكن للوكلاء المساعدة في كتابة المهارات وصيانتها، لكن النظام لا يزال يعتمد جزئيًا على الإدارة البشرية.

وهذا يقودنا إلى الطريقة الرابعة.

الجيل الرابع: اعتبار نظام الملفات كذاكرة

تصف "مكتا" الذاكرة القائمة على نظام الملفات على أنها النمط الذي تفضله Anthropic حاليًا في العديد من أنظمة ذاكرة الوكلاء.

والسبب عملي للغاية.

الوكلاء بارعون بالفعل في:

• سرد الملفات
• البحث في أسماء الملفات
• تشغيل grep
• قراءة ملفات Markdown
• تصفح الدلائل
• تحرير النصوص
• مقارنة الإصدارات

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

قد يكون التخطيط المحتمل على النحو التالي:

memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
    └── agent-104/
        └── scratchpad.md

يدعم هذا التخطيط مستويات مختلفة من الذاكرة:

• قواعد على مستوى المؤسسة
• معرفة الفريق
• سياق المشروع
• تفضيلات المستخدم
• ملاحظات عمل خاصة بوكلاء محددين

كما يجسّد مبدأ الكشف التدريجي.

يمكن للوكيل البحث في الدلائل وتحميل الملفات ذات الصلة فقط بالمهمة الحالية.

الملفات واجهة، وليست بالضرورة تخزينًا ماديًا

الواجهة بأسلوب نظام الملفات لا تتطلب أن تكون كل ذاكرة مؤسسية ملفات غير مُدارة على جهاز محمول.

يمكن للتنفيذ الأساسي أن يستخدم:

• قواعد البيانات
• تخزين كائنات مُدار بالإصدارات
• خدمات التحكم في الوصول
• فهارس البحث
• سجلات التدقيق
• واجهات برمجية تعاملية

النقطة الأساسية هي أن الوكيل يحصل على تجريد بسيط وقابل للتنقل.

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

أقرّت "مكتا" بأن هذه البنية تعود إلى مبادئ هندسة البرمجيات المألوفة. بمجرد أن تفهم الفرق السلوكيات التي ينبغي أن تكون حتمية، يمكنها نقلها إلى إطار تحكم بدلاً من ترك النموذج يرتجل في كل مرة.

أربعة حواجز حماية للذاكرة بمستوى الإنتاج

مجلد مليء بملفات Markdown قد ينجح مع مستخدم واحد.

لكن عندما يستطيع آلاف الوكلاء تحديث ذاكرة مؤسسية مشتركة، يصبح ذلك خطيرًا.

أكدت "مكتا" على أربعة مبادئ إنتاجية:

1. التحكم في الإصدارات
2. التحكم في التزامن
3. إدارة الصلاحيات
4. قابلية النقل

1. تسجيل إصدار لكل تغيير في الذاكرة

يجب أن يكون لكل تحديث للذاكرة سجل تاريخي.

تشمل البيانات الوصفية المفيدة:

• الإصدار السابق
• الإصدار الجديد
• الطابع الزمني
• المؤلف (بشري أو وكيل)
• الجلسة المصدرية
• سجلات المحادثة الداعمة
• سبب التغيير
• حالة الموافقة

إدخالات الذاكرة التي لا تحتوي على مصدر موثق يصعب كسب الثقة بها.

لنفترض أن وكيلًا أضاف:

- لا حاجة إلى موافقة للنشر إلى الإنتاج يوم الجمعة.

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

يدعم التحكم في الإصدارات:

• المراجعة
• التراجع
• التدقيق
• المقارنة
• تحليل السبب الجذري

يجب أن يكون نظام الذاكرة المُدار بالإصدارات قادرًا على الإجابة بسهولة:

أي تفاعل أدى إلى ظهور هذه القاعدة؟

2. منع الوكلاء المتزامنين من الكتابة فوق بعضهم البعض

قد يقرأ وكيلان نفس الذاكرة في الساعة 10:00.

الوكيل "أ" يكتب تحديثًا في الساعة 10:02.

الوكيل "ب" لا يعلم بهذا التغيير، فيكتب نسخته في الساعة 10:03 ويحذف تحديث الوكيل "أ" عن غير قصد.

تصف "مكتا" نمط التزامن القائم على التجزئة:

يقرأ الوكيل الذاكرة ويسجل التجزئة A
        ↓
يعدّ الوكيل التحديث
        ↓
يقرأ الوكيل الذاكرة مرة أخرى ويسجل التجزئة B
        ↓
إذا كانت التجزئة A == التجزئة B:
    يُرسل التحديث
وإلا:
    يعيد التحميل وإعادة الأساس ويعيد المحاولة

هذا هو التحكم في التزامن التفاؤلي.

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

3. التمييز بين صلاحيات القراءة والكتابة

ليس كل وكيل يجب أن يُسمح له بتعديل كل ذاكرة.

قد يكون نموذج الصلاحيات المعقول على النحو التالي:

نطاق الذاكرة	طريقة الوصول النموذجية
مبادئ المؤسسة	معظم الوكلاء للقراءة فقط؛ الكتابة عبر عملية مراجعة فقط
سياسات الأمان	الوكلاء المعنيون للقراءة فقط؛ كتابة مُقيدة بتحكم بشري
عمليات الفريق	الفريق للقراءة فقط؛ المشرفون المعينون للكتابة
قرارات المشروع	وكلاء المشروع للقراءة فقط؛ التعديلات المقترحة تحتاج موافقة
مساحة مسودات الوكيل	وكيل واحد للقراءة والكتابة
تفضيلات المستخدم	وكلاء نطاق المستخدم للوصول
سياق عملاء حساس	وصول صارم قائم على الأدوار

لا ينبغي لوكيل أن يحول ملاحظة غير مؤكدة إلى قاعدة على مستوى المؤسسة.

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

4. جعل الذاكرة قابلة للنقل

قد تصبح الذاكرة أحد أهم أصول الذكاء الاصطناعي للمؤسسة.

تحتوي على:

• القرارات
• التصحيحات
• سير العمل
• التفضيلات
• أنماط الفشل
• المعرفة بالأدوات
• التعليمات الخاصة بالمجال

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

يجب أن يتمتع نظام الذاكرة القابل للنقل بما يلي:

• واجهات برمجية واضحة
• تنسيقات قابلة للتصدير
• مخططات موثقة
• معرّفات مستقرة
• تحكم وصول قياسي
• تتبع مصدر مستقل عن الأدوات

تتيح قابلية النقل لنفس السياق المنظم بعناية دعم:

• Claude Code
• وكلاء Claude المُدارون
• الأدوات الداخلية
• أنظمة وكلاء أخرى
• سير عمل التوثيق البشري

لماذا ذاكرة الجلسة غير كافية

حتى أدوات الذاكرة المصممة جيدًا تواجه قيدين هيكليين.

القيد الأول: الوكلاء عرضة للتشتت

يجب على الوكيل إنجاز المهمة وتنظيم الذاكرة في الوقت نفسه.

استهلاك الكتابة للذاكرة يستهلك موارد كان يمكن استخدامها للهدف الحالي.

قد يقوم الوكيل بما يلي:

• حفظ محتوى أكثر من اللازم
• حفظ محتوى أقل من اللازم
• تخزين استنتاجات غير موثقة
• تخطي أعمال الذاكرة تحت ضغط الوقت
• التركيز فقط على التفاصيل المحلية بدلاً من الأنماط الأوسع

القيود الثاني: الوكيل لا يرى سوى محادثة واحدة

قد يلاحظ الوكيل أن أمرًا ما فشل مرة واحدة.

لكنه لا يستطيع رؤية أن الأمر نفسه فشل في 300 محادثة أخرى.

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

لكنه لا يستطيع رؤية أن نفس الحيرة تتكرر عبر النطاق الإقليمي بالكامل.

آلية تعلم على مستوى النظام تتطلب عملية تتمتع برؤية أوسع.

هذه العملية هي ما تسميه أنثروبيك "الحلم" (Dreaming).

الحلم: عملية خارج النطاق لتنظيم الذاكرة

الحلم هو عملية غير متزامنة تراجع سجل الوكيل بعد اكتمال العمل العادي.

تصف ملاحظات إصدار واجهة برمجة التطبيقات الحالية من أنثروبيك ميزة "الحلم" لوكلاء Claude المُدارين بأنها معاينة بحثية.

جلسة "حلم" واحدة تقرأ:

• مخزن الذاكرة الحالي
• سجلات المحادثات السابقة

ثم تنشئ مخزن ذاكرة ناتجًا معاد تنظيمه، حيث يمكنها:

• دمج الإدخالات المكررة
• استبدال المعلومات القديمة
• إبراز الرؤى المفقودة
• إعادة تنظيم المحتوى
• اقتراح ذاكرة محسّنة

هذه ليست إعادة تدريب للنموذج.

أوزان النموذج الأساسي لا تتغير.

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

تشبيه المدرسة

توضح موكتا الفرق بين الذاكرة العادية و"الحلم" باستخدام مثال المدرسة.

تخيل:

• الطلاب يكملون الواجبات.
• المعلم يصحح كل واجب.
• مدير الشؤون الأكاديمية يراجع النتائج العامة للمدرسة بأكملها.

يمكن للمعلم مساعدة طالب واحد في تصحيح خطأ ما.

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

التصحيح على مستوى النظام ليس بتصحيح كل ورقة على حدة.

بل بتحديث المنهج الدراسي.

مصطلحات الوكلاء:

• واجب الطالب = محادثة منفردة
• ملاحظات المعلم = تحديث الذاكرة داخل المحادثة
• المنهج المدرسي = مخزن الذاكرة المشترك
• مراجعة المدير = معالجة الحلم (Dreaming)
• تحديث المنهج = تغييرات الذاكرة المقترحة

وهذا يمكّن النظام من التعلم من أنماط لا يمكن لوكيل فردي إدراكها.

الآلية الميكانيكية لمعالجة الحلم

خط أنابيب معالجة الحلم المبسط يظهر على النحو التالي:

مخطط تدفق TD
    A[مخزن الذاكرة الحالي] --> D[منسق الحلم]
    B[سجلات المحادثات] --> D
    C[استدعاءات الأدوات والبيانات الوصفية] --> D
    D --> E1[وكيل المراجعة 1]
    D --> E2[وكيل المراجعة 2]
    D --> E3[وكيل المراجعة 3]
    E1 --> F[مجمّع الأنماط]
    E2 --> F
    E3 --> F
    F --> G[تغييرات الذاكرة المقترحة]
    G --> H{موافقة بشرية}
    H -->|مقبول| I[مخزن الذاكرة المحدّث]
    H -->|مرفوض| J[الاحتفاظ بالذاكرة الحالية]

عملية المراجعة يمكنها فحص أكثر من مجرد رسائل المستخدم والمساعد.

الأدلة المفيدة تشمل:

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

يبحث وكيل الحلم بعد ذلك عن أنماط مثل:

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

ذكرت موكتا أن تصميم أنثروبيك يمكن أن يتضمن أمثلة من سجلات المحادثات ذات الصلة وإحصاءات توضح تكرار النمط.

هذه الأدلة تساعد البشر على الحكم على ما إذا كان تغيير الذاكرة المقترح معقولًا.

معالجة الحلم يجب أن تقترح، لا أن تعيد كتابة كل شيء بصمت

تمتلك عملية معالجة الحلم صلاحيات وصول واسعة قد تؤثر على السلوك المستقبلي لمجموعة كاملة من الوكلاء.

وهذا يجعل التحديثات التلقائية غير المدققة محفوفة بالمخاطر.

سير العمل الأكثر أمانًا هو:

1. تحليل سجلات المحادثات المصرح بها.
2. تحديد الأنماط المتكررة.
3. ربط الأنماط بالمحادثات الداعمة.
4. صياغة تغييرات الذاكرة المقترحة.
5. تقدير مدى انتشار المشكلة.
6. طلب موافقة مراجع بشري أو مراجع خاضع لسياسات.
7. إرسال التحديثات المعتمدة مع سجل المصادر.
8. قياس تحسن الأداء في المستقبل.

على سبيل المثال:

## تحديث الذاكرة المقترح

**الهدف:** `teams/engineering/test-process.md`

**المشكلة الملاحظة:**  
استخدم الوكلاء أمر اختبارات الوحدة لتنفيذ اختبارات التكامل في 18 من أصل 63 محادثة ذات صلة.

**الأدلة:**  
المحادثات `s-102`، `s-111`، `s-118`، `s-124`، ……

**الإضافة المقترحة:**  
- استخدام `npm run test:integration` لجميع الاختبارات التي تتطلب حاويات قواعد بيانات.
- عدم استخدام `npm test` للملفات الموجودة في `tests/integration/`.

**مستوى الثقة:** مرتفع

**القرار البشري:** معلق

وهذا يحافظ على الإشراف البشري مع السماح لمجموعة الوكلاء بإنجاز معظم أعمال التحليل.

لماذا يقلل الحلم التكلفة رغم استخدامه المزيد من الرموز

تتطلب معالجة الحلم استدعاءات نموذج إضافية.

قد يبدو هذا في البداية تكلُّفًا غير ضروري.

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

المحاولة الأولى.

مقارنة اقتصادية مفيدة:

تكلفة الحلم
مقابل
تكلفة الفشل المتكرر وإعادة المحاولة وإعادة العمل والسياقات الطويلة للغاية

التوفير المحتمل يمكن أن يأتي من:

• عمليات إعادة محاولة أقل
• تفسيرات متكررة أقل
• سياقات غير ذات صلة أقل
• اختيار أفضل للأدوات
• دقة أعلى في المحاولة الأولى
• تأهيل أسرع للوكلاء الجدد
• تصحيحات بشرية متكررة أقل

لم تصدر أنثروبيك حتى الآن معيارًا عامًا يحدد مقدار ما يمكن لكل مؤسسة توفيره. القيمة المحددة تعتمد على:

• درجة تكرار المهام
• جودة الذاكرة
• تكلفة الأخطاء
• عدد المحادثات
• تصميم المراجعة
• تسعير النماذج والأدوات

من المرجح أن يحقق "الحلم" أعلى عائد عندما تنفذ مجموعة كبيرة من الوكلاء مهامًا مترابطة ويواجهون نفس الأنماط بشكل متكرر.

عملية حلم أسبوعية بسيطة بدون وكيل مُدار

لا يحتاج الفريق إلى انتظار التكامل الكامل للمنصة لاختبار هذا المفهوم.

النسخة اليدوية يمكن تشغيلها مرة واحدة أسبوعيًا.

الخطوة 1: تصدير المحادثات ذات الصلة

اجمع فقط سجلات المحادثات التي يحق للمراجع الاطلاع عليها.

نظّمها حسب:

• المشروع
• الفريق
• سير العمل
• نطاق الصلاحيات
• الفترة الزمنية

الخطوة 2: توفير الذاكرة الحالية

تضمين:

• CLAUDE.md
• المهارات ذات الصلة
• ملفات ذاكرة المشروع
• ملاحظات الفريق
• مستندات المشكلات المعروفة

الخطوة 3: طلب اقتراحات مدعومة بالأدلة

يمكن أن تكون المطالبة كالتالي:

راجع سجلات المحادثات المصرح بها وملفات الذاكرة الحالية.

حدد حالات الفشل المتكررة، والتصحيحات البشرية المتكررة، والتعليمات القديمة،
والعمليات المفقودة، والإدخالات المكررة.

لكل تعديل مقترح:
1. حدد الملف الهدف.
2. قدم معرفات المحادثات الداعمة.
3.

اشرح عدد مرات ظهور هذا النمط.
4. قم بصياغة الحد الأدنى من التعديل الفعّال.
5. لا تقم بتحرير الملفات مباشرة.

الخطوة 4: مراجعة الاقتراح

رفض التعديلات التالية:

• القائمة على حدث واحد غامض
• التي تفتقر إلى أدلة داعمة
• الواسعة النطاق بشكل مفرط
• التي تنطوي على حساسية أمنية
• التي تتجاوز صلاحيات المراجع
• التي تُنفَّذ بشكل أفضل من خلال كود حتمي

الخطوة 5: تقديم التعديلات المعتمدة

استخدم التحكم في الإصدارات، وقم بتضمين الأدلة والمصادر في سجل الالتزام أو التدقيق.

الخطوة 6: قياس النتائج

تتبّع ما إذا كان نفس الفشل يتناقص في الجلسات اللاحقة.

بدون قياس، يتحول "الحلم" إلى مجرد توثيق، وليس نظامًا تعلّميًا.

من الذاكرة المتراكمة عبر الزمن إلى البنية داخل المهمة

الذاكرة تجيب على السؤال التالي:

ما الذي يجب أن يتذكره الوكيل من العمل السابق؟

هندسة الرسوم البيانية تجيب على سؤال مختلف:

ما هي الأجزاء من المهمة الحالية التي تعتمد فعليًا على بعضها البعض؟

تربط مقالة المصدر من BAAI موضوع الذاكرة بدليل هندسة الرسوم البيانية المتداول في مجتمع تطوير الذكاء الاصطناعي.

الحجة الأساسية في ذلك الدليل هي أن العديد من "سير العمل" هي في الأساس رسوم بيانية بالفعل — ولكنها مصممة بشكل سيئ.

سير العمل المكتوب على شكل قوائم غالبًا ما يتحول بشكل مصطنع إلى عمليات تسلسلية:

البحث
    ↓
التلخيص
    ↓
المقارنة
    ↓
التحقق من الحقائق
    ↓
الكتابة

بعض هذه الخطوات قد تعتمد فعليًا على مخرجات الخطوة السابقة.

أخرى قد تنتظر دون داعٍ.

العقد والحواف وتدفق البيانات الحقيقي

في الرسم البياني لسير العمل:

• العقدة تمثل مهمة.
• الحافة تمثل اعتمادًا حقيقيًا.
• تتدفق البيانات عبر الحواف.

على سبيل المثال:

عقدة البحث تنتج نتائج البحث.

عقدة الكتابة تستهلك هذه النتائج وتنتج مسودة.

عقدة التحقق تستهلك المسودة وتنتج نتيجة مُدقَّقة.

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

اختبار الحافة الزائفة

يقترح دليل الرسوم البيانية المجتمعي اختبارًا بسيطًا لكل سهم:

هل تحتاج المهمة التالية فعليًا إلى مخرجات المهمة السابقة؟

إذا كانت الإجابة لا، فإن هذا الاعتماد هو اعتماد زائف.

تأمل سير العمل التالي:

بحث عن المنافس أ
    ↓
بحث عن المنافس ب
    ↓
بحث عن المنافس ج
    ↓
كتابة تقرير مقارن

عادةً لا يحتاج البحث عن المنافس ب إلى مخرجات البحث عن المنافس أ.

عادةً لا يحتاج البحث عن المنافس ج إلى مخرجات البحث عن المنافس ب.

يمكن تنفيذ هذه المهام بالتوازي:

flowchart TD
    A[تحديد معايير المقارنة] --> B1[بحث عن المنافس أ]
    A --> B2[بحث عن المنافس ب]
    A --> B3[بحث عن المنافس ج]
    B1 --> C[كتابة تقرير مقارن]
    B2 --> C
    B3 --> C

إزالة الحواف الزائفة تقلل من وقت الانتظار.

إذا استغرق البحث عن المنافسين الثلاثة 10 و12 و15 دقيقة على التوالي:

• التنفيذ التسلسلي يستغرق حوالي 37 دقيقة.
• التنفيذ المتوازي يستغرق حوالي 15 دقيقة من الانتظار، بالإضافة إلى تكلفة التنسيق.

الرسم البياني لا يجعل أي وكيل فردي أسرع.

إنه يغيّر طريقة الجدولة.

نمط المعيّن (الدياموند)

بعد إزالة الحواف الزائفة، يظهر شكل شائع:

1. تنقسم مهمة إلى عدة فروع مستقلة.
2. تعمل هذه الفروع بالتوازي.
3. تتجمع النتائج.
4. تقوم العقدة النهائية بتركيب النتائج.

يُشار إلى هذا عادةً باسم المعيّن (الدياموند).

مثال للبحث قد يكون كما يلي:

flowchart TD
    A[سؤال البحث] --> B1[بيانات السوق]
    A --> B2[أدلة العملاء]
    A --> B3[تحليل المنافسين]
    B1 --> C[المُدقِّق]
    B2 --> C
    B3 --> C
    C --> D[التوليف النهائي]

إجمالي الوقت المستغرق تحدده بشكل أساسي أبطأ الفروع، وليس مجموع أوقات جميع الفروع.

العمل المتوازي يحتاج إلى مُدقِّق

التوازي يُدخل خطرًا جديدًا.

قد ينتج أحد الخيوط مخرجات ضعيفة أو قديمة أو غير مدعومة.

إذا قام النظام بدمج كل شيء دون تحقق، فإن فرعًا واحدًا سيئًا قد يلوّث الإجابة النهائية.

لذلك، يضع دليل الرسوم البيانية مُدقِّقًا قبل التوليف.

يمكن للمُدقِّق أن يسأل:

• هل هذا الادعاء مدعوم؟
• هل المصدر محدّث؟

هل يتوافق الناتج مع التنسيق المطلوب؟

• هل أكملت الخيوط العاملة المهام الموكلة إليها؟
• هل اجتاز الكود الاختبارات؟
• هل تتعارض النتائج مع فروع أخرى؟
• هل توجد بيانات حساسة؟
• هل يمكن متابعة هذا الناتج بأمان؟

يجب أن يكون لدى المدقق المفيد معايير قبول واضحة.

على سبيل المثال: