أحيانًا أكتشف أن أكثر ما يجعل شركة ما في مشكلة ليس لأن لا أحد مسؤول، بل لأن الجميع يتحمل مسؤولية “جزء بسيط” فقط. يظن المنتج أن فريق التطوير أكد الأمر، ويرى التطوير أن فريق العمليات قد وافق عليه بالفعل، وتعتقد العمليات بدورها أن الشؤون القانونية لن يعترض. وفي النهاية عندما تحدث المشكلة، يكون الجميع قد شارك بدرجة ما، لكن لا يستطيع أحد أن يوضح بالضبط في أي خطوة حدث الخلل.
لاحقًا رأيت @NewtonProtocol تصميمًا صغيرًا جدًا، ففكرت فجأة في أنني لم أكن أولي اهتمامًا كافيًا لـ Authorization Receipt. كنت أعتقد أنها مجرد فاتورة/إيصال يُولَّد بعد اكتمال التنفيذ، شبيهة بسجلات التنفيذ وإشعارات الاستلام، وأن فائدتها الأساسية هي الحفظ والأرشفة. لكن كلما تابعت أكثر، أدركت أن مكان ظهورها غريب جدًا.
ليست موجودة في نهاية سير العمل، بل تأتي مع Authorization وPolicy وOperator، لتصبح جزءًا من عملية التنفيذ برمتها. ثم أعادت قراءة هذا المقطع عدة مرات، ولم أكتشف أن فهمي الأول كان منحرفًا. كانت أنظمة كثيرة تحفظ النتائج سابقًا: نجحّت المعاملة، وتم تحويل الأصول، وتم تحديث الحالة… وكلها تترك سجلات. لكن عندما تحدث مشكلة فعلًا، غالبًا ما يستمر الناس في التساؤل: من الذي وافق؟ وبأي قاعدة؟ هل تم القفز فوق خطوة ما؟ هذه المعلومات، كثيرًا ما لا يمكن الحصول عليها إلا عبر تجميعها شيئًا فشيئًا من السجلات.
يبدو أن Newton كان يعالج هذه المشكلة دائمًا. فـ Authorization Receipt لا يسجل فقط أنه تم التنفيذ. بل يربط سلسلة كاملة: ترخيص واحد، وPolicy المقابلة، وOperator الذي نفذها، والنتيجة التي انتهت إليها العملية.
مستقبلًا، إذا شكك أي شخص في هذه العملية، لا يحتاج النظام إلى إعادة الوثوق بعقدة بعينها، ولا يحتاج إلى السؤال عن فريق العمليات. يكفي أن يعيد التحقق على طول هذه السلسلة المسجلة، وأن يجد سبب صحة كل خطوة ويمتلك الأساس المقابل لها.
عندما رأيت ذلك، أدركت فجأة أن Receipt في Newton لا يشبه “إيصالًا” كما في العادة، بل يشبه “سلسلة مسؤولية” لعملية تنفيذ.
لذلك، عندما أعود للنظر في Authorization Receipt الآن، أعتقد أن ما يتركه فعلًا ليس مجرد سجل.
إنه يترك كل الأدلة اللازمة لعملية تنفيذ كاملة—من الترخيص إلى الحكم ثم إلى الاكتمال. وربما ليس ما يمكن الوثوق به على المدى الطويل هو عقدة واحدة أو منصة بعينها، بل تلك العملية نفسها التي يمكن لأي شخص إعادة التحقق منها.
#newt $NEWT
لاحقًا رأيت @NewtonProtocol تصميمًا صغيرًا جدًا، ففكرت فجأة في أنني لم أكن أولي اهتمامًا كافيًا لـ Authorization Receipt. كنت أعتقد أنها مجرد فاتورة/إيصال يُولَّد بعد اكتمال التنفيذ، شبيهة بسجلات التنفيذ وإشعارات الاستلام، وأن فائدتها الأساسية هي الحفظ والأرشفة. لكن كلما تابعت أكثر، أدركت أن مكان ظهورها غريب جدًا.
ليست موجودة في نهاية سير العمل، بل تأتي مع Authorization وPolicy وOperator، لتصبح جزءًا من عملية التنفيذ برمتها. ثم أعادت قراءة هذا المقطع عدة مرات، ولم أكتشف أن فهمي الأول كان منحرفًا. كانت أنظمة كثيرة تحفظ النتائج سابقًا: نجحّت المعاملة، وتم تحويل الأصول، وتم تحديث الحالة… وكلها تترك سجلات. لكن عندما تحدث مشكلة فعلًا، غالبًا ما يستمر الناس في التساؤل: من الذي وافق؟ وبأي قاعدة؟ هل تم القفز فوق خطوة ما؟ هذه المعلومات، كثيرًا ما لا يمكن الحصول عليها إلا عبر تجميعها شيئًا فشيئًا من السجلات.
يبدو أن Newton كان يعالج هذه المشكلة دائمًا. فـ Authorization Receipt لا يسجل فقط أنه تم التنفيذ. بل يربط سلسلة كاملة: ترخيص واحد، وPolicy المقابلة، وOperator الذي نفذها، والنتيجة التي انتهت إليها العملية.
مستقبلًا، إذا شكك أي شخص في هذه العملية، لا يحتاج النظام إلى إعادة الوثوق بعقدة بعينها، ولا يحتاج إلى السؤال عن فريق العمليات. يكفي أن يعيد التحقق على طول هذه السلسلة المسجلة، وأن يجد سبب صحة كل خطوة ويمتلك الأساس المقابل لها.
عندما رأيت ذلك، أدركت فجأة أن Receipt في Newton لا يشبه “إيصالًا” كما في العادة، بل يشبه “سلسلة مسؤولية” لعملية تنفيذ.
لذلك، عندما أعود للنظر في Authorization Receipt الآن، أعتقد أن ما يتركه فعلًا ليس مجرد سجل.
إنه يترك كل الأدلة اللازمة لعملية تنفيذ كاملة—من الترخيص إلى الحكم ثم إلى الاكتمال. وربما ليس ما يمكن الوثوق به على المدى الطويل هو عقدة واحدة أو منصة بعينها، بل تلك العملية نفسها التي يمكن لأي شخص إعادة التحقق منها.
#newt $NEWT