نتائج الامتثال

يحوّل فهرس المتطلبات توجيهًا إلى بنود قابلة للتحقق. يأتي Oloproof بفهرس لتوجيه مجلس الخزانة الكندي بشأن اتخاذ القرار الآلي، إلى جانب الفهارس الأخرى التي تسردها صفحة الولايات القضائية. ينسخها oloproof init --example governance إلى مجلد catalogues/ في المشروع بجانب ملف governance.yaml يقرؤها، فيعمل oloproof governance check هناك فورًا. يقرأ oloproof governance check هذا الفهرس مقابل أنظمتك ويقول لكل متطلب إن كان مستوفى أو مستوفى جزئيًا أو غير مستوفى أو غير منطبق أو يتعذر تحديده. وتذكر كل نتيجة ما تستند إليه: قرارات البوابة لديك، أو إفادة شخص مسمّى، أو مسودة رُوجعت.

النتيجة ملخص لقارئ. لا تغيّر قرارًا أبدًا، ولا تكون أبدًا إذنًا بالتشغيل. وهي ليست استشارة قانونية.

ملف الحوكمة

يوضع governance.yaml بجانب oloproof.yaml:

catalogue: catalogues/dadm_catalogue_2025-06-24.yaml   # as `init --example governance` copies it
systems:
  - id: triage
    name: Benefits triage
    system: triage            # the oloproof system name its runs are recorded under
    in_scope: true
    scope_reason: assesses eligibility for a federal benefit
    environment: production
    production_since: 2026-06-01
    aia_level: II
    review_period_days: 365
    bindings:
      DADM-6.3.1: [accuracy-floor]      # the gate rules that decide a measured requirement
      DADM-6.3.3#1: [every-region]      # or one part of a composite
statements:
  - id: s1
    system: triage
    target: DADM-6.1.1
    says: met                 # met, not_met or not_applicable
    by: A. Officer
    role: CIO office
    on: 2026-10-01
    link: https://example.org/aia

كيف يُتوصَّل إلى نتيجة

• تقرأ المتطلبات المقيسة قواعد البوابة المربوطة بها، عند أحدث تشغيل لكل مجموعة من الإصدار الحالي للنظام، ضمن فترة مراجعته. مستوفى فقط حين تكون كل قاعدة مربوطة PASS؛ وغير مستوفى حين تكون إحداها FAIL؛ وإلا فيتعذر تحديده. ولا يكون مستوفى جزئيًا أبدًا.
• تقرأ المتطلبات المشهود لها أحدث إفادة سارية. تتقادم الإفادة بعد فترة المراجعة، أو حين يتجاوز إصدار النظام الإصدار الذي تسمّيه.
• تبدأ المتطلبات المدعومة من مسودة نموذج، oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>، ولا تصبح نتيجة أبدًا حتى يتصرف فيها مراجع: oloproof governance review --action validate|reject|modify|annotate.
• تجمع المتطلبات المركّبة أجزاءها: جزء واحد غير محدد يمنع الاستيفاء.

القواعد في docs/engine/FINDING_RULES.md، وقد اعتُمدت بتدقيقها في 2 نوفمبر 2026.

الإنصاف بين المجموعات

يسأل البندان 6.3.3 و6.3.8 من التوجيه هل تصمد النتائج لكل مجموعة. اربطهما بقاعدة min على مقياس worst_group (مرجع الإعداد)، التي تُخضع كل مجموعة مسمّاة للحد دفعة واحدة.

الختم والتوقيع وإعادة التقييم

يكتب oloproof governance check --seal سجل نتائج مرقّمًا ومسلسلًا بالسجل الذي قبله، وفيه رأس سجل المراجعة. أضف --sign office.key --signer "CIO office" لتوقيعه بمفتاح أنشأه oloproof runner keygen؛ ويمكن لأي أحد التحقق منه بـ oloproof governance verify RECORD --public-key KEY. يقول التوقيع من ختمه، لا أن النتائج صحيحة. يُعلَّم النظام لإعادة التقييم حين لم يُقيَّم قط، أو انقضت فترة مراجعته، أو تغيّر إصداره، أو تغيّر الفهرس.

تُتابَع الإجراءات التصحيحية بـ oloproof governance ticket. يطبع oloproof governance export-tickets --to jira --project GOV، لكل تذكرة مفتوحة لم تُصدَّر بعد، تذكرة Jira التي سينشئها (REST v3 /rest/api/3/issue، والوصف بصيغة Atlassian Document Format)؛ ويطبع --to servicenow سجلًا في Table API لـ incident، أو problem مع --table problem. أضف --send --by "A. Officer" لإنشائها، مع ضبط OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN أو OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD (لا تُخزَّن ولا تُطبع أبدًا). يُكتب المفتاح الذي تعيده كل خدمة في السجل كتعليق على متطلب التذكرة: فتعرضه النتائج ولا تُرسل التذكرة مرتين أبدًا. اختُبر على استجابات مسجلة، لا على نسخة حقيقية من Jira أو ServiceNow.

قبل إرسال التذكرة يسجل السجل التصدير على أنه معلق؛ وإعادة التشغيل بعد انهيار تبحث عن التذكرة في الخدمة (بوسم في Jira، وبـ correlation_id في ServiceNow) وتسجل المفتاح الموجود بدلا من إنشاء تذكرة ثانية. تبدأ هذه التعليقات بـ oloproof-export:، وهي بادئة لا يجوز لملاحظة المراجع أن تستعملها. ما يغادر مؤسستك: ملاحظة التذكرة ومتطلبها ونظامها واسم من فتحها كما كتب في السجل وتاريخها وملخصها؛ لا شيء من محتوى الحالات.

يقرأ oloproof governance mlflow سجل نماذج MLflow: اضبط MLFLOW_TRACKING_URI، وMLFLOW_TRACKING_TOKEN إن طلبه الخادم (لا يُخزَّن أيٌّ منهما ولا يُطبع). يطابق كل نموذج مسجل النظامَ الذي يكون system أو id فيه اسمَ النموذج؛ والنموذج الذي لا يسميه أي نظام يُطبع كنظام يُضاف إلى governance.yaml، خارج النطاق حتى يقرر شخص. يُحفظ رقم كل إصدار ومعرّف تشغيله ومصدره تحت .oloproof/governance/mlflow/. ومع --tag تُكتب نتائج آخر سجل مختوم على أحدث إصدار من كل نموذج مطابق كوسوم oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. اختُبر على استجابات مسجلة، وفي 4 نوفمبر 2026 على خادم MLflow 3.18.0 حقيقي يعمل محليًا، وقُرئت الوسوم مجددًا.

يفعل oloproof governance azureml, oloproof governance sagemaker الشيء نفسه لمساحة عمل Azure Machine Learning ولسجل نماذج Amazon SageMaker. يقرأ Azure ML مساحة العمل التي تسميها AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE عبر واجهة الإدارة، برمز في AZURE_ACCESS_TOKEN (az account get-access-token)؛ ويضيف --tag الوسوم الأربعة إلى وسوم أحدث إصدار. يقرأ SageMaker مجموعات حزم النماذج كنماذج وإصدارات حزمها كإصدارات، ويوقّع كل طلب بالمتغيرات المعيارية AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION؛ ويضع --tag القيم الأربع بيانات وصفية للعميل على أحدث حزمة. لا تُخزَّن أي بيانات اعتماد ولا تُطبع، وتُحفظ عمليات الاستيراد تحت .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. اختُبر كلاهما على استجابات مسجلة بالأشكال الموثقة لكل خدمة؛ ولم يُستخدم حساب Azure أو AWS حقيقي.

الاحتفاظ والوصول وموطن البيانات

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

عدة كتالوجات، والمراجعة في مساحة العمل، وواجهة API

يمكن للمشروع أن يسمّي عدة كتالوجات عبر catalogues: [dadm.yaml, ethics.yaml]. يُقرأ كل نظام وفق الكتالوجات التي يذكرها (catalogues: على النظام)، وكتالوجات المجموعات التي تذكره (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}})، وإلا فوفق كل الكتالوجات المعلنة، وتذكر كل نتيجة كتالوجها. تَسِم النسخة الجديدة من الكتالوج متطلبًا بـ retired: "2027-01-01" مع replaced_by: <id> بدلًا من حذفه: فلا يُنتج نتيجة بعد ذلك اليوم، ويذكره السجل.

في مساحة العمل المستضافة يصادق Owner أو Admin على نتيجة أو يرفضها أو يعدّلها أو يعلّق عليها في صفحة Governance. يُسجَّل كل إجراء باسم حسابه في سجل المراجعة الخاص بمساحة العمل والمتسلسل بالتجزئة، ويُقرأ بعد السجل المدفوع، ويُصدِّر الختم السجلين معًا.

يقرأ رمز يحمل نطاق القراءة الكائنات نفسها لمشروعه: GET /api/governance/findings, /seal, /statements, /reviews, /approvals، الموصوفة بـ OpenAPI 3.1 في /api/openapi.json. لا يحمل أيٌّ منها محتوى الحالات.

ما لا يمكنه أن يخبرك به

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