AI reality وOnchain necessity وToken necessity

ملاحظة: هذا المستند هو ترجمة آلية للنسخة الإنجليزية الأصلية.

تحتوي كل بطاقة مشروع على DecAIHub على قسم AI thesis fit يجيب عن ثلاثة أسئلة. تشرح هذه الصفحة معنى كل منها وكيفية قراءتها.

باختصار: هذه ثلاثة محاور لقابلية التحقق. تبيّن مدى دعم ادعاءات المشروع حول AI والبلوكتشين ورمزه — ولا تقول شيئاً عن السعر أو جاذبية الاستثمار.

AI reality — ما الذي هو AI فعلياً هنا

السؤال: هل للمشروع مكوّن AI حقيقي يعالج البيانات وينتج نتائجاً (يتعرّف، يوصي، يتنبأ، يولّد)، أم لم يُعثر حتى الآن على دليل قابل للتحقق على مكوّن AI يعمل.

ما يُفحص (تدريجياً):

AI_0 — هل يوجد على الأقل إعلان Tier-1 عن نية AI (خارطة طريق، تحديث رسمي).
AI_1 — هل يوجد وصف لما يفعله AI بالضبط.
AI_2 — هل توجد عروض توضيحية أو أمثلة عاملة.
AI_3 — هل توجد مقاييس جودة ومعايير مقارنة.
AI_4 — هل يوجد وصف تقني أو بنية أو إصدارات نماذج.

يتراوح ai_score الناتج بين 0 و 3. إذا كان ai_score = 0، فإن DecAI Fit يصبح تلقائياً 0: بلا مكوّن AI مؤكد بمصادر Tier-1، لا يحصل المشروع على DecAI Fit أعلى من 0 اعتباراً من تاريخ التحقق.

Onchain necessity — ما الذي هو على السلسلة فعلياً

السؤال: أي جزء من المشروع يعمل فعلياً على بلوكتشين، وأي جزء يعمل على خادم تقليدي.

ما يُفحص:

OC_1 — هل توجد عقود وعناوين وشبكة يمكن التحقق منها.
OC_2 — هل الاستخدام على السلسلة أكثر من الرمز فقط؛ هل يشمل منطقاً مفيداً (تحكم بالوصول، محاسبة، قواعد، DAO).
OC_3 — هل السلسلة حاسمة: إذا استُبدل البلوكتشين بقاعدة بيانات تقليدية، هل يفقد المنتج خاصية رئيسية (قابلية التحقق، مقاومة الرقابة، تسوية بلا ثقة).

يتراوح onchain_score الناتج بين 0 و 3. كلما ارتفع، ازداد اعتماد المشروع على البلوكتشين.

Token necessity — لماذا نحتاج الرمز

السؤال: أي دور محدد يلعبه الرمز في المنتج ومدى دعم ذلك الدور.

ما يُفحص:

TK_0 — لا يوجد رمز (إن وُجد، يحصل المشروع على token_score = 2: عدم وجود رمز لا يُعاقَب عليه).
TK_1 — يُستخدم الرمز لدفع الخدمات.
TK_2 — الرمز مطلوب للحوافز (مكافآت، staking، slashing).
TK_3 — الرمز مطلوب للحوكمة (تصويت).
TK_4 — الرمز قابل للاستبدال (يمكن استبداله بـ USDC أو اشتراك دون فقدان الوظائف).

يتراوح token_score الناتج بين 0 و 3. علامة TK_4 (القابلية للاستبدال) تخفّض الدرجة: إذا كان الرمز سهل الاستبدال، فضرورته موضع تساؤل.

كيف تقرأ الحالات الخاصة

ليست كل بطاقة تحتوي على إجابات واضحة على كل محور. إليك تفسير قيم الحالة:

القيمة في البطاقة	المعنى
`unknown`	لم يُعثر على معلومات في أي مصدر Tier. هذا لا يعني غياب التقنية — يعني أن الدليل لم يُعثر عليه بعد.
`no token`	ليس للمشروع رمز أصلي. حقيقة محايدة، ليست نقصاً.
`token use case not established`	يوجد رمز، لكن وظيفته المحددة داخل البروتوكول لم تُؤكَّد بمصادر Tier-1.
`positioning only`	يُذكر AI في التسويق أو التموضع، لكن لم يُعثر على دليل Tier-1 على مكوّن AI يعمل.
`none`	لم يُكتشف شيء لهذا الجانب. مثل `unknown`، هذا وضع قراءة للدليل، وليس تأكيداً على غياب التقنية.

كيف تندمج المحاور الثلاث في DecAI Fit

تُجمع الدرجات عبر أربعة مكوّنات (AI reality، Onchain necessity، Token necessity، و Evidence) وتُحوَّل إلى DecAI Fit النهائي على مقياس من 0 إلى 6:

0 — لم يُكتشف AI reality ولا نية AI استناداً إلى المصادر الموجودة.
1–2 — توافق منخفض مع أطروحة Decentralized AI.
3–4 — توافق متوسط.
5–6 — توافق عالٍ.

تُطبَّق أيضاً حدود حوكمة: مثلاً، بلا دليل Tier-1 لـ AI أو onchain، لا يمكن أن تتجاوز الدرجة 3.

لا تخلط بين

هذا ليس تقييماً مالياً. AI reality وOnchain necessity وToken necessity تقيس قابلية التحقق من ادعاءات المشروع، لا قيمته السوقية.
الدرجة المنخفضة ليست حكماً. قد يكون المشروع في مرحلة مبكرة لم يظهر فيها الدليل بعد. تسجّل البطاقة الحالة اعتباراً من تاريخ التحقق.