عقل الشركة: ما هو وكيف تبنيه لوكلاء الذكاء الاصطناعي

عقل الشركة (company brain) ذاكرة مكتوبة ومشتركة لطريقة عمل الشركة: قراراتها وتعريفاتها وإجراءاتها وعملائها والدروس التي تعلّمتها، تبقى محدَّثة ومنظَّمة، فيجدها الناس ووكلاء الذكاء الاصطناعي معًا، ويقرؤونها، ويثقون بها.

هو الجواب عن أسئلة مثل: «من نعدّه عميلًا نشطًا؟» و«لماذا ألغينا الخطة المجانية؟» و«من المسؤول عن تصدير الفواتير؟». أجوبة كهذه تجدها عادةً في رأس أحد الزملاء، وفي محادثة من الربيع الماضي، وفي ثلاث صفحات ويكي لا تتّفق. أما عقل الشركة فيضع جوابًا واحدًا محدَّثًا في مكان واحد، ويسجّل من أين جاء.

وإليك ما لا يُعدّ عقل شركة:

• ليس نموذجًا. العقل هو المعرفة نفسها. أما روبوت المحادثة أو الوكيل الذي يجيب منها فواجهة فوقها.
• ليس كومة من كل شيء. فهرسة كل بريد وكل رسالة تمنحك بحثًا، لا ذاكرة. العقل يحفظ الخلاصة: القرار، لا الرسائل المئتين التي سبقته.
• ليس تطبيقًا لملاحظاتك الشخصية. العقل الثاني (second brain) يخدم تفكير شخص واحد. أما عقل الشركة فمشترك، ولذلك تهمّ فيه الدقة ووضوح المسؤولية والمراجعة أكثر من سرعة التدوين.

منذ ظهرت صفحات الويكي والشركات تريد مصدرًا واحدًا للحقيقة. الجديد هو من يقرؤه. فوكلاء الذكاء الاصطناعي اليوم يكتبون الشيفرة، ويردّون على العملاء، ويصوغون التقارير، ويجرون التحليلات، وكلٌّ منهم يحتاج إلى سياق الشركة ليُتقن عمله.

حين ينقص الإنسانَ السياقُ يتدبّر أمره: يسأل زميلًا، أو يتذكّر ما جرى في الربع الماضي، أو ينتبه إلى أن رقمًا ما لا يبدو صحيحًا. أما الوكيل فلا يفعل شيئًا من ذلك. لا يعرف إلا ما في نافذة سياقه، ومعظم الوكلاء يبدؤون كل جلسة من الصفر. وتقولها وثائق Claude Code صراحةً: كل جلسة تبدأ بنافذة سياق جديدة، ولا ينتقل منها إلى ما بعدها إلا ما كُتب في ملفات مثل CLAUDE.md أو AGENTS.md. فإن لم يُكتب السياق، خمّن الوكيل.

والسبب الثاني أن صفحات الويكي تبلى مع الوقت. فمذكرة LLM Wiki التي نشرها Andrej Karpathy في أبريل 2026 تختصر المشكلة في سطر واحد:

«يهجر الناس صفحات الويكي لأن عبء صيانتها يكبر أسرع من قيمتها.»

واقتراحه: دَع النموذج يتولّى مسك الدفاتر. يقرأ الوكيل المصادر الخام، ويكتب صفحات markdown مترابطة ويحدّثها، ويفحصها بين حين وآخر بحثًا عن التناقضات والادعاءات القديمة والصفحات اليتيمة. أما الناس فينتقون ويسألون. وهذه الفكرة، أن يتولّى الوكلاء صيانة المعرفة لا البحث فيها فقط، هي ما يميّز عقل الشركة عن الويكي الذي تملكه أصلًا. (ويشرح دليلنا عن ويكي LLM هذا النمط.)

ومن هناك انتشر المصطلح. وهو اليوم يشمل منصات ويكي مستضافة فيها بحث بالذكاء الاصطناعي، ومشاريع مفتوحة المصدر تحفظ ذاكرة الوكيل ملفاتِ markdown في git. وأكثر ما تختلف فيه هو السؤال الذي تتركه مذكرة Karpathy للناس: من يراجع ما كتبه الوكلاء؟

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

1. التقاط ما يهمّ

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

2. البقاء محدَّثًا

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

3. أن يصل إليه الناس والوكلاء بسهولة

يحتاج الناس إلى تصفّحه والبحث فيه. ويحتاج الوكلاء إلى قراءته دون ربط خاص بكل أداة: نص عادي، وبنية متوقَّعة، وأوصاف قصيرة يمرّون عليها قبل أن يفتحوا مستندًا كاملًا.

4. أن يكون جديرًا بالثقة

حين يكتب الوكلاء جزءًا كبيرًا من المحتوى، يجب أن يجيب كل مستند عن أربعة أسئلة من النظرة الأولى:

• من كتبه؟ شخص، أم وكيل (وأيّ وكيل)؟
• من راجعه؟ هل راجعه شخص، أم وكيل آخر فقط، أم لم يراجعه أحد؟
• من أين جاء؟ أيّ مصدر يسند كل ادعاء فيه؟
• هل ما زال صحيحًا؟ متى تأكّد منه أحد آخر مرة، ومتى تنتهي صلاحيته؟

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

ويكي مستضاف مع بحث بالذكاء الاصطناعي

الطريق الأكثر شيوعًا: تحتفظ بقاعدة معرفة مستضافة (أو تعتمد واحدة)، وتضيف فوقها طبقة ذكاء اصطناعي تبحث فيها وفي أدواتك الأخرى. وتتفاوت منتجات هذه الفئة في مدى ما تصل إليه، وفي مقدار ما يُسمح لذكائها الاصطناعي بتغييره:

• البحث المؤسسي. يتّصل بمئات من تطبيقات العمل (المحادثة، والمجلدات المشتركة، وأدوات تتبّع المهام، وأنظمة إدارة علاقات العملاء) ويجيب عن الأسئلة منها جميعًا، ولا يُظهر لكل مستخدم إلا ما يحقّ له رؤيته.
• ويكي فيه مساعد مدمج. يجيب عن الأسئلة من الويكي وبعض التطبيقات المتصلة به، ويسمح لوكلائه بإنشاء الصفحات وتحريرها.
• ويكي يحدّث نفسه بنفسه. يراقب أدواتك الأخرى، ويصوغ تحديثًا حين تتقادم صفحة، ثم يرسله إلى شخص ليوافق عليه.

نقاط القوة: الصلاحيات، وملاءمته للفرق غير التقنية، والبحث في كل شيء دفعة واحدة، ولا يحتاج معظم الناس إلى أي إعداد. نقاط الضعف: تُحفظ المعرفة في قاعدة بيانات لدى المورّد، ووكلاء البرمجة العاملون في مستودع يصلون إليها عادةً عبر API أو خادم MCP بدل قراءتها مباشرة. والبحث في المصادر الخام يعثر على المحادثة المتضاربة بالسهولة نفسها التي يعثر بها على الجواب المحسوم.

مخزن متّجهات وRAG

كثيرًا ما تبني الفرق الهندسية حلّها بنفسها: تقسّم المستندات إلى مقاطع، وتحوّلها إلى متّجهات وتخزّنها، ثم تسترجع أقرب المقاطع لحظة السؤال (التوليد المعزَّز بالاسترجاع). طريقة مرنة، وتتّسع لمجموعات نصوص هائلة.

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

ملفات markdown في git يقرؤها الوكلاء مباشرة

طريقة وصلت إليها فرق البرمجة من تلقاء نفسها: المعرفة مجلد من ملفات markdown في مستودع. يقرأ Claude Code وCodex وCursor وغيرها من الوكلاء الملفات ويعدّلونها بالأدوات نفسها التي يستخدمونها للشيفرة. وملف لقواعد العمل يشرح لهم كيف نُظّم المجلد: إما AGENTS.md، وهو صيغة مفتوحة يذكر موقع agents.md أن Codex وCursor ووكلاء برمجة كثيرين غيرهما يدعمونها، وإما CLAUDE.md في Claude Code. وهذا هو شكل ويكي LLM عند Karpathy.

نقاط القوة: يقرؤه الوكلاء ويصونونه دون أي ربط إضافي، وكل تغيير diff يمكنك مراجعته، ويمنحك git السجل ومعرفة كاتب كل سطر مجانًا، ولا شيء محبوس لدى مورّد. نقاط الضعف: لا صلاحيات غير ما يسمح به المستودع، ولا محرّر أنيق للزملاء غير التقنيين، وgit وحده لا يخبرك أي المستندات راجعها شخص.

لا خطأ في أيٍّ منها. إن كان لديك مئات الموظفين، وقواعد وصول صارمة، وقلّة ممن يفتحون الطرفية، فالويكي المستضاف سيخدمك أفضل. أما بقية هذه الصفحة فعن الطريقة الثالثة، لأنها الطريقة التي يتولّى فيها الوكلاء الصيانة. وعليها يُبنى Knowtarium: مستندات markdown نفسها والـ frontmatter نفسه، في مساحة عمل مشفّرة تشفيرًا تامًا بين الطرفين يصل إليها وكلاؤك عبر MCP.

تستطيع أن تبدأ في عصر يوم واحد، بمستودع git ووكيل البرمجة الذي تستخدمه أصلًا. والخطوات التالية تتّبع Open Knowledge Format (OKF)، وهي مواصفة مفتوحة نشرتها Google Cloud (الإصدار 0.2 على GitHub) للمعرفة التي يكتبها الوكلاء بصيغة markdown. الصيغة لا ترتبط بأي أداة، وما دام شخص أو اثنان فقط يعملان في المجلد، فقد يكفي diff من git وعين منتبهة. وفي معظم الخطوات نذكر ما يضيفه Knowtarium.

1. ابدأ بمجال واحد يؤلمك

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

2. أنشئ المستودع وبنية المجلدات

مفهوم واحد في كل ملف، في مجلدات يفهمها فريقك:

company-brain/
  AGENTS.md                 # القواعد التي يتّبعها الوكلاء في هذا المجلد
  index.md                  # محتويات المجلد، سطر لكل مستند
  log.md                    # ما الذي تغيّر، الأحدث أولًا
  company/
    glossary.md             # ما نعنيه بالعميل النشط والتسرّب وMRR
    decisions/
      2026-08-pricing.md    # قرار واحد في كل ملف، مع سببه
  product/
    plans-and-limits.md
    release-process.md
  meetings/
    2026-08-14-pricing-review.md
  customers/
    segments.md
    accounts/northwind.md
  runbooks/
    refunds.md
    on-call.md

index.md وlog.md اسمان محجوزان في OKF: الأول يسرد ما في المجلد، والثاني يسجّل ما تغيّر. ويقرأ الوكلاء الفهرس أولًا، فلا يفتحون إلا المستندات التي يحتاجونها.

3. اكتب القواعد لوكلائك

ضع قواعد العمل في AGENTS.md (واجعل CLAUDE.md يشير إليه إن كنت تستخدم Claude Code). واجعله قصيرًا ومحدّدًا. وفي دليلنا عن AGENTS.md لقواعد المعرفة نسخة أوفى.

# قواعد العمل في قاعدة المعرفة هذه
 
- مفهوم واحد في كل ملف. ابحث قبل أن تنشئ ملفًا جديدًا، وإن وجدت ملفًا قائمًا فحدّثه.
- يبدأ كل ملف بقسم frontmatter فيه: type وtitle وdescription.
- حين تكتب ملفًا أو تغيّره، ضع اسم وكيلك وإصداره في generated.by.
- لا تضف نفسك ولا أحدًا غيرك إلى verified أبدًا. هذا عمل المراجعين وحدهم.
- اذكر مصدر كل حقيقة في حاشية: [^source-id].
- ضع تاريخ stale_after للحقائق التي تتغيّر بسرعة (الأسعار، والمسؤولون، والحدود).
- اربط المستندات المتصلة بروابط markdown تبدأ من جذر الحزمة: [التسرّب](/metrics/churn.md).
- أضف إلى log.md سطرًا عن كل تغيير: التاريخ، والملف، وماذا تغيّر ولماذا.

4. سجّل أصل كل مستند

الـ frontmatter هو ما يجعل العقل جديرًا بالثقة. وتعرّف OKF حقولًا للأسئلة الأربعة أعلاه بالضبط: generated (من كتبه ومتى)، وverified (من راجعه)، وsources (من أين جاءت الادعاءات)، وstale_after (متى يحتاج إلى فحص جديد).

---
type: Decision
title: الخطط السنوية تمنح شهرين مجانًا
description: لماذا يساوي السعر السنوي 10 أضعاف الشهري، ومتى نعيد النظر فيه.
status: stable
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sara, at: 2026-09-21T14:30:00Z }
stale_after: 2027-03-31T00:00:00Z
sources:
  - id: pricing-review
    resource: /meetings/2026-08-14-pricing-review.md
    author: human:sara
---
 
سعر الخطة السنوية عشرة أضعاف السعر الشهري.[^pricing-review]
نعيد النظر في ذلك نهاية الربع الأول، بعد أن تصلنا أرقام التسرّب.

وتُكتب أسماء الفاعلين بصيغة ثابتة: وكيل مع إصداره (claude-code/2.1)، أو شخص (human:sara)، أو عملية (process:billing-sync). فيستنتج القارئ مستوى الثقة في المستند من قائمة verified، بدل أن يثق بوسم. وعن عرف الحواشي، راجع كيف تجعل الوكلاء يستشهدون بمصادرهم.

5. انطلق مما لديك أصلًا

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

6. راجع كل تغيير قبل أن يعتمد عليه أحد

هذه هي الخطوة التي تتخطّاها معظم الفرق، وهي الخطوة التي تهمّ فعلًا. على الوكلاء أن يفتحوا طلب دمج (pull request)، أو أن يتركوا تغييراتهم دون commit، بدل أن يكتبوا مباشرة في الفرع الرئيسي. ثم يقرأ شخصٌ الـ diff، ويتحقّق من المصدر المستشهَد به، ويضيف مدخله في verified حين يكون التغيير صحيحًا. وما الذي تبحث عنه في المراجعة؟ يشرحه دليل كيف تراجع تعديلات الوكلاء.

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

في Knowtarium

يتولّى Knowtarium الاتجاهين حيث تفعّل المراجعة («Ask me first»، لمساحة عمل كاملة أو لمجلد). هناك ينتظر تغيير الوكيل على شكل diff حتى توافق عليه، وموافقتك تضيفك إلى verified. وينتظر تعديلك أنت حتى تطلب من وكيل أن يراجعه («راجع تعديلات اليوم»)، والمستند الذي راجعه الطرفان منذ آخر تغيير فيه يصبح موثَّقًا بالكامل. وفي كل مكان آخر، تُحفظ تغييرات الوكلاء فورًا، موقَّعةً ويمكن التراجع عنها.

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

7. اجعل للحداثة موعدًا ثابتًا

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

في Knowtarium

في Knowtarium، تسرد صفحة Stale and expiring المستندات التي تجاوزت stale_after والتي يقترب موعدها، ويستطيع الوكلاء أن يطلبوا القائمة نفسها، جاهزةً لإعادة الفحص.

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

8. أعطِ الوكلاء جميعًا المدخل نفسه

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

هذا هو البناء نفسه وKnowtarium جزء منه، نتتبّع فيه قرار التسعير من المثال أعلاه. لا يحلّ Knowtarium محلّ وكيلك. إنه المكان الذي تُحفظ فيه المستندات، مشفّرةً تشفيرًا تامًا بين الطرفين، وترى فيه ما فعله كل وكيل، وتقرّر فيه ما يُعدّ مراجَعًا.

استورد مجلد company-brain إلى مساحة عمل، واربط وكلاءك بالأمر npx knowtarium connect، وفعّل المراجعة للمجلدات التي تُحسم فيها أمور المال، مثل company/decisions/.

1. دع وكيلًا يكتب، ثم انظر ما الذي تغيّر. اطلب من الوكيل أن يحوّل ملاحظة اجتماع التسعير إلى مستند قرار. ولأن المراجعة مفعّلة في ذلك المجلد، ينتظر التغيير على شكل diff، موسومًا بأنه غير موثَّق. اقرأه، وافتح ملاحظة الاجتماع المستشهَد بها، ثم وافق عليه: يضيفك Knowtarium إلى verified مع الوقت. وإن كان خاطئًا، فارفضه مع تعليق. أما في المجلدات التي لا مراجعة فيها، فيُحفظ التغيير فورًا، موقَّعًا من الوكيل ومعلَّمًا على المستند، وزر Undo على بُعد نقرة.
2. عدّل حقيقة بنفسك، ودع وكيلًا يراجعها. لنفترض أن خصم الخطة السنوية تغيّر. تعدّل القرار في Knowtarium، فيُوقَّع التغيير باسمك، وينتظر مراجعة وكيل. قل لوكيلك «راجع تعديلات اليوم»: فيقرأ الـ diff، ويتتبّع الروابط إلى مستندات مثل plans-and-limits.md، ويصلح الرقم القديم أو ينبّه إليه أينما بقي. وحين تُسجَّل المراجعتان، يصبح القرار موثَّقًا بالكامل.
3. راقب الحداثة. تنتهي صلاحية القرار في 31 مارس 2027. تُدرجه صفحة Stale and expiring حين يقترب التاريخ، ثم تُدرجه متقادمًا بعد أن يمرّ، حتى يحدّثه أحد. والتحديث تغيير جديد، فيحظى بنظرة ثانية خاصة به.
4. خذه معك. صدّر مساحة العمل أو مجلدًا منها بصيغة markdown عادية متى شئت. ومدخلات verified تنتقل مع الملفات، فيرى كل من يقرؤها من راجع ماذا، في أي محرّر.

عقل الشركة المبني من ملفات markdown في git يُشارَك كما تُشارَك الشيفرة: عبر المستودع. ينسخه الجميع، ويعدّل الوكلاء والناس الملفات، وتصل التغييرات عبر commits وطلبات الدمج. يوفّر git السجل والفروع وتعارضات الدمج، وتوفّر منصة git التي تستضيفه التحكّم في الوصول.

وهنا تحديدًا يجدر بنا أن نكون دقيقين في ما يفعله Knowtarium اليوم وما لا يفعله.

• مشاركة الفريق لم تُبنَ بعد. حساب Knowtarium ومساحات العمل فيه تخصّ شخصًا واحدًا: لا مساحات عمل مشتركة، ولا صلاحيات للأعضاء، ولا تحرير مشترك في الوقت الفعلي. مساحات العمل المشتركة في خطّتنا، لكن ليس في الإصدار الأول.
• ما تستطيع مشاركته هو الملفات. حين توافق على تغيير في Knowtarium، يُضاف اسمك والوقت إلى قائمة verified في ذلك المستند. صدّر مساحة العمل بصيغة markdown عادية وضعها في مستودع، فيرى كل من يقرؤها المراجعة، أيًّا كانت الأداة التي يفتح بها الملف. لكنها نسخة، لا رابط حيّ.
• شخص واحد، وأكثر من وكيل. تستطيع أن تربط عدة وكلاء (Claude Code وCodex وCursor وClaude Desktop)، كلًّا بمساحة عمل واحدة أو ببعض مجلداتها فقط، للقراءة فقط أو للقراءة والكتابة. ويُظهر كل تغيير أي وكيل أجراه، وإلغاء وصول أحدهم يقطعه فورًا.
• لا يحتاج إليه الجميع. الزملاء الذين لا يراجعون أبدًا يستطيعون قراءة الملفات المصدَّرة في محرّرهم، أو تصفّحها على منصة git، أو ترك وكلائهم يقرؤونها.

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

• إدخال كل شيء. حين تُلقي كل قناة وكل صندوق بريد في العقل، تدفن الأجوبة المحسومة تحت النقاشات. التقط القرارات والتعريفات، واربط المادة الخام مصدرًا لها.
• لا سجل للمنشأ. حين تعجز عن معرفة أي المستندات كتبها وكيل ولم يراجعها أحد، يصير عليك أن تشكّ فيها كلها.
• وكلاء يوافقون على وكلاء. أن يؤكّد وكيل ثانٍ عمل الأول أمر مفيد، لكنه ليس مراجعة شخص. أبقِ الأمرين منفصلين.
• لا تواريخ انتهاء. الأسعار والمسؤولون والحدود والهياكل التنظيمية تتقادم خلال أشهر. ومن دون stale_after، تبدو المستندات المتقادمة مثل الحالية تمامًا.
• الاستشهاد بما يختفي. رابط إلى رسالة محادثة، أو إلى اجتماع لم يسجّله أحد، ليس مصدرًا. احفظ المصدر في المستودع (ملاحظة اجتماع أو ملفًا مصدَّرًا) واستشهد بالملف.
• لا مسؤول. لا بد أن ينظر أحد في ما غيّره الوكلاء. وإن صارت المراجعة مهمة الجميع، فلن يقوم بها أحد.