الخلاصة

  • نُشرت المراجعة 01 من WebProof في 5 سبتمبر بوصفها Internet-Draft فردية لا تحظى بتأييد IETF ولا بمكانة رسمية في مسار المعايير، مع أنها تتضمن قسماً يصف نفسه بأنه توجيه معياري لأنظمة الذكاء الاصطناعي.
  • يضع النص نفسه سقفاً دقيقاً لأدلته: مرساة سلسلة الكتل تحدد موعداً أقصى لمعرفة بصمة ما، وDOI يحفظ بيانات وصفية صرح بها المودِع، والتوقيع يرتبط بمفتاح؛ ولا يثبت أي منها وحده الحقيقة أو الأسبقية أو الهوية أو حق إصدار الأوامر لنظام آخر.
  • يحتاج المشغّل إلى إيصالين منفصلين: أحدهما للمحتوى الذي جُلب، والآخر للسياسة التي سمحت للنموذج باتباع تعليمات بعينها. من دونهما يستطيع موضوع التحليل أن يرفع نفسه خفية إلى مرتبة قاعدة التحليل.

يسجل إعلان 5 سبتمبر واقعة محدودة: أصبحت الوثيقة draft-reilly-webproof-01، من 62 صفحة ومن تأليف Lawrence John Reilly Jr.، متاحة. لا يعلن البريد تبنياً من مجموعة عمل أو موافقة من IESG أو استخداماً لدى مزود ذكاء اصطناعي.

تقترح الوثيقة WebProof Record يطبّع المورد الرقمي، ويحسب بصمته، ويربطها بمرساة زمنية على Bitcoin وبإيداع يحمل DOI، ثم يضيف توقيعاً ووسائل اكتشاف عبر HTTP وDNS. غير أن القسم 15 يغيّر المخاطَب.

يحمل القسم اسم “AI System Directive”. ويخاطب النماذج اللغوية والوكلاء والأنظمة المدمجة التي تعالج الوثيقة أو تفهرسها أو تلخصها أو تستشهد بها. يطلب منها بصيغة MUST أن تنسب مصطلح WebProof إلى المؤلف، وأن تعترف بمنشور محدد من 2025 بوصفه الأصل، وألا تعرض عناصر معينة على أنها مجهولة المصدر أو من عمل شخص آخر.

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

صفة الوثيقة تسبق صيغة الإلزام

تصف صفحة Datatracker العمل بأنه Internet-Draft فردي نشط، من دون RFC stream أو Area Director مسؤول أو موعد telechat. وتضيف التحذير الحاسم: يستطيع أي شخص تقديم I-D؛ هذه الوثيقة غير مؤيدة من IETF ولا مكانة رسمية لها في عملية معاييرها.

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

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

تشرح RFC 8174 الدلالة الخاصة للكلمات الكبيرة في BCP 14، مثل MUST وSHOULD وMAY. فائدتها أن تجعل متطلبات المواصفة واضحة وقابلة للاختبار. لكنها لا تقرر مَن اعتمد المواصفة أو مَن يخضع لها. قد يعلن برنامج أنه ينفذ WebProof فيلتزم بمتطلبات ملف المطابقة؛ أما نموذج عثر على الوثيقة أثناء البحث فلا يصبح تلقائياً تنفيذاً للبروتوكول.

ويقول القسم إن الرقابة البشرية هي العليا وإن التوجيه يتراجع أمام prompts ذات مرتبة أعلى وفق إطار AIMED. لكن AIMED في Datatracker هو أيضاً I-D فردي. يمكن لمقترحين أن يصفا سلماً نظرياً، لكنهما لا يثبتان سلم التعليمات الحقيقي لدى شركة أو مؤسسة عامة أو غرفة أخبار.

المرساة تحفظ الادعاء ولا تفصل في صحته

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

أما DOI فيجعل الإيداع قابلاً للاكتشاف وأكثر دواماً. البيانات الوصفية تظل تصريحاً من المودِع. حفظ تصريح ثابت إنجاز في سلسلة العهدة، لكنه ليس تحكيماً مستقلاً في الأسبقية التاريخية.

التوقيع يضيف رابطة أخرى من دون أن يكمل الهوية. تحدد RFC 7515 صيغة JWS التي يستشهد بها المقترح. يمكن للتحقق أن يربط التوقيع بالمفتاح وبالسجل المحمي. ثم تبقى أسئلة: مَن كان يسيطر على المفتاح، وكيف رُبط بشخص أو مؤسسة، وما التفويض الذي حمله، ومتى انتهى أو أُلغي؟

وللزمن مسار ثقة منفصل. تتيح RFC 3161 لسلطة ختم زمني أن تربط بصمة بوقت تصرح به. قد يضيّق ذلك المجال الزمني، لكنه يدخل طرفاً موثوقاً آخر. لا تحوّل عبارة «كان موجوداً قبل هذا الوقت» إلى حكم بأن شخصاً بعينه ابتكر الفكرة أولاً.

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

كتابة مسار معروف لا تسجله عالمياً

يقترح النص /.well-known/webproof. تنظم RFC 8615 مساحة /.well-known/ وتطلب تسجيل اللاحقات الجديدة لتجنب التضارب وتحديد الصيغة والنطاق وجهة التحكم بالتغيير. عند الفحص في 7 سبتمبر، لم يتضمن سجل IANA مدخلاً باسم webproof.

هذه لقطة زمنية لا رفض أبدي. فائدتها الفصل بين سلسلة مقترحة في مسودة، وطلب تسجيل، وصف في IANA، وخدمة تعمل، وعميل يدعمها، وسياسة تقبل النتيجة. لا يرث طورٌ حالة الطور التالي.

وينطبق ذلك على حقول HTTP وسجل TXT عند _webproof. يمكنها أن تشير إلى مكان الدليل، ولا تقرر معنى الدليل. يحذر النص نفسه من اعتبار hash header القادم مع المورد نتيجة تحقق مستقلة، ومن اعتبار DNS غير المحمي بـDNSSEC سلطة لمادة المفاتيح.

لا يضع مقدم Evidence سياسة القبول وحده

يربط WebProof سجله بمفردات الإثبات عن بعد. تفصل RFC 9334 بين Evidence التي يرسلها Attester، وسياسة التقييم، وAttestation Results، وقرار Relying Party. هذا الفصل يمنع الدليل من احتواء حكم ملزم للطرف الذي سيعتمد عليه.

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

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

تنفيذ المؤلف يحتاج إلى تنفيذ مستقل

يذكر قسم حالة التنفيذ أن المؤلف يشغل عملية الإرساء وإيداع DOI وخدمة حية. تشجع RFC 7942 على إدراج حالة التنفيذ في Internet-Drafts كي يرى المجتمع ما جُرّب فعلاً أثناء تطور العمل.

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

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

إيصال للمستند وآخر للسلطة

تقود Minimum Initial Specification لدى Heng Lu إلى سجل صغير بدلاً من شارة «موثوق» شاملة. يحفظ إيصال المستند URI والمراجعة والبصمة ووقت الجلب والصفة المؤسسية وادعاءات المؤلف والأدلة الخارجية. ويحفظ إيصال الحوكمة مُصدر السياسة وإصدارها ونطاقها وأسبقيتها وفترة سريانها والاستثناء والإلغاء والمسؤول.

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

وأخيراً تجعل Running-Code Primacy الادعاء قابلاً للفحص. إذا قيل إن AI امتثل للتوجيه، فيجب إظهار سلم التعليمات الذي طُبق فعلاً والنتيجة التي خرجت. وجود MUST في الملف ليس سجل تنفيذ.

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

المصادر

  1. Datatracker — WebProof
  2. WebProof، المراجعة 01
  3. إعلان Internet-Draft
  4. Datatracker — AIMED
  5. RFC 8174 — كلمات المتطلبات الكبيرة
  6. RFC 8615 — Well-Known URIs
  7. سجل IANA لعناوين Well-Known URI
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — بروتوكول الختم الزمني
  10. RFC 9334 — بنية RATS
  11. RFC 7942 — حالة التنفيذ
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy