Ouamarkom - اقتصاد أوامر الذكاء الاصطناعي
OUAMARKOM™ - المواصفة التقنية لنموذج UEARM v0.1

نموذج التمثيل الموحد للفعل الاقتصادي
UEARM Technical Specification v0.1

Unified Economic Action Representation Model (UEARM) v0.1

الاسم الكامل: Unified Economic Action Representation Model
الاسم العربي: نموذج التمثيل الموحد للفعل الاقتصادي
معرّف المواصفة: OUAMARKOM-UEARM-SPEC-001
الإصدار: 0.1
تاريخ الإصدار: 4 نوفمبر 2026
الحالة: مواصفة تقنية مقترحة - قيد التنفيذ التجريبي
الإطار البحثي: CE-AI™
النموذج التشغيلي: CE-AI™ Pipeline
التصنيف: مواصفة بحثية وهندسية
الجهة المطوّرة: قطاع البحث والتطوير - أوامركم™ (OUAMARKOM™)
حالة المواصفةمواصفة مقترحة - تجريبية
حالة التحققبانتظار التقييم التجريبي
حالة التوحيد المعياريليست معياراً صناعياً معتمداً

فهرس المحتويات

  1. 1. الغرض والنطاق
  2. 2. المصطلحات واللغة المعيارية
  3. 3. المبادئ التصميمية الأساسية
  4. 4. البنية المنطقية لـ UEARM
  5. 5. نموذج البيانات
  6. 6. مخطط JSON للإصدار UEARM v0.1
  7. 7. قواعد التحقق الدلالي
  8. 8. آلة حالات التنفيذ (Execution State Machine)
  9. 9. دلالات سحب التفويض (Revocation Semantics)
  10. 10. التزامن والتعرض الاقتصادي التراكمي
  11. 11. نموذج الأدلة والتحقق
  12. 12. إدارة الإصدارات والتوافق
  13. 13. الأمن ونموذج التهديدات
  14. 14. متطلبات المطابقة
  15. 15. مجموعة اختبارات المطابقة الأولية
  16. 16. معمارية التنفيذ المرجعية
  17. 17. خطة التحقق التجريبي
  18. 18. القيود المعروفة في الإصدار v0.1
  19. 19. خارطة الإصدارات التقنية المقترحة
  20. 20. الموقف المؤسسي والتقني
  21. 21. المراجع التقنية
  22. ضبط الوثيقة والتحكم بالإصدار

1. الغرض والنطاق

1.1 الغرض

تحدد هذه الوثيقة البنية التقنية الأولية لنموذج UEARM - Unified Economic Action Representation Model، وهو نموذج مقترح للتمثيل المنظم للأفعال الاقتصادية التي تطلبها أو تنشئها أو تفوضها أو تنفذها أنظمة الذكاء الاصطناعي.

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

  • 1. الهوية ومصدر الطلب.
  • 2. الفعل الاقتصادي.
  • 3. المعلمات الاقتصادية.
  • 4. السلطة المفوضة.
  • 5. السياسات والقيود.
  • 6. سياق التنفيذ.
  • 7. قرار الحوكمة.
  • 8. حالة التنفيذ.
  • 9. الأدلة والتحقق.
  • 10. النتيجة الاقتصادية والتشغيلية.

تضع هذه المواصفة عقداً تقنياً أولياً يمكن استخدامه في بناء نموذج تنفيذي واختبار مدى اتساق العلاقات بين هذه العناصر.

1.2 نطاق المواصفة

تحدد UEARM v0.1 ما يلي:

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

1.3 ما لا تغطيه المواصفة

لا تهدف UEARM v0.1 إلى تعريف:

  • بروتوكول عالمي موحد للمدفوعات.
  • نظام متكامل لإدارة الهوية.
  • آلية تسوية مالية بعينها.
  • لغة سياسات موحدة.
  • بنية تحتية متكاملة للمفاتيح والتوقيعات الرقمية.
  • إطار قانوني شامل للتفويض الاقتصادي.
  • بوابة تنفيذ إنتاجية مكتملة.
  • معيار صناعي معتمد.

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

1.4 الحالة الفنية

تمثل UEARM v0.1 مواصفة تقنية مقترحة.

تهدف بنيتها واشتراطاتها السلوكية إلى دعم التنفيذ الأولي والتجارب المضبوطة.

ولا يُعد هذا الإصدار مصادقاً عليه من جهة معيارية أو مثبتاً من خلال اختبارات شاملة للتوافق التشغيلي أو الاعتماد المستقل.

2. المصطلحات واللغة المعيارية

تُستخدم المصطلحات التالية بمعانيها المحددة في هذه المواصفة:

المصطلح المعنى
MUST يجب الالتزام بالمتطلب
MUST NOT يُحظر مخالفة المتطلب
SHOULD يُوصى بالالتزام به ما لم يوجد مبرر موثق
SHOULD NOT يُوصى بتجنب الممارسة
MAY يجوز تطبيقه اختيارياً

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

3. المبادئ التصميمية الأساسية

تستند UEARM v0.1 إلى المبادئ التالية:

3.1 الفصل بين القدرة والسلطة

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

3.2 ربط التفويض بالفعل

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

3.3 التحقق عند نقطة التنفيذ

يجب التحقق من صلاحية التفويض والقيود عند نقطة التنفيذ القابلة للإنفاذ، وليس الاكتفاء بالتحقق عند إنشاء الطلب.

3.4 سلامة المعلمات الاقتصادية

يجب التمييز بين:

  • القيمة المطلوبة.
  • القيمة المصرح بها.
  • القيمة المحجوزة.
  • القيمة المنفذة.
  • القيمة التي تمت تسويتها فعلياً، إذا ثبت ذلك.

ولا يجوز التعامل مع هذه القيم على أنها متطابقة.

3.5 التمثيل الصريح للحالات

يجب تمثيل حالات التنفيذ بصورة صريحة، وإخضاع الانتقالات بينها لقواعد محددة.

3.6 مراعاة سحب التفويض

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

3.7 مصدر الأدلة

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

3.8 التحقق من النتائج

لا يجوز اعتبار إشعار نجاح التنفيذ دليلاً تلقائياً على اكتمال التسوية الاقتصادية.

3.9 التعلم المنضبط

لا يجوز أن يؤدي التعلم أو التكيف إلى توسيع السلطة الاقتصادية المفوضة تلقائياً.

3.10 قابلية التتبع

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

4. البنية المنطقية لـ UEARM

4.1 التمثيل الأساسي

يُعبّر عن النموذج المقترح بالصيغة التالية:

UEARM = {I, A, E, D, P, C, G, X, V, O}
الرمز المكوّن الوظيفة إلزامي
I الهوية ومصدر الطلب تحديد الجهة المبادرة ومصدر الطلب نعم
A الفعل الاقتصادي تعريف العملية الاقتصادية المطلوبة نعم
E المعلمات الاقتصادية المبالغ والعملات والكميات والمستفيدون نعم
D السلطة المفوضة تحديد نطاق التفويض وشروطه نعم
P السياسات والقيود تحديد القواعد والحدود المطبقة نعم
C سياق التنفيذ تحديد البيئة والسياق التشغيلي نعم
G قرار الحوكمة تسجيل القبول أو الرفض أو التصعيد نعم
X حالة التنفيذ تمثيل الحالة التشغيلية نعم
V الأدلة والتحقق تسجيل الأدلة ونتائج التحقق نعم
O النتيجة تمثيل النتيجة الاقتصادية والتشغيلية نعم

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

4.2 الفصل الوظيفي

المكوّن المسؤولية
UEARM تحديد بنية تمثيل الفعل الاقتصادي
CE-AI™ Pipeline تحديد المسار التشغيلي المقترح
CEP™ دراسة آليات ضبط الانتقال من الأمر إلى التنفيذ
Smart Hand™ توفير بيئة التنفيذ التجريبي
GEAB™ تحديد سيناريوهات الاختبار ومقاييس التقييم المقترحة

لا يُفترض أن كل مكوّن يستلزم خدمة مستقلة أو طبقة معمارية منفصلة. يجب إثبات القيمة المستقلة لكل طبقة من خلال التجربة.

5. نموذج البيانات

5.1 البنية العليا

يجب أن تتضمن وثيقة UEARM v0.1 الحقول العليا التالية:

الحقل نوع البيانات إلزامي الوصف
schema_version نص نعم إصدار مخطط البيانات
action_id نص نعم معرّف الفعل الاقتصادي
created_at تاريخ ووقت نعم وقت إنشاء الوثيقة
identity كائن نعم الهوية ومصدر الطلب
economic_action كائن نعم العملية الاقتصادية المطلوبة
delegated_authority كائن نعم التفويض ونطاق السلطة
policy كائن نعم مراجع السياسات
execution_context كائن نعم بيئة التنفيذ
governance كائن نعم قرار الحوكمة
execution كائن نعم حالة التنفيذ
evidence مصفوفة نعم سجلات الأدلة
outcome كائن نعم النتيجة الحالية
extensions كائن لا الامتدادات الخاصة بالتطبيق

5.2 الهوية ومصدر الطلب (Identity & Provenance)

يجب أن يحتوي كائن الهوية على:

  • initiator_id: معرّف الجهة المبادرة.
  • initiator_type: نوع الجهة المبادرة.
  • request_id: معرّف الطلب.

تشمل أنواع الجهات المبادرة الأولية:

  • HUMAN
  • AI_AGENT
  • ORGANIZATION
  • SYSTEM

ينبغي حفظ مصدر الطلب وسلسلة التفويض عند الحاجة.

ولا يجوز اعتبار ادعاء الهوية غير المتحقق منه إثباتاً مستقلاً للهوية الموثوقة.

5.3 الفعل الاقتصادي (Economic Action)

يجب أن يحتوي كائن الفعل الاقتصادي على:

  • action_type: نوع الفعل.
  • resource: المورد الاقتصادي المعني.
  • parameters: معلمات الفعل.

تشمل أنواع الأفعال الأولية:

  • PROCUREMENT - المشتريات.
  • FINANCIAL_TRANSFER - التحويل المالي.
  • CAPITAL_ALLOCATION - تخصيص رأس المال.
  • PAYMENT_INITIATION - بدء الدفع.
  • RESOURCE_ALLOCATION - تخصيص الموارد.
  • CONTRACTUAL_COMMITMENT - الالتزام التعاقدي.

يجوز إضافة أنواع أخرى وفق آلية امتدادات موثقة أو إصدار لاحق.

يحدد حقل المورد الحساب أو الأصل أو العقد أو المورد الاقتصادي المرتبط بالفعل.

5.4 المعلمات الاقتصادية (Economic Parameters)

عندما يتضمن الفعل قيمة مالية، يجب تمثيل المبلغ كسلسلة عشرية نصية.

مثال صحيح:

"amount": "15000.00"

ولا يوصى بتمثيله باستخدام رقم فاصلة عائمة:

"amount": 15000.00

وذلك لتجنب الاعتماد على الحسابات الثنائية التقريبية في قرارات التفويض المالي.

يجب ربط المبلغ برمز عملة صريح، ويوصى باستخدام الرموز الأبجدية المعتمدة في ISO 4217.

يجب التمييز بين:

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

ولا يجوز دمج هذه القيم في حقل واحد.

5.5 السلطة المفوضة (Delegated Authority)

يجب أن يتضمن كائن التفويض:

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

ينبغي أن يتضمن التفويض مرجعاً إلى المستند أو السجل الذي يثبت منح السلطة.

يجب التحقق من أن التفويض يشمل نوع الفعل ومعلماته الاقتصادية.

ولا يجوز تفسير التفويض بإجراء المشتريات على أنه تفويض تلقائي بإجراء التحويلات المالية.

5.6 السياسات والقيود (Policy & Constraints)

يجب أن يحدد كائن السياسات مراجع السياسات المطبقة.

عند إجراء تقييم للسياسات، ينبغي حفظ:

  • معرّف السياسة.
  • إصدار السياسة.
  • وقت التقييم.
  • مرجع سياق التقييم.
  • نتيجة التقييم.

مجرد وجود مرجع لسياسة لا يثبت أنها خضعت للتقييم بنجاح.

5.7 سياق التنفيذ (Execution Context)

ينبغي أن يتضمن سياق التنفيذ:

  • معرّف البيئة.
  • معرّف نظام التنفيذ.
  • المنطقة أو الولاية التنظيمية عند الحاجة.
  • الطابع الزمني للسياق.
  • مرجع سياق التزامن أو المعاملة.

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

5.8 قرار الحوكمة (Governance Decision)

يجب أن يتضمن كائن الحوكمة:

  • معرّف القرار.
  • قيمة القرار.
  • وقت اتخاذ القرار.
  • سبب القرار.

القيم الأولية للقرار:

  • ADMIT - قبول السماح بالانتقال إلى التنفيذ.
  • REJECT - رفض.
  • ESCALATE - تصعيد للمراجعة أو الموافقة الإضافية.

يجب ربط قرار ADMIT بالفعل والتفويض اللذين جرى تقييمهما.

وأي تغيير جوهري في معلمات الفعل يستلزم إعادة تقييم التفويض.

ولا يجوز تفسير ADMIT على أنه دليل على وقوع التنفيذ.

5.9 حالة التنفيذ (Execution State)

يجب أن يحتوي كائن التنفيذ على:

  • الحالة الحالية.
  • وقت آخر انتقال للحالة.

وينبغي أن يتضمن أيضاً:

  • معرّف محاولة التنفيذ.
  • مفتاح منع التكرار.
  • معرّف المنفذ.
  • حالة الإلغاء.
  • مرجع إيصال التنفيذ.

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

5.10 الأدلة والتحقق (Evidence & Verification)

ينبغي أن يتضمن كل سجل دليل:

  • معرّف الدليل.
  • نوع الدليل.
  • مصدر الدليل.
  • وقت الالتقاط.
  • معرّف الحدث أو المعاملة المرتبطة.
  • مرجع سلامة الدليل، عند توفره.

تشمل أنواع الأدلة المحتملة:

  • COMMAND_RECORD
  • AUTHORIZATION_RECORD
  • POLICY_DECISION
  • EXECUTION_RECEIPT
  • SYSTEM_ACKNOWLEDGEMENT
  • SETTLEMENT_CONFIRMATION
  • STATE_TRANSITION
  • CANCELLATION_RECORD

يجب الفصل بين:

  • 1. تسجيل الدليل.
  • 2. التحقق من سلامة الدليل.
  • 3. التحقق المستقل من الادعاء الذي يدعمه الدليل.

ولا يجوز اعتبار الدليل المسجل دليلاً متحققاً منه تلقائياً.

5.11 النتيجة (Outcome)

يجب أن يمثل كائن النتيجة أحدث حالة معروفة.

القيم الأولية:

  • PENDING
  • COMPLETED
  • PARTIALLY_COMPLETED
  • REJECTED
  • FAILED
  • CANCELLED
  • EXPIRED
  • UNRESOLVED

ينبغي أن تشير النتيجة إلى الأدلة التي تدعم تصنيفها.

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

6. مخطط JSON للإصدار UEARM v0.1

يحدد مخطط JSON التالي العقد البنيوي الأولي للمواصفة.

يستخدم المخطط مسودة JSON Schema Draft 2020-12.

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

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://ouamarkom.com/spec/uearm/0.1/schema.json", "title": "UEARM Economic Action", "description": "Proposed Unified Economic Action Representation Model v0.1", "type": "object", "additionalProperties": false, "required": [ "schema_version", "action_id", "created_at", "identity", "economic_action", "delegated_authority", "policy", "execution_context", "governance", "execution", "evidence", "outcome" ], "properties": { "schema_version": { "type": "string", "const": "0.1" }, "action_id": { "$ref": "#/$defs/identifier" }, "created_at": { "type": "string", "format": "date-time" }, "identity": { "type": "object", "additionalProperties": false, "required": [ "initiator_id", "initiator_type", "request_id" ], "properties": { "initiator_id": { "type": "string", "minLength": 1 }, "initiator_type": { "type": "string", "enum": [ "HUMAN", "AI_AGENT", "ORGANIZATION", "SYSTEM" ] }, "request_id": { "$ref": "#/$defs/identifier" }, "provenance_ref": { "type": "string" } } }, "economic_action": { "type": "object", "additionalProperties": false, "required": [ "action_type", "resource", "parameters" ], "properties": { "action_type": { "type": "string", "minLength": 1 }, "resource": { "type": "object", "required": [ "resource_type", "resource_id" ], "properties": { "resource_type": { "type": "string" }, "resource_id": { "type": "string" } }, "additionalProperties": false }, "parameters": { "type": "object", "minProperties": 1 }, "requested_amount": { "$ref": "#/$defs/money" }, "beneficiary_id": { "type": "string" } } }, "delegated_authority": { "type": "object", "additionalProperties": false, "required": [ "grant_id", "granting_principal", "authorized_agent", "permitted_action_types", "status", "valid_from", "valid_until" ], "properties": { "grant_id": { "$ref": "#/$defs/identifier" }, "granting_principal": { "type": "string", "minLength": 1 }, "authorized_agent": { "type": "string", "minLength": 1 }, "permitted_action_types": { "type": "array", "minItems": 1, "uniqueItems": true, "items": { "type": "string" } }, "maximum_amount": { "$ref": "#/$defs/money" }, "status": { "type": "string", "enum": [ "ACTIVE", "REVOKED", "EXPIRED", "SUSPENDED" ] }, "valid_from": { "type": "string", "format": "date-time" }, "valid_until": { "type": "string", "format": "date-time" }, "authority_reference": { "type": "string" }, "revocation_reference": { "type": "string" } } }, "policy": { "type": "object", "additionalProperties": false, "required": [ "policy_ids" ], "properties": { "policy_ids": { "type": "array", "items": { "type": "string" }, "uniqueItems": true }, "policy_version": { "type": "string" }, "evaluation_reference": { "type": "string" } } }, "execution_context": { "type": "object", "additionalProperties": false, "required": [ "environment_id", "execution_system_id" ], "properties": { "environment_id": { "type": "string" }, "execution_system_id": { "type": "string" }, "region": { "type": "string" }, "context_reference": { "type": "string" } } }, "governance": { "type": "object", "additionalProperties": false, "required": [ "decision_id", "decision", "decided_at", "reason_code" ], "properties": { "decision_id": { "$ref": "#/$defs/identifier" }, "decision": { "type": "string", "enum": [ "ADMIT", "REJECT", "ESCALATE" ] }, "decided_at": { "type": "string", "format": "date-time" }, "reason_code": { "type": "string" }, "authority_snapshot_ref": { "type": "string" }, "policy_evaluation_ref": { "type": "string" } } }, "execution": { "type": "object", "additionalProperties": false, "required": [ "state", "updated_at" ], "properties": { "state": { "type": "string", "enum": [ "CREATED", "PENDING", "AUTHORIZED", "REJECTED", "EXECUTING", "PARTIALLY_EXECUTED", "COMPLETED", "FAILED", "CANCEL_REQUESTED", "CANCELLED", "EXPIRED" ] }, "updated_at": { "type": "string", "format": "date-time" }, "attempt_id": { "type": "string" }, "idempotency_key": { "type": "string" }, "executor_id": { "type": "string" }, "executed_amount": { "$ref": "#/$defs/money" }, "cancel_reference": { "type": "string" } } }, "evidence": { "type": "array", "items": { "$ref": "#/$defs/evidence" } }, "outcome": { "type": "object", "additionalProperties": false, "required": [ "status" ], "properties": { "status": { "type": "string", "enum": [ "PENDING", "COMPLETED", "PARTIALLY_COMPLETED", "REJECTED", "FAILED", "CANCELLED", "EXPIRED", "UNRESOLVED" ] }, "settled_amount": { "$ref": "#/$defs/money" }, "outcome_reference": { "type": "string" }, "verified_at": { "type": "string", "format": "date-time" }, "verification_reference": { "type": "string" } } }, "extensions": { "type": "object" } }, "$defs": { "identifier": { "type": "string", "minLength": 1, "maxLength": 128 }, "money": { "type": "object", "additionalProperties": false, "required": [ "amount", "currency" ], "properties": { "amount": { "type": "string", "pattern": "^(0|[1-9][0-9]*)(\\.[0-9]+)?$" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$" } } }, "evidence": { "type": "object", "additionalProperties": false, "required": [ "evidence_id", "evidence_type", "source", "captured_at" ], "properties": { "evidence_id": { "$ref": "#/$defs/identifier" }, "evidence_type": { "type": "string", "minLength": 1 }, "source": { "type": "string", "minLength": 1 }, "captured_at": { "type": "string", "format": "date-time" }, "event_reference": { "type": "string" }, "integrity_reference": { "type": "string" }, "verification_status": { "type": "string", "enum": [ "NOT_VERIFIED", "INTEGRITY_CHECKED", "INDEPENDENTLY_VERIFIED", "REJECTED" ] } } } } }

6.1 متطلبات التحقق من المخطط

يجب على التطبيق:

  • 1. التحقق من الوثيقة وفق إصدار المخطط المعلن.
  • 2. رفض الوثائق التي تفتقد حقولاً إلزامية.
  • 3. رفض أنواع البيانات والقيم غير الصحيحة.
  • 4. رفض المبالغ المالية ذات التنسيق غير الصحيح.
  • 5. رفض أسماء الخصائص المكررة عند مرحلة تحليل JSON.
  • 6. تنفيذ التحقق الدلالي بعد التحقق البنيوي.
  • 7. توثيق آلية التعامل مع إصدارات المخطط غير المدعومة.

قد تتعامل بعض أدوات JSON Schema مع الكلمة "format" بوصفها وصفاً أو تعليقاً لا شرط تحقق إلزامياً. لذلك يجب التحقق من صحة التواريخ والتنسيقات الحساسة صراحةً في طبقة التطبيق.

7. قواعد التحقق الدلالي

التحقق البنيوي ضروري لكنه غير كافٍ.

يتطلب UEARM طبقة تحقق إضافية تفحص العلاقات بين الحقول.

7.1 ربط السلطة بالفعل

يجب تحقق الشروط التالية قبل السماح بانتقال الفعل إلى التنفيذ:

  • تطابق الوكيل المصرح له مع الوكيل المبادر.
  • وجود نوع الفعل ضمن قائمة الأفعال المسموح بها.
  • صلاحية التفويض زمنياً.
  • كون حالة التفويض ACTIVE.
  • عدم تجاوز المبلغ المطلوب للحد المالي المصرح به.
  • تطابق العملة مع قيد العملة إن وجد.
  • توافق المورد والمستفيد مع القيود المعمول بها.

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

7.2 الصلاحية الزمنية

يجب تطبيق العلاقة التالية:

valid_from ≤ authorization_time < valid_until

ولا يجوز اعتبار التفويض صالحاً خارج فترة سريانه.

ينبغي استخدام طوابع زمنية متزامنة وتوثيق افتراضات مزامنة الساعة.

7.3 التحقق المالي

بالنسبة للفعل المالي:

requested_amount ≤ authorized_maximum_amount

يجب استخدام الحساب العشري الدقيق في المقارنة.

ويُحظر الاعتماد على عمليات المقارنة الثنائية ذات الفاصلة العائمة لاتخاذ قرارات التفويض المالي.

كما يجب التحقق من العملة والدقة العشرية المسموح بها.

7.4 سلامة المعلمات

أي تغيير جوهري في الحقول التالية يستلزم إعادة تقييم التفويض:

  • نوع الفعل.
  • المبلغ.
  • العملة.
  • المستفيد.
  • المورد المصدر.
  • المورد المستهدف.
  • القيود التنفيذية ذات الصلة.

ولا يجوز إعادة استخدام قرار حوكمة سابق لتفويض فعل تغيرت معلماته الجوهرية.

7.5 اتساق القرار

إذا كانت:

governance.decision = REJECT

فلا يجوز انتقال الفعل إلى حالة EXECUTING.

إذا كانت:

governance.decision = ESCALATE

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

إذا كانت:

governance.decision = ADMIT

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

7.6 اتساق الأدلة

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

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

8. آلة حالات التنفيذ (Execution State Machine)

8.1 الحالات المحددة

الحالة المعنى
CREATEDتم إنشاء تمثيل الفعل
PENDINGالفعل بانتظار التقييم أو المعالجة
AUTHORIZEDتمت الموافقة على الفعل
REJECTEDتم رفض الفعل
EXECUTINGبدأ التنفيذ
PARTIALLY_EXECUTEDتم تنفيذ جزء من الفعل
COMPLETEDاكتملت عملية التنفيذ
FAILEDفشل التنفيذ
CANCEL_REQUESTEDتم استلام طلب الإلغاء
CANCELLEDتم تأكيد الإلغاء وفق دلالات التنفيذ المحددة
EXPIREDانتهت صلاحية الفعل أو التفويض قبل اكتماله

8.2 الانتقالات المسموح بها

الحالة الحالية الحالات التالية المسموح بها
CREATEDPENDING، REJECTED، EXPIRED
PENDINGAUTHORIZED، REJECTED، EXPIRED
AUTHORIZEDEXECUTING، CANCEL_REQUESTED، EXPIRED
EXECUTINGPARTIALLY_EXECUTED، COMPLETED، FAILED، CANCEL_REQUESTED
PARTIALLY_EXECUTEDEXECUTING، COMPLETED، FAILED، CANCEL_REQUESTED
CANCEL_REQUESTEDCANCELLED، EXECUTING، PARTIALLY_EXECUTED، COMPLETED، FAILED
REJECTEDنهائية
COMPLETEDنهائية لمحاولة التنفيذ
FAILEDنهائية لمحاولة التنفيذ
CANCELLEDنهائية لمحاولة التنفيذ
EXPIREDنهائية

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

8.3 إنفاذ الانتقالات

يجب أن يتضمن كل انتقال:

  • 1. الحالة السابقة.
  • 2. الحالة الجديدة.
  • 3. الطابع الزمني للانتقال.
  • 4. المكوّن الذي بدأ الانتقال.
  • 5. سبب الانتقال أو مرجع الحدث.
  • 6. سجل الانتقال القابل للتدقيق.

ويجب رفض أي انتقال يخالف آلة الحالات.

8.4 دلالات الإلغاء

يجب التمييز بين طلب الإلغاء والإلغاء المؤكد.

"CANCEL_REQUESTED" يعني أن طلب الإلغاء قد تم استلامه.

"CANCELLED" يعني أن نظام التنفيذ أكد تحقق شروط الإلغاء المحددة.

ولا يجوز تسجيل نجاح الإلغاء قبل الحصول على التأكيد المطلوب.

إذا تجاوز التنفيذ نقطة غير قابلة للعكس، فلا يجوز الادعاء بأن الإلغاء قد عكس الفعل الاقتصادي.

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

9. دلالات سحب التفويض (Revocation Semantics)

9.1 المتطلب العام

قد يتم سحب التفويض بصورة مستقلة عن دورة حياة الفعل الاقتصادي.

يجب أن يحدد التطبيق أثر السحب على الحالات التالية:

  • الأفعال المنشأة.
  • الأفعال المعلقة.
  • الأفعال المصرح بها.
  • الأفعال قيد التنفيذ.
  • الأفعال المنفذة جزئياً.

9.2 السحب عند نقطة التنفيذ

قبل بدء التنفيذ، يجب إعادة التحقق من صلاحية التفويض.

إذا تم سحب التفويض قبل نقطة التنفيذ القابلة للإنفاذ، فلا يجوز تنفيذ الفعل استناداً إلى ذلك التفويض.

9.3 السحب أثناء التنفيذ

إذا تم سحب التفويض بعد بدء التنفيذ، يجب تقييم ما إذا كان:

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

ويجب الاحتفاظ بحدث السحب والطابع الزمني الخاص به.

9.4 سجل سحب التفويض

ينبغي أن يتضمن سجل السحب:

  • معرّف التفويض.
  • معرّف عملية السحب.
  • الجهة التي قامت بالسحب.
  • وقت السحب.
  • نقطة سريان السحب.
  • مرجع السبب.
  • معرفات الأفعال المتأثرة، عند توفرها.

10. التزامن والتعرض الاقتصادي التراكمي

10.1 مخاطر التزامن

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

مثال:

  • الحد المصرح به: 10,000 دولار.
  • الفعل A: 6,000 دولار.
  • الفعل B: 6,000 دولار.

قد يؤدي التحقق المستقل من كل طلب إلى السماح بتعرض إجمالي قدره 12,000 دولار، إذا كان الطلبان يستخدمان التفويض المشترك نفسه.

10.2 الحجز الذري

عندما يتضمن التفويض حداً مالياً إجمالياً، ينبغي استخدام آلية حجز ذرية أو آلية مكافئة للتحكم في التزامن.

يجب الحفاظ على الثابت التالي:

Reserved Exposure + Executed Exposure ≤ Applicable Aggregate Limit

يجب توثيق كيفية التعامل مع الحجوزات والعكس والتسويات والتعديلات.

10.3 التحكم في التزامن

يجب منع استخدام قرارات تفويض قديمة لتجاوز حد اقتصادي إجمالي تم تحديثه.

وينبغي استخدام واحد أو أكثر من الأساليب التالية:

  • المعاملات الذرية في قواعد البيانات.
  • سجلات التفويض ذات الإصدارات.
  • التحكم التفاؤلي في التزامن.
  • المعالجة التسلسلية للمعاملات.
  • الأقفال الموزعة مع توثيق حالات الفشل.

10.4 منع التكرار (Idempotency)

ينبغي أن تمتلك كل محاولة تنفيذ مفتاحاً فريداً لمنع التكرار.

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

إذا أعيد استخدام المفتاح نفسه مع معلمات مختلفة جوهرياً، فيجب رفض الطلب أو اشتراط مفتاح جديد.

ويجب الاحتفاظ بسجلات منع التكرار لمدة موثقة تتناسب مع مخاطر العملية ودورة حياتها.

11. نموذج الأدلة والتحقق

11.1 دورة حياة الأدلة

تعتمد المواصفة دورة الأدلة التالية:

إنشاء الدليل→ تسجيل الدليل→ التحقق من سلامته→ التحقق المستقل→ إسناد النتيجة

ويجب التمييز بين كل مرحلة.

11.2 سجل الدليل

ينبغي أن يتضمن سجل الدليل:

  • معرّف الدليل.
  • معرّف الفعل.
  • معرّف الحدث.
  • نوع الدليل.
  • النظام المصدر.
  • وقت الالتقاط.
  • مرجع سلامة الدليل.
  • حالة التحقق.
### 11.3 سلامة الأدلة

عندما يتطلب التطبيق حماية التوقيع أو السلامة التشفيرية، يجوز استخدام آليات التوقيع والتوحيد القياسي المعتمدة.

يوفر RFC 8785 مواصفة لتوحيد تمثيل JSON تُعرف باسم JSON Canonicalization Scheme، بهدف إنتاج تمثيل متكرر يمكن استخدامه في عمليات التجزئة والتوقيع.

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

11.4 استقلال التحقق

ينبغي الفصل بين النظام الذي ينفذ الفعل والنظام أو العملية التي تتحقق من نتيجته.

وعندما يتعذر التحقق المستقل، يجب تمثيل النتيجة بحالة مناسبة مثل UNRESOLVED أو حالة غير متحقق منها.

11.5 الاحتفاظ بالأدلة

يجب أن يحدد التطبيق:

  • مدة الاحتفاظ بالأدلة.
  • ضوابط الوصول.
  • حماية السلامة.
  • صلاحيات التدقيق.
  • قيود الخصوصية.
  • متطلبات الحذف والاحتفاظ النظامي.

12. إدارة الإصدارات والتوافق

12.1 معرّف الإصدار

الإصدار الأول:

"0.1"

يجب أن يحدد حقل "schema_version" إصدار المخطط المستخدم في تفسير الوثيقة.

12.2 سياسة الإصدارات

ينبغي أن تميز سياسة الإصدارات المستقبلية بين:

  • التعديلات التصحيحية: توضيحات أو إصلاحات لا يُقصد منها إحداث عدم توافق بنيوي.
  • التعديلات الفرعية: إضافات متوافقة مع الإصدارات السابقة.
  • التعديلات الرئيسية: تغييرات قد تؤثر في صلاحية التطبيقات أو البيانات السابقة.

تظل سياسة الإصدارات النهائية خاضعة للتطوير.

12.3 الحقول غير المعروفة

في الإصدار v0.1:

  • يجب رفض الحقول العليا غير المعروفة.
  • يجب وضع امتدادات التطبيقات داخل "extensions".
  • ينبغي تسمية الامتدادات باستخدام نطاقات أسماء موثقة.
  • يُحظر تفسير الحقول غير المعروفة تلقائياً على أنها تعليمات تمنح سلطة تنفيذية.

12.4 ترحيل المخططات

لا يجوز تغيير المعنى الدلالي لحقل موجود بصورة صامتة عند الانتقال بين الإصدارات.

ينبغي أن يحافظ الترحيل على:

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

13. الأمن ونموذج التهديدات

ينبغي أن تراعي تطبيقات UEARM التهديدات التالية على الأقل:

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

هذه القائمة تمثل نموذج تهديدات أولياً، ولا تعد تقييماً أمنياً شاملاً.

يتطلب التطبيق الإنتاجي تحليلاً مستقلاً للتهديدات واختبارات أمنية وتصميماً لإدارة المفاتيح وضوابط تشغيلية مناسبة.

14. متطلبات المطابقة

يمكن تقييم تطبيق UEARM v0.1 وفق أربعة مستويات.

المستوى الأول: المطابقة البنيوية (Structural Conformance)

يتعين على التطبيق:

  • قبول الوثائق الصحيحة وفق المخطط.
  • رفض الوثائق ذات البنية غير الصحيحة.
  • إنفاذ الحقول الإلزامية.
  • التحقق من أنواع البيانات والقيم المحددة.

المستوى الثاني: المطابقة الدلالية (Semantic Conformance)

يتعين على التطبيق:

  • التحقق من العلاقة بين التفويض والفعل.
  • التحقق من المعلمات الاقتصادية.
  • التحقق من مراجع السياسات.
  • التحقق من الصلاحية الزمنية.
  • إنفاذ اتساق قرار الحوكمة.

المستوى الثالث: مطابقة التنفيذ (Execution Conformance)

يتعين على التطبيق:

  • إنفاذ آلة الحالات.
  • إعادة التحقق من التفويض عند نقطة التنفيذ.
  • تطبيق سلوك محدد للإلغاء وسحب التفويض.
  • منع التنفيذ المكرر غير المقصود.
  • معالجة التزامن والحدود التراكمية.

المستوى الرابع: مطابقة الأدلة والنتائج (Evidence & Outcome Conformance)

يتعين على التطبيق:

  • تسجيل أدلة قابلة للتتبع.
  • التمييز بين تسجيل الأدلة والتحقق منها.
  • الحفاظ على سجل التنفيذ.
  • الفصل بين اكتمال التنفيذ والتسوية الاقتصادية.
  • دعم إسناد النتائج إلى أدلتها.

هذه المستويات فئات تقييم مقترحة، وليست شهادات اعتماد خارجية.

15. مجموعة اختبارات المطابقة الأولية

تمثل الاختبارات التالية خط أساس تجريبياً أولياً.

معرّف الاختبار السيناريو النتيجة المتوقعة
UEARM-T001فعل صحيح ضمن حدود التفويضيجوز إصدار ADMIT
UEARM-T002المبلغ المطلوب يتجاوز الحدREJECT أو تصعيد وفق السياسة
UEARM-T003نوع فعل غير مصرح بهREJECT
UEARM-T004تفويض منتهي الصلاحيةمنع التنفيذ
UEARM-T005سحب التفويض قبل التنفيذمنع التنفيذ
UEARM-T006تعديل جوهري للمعلماتوجوب إعادة التقييم
UEARM-T007تكرار مفتاح الطلب والمعلمات نفسهامنع التنفيذ المكرر
UEARM-T008استخدام المفتاح نفسه مع معلمات مختلفةرفض أو اشتراط مفتاح جديد
UEARM-T009طلبات متزامنة تتجاوز الحد الإجماليالحفاظ على الحد الإجمالي
UEARM-T010انتقال غير صحيح بين الحالاترفض الانتقال
UEARM-T011طلب إلغاء دون تأكيدعدم تسجيل الإلغاء المؤكد
UEARM-T012تنفيذ جزئيتسجيل PARTIALLY_EXECUTED
UEARM-T013إشعار تنفيذ دون دليل تسويةبقاء التسوية غير متحقق منها
UEARM-T014غياب مصدر الدليلفشل التحقق من الدليل
UEARM-T015إصدار مخطط غير مدعومرفض المعالجة أو عزل الوثيقة صراحةً

15.1 حالة اختبار توضيحية: تجاوز حد التفويض

المدخلات:

  • الوكيل: Agent-Alpha-07
  • نوع الفعل: CAPITAL_ALLOCATION
  • المبلغ المطلوب: 15,000 دولار.
  • الحد المصرح به: 10,000 دولار.
  • حالة التفويض: ACTIVE.

النتيجة المتوقعة:

  • قرار الحوكمة: REJECT.
  • سبب الرفض: REQUEST_EXCEEDS_AUTHORIZED_LIMIT.
  • حالة التنفيذ: REJECTED.
  • المبلغ المنفذ: صفر.
  • النتيجة: REJECTED.

هذه حالة اختبار محددة، وليست ادعاءً بأن الاختبار نُفذ أو اجتاز التقييم.

15.2 حالة اختبار توضيحية: سحب التفويض

الحالة الأولية:

  • حالة التفويض: ACTIVE.
  • حالة الفعل: AUTHORIZED.
  • لم يبدأ التنفيذ.

الحدث:

يتم سحب التفويض.

النتيجة المتوقعة:

  • تسجيل حدث السحب.
  • فشل إعادة التحقق من التفويض.
  • منع التنفيذ.
  • انتقال الفعل إلى حالة غير قابلة للتنفيذ وفق القواعد المحددة.

يجب أن يوثق التطبيق الانتقال الدقيق المستخدم لهذه الحالة.

16. معمارية التنفيذ المرجعية

يمكن تنفيذ النموذج الأولي باستخدام المكونات المنطقية التالية:

المكوّن المسؤولية
مستقبِل الأفعال (Action Intake)استقبال طلبات الأفعال الاقتصادية
مدقق UEARM (UEARM Validator)التحقق البنيوي والدلالي
محلل الهوية (Identity Resolver)تحديد هوية الجهة المبادرة
محلل التفويض (Authority Resolver)تقييم السلطة المفوضة
محرك السياسات (Policy Evaluator)تقييم السياسات والقيود
محرك قرار الحوكمة (Governance Decision Engine)إنتاج ADMIT أو REJECT أو ESCALATE
متحكم التنفيذ (Execution Controller)إنفاذ شروط نقطة التنفيذ
مدير الحالات (State Manager)إدارة انتقالات التنفيذ
مسجل الأدلة (Evidence Recorder)تسجيل الأحداث والأدلة
متحقق النتائج (Outcome Verifier)تقييم النتائج التشغيلية والاقتصادية
مخزن التدقيق (Audit Store)حفظ السجل والمصدر التاريخي

هذه مسؤوليات منطقية، ولا تعني أن كل مسؤولية تتطلب خدمة أو عملية أو طبقة منفصلة.

يجب إثبات الحاجة إلى فصل كل مكوّن عن غيره من خلال نتائج التجارب.

16.1 تسلسل المعالجة المرجعي

  • 1. استقبال طلب الفعل الاقتصادي.
  • 2. قراءة إصدار UEARM المعلن.
  • 3. التحقق من بنية الوثيقة.
  • 4. التحقق من العلاقات الدلالية.
  • 5. تحديد الهوية والتفويض.
  • 6. تقييم السياسات والقيود.
  • 7. إصدار قرار الحوكمة.
  • 8. تسجيل القرار ومراجعه الداعمة.
  • 9. إعادة التحقق من التفويض عند نقطة التنفيذ.
  • 10. تطبيق ضوابط التزامن ومنع التكرار.
  • 11. تنفيذ الفعل المسموح به.
  • 12. تسجيل أحداث التنفيذ.
  • 13. التقاط الأدلة والتحقق من سلامتها.
  • 14. التحقق من النتيجة.
  • 15. حفظ السجل النهائي للفعل.

17. خطة التحقق التجريبي

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

المرحلة A - التحقق من المخطط

الهدف: التأكد من أن JSON Schema يقبل الوثائق الصحيحة ويرفض البنى غير الصحيحة.

المخرجات:

  • مدقق المخطط.
  • ملفات اختبار صحيحة.
  • ملفات اختبار غير صحيحة.
  • تقرير التحقق.

المرحلة B - التحقق الدلالي

الهدف: التحقق من اتساق معلمات الفعل مع السلطة المفوضة والسياسات.

المخرجات:

  • اختبارات التفويض.
  • اختبارات الحدود المالية.
  • اختبارات الصلاحية الزمنية.
  • اختبارات ربط المعلمات.

المرحلة C - آلة حالات التنفيذ

الهدف: التحقق من انتقالات الحالات المسموح بها وغير المسموح بها.

المخرجات:

  • تنفيذ آلة الحالات.
  • سجل الانتقالات.
  • تقرير الاختبارات.

المرحلة D - سحب التفويض والتزامن

الهدف: تقييم توقيت سحب التفويض وإنفاذ حدود التعرض التراكمي.

المخرجات:

  • سيناريوهات سحب التفويض.
  • اختبارات التنفيذ المتزامن.
  • حسابات التعرض الاقتصادي.
  • سجلات الفشل والتعافي.

المرحلة E - الأدلة والتحقق من النتائج

الهدف: تقييم قدرة التطبيق على التمييز بين دليل التنفيذ والنتيجة الاقتصادية المتحقق منها.

المخرجات:

  • سجلات الأدلة.
  • نتائج التحقق.
  • تقرير إسناد النتائج.

المرحلة F - التقييم المقارن

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

محاور التقييم:

  • اكتمال نموذج البيانات.
  • اتساق التفويض.
  • قابلية التشغيل البيني.
  • تتبع التنفيذ.
  • سلوك سحب التفويض.
  • معالجة التزامن.
  • تغطية التحقق من الأدلة.
  • العبء التشغيلي الإضافي.

لا تحدد هذه المواصفة أرقام أداء أو ادعاءات تفوق مثبتة.

18. القيود المعروفة في الإصدار v0.1

تتطلب المسائل التالية أعمالاً هندسية إضافية:

تم توثيق هذه القيود لإبقاء حدود الإصدار واضحة وقابلة للمراجعة.

19. خارطة الإصدارات التقنية المقترحة

الإصدار نطاق التطوير المقترح
v0.1نموذج البيانات والمخطط والقواعد الدلالية وآلة الحالات
v0.2بصمة الفعل وربط التفويض ونموذج الأحداث
v0.3دلالات الإلغاء والتزامن والتنفيذ الجزئي
v0.4سلامة الأدلة وملفات التحقق من النتائج
v0.5التشغيل البيني والتقييم المقارن
v1.0مواصفة مرشحة مستقرة، بعد التحقق والمراجعة المستقلة

هذه مراحل تطوير مقترحة وليست مواعيد إصدار ملزمة.

20. الموقف المؤسسي والتقني

تقدم أوامركم™ مواصفة UEARM v0.1 بوصفها إصداراً هندسياً أولياً ضمن أبحاثها في مجال التنفيذ الاقتصادي المحكوم بالذكاء الاصطناعي.

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

ولا تدعي هذه الوثيقة أنها معيار صناعي معتمد أو أنها بديل عن تقنيات التفويض والسياسات والمدفوعات والهوية ومعالجة المعاملات القائمة.

يجب إثبات القيمة التقنية للنموذج من خلال:

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

21. المراجع التقنية

ضبط الوثيقة والتحكم بالإصدار

الحقل القيمة
الجهةأوامركم™ - OUAMARKOM™
اسم الوثيقةالمواصفة التقنية لنموذج UEARM
المعرّفOUAMARKOM-UEARM-SPEC-001
الإصدار0.1
تاريخ الإصدار4 نوفمبر 2026
الإطار البحثيCE-AI™
الحالةمواصفة مقترحة - تجريبية
حالة التحققبانتظار التقييم التجريبي
حالة التوحيد المعياريليست معياراً صناعياً معتمداً
الجهة المسؤولةقطاع البحث والتطوير - أوامركم™

أوامركم™ | OUAMARKOM™

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

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

© 2026 OUAMARKOM™ Research & Development