أثناء مراجعة وثائق @termix_ai، اكتشفت أن ليس كل وظيفة يمكن التحقق منها بنفس الطريقة. بعض المهام ثنائية: إما أن الكود يُكوّن أو لا يُكوّن. وبعض المهام ذات طابع ذاتي: هذا التصميم جيد أو سيء. يتعامل البروتوكول مع كلا النوعين باستخدام استراتيجيتين مختلفتين تمامًا للتحقق. **التحقق البرمجي** مخصص للعمل الموضوعي: تحويل البيانات، تجميع الكود، تكامل واجهات برمجة التطبيقات. يقدم الوكيل المنتج النهائي، ثم يُشغل النظام ثنائي RISC-V داخل zkVM. إذا كان أثر التنفيذ صالحًا، يتم تحرير الدفع. لا نقاش. لا رأي. فقط رياضيات. **التحقق حسب المعايير** مخصص للعمل الذاتي: الكتابة الإبداعية، التحليل الاستراتيجي، نقد التصاميم. تقوم عدة نماذج لغوية داخل TEE بتقييم المنتج النهائي وفقًا لمجموعة معايير محددة مسبقًا. لا يزال التقييم صارمًا، لكنه يسمح بالتفسير. • التحقق البرمجي أرخص وأسرع. ثق فقط في الرياضيات. • التحقق حسب المعايير يتعامل مع الأحكام المعقدة لكنه يستهلك المزيد من الغاز. • التحقق البرمجي ثنائي: نجاح أو فشل. • التحقق حسب المعايير ينتج درجة: كلما ارتفعت الدرجة، زادت المكافأة. يحدد العملاء الاستراتيجية عند إنشاء المهمة. غير قابلة للتغيير. لا تغيير في القواعد منتصف الطريق. ما أقدره هو المرونة. يمكن لوكيل مثل audit-factory.agent على https://t.co/RFxl1FJ1nT استخدام التحقق البرمجي للتحقق من الأمان. بينما يستخدم الوكيل الإبداعي التحقق حسب المعايير للمحتوى. البروتوكول يتكيف مع العمل، وليس العكس.