تواجه هندسة الفوضى في البيئات الإنتاجية تحدياً جوهرياً يتمثل في فجوة بين ما يعرفه النظام من مخاطر وما يجب عليه تعلمه. على الرغم من وجود أدوات ناضجة لضمان السلامة، مثل الحد من الميزانية الخطأ والظروف للإيقاف التلقائي، فإنها لا تجيب على السؤال الأهم: هل اختبر التجربة الجاهزة للتحقق من فرضية صحيحة حول سلوك النظام؟ معظم الأدوات الحالية تكتفي بالتحقق من أن التجربة آمنة ولم تتجاوز الحدود الميزانية، دون التأكد من أن النتيجة غيّرت فهم الفريق لكيفية انتشار الأعطال. تستند هذه الفجوة الهيكلية إلى فصل بين طبقة السلامة وطبقة النية. طبقة السلامة تحدد مقدار الكسر المسموح به، بينما تحدد النية ما سيتعلمه الفريق من هذا الكسر. دمج هذين المفهومين في أدوات نصوص ثابتة يؤدي إلى تراكم سكريبتات اختبار لا تولد رؤى جديدة. تظهر الملاحظات من خبراء في شركات مثل Intuit وGPTZero وCoders.dev أن الأدوات الحالية تركز على الميكانيكا فقط، مثل إنهاء حاويات معينة، دون فهم السبب المنطقي أو الفرضية وراء ذلك. هذا يعني أن المهندسين يكتبون فرضيات في وثائق خارجية لا يتفاعل معها أداة الاختبار، مما يؤدي إلى تكرار الاختبارات وفقدان الفرضيات عند مغادرة الموظفين أو تغير بنية النظام. لحل هذه المشكلة، يقترح نموذج هندسة الفوضى القائمة على النية، الذي يُستند إليه ببراءة اختراع أمريكية، نظاماً يتكون من أربعة طبقات. أولاً، يقوم مولد التجربة باستنتاج الاختبار المناسب بناءً على مواصفات النية بدلاً من الاعتماد على نصوص ثابتة. ثانياً، يضيف مقيّض السلامة سياقاً سلوكياً لحساب منطقة الانفجار. ثالثاً، يسجل النتائج لتحديث نموذج النظام بدلاً من مجرد تدوين ملاحظات ما بعد الحوادث. يعتمد هذا النظام على مواصفات واضحة تتضمن الفرضية، معايير القبول، ونطاق الحظر، مما يسمح للنظام بتحديد المكونات الحرجة في مسار سلوك مستخدم محدد وتجنب المكونات غير المهمة. يختلف هذا النهج جذرياً عن التقييم الثابت للسلامة، حيث يعتمد على تقييم مرونة النظام في الوقت الفعلي. بدلاً من الاعتماد على عتبات ثابتة، يقوم النظام بحساب "ميزانية المرونة" التي تقيس كم إضافية من الضغط يمكن للنظام امتصاصه قبل أن تبدأ السلوكيات خارج نطاق التجربة في التدهور. كما يأخذ في الاعتبار سياق المستخدم؛ فقد يكون نفس الخطأ تقنياً كارثياً في سياق تسجيل الدخول، بينما يكون غير ملحوظ في سياق آخر. يمتد هذا المفهوم ليشمل الإشارات التجارية، حيث يمكن إيقاف التجربة فورياً إذا انخفضت الإيرادات الفعلية، مما يجعل اختبار الفوضى مرتبطاً بالقيمة الملموسة للعمليات بدلاً من مقاييس الخادم فقط. تؤكد هذه المقاربة أن المشكلة ليست مجرد هندسة برمجيات أو أوركيسترة، بل هي مشكلة ذكاء اصطناعي تتطلب نماذج تعلم لفهم السببية في انتشار الأعطال. لا يمكن للأدوات الحالية تفسير سبب تصاعد الخطأ في طوبولوجيا معينة بناءً على ملاحظات عابرة. لإغلاق هذه الفجوة، يحتاج المجال إلى تبني ثلاثة متطلبات: توحيد مقياس مواصفات النية ليصبح قابلاً للقراءة الآلية، توثيق نتائج التجارب بشكل منظم وقابل للاستعلام لتغذية النماذج التنبؤية، وإنشاء مؤشرات لجودة الفرضية تقيس مدى تغيير النتيجة لفهم الفريق للنظام، وليس مجرد غطاء الاختبار أو بقاء النظام. بدون هذه البنية التحتية، ستظل برامج هندسة الفوضى مجرد تراكم للسكريبتات دون تراكم حقيقي للمعرفة.