ماذا يجب أن تتضمن مواصفات تهيئة جهاز Android؟

الإجابة المختصرة

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

مواصفات التهيئة سجل مشروع مضبوط

مواصفات تهيئة جهاز Android ليست ورقة بيانات استهلاكية، ولا ملف بناء تطبيق Android، ولا دليلًا على اجتياز الجهاز للقبول. إنها سجل مشروع مضبوط الإصدار يعرّف حالة التسليم المقصودة. و«مواصفات تهيئة جهاز Android» لغة مشروع خاصة بـVantora وليست نوع وثيقة رسميًا في Android، لذا ينبغي لكل حقل جوهري أن يحدد حالة، ويرتبط بدليل، ويسمّي جهة مسؤولة، ويعرّف ما يحدث حين تتغير تلك الحالة. وهذا الانضباط تفرضه المنصة ولم يُبتكر لها: فكل قيمة يعاملها المشتري تقريبًا على أنها شيء واحد هي في الحقيقة عدة أشياء. فـAndroid يعرض الطراز والمنتج والعتاد وSKU ومعرّفات الإصدار حقولًا منفصلة؛ وتتحرك تسمية الإصدار ومستوى API ومعرّف الإصدار ومستوى تصحيح الأمان بعضها مستقلًا عن بعض؛ ويحمل التطبيق اسم حزمة، ورمز إصدار، واسم إصدار، وهوية توقيع لا يُغني أي منها عن الآخر. وأي مواصفات تدمج أيًا من ذلك في عبارة ودودة واحدة تكون قد فقدت أصلًا القدرة على القول إن وحدتين متطابقتان — وهو السؤال الوحيد الذي يستطيع فحص الدُفعة الإجابة عنه فعلًا. ويهم اللازمُ بالقدر نفسه: تبقى نتائج التوافق والترخيص والموافقة السوقية وأدلة القبول سجلات منفصلة لكل منها جهة حائزة، لأن المواصفات التي تبتلعها تصير الوثيقة التي يستشهد بها الجميع ولا يستطيع أحد التحقق منها.

ما العينة مضبوطة الإصدار لجهاز Android

تصف مواصفات التهيئة نية. أما العينة مضبوطة الإصدار فهي النظير المادي: وحدة واحدة مهيأة التُقطت هويتها الكاملة ودُوّنت ووُضعت تحت ضبط التغيير، بحيث يمكن تتبّع أي ادعاء لاحق عن الأسطول إلى شيء وُجد فعلًا على منضدة اختبار في تاريخ معلوم. وأهمية العبارة أن «العينة التي أرسلناها» ليست سجلًا؛ فهي تسمّي كائنًا لا حالة. وبعد ثلاثة أشهر لن يستطيع أحد أن يجزم أي إصدار برامج ثابتة كانت تحمله تلك الوحدة، وأي رمز إصدار للتطبيق كان مثبتًا، وهل حُدّث المشغّل بين العرض التوضيحي والاعتماد، وأي مراجعة سياسة كانت مطبقة حين نفّذ المختبِر سيناريوهات الكشك. والعينة مضبوطة الإصدار تجيب عن ذلك كله من سجل مكتوب لا من الذاكرة، وتفعل ذلك لأن الهوية التُقطت وقت التهيئة لا أُعيد بناؤها بعد ذلك. والهوية التي تحملها العينة ثلاث طبقات، لكل منها سبب مختلف. هوية الشراء — الشركة المصنّعة، والطراز الدقيق، وSKU الإقليمي، ونسخة الذاكرة والتخزين، ومسار التوريد — تجيب عن سؤال «هل يمكن شراء هذه الوحدة مجددًا في السوق المستهدف؟»، وهو السؤال الذي تسقط فيه العينة الواعدة غالبًا بعد أشهر. وهوية وقت التشغيل — الرقم التسلسلي، وIMEI، وإصدار Android ومستوى API، ومستوى تصحيح الأمان، ومعرّف إصدار البرامج الثابتة أو بصمته، وحالة GMS أو AOSP — تجيب عن سؤال «هل وحدة الإنتاج فعلًا هي المنصة البرمجية نفسها؟»، وتُلتقط من الجهاز لا من ورقة البيانات لأن الاثنين يختلفان أكثر مما يتوقع المشترون. وهوية التهيئة — أسماء حزم التطبيقات مع رمز الإصدار واسم الإصدار، ومسار التوقيع والتوزيع، وحزمة المشغّل وإصداره، وإصدار DPC أو وكيل الإدارة، ومراجعة ملف السياسة، ووضع الملكية، ومسار التزويد — تجيب عن سؤال «ما الذي طُبِّق فعليًا على هذه الوحدة؟». وفوق ذلك كله تأتي حقول العملية التي تجعل السجل قابلًا للدفاع عنه لا مجرد مفصَّل: تاريخ التهيئة، والمختبِر المسمى، ومراجعة مصفوفة القبول التي اختُبرت الوحدة مقابلها، والقيود المعروفة المقبولة معها، وتاريخ اعتماد العميل والمُعتمِد. وبدون المجموعة الأخيرة يكون السجل لقطة تقنية؛ ومعها يصير السجل قرارًا. ويضيف ضبط الإصدار ثلاث خصائص لا تملكها اللقطة. فالحالات السابقة تُحفظ ولا يُكتب فوقها، فيمكن الإجابة عن سؤال يخص وحدة سُلّمت في مارس بالرجوع إلى المراجعة التي كانت تحكم مارس. ولكل مراجعة نطاق يسمّي الدفعات أو الشرائح التي تحكمها، وهو ما يتيح لشريحة تجريبية من عشرين إلى مئة وحدة أن تعمل وفق مراجعة واحدة بينما تنتظر بقية وحدات البرنامج المراجعة التالية. وكل تغيير منسوب إلى شخص — أحدهم طرحه وأحدهم اعتمده، وكلاهما مسجل — وهو الفرق بين تعديل ومشادّة. أما آليات إعادة إنتاج حالة معتمدة عبر وحدات الإنتاج فتعود إلى تجهيز الدُفعات؛ والمهم هنا أن للتجهيز مرجعًا ثابتًا يعيد إنتاجه، وقاعدة إيقاف تُفعَّل حين تنحرف وحدة عنه.

كيف يشير سجل العينة ومواصفات التهيئة أحدهما إلى الآخر

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

استخدم سبعة أقسام وأربعة ضوابط للحقول

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

استبدل بالتسميات الغامضة بنودًا مضبوطة

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

أبقِ سجلات الطرح منفصلة

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

جمّد المرجع ثم اضبط التغيير

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

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

مراجعة أم تعديل: ما الذي يستدعيه كل تغيير

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

حين يشحن OEM إصدار برامج ثابتة جديدًا بعد القبول

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

كيف يُقيَّم طلب الاستبدال

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

نزّل قالب مواصفات تهيئة الجهاز

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