الالتزام الذي يجيب عنه سجل التغييرات ليس مكتوباً في صورة مهلة، وهو أصعبها استيفاءً بأثر رجعي: ستسأل جهة رسمية عمّا كان سجلكم ينص عليه في تاريخ مضى، وربما قبل سنوات.

تُجمّد كل لقطة ما كان السجل ينص عليه في تلك اللحظة وتختمه ببصمة SHA-256. ولا يستطيع أحد تعديل اللقطات أو حذفها، ولا حتى مدير يملك كل صلاحية أخرى في قاعدة البيانات. وهذه ليست صلاحية عجزتم عن العثور عليها — بل هي مقصد الميزة نفسها.

المحادثة وسجل التغييرات يجيبان عن سؤالين مختلفين. فالمحادثة تخبركم أن شيئاً تغيّر ومن غيّره. أما سجل التغييرات فيخبركم بما كان السجل ينص عليه في تاريخ بعينه. الأول نافع خلال الأسبوع. والثاني هو ما تطلبه الجهة بعد سنوات، ولا تعيد بناءه أي كمية من المحادثة.

تسجيل شخص يخرج ثم يعود. يتوقف شخص عن كونه مالكاً مستفيداً حقيقياً ثم يعود — نقل ملكية عائلي يُعكس، أو اتفاقية مساهمين تنقضي ثم تُجدَّد. سجّلوا تاريخ الانتهاء على القيد الأول وأنشئوا قيداً جديداً للفترة الثانية. ويبقى كلاهما في السجل. أما الكتابة فوق القيد الأصلي بتواريخ جديدة فتنتج قيداً يُظهر ملكية متصلة، وهو غير صحيح، ويمحو الفجوة التي يريد المراجع رؤيتها تحديداً.

مثال عملي. صار لدى Al Mirfa Contracting LLC الآن أربع لقطات: التفعيل في 11 مارس 2026، واكتمال السجل في 20 مارس 2026، والإخطار بتغيير الملكية في 14 يوليو 2026، وطلب الجهة الرسمية في 5 أكتوبر 2026 الذي يتناوله الدرس التالي. وحين تُسألون في 2031 عمّا كان السجل ينص عليه في يونيو 2026، تقرؤون اللقطة المأخوذة في 20 مارس 2026، لأنها ظلّت السارية حتى تغيير يوليو. لا تعيدون بناءه، ولا تعتمدون على ذاكرة أحد.

نقطة احتفاظ تستحق أن تطرحوها على مستشاركم. لأن اللقطات لا تُحذف، تبقى البيانات الشخصية المسجَّلة فيها ما بقي السجل. ولا يوثّق دليل المستخدم أي آلية تطهير، فلن تصف هذه الدورة آلية. وبالنظر إلى ما تحويه هذه القيود، قرّروا عن قصد من يحمل UBO: مدير، وراجعوا تلك القائمة كلما تغيّرت أدوار الأشخاص.

العطل الشائع. «لا يمكن تعديل لقطة السجل» هو السلوك المقصود. خذوا لقطة جديدة؛ وتبقى القديمة. وإن حوت لقطة خطأً حقيقياً، فالإصلاح الصحيح قيد حالي مصحَّح مع الأثر الذي يبيّن متى اكتشفتموه — لا ماضٍ يُعاد كتابته.