الاحتجاز عبر البيانات لا يتعلق بالبيانات ذاتها، بل بما تجذبه؛ وجعل البيانات وحدها قابلة للعكس يترك البنية التي تُبقي قائمة سليمة.

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

طالما جعلت الصيغة الاحتكارية التاريخية لـSnowflake (micro-partitions) البيانات غير قابلة للقراءة خارج المنصة. تخفف عملية اعتماد صيغة Apache Iceberg المفتوحة مؤخرًا هذا القيد دون إزالته: تبقى الفهارس (catalogs)، في تكوينات عديدة، مُدارة من قِبل Snowflake، وتُطبَّق تكاليف مغادرة عند تنفيذ أي معالجة في مكان آخر. تُجسّد البيئة الأصلية — Marketplace، والتطبيقات الأصلية، وحلّ الهوية المنفَّذ في مكانه — الجاذبية في فعلها: فالحوسبة والخدمات الخارجية هي ما يأتي إلى البيانات، لا العكس.

تقابل Databricks اتهام الاحتجاز بحجة انفتاح بالتصميم: Delta Lake مفتوح المصدر منذ نشأته، وUnity Catalog نفسه مفتوح المصدر، وقابلية تشغيل بيني مُدَّعاة مع صيغتي Iceberg وParquet. تتناول هذه الحجة الطبقة الصحيحة لكنها لا تتناول السؤال الصحيح. لم تعد الجاذبية تكمن في امتداد الملف — وهو منفتح فعلاً — بل في مركزة مستوى الحوكمة: فهرس بيانات وصفية (metastore) وحيد، ونظام تتبّع نَسَب (lineage) وحيد، وسياسات وصول تُحدَّد مرة واحدة لكل الاستخدامات. مغادرة المنصة تترك الملف متاحًا؛ لكنها لا تُعيد لا رسم بياني تتبّع النَسَب ولا بنية الحوكمة التي كانت تحكم الوصول إليه، والتي يجب إعادة بنائها بالكامل في مكان آخر. صيغة مفتوحة على مستوى الملف لا تعني مركز جاذبية مفتوحًا على المستوى التنظيمي.

يتيح التكامل الأصلي بين BigQuery وVertex AI وLooker تدريب النماذج وتنفيذها مباشرة بلغة SQL، دون تصدير مسبق للبيانات. يسمح BigQuery Omni باستجواب بيانات موجودة خارج Google Cloud، لكن تنسيق هذه الخدمة يبقى مُدارًا من Google Cloud. الفجوة ليست تعاقدية فقط: بأسعار عام 2026 القياسية، تتراوح رسوم مغادرة الإنترنت التي تفرضها Google Cloud بين 0.08 و0.12 دولار لكل غيغابايت حسب شريحة الحجم، وتصل إلى 0.23 دولار لكل غيغابايت للعبور بين القارات — أي، لكل بيتابايت مُصدَّر، ما بين 80,000 وأكثر من 200,000 دولار كمرتبة قياسية. أما المعالجة في مكانها، ضمن المنطقة ذاتها، على خدمة أصلية من Google عبر الوصول الخاص إلى Google (Private Google Access)، فلا تستدعي بالمقارنة أي رسوم مغادرة. يعزز زمن النقل هذه الملاحظة: بمعدل مستدام قدره 10 غيغابت/ثانية، يتطلب نقل بيتابايت واحد نحو تسعة أيام من النقل المتواصل — وهو حدّ فيزيائي نظري أدنى، محسوب دون تدهور أو تنازع أو انقطاع، وبالتالي هو سقف أدنى لا متوسط مُلاحَظ. إن مجرد بلوغ هذا الحد النظري لمقياس الأسبوع كافٍ وحده لتقويض الجدوى التشغيلية لأي خط معالجة خارجي مبني على مجموعة البيانات هذه: فلا أي تحسّن واقعي لشروط النقل سيُعيد هذا التأخير إلى مقياس المليثانية الذي تتطلبه المعالجة في مكانها. الاحتجاز الناتج عن ذلك لم يعد حينئذ سياسة تسعير قابلة للعكس، بل نتيجة لفيزياء النقل ذاتها. لذا فإن Vertex AI وLooker محفَّزان بنيويًا لتشغيل بيانات مقيمة أصلاً في BigQuery ليس بخيار تعاقدي، بل لأن تكلفة وزمن أي سيناريو آخر قابلان للقياس ومُثبِّطان على مقياس البيتابايت.

استندت آلية تكاليف التغيير التي صاغها كليمبرر (1987)، في مكوّنها الأكثر قابلية للتقدير المباشر، إلى قدرة المزوّد القائم على فرض رسوم على المغادرة ذاتها — ضريبة الاستخراج الشبكي الموثقة في I.2 بالنسبة لـSnowflake وDatabricks وBigQuery. تُحيِّد المادة 29 هذا المكوّن تحديدًا: اعتبارًا من 12 يناير 2027، لن تستطيع أي منصة معارضة مرتبة قياسية تتراوح بين 80,000 وأكثر من 200,000 دولار لكل بيتابايت مُصدَّر لردع تغيير المزوّد. على هذا البُعد التعريفي المحدد، يعمل الدرع التنظيمي.

أثبت الفصل I.2، بالنسبة لـDatabricks، أن الجاذبية لم تعد تكمن في صيغة الملف — المنفتحة فعلاً — بل في مركزة مستوى الحوكمة: فهرس بيانات وصفية وحيد، ونظام تتبّع نَسَب وحيد. بالنسبة لـBigQuery، تنبع الجاذبية من التكامل الأصلي مع Vertex AI وLooker. لا فهرس ورسم تتبّع النَسَب لفهرس حوكمة، ولا نماذج التعلم الآلي المدرَّبة على البيانات في مكانها، ولا لوحات المتابعة وخطوط المعالجة المبنية على هذا التكامل الأصلي، تندرج ضمن «الخدمة الأساسية» التي تفرض المادة 30 جعلها متكافئة وظيفيًا في مكان آخر. تنطبق حرية المغادرة التي حصلت عليها المادة 29 على نقل البيانات؛ ولا تمتد إلى إعادة بناء ما تجمّع حولها.

تفترض الآلية الموثقة في I.1 كتلة متراكمة في نقطة واحدة. تتمثل الاستجابة البنيوية الأولى في منع تشكّل مثل هذه النقطة الوحيدة: توزيع رصيد البيانات وفق حدود المجالات التجارية بدلاً من تجميعه في مستودع تحليلي وحيد، بحيث لا تتجاوز أي مجموعة فرعية بمفردها الحجم الحرج الذي يُطلق الديناميكية الجاذبية.

تُخزَّن بيانات كل مجال بصيغة جدول مفتوحة، قابلة للاستعلام مباشرة من قِبل أي محرك حوسبة متوافق، دون تكرار مسبق في الصيغة الاحتكارية لمنصة معينة. أثبت الفصل I.2، بالنسبة لـDatabricks، أن انفتاح صيغة الملف وحده لا يكفي لإزالة الجاذبية إذا بقي فهرس الحوكمة — فهرس البيانات الوصفية، وتتبّع النَسَب، والتحكم في الوصول — مستضافًا ومُشغَّلاً من قِبل مزوّد وحيد. يعتبر هذا الاقتراح إذن أن طبقة الحوكمة نفسها يجب أن تكون قابلة للاستضافة بشكل مستقل عن أي محرر وحيد، وإلا فإن الفصل على مستوى الملف لن يفعل سوى نقل الجاذبية طبقة إلى أعلى، دون إزالتها — الآلية ذاتها الموثقة في I.2.

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

أثبت الفصل الأول أن البيانات المتراكمة تمارس جذبًا فيزيائيًا واقتصاديًا على الحوسبة والخدمات المحيطة بها، بمعزل عن أي بند يعالج البيانات وحدها. أثبت الفصل الثاني أن قانون البيانات الأوروبي يُحيِّد فعليًا المكوّن التعريفي لهذه الآلية، لكنه يترك خارج نطاقه طبقة الحوكمة وفهرس البيانات الوصفية والنماذج المتراكمة فوق الخدمة الأساسية. يستجيب الفصل الثالث تحديدًا لهذا الحد عبر التجزئة المتعمدة وفصل الحوسبة عن البيانات بالتصميم، بالتكلفة المذكورة في III.3: التضحية بالأداء العابر للمجالات والاتساق الشامل.

بقيت نقطة واحدة مفتوحة عند التأطير، تتعلق بالفصل I.2: هل تُسمّى الجهات الثلاث منذ المسودة الأولى، أم يُحتفظ بآلية عامة إلى حين تأطير لاحق من Gemini؟ حسم أمين الأمر بتسميتها فورًا، مما أطلق، قبل أي كتابة، بحثًا مستقلًا عن كل جهة من الجهات الثلاث — صيغة تخزينها، وفهرس حوكمتها، وتعريفات مغادرتها الشبكية — بدلاً من دمجها من الذاكرة.

شمل التصحيح المطلوب نقطتين متمايزتين. من جهة، إعادة التكييف الصريحة للقصور الذاتي الحركي كامتداد يقترحه هذا المجلد بدلاً من كونه نتيجة مباشرة لمكروري. ومن جهة أخرى، حقن مرتبة قياسية تجريبية بخصوص BigQuery: بدلاً من تقديم رقم من الذاكرة، تحقق بحث مستقل من تعريفات مغادرة Google Cloud لعام 2026 (0.08 إلى 0.23 دولار لكل غيغابايت حسب الوجهة) ومعدل مرجعي قدره 10 غيغابت/ثانية، مما أتاح حساب مرتبة قياسية تتراوح بين 80,000 وأكثر من 200,000 دولار لكل بيتابايت مُصدَّر، ثم زمن نقل نظري قدره نحو تسعة أيام، أُعيد تكييفه في خطوة ثانية ليُوصَف صراحةً بأنه حدّ فيزيائي أدنى لا متوسط مُلاحَظ.

أنتج هذا التدقيق الشامل توصية بإثراء نظري للقسم I.1 — مرجع إضافي يهدف إلى تعزيز الانتقال من الاعتماد البرمجي الفردي إلى الأسر عبر النظام البيئي للأطراف الثالثة. لم يتمكن بحث مستقل من تأكيد لا سنة المرجع المقترح ولا محتواه الدقيق. وبدلاً من دمجه تحت تحفظ، تم التخلي عن المرجع صراحةً: خلافًا للمجلد السابع، حيث أنتج التدقيق الشامل إثراءً دُمِج فعليًا (تيس، 1986)، أعقب التدقيق الشامل لهذا المجلد هنا سحبٌ، إذ تنطبق قاعدة التحقق الواقعي على توصية من التدقيق الشامل بالقدر ذاته الذي تنطبق به على أي مثال آخر مسمّى.