قراءة البنية الطبقية لـ SKU.md v0.8: معلومات يستضيفها التاجر ومعاملات تشترط موافقة المنصة

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

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

اللون يحدد حدود السلطة

تمثل الصناديق البيضاء ملفات أو هياكل بيانات أو آليات. ويجيب اللون المحيط بها عن سؤال: من يستطيع إنشاء هذه الآلية وتشغيلها فعليًا؟

في الطبقات الخضراء المزرقة يملك التاجر سلطة النشر. يستطيع ضبط robots.txt وتوفير Sitemap ونشر llms.txt وملف sku.md الجذري وإضافة فهارس التقسيم ووثائق المنتجات وأدوات الصفحة على نطاقه. تظل الاستضافة الصحيحة والتحليل الآمن والبيانات الدقيقة ضرورية، لكن وجود الملف نفسه لا يحتاج إلى موافقة مسبقة من منصة تجارية.

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

وهكذا يفصل المخطط بين فعلين يسهل الخلط بينهما: نشر إعلان، وامتلاك سلطة تنفيذ ما يعلنه.

يتحكم التاجر في الحوكمة والاكتشاف

تضم الطبقة الأولى robots.txt وllms.txt وsitemap.xml. تساعد الملفات الثلاثة المستهلك على اكتشاف موارد الموقع وفهمها، لكنها تؤدي أدوارًا مختلفة.

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

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

تحافظ عائلة SKU-MD على حجم جذري محدود

الطبقة الخضراء المزرقة الثانية هي عائلة مستندات SKU-MD.

• ملف بيان Catalog جذري في /sku.md.
• فهارس تقسيم اختيارية لكتالوج كبير أو مقسّم.
• مستندات *.sku.md لكل منتج.

يوصف الملف الجذري بأنه ذو تعقيد O(1) لأن حجمه ينبغي أن يبقى محدودًا مع نمو الكتالوج، لا لأن البحث في الكتالوج كله يتم بزمن ثابت. يظل الملف صغيرًا لأنه يربط بنقاط دخول Catalog والتقسيمات وواجهات اكتشاف وثائق المنتجات بدل تضمين كل منتج.

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

تظل هذه الملفات كلها تحت سيطرة التاجر. وتنبع سلطتها من ملكية النطاق وعناوين URL الأساسية والمراجعات المتسقة والأدلة والتسليم الصحيح عبر HTTP، لا من اسم الملف وحده.

تفصل طبقة معلومات المنتج المعرفة المستقرة عن الحالة المتغيرة

تجمع الطبقة الثالثة Product JSON-LD مع معرفة SKU.md، وتضع offer_snapshot بجوار live_verification. ويمنع هذا الترتيب التعامل مع الحقائق المستقرة والحالة التجارية المتقلبة كسجل واحد لا تمييز فيه.

يوفر Product JSON-LD دلالات راسخة للمنتج على مستوى الصفحة. ويمكن لمعرفة SKU.md تنظيم الحقائق والادعاءات والإفصاحات والإرشادات والقيود والأدلة المرتبطة بها. طبقة المعرفة مخصصة للعبارات الجديرة بالنشر والتدقيق، ولا يجوز استخدامها لتثبيت أسعار مؤقتة أو مخزون أو عروض شحن أو حملات ترويجية داخل نص دائم.

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

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

يسلك capabilities[] وprotocol_profiles[] مسارين مختلفين

تنقسم البنية بعد معلومات المنتج، لا إلى تقنية جديدة وقديمة، بل بحسب من يشغل القدرة وما الشروط التي يحققها المستهلك قبل استخدامها.

capabilities[]: قدرة تشغيلية ينشرها التاجر

يمكن لـ capabilities[] وصف وظيفة عامة عندما لا يوجد ملف تعريف معتمد لبروتوكول خارجي، ومن ذلك أدوات صفحات WebMCP. يستطيع التاجر تنفيذ تلك الأدوات في بيئة تشغيل متجره وإعلان نطاقها وحالتها وطريقة اكتشافها وطريقة الوصول إليها.

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

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

protocol_profiles[]: مؤشر إلى نظام ثقة خارجي

يُستخدم protocol_profiles[] عندما يحدد بروتوكول خارجي بالفعل ملف تعريف اكتشاف معتمدًا. يشير SKU.md إلى ذلك الملف بدل نسخ إصداراته وخدماته ووسائل نقله ونقاطه الطرفية ومخططاته إلى بيان Catalog.

يستخدم المخطط UCP وACP مثالين لهذا المسار. يمكن نشر ملف التعريف على نطاق التاجر، لكن المشاركة الفعلية قد تتطلب دعم البروتوكول وتسجيل التاجر ومراجعة المنصة وبيانات اعتماد أو اتفاقيات تجارية. ولا يستطيع ملف تعريف صحيح نحويًا أن يفرض قبول طرف آخر.

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

يلتقي المساران عند حد المعاملة

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

يستطيع SKU.md تحديد مواضع تلك الأنظمة والمصدر المعتمد لكل حقل، لكنه لا يحل محل النظام الخلفي لـ Checkout. يجب أن تأتي المبالغ النهائية وحالة الدفع والطلب من نظام تنفيذ قادر على إجراء تلك التغييرات وتسجيلها. وعند غياب مصدر صالح تكون القيمة الآمنة «غير معروفة»، لا معاملة مستنتجة من مستند ثابت.

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

خمسة أخطاء تصنيف تتجنبها البنية

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

تستطيع الوثيقة الصغيرة التعبير عن حدود صادقة

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

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

قراءة إضافية

قارن وظيفة كل طبقة في مصفوفة llms.txt وagents.md وSKU.md