حدّ إعادة الإنتاج: نموذج قابل للاختبار لقياس استقلال استعادة التقنية عن المورد الأصلي

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

الأدلة: تشكل تجربة إصلاح برمجية المسبار (Voyager 1) عام 2024، ومسارات صيانة مركبات (Fisker Ocean) عقب إفلاس صانعها، وانتقال المعرفة لدى (VanMoof) خلال 2023–2026، حالات مختلفة لتمييز القدرة التقنية عن الجغرافيا وملكيات الأصول والحقوق. وتوفر (Reproducible Builds)، و(SLSA 1.2)، و(SPDX)، و(The Update Framework; TUF) آليات جزئية تتيح حفظ المعلومات أو إثبات المنشأ أو تأمين الإصدارات، لكنها لا تكفي كل واحدة منها وحدها لضمان استقلال إعادة التشغيل.

المنهج المنفذ: أنشئ برنامج (Python) تجريبي صغير واختباران سلوكيان، وبُنيت له حزمتان في مسارين مؤقتين منفصلين مع ثبات المدخلات وترتيب الملفات والطوابع الزمنية. تطابقت الحزمتان بايتاً ببايت؛ وأُنتجت التجزئة (SHA-256) نفسها في كلتيهما. كما فُحصت شجرة اصطناعية من 26 عقدة تشمل أصولاً محلية واحتياجات من المورد وأجزاء قابلة للاشتقاق. نُفذت ثماني حالات لمسارات الاستعادة، أربعة مع المورد متاح وأربعة في غيابه. في الحالة الثانية افتقرت مسارات الصورة التنفيذية والشيفرة المودعة والشيفرة مع أدوات بناء محلية إلى 3 و5 و3 مدخلات أولية على التوالي؛ واكتمل مسار نواة محمولة مفترضة بلا مدخلات مفقودة، مع افتراض الاحتفاظ بست من ثماني وظائف، دون ادعاء تطابقه الكامل مع الأصل.

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

الكلمات المفتاحية: الاستقلال التقني (Technical Independence)؛ حد إعادة الإنتاج (Reproduction Boundary)؛ استعادة الوظيفة (Functional Recoverability)؛ البناء القابل لإعادة الإنتاج (Reproducible Builds)؛ قائمة مكونات البرمجيات (SBOM)؛ أصول سلسلة البناء (Build Chain Assets)؛ الاعتماد على المورد (Supplier Dependence)؛ محاكاة التبعيات (Dependency Closure)؛ ميراث البرمجيات (Software Inheritability).

Question. Does owning a service's data, source code, or compiled image establish the practical ability to rebuild, modify, validate, or replace its essential function when the original supplier is unavailable? We introduce a proposed Reproduction Boundary: the last independently executable and verifiable transition within a service's source-to-operation chain, conditional on specified functionality, lawful access, build tools, cryptographic trust, hardware interfaces, skills, and testing.

Completed work. An original small Python demonstration service was packaged twice at separate temporary locations using identical explicitly fixed archive metadata. Its two SHA-256 digests and raw bytes matched, and two basic functional checks passed. An entirely synthetic 26-node dependency graph and four alternative restoration targets were evaluated both with and without vendor primitives, producing eight deterministic route checks. Under the stipulated supplier-absent condition, the archived-image, source-escrow and local-toolchain routes had respectively 3, 5 and 3 unavailable primitive prerequisites and could not complete. The assumed portable-minimum route had none but retained only six of eight stipulated features. These results are properties of an invented graph and toy package; they are not supplier-outage probabilities, measured Saudi systems, real security certifications, independent reproductions of production software, or restoration-time estimates.

Contribution and next study. The framework separates byte-level reproducibility, behavioral acceptability, authorization to deploy, and economic attractiveness. It identifies the data and authorized technical experiments needed to learn whether an independently exercised reconstruction capability predicts shorter or cheaper vendor-exit transitions than inventories, escrow commitments, or system redundancy alone. Proposed falsification and economic decision criteria are explicit; no causal estimate or validated national index is claimed.

Keywords: sovereign recoverability; independent rebuild; software supply chain; hermetic build; functional equivalence; digital maintenance; supplier disappearance; reproducible software; Saudi Arabia.

السؤال المركزي: ما الشروط التي تجعل جهة ما قادرة على إعادة إنتاج وظيفة تشغيلية محددة، قانونياً وتقنياً وبجودة يمكن إثباتها، من دون حضور المورد الأصلي الذي يوفر بعض أدواتها أو حقوق تشغيلها؟

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

إن وصف «السيادة الرقمية» قد يحمل أبعاداً قانونية وسياسية لا تدخل كلها في التصميم الهندسي. ولذلك تفصل الورقة ثلاثة أسئلة:

1. هل المادة موجودة؟ بيانات، شيفرة، نسخ تنفيذية، وثائق، صور تشغيلية، حزم وتعريفات.
2. هل المسار متاح وصحيح؟ أدوات، حق استعمال، مفاتيح توقيع مملوكة على نحو مشروع، عتاد قابل للاستبدال، اختبارات سلوك، خبرة بشرية.
3. هل الاستثمار في هذا المسار مجدٍ؟ تكلفة الاحتفاظ بالقدرة وتجديدها، وكلفة إعادة التطوير أو شراء بديل، ومقدار الضرر المتوقع من غياب المورد وطول عمر المنتج.

هذه الأسئلة ليست مستويات نضج تُمنح بالشعور؛ إنها اختبارات مختلفة بمقامات مختلفة.

1.1 ما الذي قد يغير الجواب؟

إن أثبتت دراسة مأذون بها أن نسخة من الشيفرة محفوظة لا تزيد عملياً قدرة فرق مستقلة على بناء إصدار صالح عند غياب المورد، فسيتغير تركيب عقود التطوير واهتمام الجهات من شراء مصدر وحده إلى احتفاظ قابل للفحص ببيئة البناء واختباراته، وربما إلى تطوير نواة قابلة للنقل. وبالمقابل، إذا أظهرت دراسات المقارنة أن أعباء المستودعات المستقلة تزيد الأعطال والكلفة دون تحسين فعلي في سرعة الاستعادة بالنسبة إلى فئة من الخدمات، فلا مسوغ لتعميمها.

1.2 الفرضيات المقترحة

• H1 (اكتمال المسار): في منتجات ذات اعتماديات مُرخّصة أو صعبة الاستبدال، يكون اجتياز اختبار إعادة البناء الفعلي متنبئاً بقدرة النقل والاصلاح بصورة أوضح من مجرد وجود نسخة للمصدر، بعد ضبط تعقيد المنتج وحجمه وفريقه.
• H2 (حدّ الوظيفة): ترتفع فرصة الحصول على بديل مقبول عندما تُعرف وظائف أساسية مستقلة عن الخصائص الثانوية قبل انقطاع المورد، لكن ذلك قد يخفض عدد الخصائص المتاحة.
• H3 (صلاحية الأصول عبر الزمن): يصبح حفظ المصدر أقل فاعلية إن لم تصاحبه آليات تحديث الحزم وبنى المترجمات وواجهات العتاد مع تقادمها.
• H4 (العائد المشروط): ليست كل خدمة جديرة بكلفة إعادة إنتاج مستقلة؛ القيمة تتفاعل مع أفق استعمالها وعمق تخصيصها وتوافر السوق البديلة وكلفة الخطأ.

الفرضية المضادة القوية: قد يكون شراء منتج بديل حديث وإعادة تصميم العمليات أكثر فعالية من إعادة بناء نظام قديم، وقد تكون الاعتماديات التجارية المدارة من مقدم ذي قاعدة عملاء كبيرة أقل خطراً من نسخة محلية قليلة الصيانة. ينبغي إتاحة هذين الاحتمالين في التجربة، لا عزلهما بوصفهما اعتراضاً سياسياً.

2.1 مسبار (Voyager 1): مسافة فيزيائية كبيرة وطرق إصلاح معرفية متاحة

أعلنت وكالة الفضاء الأمريكية (National Aeronautics and Space Administration; NASA) في 22 أبريل 2024 أن إرسال بيانات هندسية مفهومة استؤنف بعدما شخص مهندسون عطباً في جزء من ذاكرة نظام بيانات الرحلة (Flight Data Subsystem; FDS) وأعادوا توزيع قسم من الشيفرة وتعليماتها في مواضع أخرى. كانت المسافة تفوق 24 مليار كيلومتر، مع زمن انتقال إشارة يقارب 22.5 ساعة في الاتجاه الواحد. وكان أول نجاح عملي قابلاً للرصد في 20 أبريل. ثم أعلنت لاحقاً استئناف بيانات علمية من جهازين في مايو؛ لا يجوز دمج المرحلتين في «استعادة كاملة» لحظة أبريل. S01S02

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

2.2 المركبة (Fisker Ocean): المالك يصبح جزءاً من صناعة الصيانة

دخل صانع السيارات (Fisker) إجراءات الإفلاس عام 2024. في بيان مودَع في قضية الإفلاس بتاريخ 26 يوليو 2024، شرحت جمعية المالكين (Fisker Owners Association; FOA) حاجة الاستمرارية إلى الوصول للشيفرة وأدوات الصيانة والخدمات السحابية والقطع واتصالات المركبات، بصفتها طرفاً يسعى إلى اتفاق لا مصدراً محايداً لتقييم المخرجات. وتعرض صفحة متجر التطبيقات تطبيق (OceanLink Pro)، الذي طوّرته وتقدمه (Undercurrent Inc.) وتصفه بالتطبيق الرسمي لأعضاء الجمعية، بوظائف معلنة تختلف بحسب عتاد السيارة ونسخة البرامج. لا يثبت البيان ولا صفحة المنتج توقف جميع السيارات أو استقلال كل وظائفها. S08S09S10

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

2.3 (VanMoof): ثلاث صدمات مختلفة وعمر تقني مركب

يثبت تقرير أصلِي منشور من أمناء إفلاس (VanMoof) أن محكمة أمستردام (District Court of Amsterdam) أعلنت إفلاس كيانات هولندية تابعة لها في 17 يوليو 2023. في تلك الأيام نشرت منافستها (Cowboy) تطبيق (Bikey) يعلن حفظ مفتاح دراجات طراز (S3/X3) محلياً للحالات التي تتعذر فيها خدمات الشركة الأصلية. ركز وصف الإطلاق على هذه الطرز، فيما يسجل تاريخ الإصدارات إضافة دعم (A5/S5) لاحقاً؛ ولا يثبت ذلك دعماً شاملاً طويل الأمد لكل الطرز. S03S04

وفي 27 فبراير 2024 أعلن المالكون الجدد توسيع إتاحة تعليمات الصيانة والرسومات الفنية لأجيال من الدراجات عبر (VanMoof Archives)، مع توضيح أن بعضها كان سابقاً محصوراً بورش معتمدة. وتلك وثائق تخص إصلاحاً ميكانيكياً وإجرائياً، ولا تستلزم توافر جميع مخططات الإلكترونيات أو مفاتيح النشر أو ملكية البرمجيات. S05S06

وفي 2026 أعلن صانع الدراجة عن تغيير في اتصال طرز قديمة يعتمد على شبكة الجيل الثاني (2G)، مع تاريخ 1 أبريل كحد للاشتراك الذي يحافظ على تتبع السرقة لفئات محددة. وأوضح أن القفل والقيادة وسائر الوظائف المستقلة لا تتوقف. وينفصل هذا عن إفلاس 2023: الذي يتقادم هنا بنية اتصال خارج الجهاز حتى مع عودة العلامة والنشاط التجاري. S07

هذا التسلسل يوفر اختباراً مفاهيمياً لثلاثة أسباب متميزة: انقطاع كيان تجاري؛ انغلاق معرفة الصيانة؛ تقادم بروتوكول خارجي. لا ينبغي دمجها في كلمة «عطل» أو إلصاق نتائج أحدها بالآخر. ويمكن اعتبار مبادرة توسيع الأدلة حالة مضادة جزئية لفكرة أن كل مورد سيتصرف لمنع الاستمرار بعد إعادة الهيكلة.

2.4 الدليل السعودي: أصول قابلة للمشاركة، دون افتراض إمكانية البناء

تصف هيئة الحكومة الرقمية (Digital Government Authority; DGA) برنامج مستودع البرمجيات الحكومية السحابية (Government Cloud Software Repository; GPaaS) باعتباره وسيلة لتخزين وتبادل الشيفرات الحكومية الحرة ومفتوحة المصدر وتعزيز تطويرها. وتعرض الهيئة العامة للعقار (Real Estate General Authority; REGA) على موقعها متطلبات ودور البرمجيات المفتوحة ومنصة إيداع حكومية. S17S18

تلك الملاحظة مهمة لأنها تحدد نقطة انطلاق فعلية يمكن أن تقوم عليها اختبارات إعادة البناء، لا تدعي أن المنصة نفسها تقيس استقلال إعادة التشغيل أو أن جميع برمجيات المملكة فيها. ويلزم اختبار علني أو مأذون لعينات محددة قبل إصدار حكم على فعالية نقلها.

3.1 الحفظ طويل الأجل (Digital Preservation)

يركز أرشيف التراث البرمجي (Software Heritage) على تجميع أصول الشيفرة المفتوحة العامة وتاريخ تطورها وإتاحتها بمرجع قابل للتتبع. يختلف هذا الهدف عن توفير صورة كاملة لبيئة الإنتاج، أو ضمان بقاء المُترجم الذي استخدمته نسخة قديمة، أو وجود رخصة تسمح باستخدام كل اعتماد تجاري. S15

يمكن للأرشفة أن تنقذ أصلًا لا يعوض، لكن صورة المستودع وحدها قد تخلو من حزم خارجية وسجل إعدادات التشغيل وحالة قاعدة البيانات وقيم سرية يجب عدم إيداعها أصلاً. وقد لا تكون بعض الأجزاء قابلة للتوزيع قانونياً. ينبغي ترتيب الأصول إلى: مادة قابلة للحفظ والنشر، مادة قابلة للحفظ بموجب قيود، وأصول لا يجوز حفظها أو توزيعها خارج ضوابط مشروعة.

3.2 مطابقة الناتج للبناء (Reproducible Builds)

يعرّف مشروع (Reproducible Builds) البناء القابل لإعادة الإنتاج بأنه إعادة إنشاء نواتج متطابقة بايتاً بايتاً عند توفر الشيفرة والبيئة والتوجيهات ذاتها. وتشمل تفاصيل البيئة المؤثرة إصدارات الاعتماديات، ومتغيرات اللغة المحلية، والطابع الزمني، والمسار الذي يجري منه البناء. S11

ما يثبته التطابق: تحت الفرضيات والإعدادات المعطاة، يمكن إعادة توليد البايتات نفسها من مدخلات محددة. ما لا يثبته: خلو البرمجية من العيوب، أو أن المترجم غير ضار، أو إمكان استيراد البيانات، أو شرعية مفاتيح نشرها، أو قبول الهيئة المختصة استخدامها. إنهما برهانان من فئتين مختلفتين.

لا تقاس قابلية إعادة البناء دائماً بتطابق البتات؛ حين يستلزم ترحيل المنصة أو تغيير المعمارية اختلاف البايتات يكون معيار تكافؤ السلوك المقبول (Behavioral Equivalence) أنسب، ويحتاج إلى تعريف المدخلات والمخرجات وحدود الخطأ والاختبارات. لا ينبغي وصف تكافؤ السلوك بأنه تطابق ثنائي.

3.3 المنشأ ومكونات البرمجية (Provenance and SBOM)

تحدد مواصفة (Software Package Data Exchange; SPDX) أساليب لوصف أصول البرمجيات وروابطها وتراخيصها. وتقدم (Supply-chain Levels for Software Artifacts; SLSA 1.2) متطلبات وطبقات لتتبع منشأ مصدر الشيفرة ومنشأ البناء بدرجات ضمان مختلفة. لا تستلزم أي منهما أن يحصل الطرف الثاني تلقائياً على الحق أو القدرة لامتلاك جهاز التوقيع أو التفعيل أو المعالج. S12S13

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

3.4 أمن التحديث وبناء الثقة (Secure Software Update)

يصمم (The Update Framework; TUF) منهجاً للحد من مخاطر مفاتيح إصدار التحديثات ونسخها القديمة أو المصطنعة، باستخدام بيانات وصفية موقعة وصلاحيات مختلفة للمفاتيح وتواريخ انتهاء. وفي نهاية الأمر يظل تشغيل برنامج جديد على عتاد ما مشروطاً بقواعد الثقة لذلك العتاد. S14

المهم هنا التمييز بين امتلاك توقيع صحيح وامتلاك حق تغيير الجهة المصرح لها بالتوقيع. قد تمنع حماية تحديثات سليمة ملاحقة برمجية غير مأذونة، حتى لو حمل مالك الجهاز الشيفرة. لا ينبغي التعامل مع تجاوز هذه الحماية بوصفه «حل استعادة»؛ يلزم تصريح من مالك الحقوق أو تصميم سابق قابل للتحديث المشروع أو خيار عتاد بديل صالح.

3.5 الثقة في المُترجم (Trusting Trust)

أظهر كين تومبسون (Ken Thompson) في محاضرته (Reflections on Trusting Trust) كيف قد لا يكفي فحص الشيفرة وحدها لفهم ما تحمله النسخة التنفيذية إذا كانت أدوات إنتاجها محل شك. وطوّر ديفيد ويلر (David A. Wheeler) لاحقاً منهج تجميع مزدوج متنوع (Diverse Double-Compiling; DDC) لتفحص تطابق بعض المترجمات مع المصادر المقصودة وفق فرضيات محددة. S16S19

هذا ليس مطالبة كل جهة بإعادة كتابة كل مُترجم برمجي. لكنه يوضح أن «إمكان بناء البرنامج» مسألة قابلة للتجزئة إلى ضمانات: حفظ الأدوات؛ إمكانية الوصول إلى مصدرها؛ اختلاف جهات التحقق؛ صلاحية المترجم للمنصة؛ وتوافر برهان تحقق مناسب للمخاطر.

نعرف خدمة محددة s ووظيفة مقبولة f ضمن سيناريو فقدان مورد z. يتضمن مسار إنتاجها أصولاً أولية ومراحل مشتقة (Artifact Dependency Graph; ADG)، وقد تكون بعض الأصول مطلوبة أصلاً وبعضها بدائل اختيارية. لا يعد وجود علاقة اعتماد مثبتاً دون فحص المنتج الفعلي.

المتغيرات الأساسية:

• A(v,z): توافر أصل أو حق أو قدرة أولية v بصورة مشروعة ومستقلة في السيناريو z، قيمتها صفر أو واحد في النموذج الحتمي المبسط.
• Anc(r): مجموعة المتطلبات الأولية التي يعتمد عليها مسار إعادة إنتاج r، بعد تتبع الاعتماديات حتى جذورها.
• V(r): حكم مستقل على بلوغ المخرجات مستوى السلامة والسلوك المطلوب، وليس مجرد نجاح تجميع الملفات.
• L(r): حكم مستقل على شرعية تشغيل الطريق ونشره والاحتفاظ بأصوله وفق الاتفاق الساري.
• F(r): مجموعة الوظائف التي يمكن إثباتها عملياً بالمسار لا التي وعد بها في خطته.

نقترح قياس شرط أولي للبناء، خاصاً بكل مسار، بالصورة:

$$P_r = \prod_{v\in Anc(r)} A(v,z)$$

يعني أن P_r = 1 إذا كانت جميع متطلباته الأولية متاحة في ذلك السيناريو، وليس أن البرنامج ناجح أو آمن أو قانوني حكماً. أما اكتمال إعادة الإنتاج العملي فيحتاج فوق ذلك إلى تحقق V(r) وL(r)، ووجود الوظيفة f ضمن F(r). عندما تنجح طرق بديلة مستقلة قد يتوفر مسار صالح رغم فشل طرق أخرى.

نقيس في المثال المصطنع عدد الاعتماديات الجذرية المفقودة:

$$B_r = \sum_{v\in Anc(r)} (1-A(v,z))$$

هذا عدد عوائق لا وزن اقتصادي لها. فقد يكون عائق مفتاح واحد غير قابل للاستبدال أشد تعقيداً من عشرة ملفات مستعادة من مستودع آخر في دقائق. ولا نقارن رقم B_r وحده بين خدمات مختلفة دون تعريف الأصول وحدودها.

إذا أتيحت بيانات زمنية حقيقية، يمكن دراسة زمن استعادة الوظيفة بوصفه زمن أول نجاح لاختبار السلامة والاستعمال على بيئة بديلة بعد لحظة إعلان غياب المورد؛ مع اعتبار الحالات التي لم تنجح قبل انتهاء التجربة حالات مراقبة منقوصة (Right-Censored). ولا نقترح نسبة مئوية وطنية من عدد الملفات المحفوظة، فذلك يخلط كميات غير متجانسة ويخفي «عائقاً مانعاً» واحداً.

5.1 التصميم

أنشأنا ملف (analysis/demo_service.py) يحوي وظيفة بايثون صغيرة لفحص وجود معرّف اصطناعي ضمن مجموعة محلية، مع ناتج يحوي معرّف الطلب وراية منطقية ونسخة مخطط. لا تقرر هذه الوظيفة حقاً فعلياً ولا تتصل بأي بيانات خارجية.

يستخدم (analysis/reproduce.py) مكتبة (zipfile) القياسية لتجميع ثلاثة عناصر ثابتة: شيفرة الخدمة، ومخطط JSON صغير، وملف يثبت قيمة زمن البناء المرجعية. وفرزنا أسماء الملفات وفرضنا طابعاً زمنياً موحداً وبيانات وصفية متفقة، ثم بنينا الحزمة في مسارين مؤقتين منفصلين. قارنا بايتات الملفين مباشرة وتجزئتيهما (SHA-256). لم نسحب اعتماداً عبر الإنترنت أو ننفذ سلسلة توقيع تجارية.

5.2 المخرجات الفعلية

• عدد المحاولات المستقلة مكانياً داخل العملية الواحدة: 2.
• حالة التطابق على مستوى البايت: True.
• التجزئة لكل منهما: 36c763c61b7114cffe473a230d5d583ca9accef14ff60bdebfab3d78747fdc52.
• اختبار خدمة إيجابي وسلبي صغير: اجتازا كليهما.
• أرشيف النتيجة المؤقت ليس حزمة إنتاجية ولم يُنشر بوصفه تحديثاً قابلاً للتثبيت؛ وسجّلت التجربة حجمه وتجزئتي البناء ونتيجة الاختبارين في ملف تحقق سمّته data/toy_rebuild_verification.json.

النتيجة العلمية المسموح بها ضيقة: عندما ثبتت المدخلات ومعلومات التغليف في هذا المثال، أعطت عمليتا البناء النتيجة نفسها. لا نطلق اسم إعادة إنتاج مستقلة تحققت منها جهة ثالثة؛ فقد استخدمت المحاولتان الشيفرة ذاتها ومترجم اللغة القياسي في البيئة نفسها. ولا تثبت هذه التجربة قابلية إعادة إنتاج برامج تستخدم مترجمات ورخصاً ومكتبات وعتاداً متغايراً.

5.3 ضابط فشل لم يُنفذ على نظام واقعي

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

6.1 المدخلات المصطنعة

أنشأنا ملف data/reproduction_graph.json يصف 26 عقدة، تضم أصولاً جذرية مثل مصدر الخدمة وتصدير البيانات ومخططها وأداة بناء محلية ومرآة حزم، إلى جانب متطلبات تعود إلى المورد مثل مترجم مملوك وحزمة تطوير وتفعيل وتوقيع وبرمجية ثابتة، وعقد ناتجة يمكن اشتقاقها من عقد سابقة.

هي خريطة تعليمية مُختلقة. لا تمثل شركة معينة، ولا صنف أجهزة سعودي، ولا تكشف نقاط تحكم أو تعطل فعلية. فصلنا بين توافر المكون الأولي وبين نجاح وظيفة تشغيلية كاملة؛ كل مسار في هذه التجربة يفترض مسبقاً أن الاختبارات والحقوق الأخرى مستوفاة، فلا يحاول البرنامج تقييمها أو اختراقها.

تعرف البيانات أربعة مسارات:

1. image_archive: نشر صورة تشغيلية محفوظة مع بيانات وتكوينات وشروط تفعيل وتوقيع وعتاد من المورد.
2. source_escrow: بناء النسخة من مصدر متاح لكن باستخدام مُترجم وحزمة تطوير أصليين، بالإضافة إلى متطلبات التشغيل الأصلية.
3. source_with_local_tools: بناء المصدر بأدوات وحزم محلية؛ تبقى بعض متطلبات التفعيل والتوقيع والعتاد الأصلي.
4. portable_minimum: تغيير تصميم جزء من الوظيفة وتجميعه بمكونات بديلة مفترضة، مع ترخيص صالح وتوقيع محلي مشروع ووظائف أضيق من الأصل.

فحصنا كل طريق عند المورد متاح ثم عند المورد غير متاح. لم نحدد احتمالات السيناريوهين، بل حالتي شروط حتميتين.

6.2 المخرجات الفعلية

نفذ البرنامج 8 تقويمات، لا 8 تجارب حقيقية على منتجات مختلفة. وسجّلت التجربة أسماء المتطلبات المفقودة ومخرجات كل مسار في ملف سمّته data/closure_results.csv. نجح اختبار داخلي يتأكد من أن عدد العقد الجذرية غير المتاحة يساوي هذه النتائج المعلنة.

تدل الأرقام على أن إيداع المصدر ليس بديلاً كافياً في وصفة ما زالت تستدعي أصولاً من المزود، وأن الانتقال إلى نواة محمولة قد يقلل الاعتماد ولكن على حساب وظائف معينة. إنها نتيجة بنيوية حساسة لطريقة رسم الاعتماديات: لو تغيرت العقد أو حقوق استعمالها أو ظهرت بدائل، تغير الحكم. ولم نقس تكلفة الإصلاح أو أوقات الانتقال أو أمان النسخة المستعادة.

6.3 ماذا يتغير لو أعيد تصميم التجربة؟

إذا افترضنا أن المورد يمنح إذن تشغيل غير مشروط ومفتاح تحديث صالحاً مستقلاً قبل مغادرته، فقد تختفي بعض العقد المفقودة في مسارات الصورة والشيفرة. وإذا كان البديل المحمول يتطلب شيفرة مصدرية غير مرخص لها بالتعديل، يفشل رغم أن شجرة الملفات تبدو مكتملة. وإذا تطلب معيار الوظيفة جميع الميزات الثماني، فلن يُعد مسار النواة المحمولة نجاحاً في المقام نفسه، وإن أمكن وصفه بأنه «إحلال جزئي».

التصميم الدقيق لمعيار القبول إذن ليس تجميلاً بحثياً. إنه يحدد ما نعنيه بلفظة «استعدنا».

ليس النموذج طريقاً إلى صناعة محلية لكل شيء مهما بلغت التكلفة. يحتاج القرار إلى تحليل خيار إعادة البناء (Rebuild Option) أو خيار شراء بديل (Replacement Option)، مع حساب قيمة إبقاء أحدهما مفتوحاً. يمكن للشركة أو الجهة العامة أن تدفع اليوم تكلفة إضافية لامتلاك حق وأدوات تُخفض تعقيد تغيير المورد بعد خمس سنوات، لكن تلك التكلفة قد تتجاوز المنفعة إذا كان عمر البرنامج قصيراً وتوجد بدائل متنافسة جاهزة.

نقترح فصل ست مجموعات من الكلفة دون اختراع أرقام وطنية:

1. تكلفة حفظ قابلية البناء: تخزين مصدر ومواد برمجية مرخصة، وتحديث مرايا حزم، وتوثيق الإصدارات، واختبارات دورية.
2. تكلفة التخصص المفقود: تنازل الأداء عن عتاد أو برنامج مُحسن لمهمة معينة عند استخدام بديل محمول.
3. تكلفة المعرفة: وقت مهندس قادر على فهم نظام قديم وتغيير سلوكه دون إدخال أعطال جديدة.
4. تكلفة الحقوق والثقة: تراخيص وأساليب التوقيع المعتمدة وصيانة التحديثات والإفصاح الملائم.
5. تكلفة التوقف أو استبدال الخدمة: خسارة وظيفة موثقة وتأخير إنتاجي ومصروف الانتقال.
6. تكلفة البديل الكامل: شراء نظام جديد، وتحويل بيانات، وتدريب، وإيقاف العمل القديم وفق إجراء مقبول.

يجدر مقارنة ما تدفعه المؤسسة للاحتفاظ بقدرتها على التعديل مع ثمن التخلص من التقنية برمتها، لا مع قيمة صورة خادم قديمة فقط. ويجب فصل التكاليف الغارقة (Sunk Costs) عن تكاليف مستقبلية قابلة للتجنب؛ فعائد الاستثمار السابق لا يصبح حجة لاستمرار منتج غير مجدٍ.

7.1 السيناريو الذي يضعف أطروحتنا

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

8.1 التصميم والعينة المطلوبة

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

يختبر فريق مستقل عن فريق الإنشاء مقدار ما يستطيع إنتاجه من الحزمة المصرح بها دون حسابات المورد. يجب منع وصول الباحثين إلى بيانات مستخدمين حقيقية أو أسرار تشغيلية، واستخدام مختبرات مفصولة وبيانات اصطناعية أو مجهولة الهوية حيث يلزم. لا يتطلب البحث تجارب على أنظمة حرجة حية.

8.2 أربع مراحل عملية قابلة للتسجيل

المرحلة الأولى: حفظ المصدر والأصل. يحصي الفريق ما أمكنه استلامه مشروعاً من مصدر ومخططات اعتماد وتراخيص وصور وحزم وبيانات اختبار. يُسجل بدقة ما هو مفقود وما هو معروف لكنه ممنوع الوصول.

الثانية: إعادة إنتاج البناء. يحاول الفريق إنشاء نسخة تشغيلية أو يبين لماذا تعذر ذلك، ويحتفظ بسجل المدخلات والأوامر ونسخ الأدوات والتجزئات. عند وجود نتائج مختلفة يميز الاختلافات المتوقعة من إخفاق قابلية إعادة البناء.

الثالثة: إصلاح مشكلة آمنة مختارة مسبقاً. في بيئة اختبارية، يُكلف الفريق بإصلاح خلل اصطناعي أو تعديل وظيفة ضيقة، وتُستخدم مجموعة اختبارات ثابتة قبل المحاولة. لا يجوز وصف عبور الاختبارات بأنه برهان أمان شامل.

الرابعة: نقل وظيفة محورية. يحاول الفريق تشغيل الوظائف الأساسية المختارة على منصة بديلة مصرح بها. يُسجل عددها ونتائج قبولها والفروق في الكمون والتكلفة والطاقة عند توافر أجهزة قياس موثوقة. تحسب النتائج على مستوى الخدمة لا في صورة مؤشر وطني واحد يوهم بأن جميع الوظائف متجانسة.

8.3 ما الذي نقيسه وما الذي لا نقيسه؟

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

المقارِنات: وجود مصدر وحده؛ وجود صورة تنفيذية؛ وجود مصدر مع حزم بناء ومشغلات مؤرشفة؛ بديل معياري جاهز. قد تتداخل خصائصها، ويجب تحديد كيفية الاختيار حتى لا تكون أفضل الفرق تذهب دائماً إلى أسهل المنتجات.

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

8.4 شروط توقف أو رفض مشروع تجريبي

إذا احتاج الاختبار إلى تعطيل نظام انتاجي، أو تجاوز مفتاح توقيع مصنّع، أو الحصول على أصول بلا ترخيص، أو جمع خريطة تشغيلية حساسة، يجب استبعاد تلك الخطوة. يمكن استبدالها بمحاكاة أو إجراء مأذون محدود. فاستقلال إعادة الإنتاج لا يستحق اختراق ضمان السلامة أو الحقوق التي يفترض أن يحميها.

هذه ليست توقعات محسوبة؛ إنها سيناريوهات شرطية (Conditional Scenarios) مرتبطة بإشارات يمكن رصدها.

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

المسار الثاني: تعميم البناء المحلي بلا كفاءة انتقائية. تحاول جهات إعادة صناعة كل ما تشتريه، بما في ذلك ما تشتريه أرخص من منافسة دولية قوية، فتخلق تكاليف صيانة وتأخيراً وخبرة موزعة على مشاريع لا تبررها أهميتها. العلامة الحاسمة هنا ارتفاع تكلفة الاستقلالية دون تحسن في معدلات الإصلاح أو سهولة الانتقال.

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

9.1 ست إشارات للمرصد

1. نسبة الوظائف المختبرة فعلياً، وليس عدد المشاريع التي أعلنت خطط استمرارية.
2. معدلات النجاح والفشل في إعادة البناء بين فرق مستقلة، حسب نوع المنتج.
3. مدة انقطاع الدعم الفعلية للمورد وأثرها في القدرة على تحديث نسخة اختبارية.
4. حصة المنتجات التي يُملك لها مرآة حزم حديثة وبيئة بناء قابلة لإعادة التشغيل بصورة مشروعة.
5. فرق تكلفة النقل الفعلي مقارنة بشراء بديل جديد، مع محاسبة وظائف مخفّضة.
6. منتجات سعودية لها عملاء يدفعون مقابل خدمات قابلية النقل والتحقق والإصلاح، لا مجرد اختبارات مختبرية منشورة.

تظل لدى هذا العمل ستة حدود كبيرة:

1. غياب البيانات السعودية الإنتاجية: ليس لدينا عينات معتمدة من عمليات شراء أو بناء أو نقل مؤسسات سعودية؛ لذلك لا يجوز القول إن المؤشر أثبت هشاشتها أو قوتها.
2. تبسيط الشجرة: التبعيات الواقعية قد تحتوي على شروط اختيارية ودورات وتوافق إصدارات وأعطال مشتركة ونظم ترخيص معقدة؛ النموذج المنفذ شجرة شروط أولية مبسطة مع مشتقات مستقلة.
3. إظهار السلامة: توافر متطلبات بناء لا يعني أن البرنامج آمن أو يؤدي النتائج المطلوبة. اختبارات العرض صغيرة جداً.
4. تباين الحقوق: قد يمنع القانون أو العقود استعمال مصدر محفوظ أو مفتاح أو برمجية ثابتة؛ لم نُجر تقييماً قانونياً لمنتج معين.
5. مشكلة المعرفة الضمنية: لا تقيس الشجرة مقدار خبرة المهندس ولا زمن التدريب ولا اتساع مساحة الأخطاء.
6. اختلاف بناء البايتات عن الهجرة: ينتج نقل خدمة إلى عتاد آخر بايتات مختلفة؛ قد يكون أنجح استراتيجياً لكنه لا يظهر في اختبار مطابقة (SHA-256) وحده.

وعليه لا نسمي النموذج «مؤشر سيادة سعودية» ولا «شهادة قابلية استعادة». إنه مفاهيم وتعريفات وتجربتان صغيرتان مع برنامج بحث واقعي مقترح.

لكي تكون الإضافة علمية، يجب أن نحدد ما يجعلها أقل إقناعاً:

• إذا استطاع مقدمو خدمة مستقلة شراء بدائل جديدة وتشغيلها بأمان أسرع وأقل تكلفة بشكل منتظم من إعادة بناء الأصل، ستضعف القيمة العامة لاحتفاظ الجهات بقدرات البناء على الفئات المدروسة.
• إذا ظهر أن اختبارات الاحتفاظ بسلسلة البناء لا تضيف قدرة تنبؤية بعد حساب خبرة الفرق وبساطة البرامج وقوة المورد، يجب تعديل الادعاء بأن «حد إعادة الإنتاج» مقياس مهم مستقل.
• إذا تعذر تحديد «وظيفة أساسية» دون خسارة حقوق أو خصائص حيوية، فسيكون نموذج النواة المحمولة غير مناسب لتلك الخدمة حتى لو كان قابلاً للتنفيذ.
• إذا أثبتت أدلة تقنية أن اعتماداً وصفناه بأنه حصري يمكن استبداله فوراً ببديل موثوق ومرخص، فلا يجوز إبقاؤه «عائقاً مانعاً» في الرسم.
• وإذا كانت معظم البرامج ذات أعمار قصيرة وتستبدل بكفاءة، فقد يصبح حفظ القدرات الهندسية العام أفضل من حفظ وصفات بناء منتجات تتقادم بسرعة.

وهنا يكمن الفرق بين اقتراح ريادي ودعوى مغلقة: أن نسأل عن النتيجة التي ستضطرنا إلى تغيير الاستراتيجية قبل أن نصرف عليها المليارات.

بنية ملفات التجربة الأصلية كما تصفها المخطوطة:

المواد المتاحة مع هذه الطبعة: تضم حزمة المواد البحثية جدول الحالات الثماني (closure_results.csv) المستخرج من مصنف الأدلة المرفق، وسجل المصادر (source_register.csv)، ودفتر الوقائع (news_casebook.md). وتتاح النسخة البحثية المنسقة بصيغة (PDF) منفصلة عبر رابط التنزيل.

تصف المخطوطة إجراء التجربة الأصلية بتشغيل الأمر python3 analysis/reproduce.py من مسار العمل، ثم مقارنة ناتجي (CSV) و(JSON). ولا يفترض الإجراء الموصوف اعتماديات برمجية خارج مكتبة (Python) القياسية. وقد يكشف اختلاف إصدار تفسير (ZIP) أو (Python) اختلافاً في ملف الحزمة لدى بيئة ثالثة؛ وعندها يلزم توصيف البيئة كاملاً قبل استنتاج فشل الفكرة ذاتها.

تظل ملفات الأرشيف التي أنشئت داخل الأدلة المؤقتة غير منشورة كبرامج جاهزة؛ تُحفظ نتيجة التحقق فقط، وتُصنع الحزمة مجدداً عند تشغيل البرنامج.

نتيجة الورقة ليست «يجب ألا نثق بالموردين»؛ فقد يكون المورد أفضل من يعيد التشغيل وأكثرهم قدرة على حفظ الابتكار. وهي ليست «المصدر المفتوح حل لكل شيء»؛ إذ قد تتقادم أدواته أو تختفي خبرته أو يعجز عن تنفيذ وظائف لها حقوق معقدة.

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

أثبتت التجربتان الصغيرتان إمكان بناء حزمة واحدة مرتين بايتاً بايتاً في بيئة معروفة، وأن فقد عدد محدود من الجذور في نموذج اعتماديات اصطناعي يقطع مسارات وإن بقيت بقية المواد محفوظة. أما ما إذا كان توسيع هذا المبدأ إلى خدمات سعودية يحقق عائداً حقيقياً في التكلفة والزمن والاستقلال والصيانة، فهذه فرضية تحتاج تجربة مستقلة.

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

تُجمع تفاصيل المصادر وتواريخ النشر والأحداث وحدود الاستدلال وتفرعات الاستشهاد في سجل المصادر (source_register.csv) ودفتر الوقائع (news_casebook.md) ضمن حزمة الأدلة. وتظهر المعرفات المقابلة هنا:

1. S01 الإدارة الوطنية للملاحة الجوية والفضاء (NASA): Voyager 1 Resumes Sending Engineering Updates to Earth، 22 أبريل 2024.
2. S02 الإدارة الوطنية للملاحة الجوية والفضاء (NASA): Voyager 1 Resumes Sending Science Data from Two Instruments، 22 مايو 2024.
3. S03 (VanMoof Bankruptcy Trustees): Fourth Public Bankruptcy Report, 6 يونيو 2024، تسجيل 17 يوليو 2023.
4. S04 (Cowboy SA): الصفحة الأصلية لتطبيق Bikey، يوليو 2023.
5. S05 (VanMoof): بيان استئناف الملكية وبرنامج التعافي، يوليو 2024.
6. S06 (VanMoof): VanMoof Archives for Legacy Models, 27 فبراير 2024.
7. S07 (VanMoof): What's Happening with 2G Network Shutdown، إرشادات 2026.
8. S08 (Fisker Owners Association): بيان جمعية المالكين في ملف إفلاس الشركة أمام المحكمة الأمريكية، 26 يوليو 2024، ص 2. نص البيان الأصلي مفهرس، لكن خادم الملف لم يستجب للفتح المباشر أثناء التحقق النهائي.
9. S09 (Undercurrent Inc.): الصفحة الأصلية لتطبيق OceanLink Pro، الموصوف بأنه التطبيق الرسمي لأعضاء جمعية (Fisker Owners Association).
10. S10 (Reuters): خبر اعتماد خطة إفلاس (Fisker) في 11 أكتوبر 2024.
11. S11 (Reproducible Builds): Definitions، التعريف الفني للبناء المتطابق.
12. S12 (SLSA): SLSA Specification Version 1.2، المعتمدة في 24 نوفمبر 2025.
13. S13 (SPDX): Specifications, قائمة مكونات البرمجيات وتراخيصها.
14. S14 (The Update Framework): Overview, أمان تحديث البرمجيات.
15. S15 (Software Heritage): FAQ، أهداف الحفظ طويل الأمد.
16. S16 كين تومبسون (Ken Thompson): Reflections on Trusting Trust, 1984.
17. S17 هيئة الحكومة الرقمية (Digital Government Authority): Government Cloud Software Repository (GPaaS).
18. S18 الهيئة العامة للعقار (Real Estate General Authority): Free and Open-Source Government Software، صفحة مؤسسية رسمية غير مؤرخة.
19. S19 ديفيد ويلر (David A. Wheeler): Fully Countering Trusting Trust through Diverse Double-Compiling, 2010.

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