يمكن لسير العمل أن يكتمل بشكل مثالي ولا يزال يترك العالم الخارجي في حالة خاطئة. تخيل تطبيقًا تجاريًا ذاتيًا حول @RialoHQ يتلقى طلبًا على آخر قطعة متاحة في المخزون. يُكمل سير العمل بنجاح. يتم تسديد الدفع، ويتم تأكيد الطلب، ويتلقى العميل إيصاله. من منظور تطبيق البلوكشين، يبدو كل شيء مكتملًا. لكن واجهة برمجة تطبيقات المخزن لم تتلق أبدًا تحديث المخزون النهائي. حالة البلوكشين تقول الآن إن القطعة بيعت. أما المخزن فلا يزال يشير إلى وجود قطعة واحدة متاحة. بعد بضع دقائق، يقرأ نظام آخر مخزون المخزن ويسعى لبيع نفس القطعة مرة أخرى. لم يفشل شيء بالضرورة داخل المعاملة الأصلية. المشكلة هي أن نظامين من المفترض أن يصفا نفس الواقع قد انفصلا عن بعضهما البعض. هنا تصبح فكرة التوافق مثيرة للاهتمام عند التفكير في التطبيقات المبنية حول Rialo. عندما يتفاعل البرنامج مع واجهات برمجة تطبيقات خارجية، وقواعد بيانات، وأنظمة دفع، وخدمات أخرى في العالم الحقيقي، لا يعني التنفيذ الناجح دائمًا أن جميع الأنظمة المتصلة انتهت في الحالة المتوقعة. لذلك قد يحتاج التطبيق إلى التطلع أبعد من "هل نجح إجرائي؟" والسؤال في النهاية: "هل انعكس العالم الخارجي الآن كما كان ينبغي أن يحدث؟" إذا كان التطبيق يتوقع أن ينتقل المخزون من 1 إلى 0، فيمكنه مقارنة النتيجة المتوقعة مع الحالة المبلغ عنها من قبل النظام الخارجي. إذا كان المخزن لا يزال يبلغ عن وجود قطعة واحدة، فإن عدم التوافق يصبح شيئًا يمكن للتطبيق تحديده ومعالجته بدلاً من افتراض صمت أن كل شيء لا يزال متزامنًا. تظهر نفس المشكلة في المدفوعات، والحجوزات، والخدمات اللوجستية، والعديد من سير العمل الأخرى حيث يتفاعل تنفيذ البلوكشين مع أنظمة خارج السلسلة. وهذا يخلق تمييزًا مهمًا. التنفيذ يخبرك بما فعله التطبيق. التوافق يخبرك ما إذا كان الواقع انتهى حيث توقع التطبيق أن يكون. بالنسبة للتطبيقات التي تتصل بشكل متزايد بين تنفيذ البلوكشين والعالم الخارجي، يمكن أن يكون كلاهما مهمًا. لأن إكمال سير العمل شيء واحد. والتأكد من أن كل نظام متصل يتفق على ما حدث شيء آخر.