عقد تأليف LLM

الغرض والجمهور

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

هذا هو المستند الرئيسي الذي يجب تسليمه إلى LLM. الأدلة الأخرى اختيارية. للحصول على مسار توجيه إنساني واحد يغطي التنفيذ المحمي، وتقييم DG-as-skill، والتركيب التكراري، انظر skill_pathways_onboarding.md.

تنفيذ مرجعي

للحصول على تنفيذ قانوني ملموس لهذا العقد (عملية حتمية غير متصلة بالإضافة إلى عملية الاشتراك المباشر)، انظر:

الثوابت غير القابلة للتفاوض

Decision Gate هو حد تنفيذ، وليس تحليل استشاري.
يجب أن تُحل الادعاءات الواقعية التي تم وضع علامة عليها على أنها مطلوبة بواسطة الأدلة، وليس ثقة النموذج.
يجب حظر الإجراءات التبعية عندما تكون المطالب المطلوبة غير محلولة.
precheck هو فقط للتكرار؛ المسارات الناتجة تتطلب تقييمًا مباشرًا.
الفجوات في القدرات تفشل بشكل مغلق.

تسلسل أدوات الكانونيكية

استخدم هذه التسلسل لكل سير عمل:

Capability discovery
- providers_list
- provider_contract_get
- provider_check_schema_get
Authoring
- استخراج المطالبات
- بناء claim_inventory
- تجميع claim_condition_map
Fast loop
- schemas_register
- precheck
Consequential boundary
- scenario_define (إذا لم يكن معرفًا بالفعل)
- scenario_start
- scenario_next
Audit/debug
- runpack_export و/أو evidence_query حسب ما تسمح به السياسة

تقاطع المهارات

هذا المستند يبقى البروتوكول المعتمد. المهارات هي أطر تشغيلية لاستخدام البروتوكول بشكل متسق.

مهارات المستودع القياسي:

skills/decision-gate-authoring
skills/decision-gate-verification
skills/decision-gate-capability-discovery

ممر المشاة:

قسم دليل التشغيل	المهارة الأساسية	تسلسل الأدوات المحددة
تسلسل الأدوات القياسي	`decision-gate-authoring`	`providers_list` -> `provider_contract_get` -> `provider_check_schema_get` -> `schemas_register` -> `precheck` -> `scenario_define` -> `scenario_start` -> `scenario_next`
مصافحة اكتشاف القدرات	`decision-gate-capability-discovery`	`providers_list` -> `provider_contract_get` -> `provider_check_schema_get`
عقد تحليل المطالبات	`decision-gate-authoring`	استخراج المطالبات + توليد `claim_inventory` (مدعوم بالعقد)
عقد تجميع الشروط	`decision-gate-authoring` + `decision-gate-capability-discovery`	التحقق من المخططات + التحقق من المقارنات/النوع قبل `claim_condition_map`
عقد التنفيذ + قواعد التوقف القاسية	`decision-gate-authoring` + `decision-gate-verification`	حلقة سريعة لـ `precheck`، ثم بدء `scenario_start` مباشرة + `scenario_next`، ثم `runpack_export` + `runpack_verify`
كتلة تحفيز الوكيل القياسي	جميع المهارات الثلاث	تعليمات مهارية مضغوطة تحافظ على هذا العقد (ليست مصدرًا ثانيًا للحقيقة)

decision_gate_docs_search استعلامات لدعم سير العمل المهاري:

{
  "query": "llm authoring capability discovery handshake providers_list provider_check_schema_get",
  "max_sections": 4
}

{
  "query": "precheck versus live scenario_next hard stop rules enforcement_verdict",
  "max_sections": 4
}

{
  "query": "runpack_export runpack_verify trust lane verified asserted",
  "max_sections": 4
}

اكتشاف القدرة المصافحة

اكتشاف القدرات إلزامي قبل تجميع الشروط في المجالات العشوائية.

1) قائمة مقدمي الخدمة

{}

استخدم الحمولة أعلاه مع providers_list.

2) استرجاع عقد المزود

{
  "provider_id": "json"
}

استخدم الحمولة أعلاه مع provider_contract_get.

3) استرجاع تفاصيل مخطط التحقق

{
  "provider_id": "json",
  "check_id": "path"
}

استخدم الحمولة أعلاه مع provider_check_schema_get.

على الأقل، اجمع:

allowed_comparators
params_schema
result_schema

عقد تحليل المطالبات

يجب تمثيل كل بيان واقعي للمرشح في claim_inventory.

قواعد التصنيف:

gatable = true فقط عندما يمكن التحقق من المطالبة بشكل حتمي ضد مصدر الأدلة.
gating_required = true للمطالبات التي تمنع الإجراءات التبعية إذا لم يتم حلها.
gatable = false يتطلب reason غير فارغ.

وضعان تشغيليان مدعومان:

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

من المتوقع أن تكون هناك خصوصية في المجال: تعتمد المطالبات على مصادر البيانات والوصول لكل فريق.

عقد تجميع الشروط

لكل مطالبة gatable = true، قم بتجميع شرط واحد أو أكثر باستخدام:

provider_id
check_id
params
comparator
متوقع
trust_min_lane

متطلبات التجميع:

يجب أن يكون المقارن في allowed_comparators من provider_check_schema_get.
params يجب أن تتوافق مع params_schema.
expected يجب أن يكون متوافقًا مع result_schema ودلالات المقارنات.
يجب أن تكون قيم condition_id فريدة ضمن السيناريو.

عقد التنفيذ

حلقة التكرار السريعة (المؤكدة)

سجل المخطط عبر schemas_register.
قم بتشغيل precheck ضد الحمولة المؤكدة.
إصلاح تخطيط المطالبات، المخطط، أو الشروط حتى يتم تقييم المطالبات المطلوبة لتكون في حالات النجاح.

الحدود التبعية (تم التحقق منها)

قبل أي إجراء ذو عواقب:

تأكد من تعريف السيناريو (scenario_define).
إنشاء تشغيل (scenario_start).
تنفيذ التقييم المباشر (scenario_next).
تابع فقط إذا كانت نتيجة القرار هي اجتياز/تقدم/اكتمال لسياسة الحدود الخاصة بك.

قواعد التوقف القاسية (يجب عدم المتابعة)

لا تسمح باتخاذ إجراء تبعي عندما تكون أي من الشروط أدناه صحيحة:

لا يوجد تعيين لمطالبة مطلوبة في claim_condition_map.
شرط مطلوب مرتبط يحل false أو unknown.
scenario_next لا يُرجع نتيجة مرور مسموح بها لحد الإفراج.
السياسة تتطلب تحقق ولكن يتم استخدام أدلة مؤكدة فقط.
فشل التحقق من صحة عقد مزود/تحقق/مقارن/نوع.

كتلة موجه الوكيل القياسي

قم بلصق هذا في موجه نظام وكيلك، ثم اربط طبقة الأداة بأدوات DG MCP.

You are the Decision Gate Authoring Agent. Follow this protocol exactly.

Inputs:
- draft_output: candidate output text or structured payload
- consequence_boundary: the action that must be blocked unless gates pass
- policy_defaults:
  - required_risk_levels: ["high", "critical"]
  - required_min_lane: "verified"

Required outputs (all four):
1) claim_inventory
2) capability_matrix
3) claim_condition_map
4) enforcement_verdict

Protocol:
1. Discover provider capabilities using providers_list, provider_contract_get, provider_check_schema_get.
2. Extract factual claims from draft_output.
3. Build claim_inventory:
   - Set gatable=true only for deterministically checkable claims.
   - Set gating_required=true for claims whose failure must block consequence_boundary.
   - Include non-empty reason for every gatable=false claim.
4. Build claim_condition_map for all gatable=true claims.
5. Validate mappings against provider check contracts (comparators, params, value types).
6. Run precheck for fast iteration.
7. Before consequence_boundary, run live scenario_start + scenario_next.
8. Set enforcement_verdict.can_proceed=true only if all required gatable claims are resolved by passing live-evaluated conditions at required trust lane.

Hard-stop behavior:
- If any required gatable claim is unmapped, unknown, false, or lane-invalid, set can_proceed=false and emit explicit blocking_reasons.
- Never treat model confidence or self-verification text as evidence.

قوالب JSON المدمجة

claim_inventory (مطلوب)

{
  "claim_inventory": [
    {
      "claim_id": "claim_001",
      "claim_text": "Case X exists in court records",
      "gatable": true,
      "gating_required": true,
      "reason": "Deterministic external lookup available",
      "evidence_source_hint": "court_records_api",
      "risk_level": "high"
    }
  ]
}

capability_matrix (مطلوب)

{
  "capability_matrix": [
    {
      "provider_id": "json",
      "check_id": "path",
      "allowed_comparators": ["equals", "exists", "not_exists", "in_set"],
      "params_schema_ref": "provider_check_schema_get:json:path:params_schema",
      "result_schema_ref": "provider_check_schema_get:json:path:result_schema"
    }
  ]
}

claimconditionmap (مطلوب)

{
  "claim_condition_map": [
    {
      "claim_id": "claim_001",
      "condition_id": "case_exists",
      "provider_id": "rest",
      "check_id": "json_path",
      "params": {
        "url": "https://api.example.com/cases/lookup?id=925-F3d-1339",
        "jsonpath": "$.exists"
      },
      "comparator": "equals",
      "expected": true,
      "trust_min_lane": "verified"
    }
  ]
}

enforcement_verdict (مطلوب)

{
  "enforcement_verdict": {
    "can_proceed": false,
    "blocking_reasons": [
      "required claim claim_001 unresolved",
      "live evaluation not complete"
    ],
    "required_claims_unresolved": ["claim_001"]
  }
}

المسار الذهبي الأدنى (تدفق شامل من البداية إلى النهاية)

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

نصيحة ويندوز: PowerShell/CMD لا تدعم curl متعددة الأسطر بأسلوب bash. استخدم أمرًا في سطر واحد أو سلاسل PowerShell هنا. نصيحة الإعدادات المسبقة: ابدأ بـ configs/presets/quickstart-dev.toml للاستخدام المحلي.

الخطوة 1: تعريف السيناريو

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "scenario_define",
      "arguments": {
        "spec": {
          "scenario_id": "llm-precheck",
          "namespace_id": 1,
          "spec_version": "v1",
          "stages": [
            {
              "stage_id": "main",
              "entry_packets": [],
              "gates": [
                {
                  "gate_id": "quality",
                  "requirement": { "Condition": "report_ok" }
                }
              ],
              "advance_to": { "kind": "terminal" },
              "timeout": null,
              "on_timeout": "fail"
            }
          ],
          "conditions": [
            {
              "condition_id": "report_ok",
              "query": {
                "provider_id": "json",
                "check_id": "path",
                "params": { "file": "report.json", "jsonpath": "$.summary.failed" }
              },
              "comparator": "equals",
              "expected": 0,
              "policy_tags": []
            }
          ],
          "policies": [],
          "schemas": [],
          "default_tenant_id": 1
        }
      }
    }
  }'

الخطوة 2: تسجيل مخطط التحقق المسبق

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "schemas_register",
      "arguments": {
        "record": {
          "tenant_id": 1,
          "namespace_id": 1,
          "schema_id": "llm-precheck",
          "version": "v1",
          "schema": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
              "report_ok": { "type": "number" }
            },
            "required": ["report_ok"]
          },
          "description": "LLM precheck payload schema",
          "created_at": { "kind": "logical", "value": 1 },
          "signing": null
        }
      }
    }
  }'

الخطوة 3: التحقق المسبق (حلقة سريعة)

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "precheck",
      "arguments": {
        "tenant_id": 1,
        "namespace_id": 1,
        "scenario_id": "llm-precheck",
        "spec": null,
        "stage_id": "main",
        "data_shape": { "schema_id": "llm-precheck", "version": "v1" },
        "payload": { "report_ok": 0 }
      }
    }
  }'

شكل الاستجابة المتوقع:

{
  "decision": {
    "kind": "complete",
    "stage_id": "main"
  },
  "gate_evaluations": [
    {
      "gate_id": "quality",
      "status": "true",
      "trace": [
        { "condition_id": "report_ok", "status": "true" }
      ]
    }
  ]
}

الخطوة 4: الحدود الحية (مطلوبة قبل اتخاذ إجراء تبعي)

# scenario_start
curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "tools/call",
    "params": {
      "name": "scenario_start",
      "arguments": {
        "scenario_id": "llm-precheck",
        "run_config": {
          "tenant_id": 1,
          "namespace_id": 1,
          "run_id": "run-1",
          "scenario_id": "llm-precheck",
          "dispatch_targets": [],
          "policy_tags": []
        },
        "started_at": { "kind": "unix_millis", "value": 1710000000000 },
        "issue_entry_packets": false
      }
    }
  }'

# scenario_next
curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 5,
    "method": "tools/call",
    "params": {
      "name": "scenario_next",
      "arguments": {
        "scenario_id": "llm-precheck",
        "request": {
          "run_id": "run-1",
          "tenant_id": 1,
          "namespace_id": 1,
          "trigger_id": "trigger-1",
          "agent_id": "agent-1",
          "time": { "kind": "unix_millis", "value": 1710000000000 },
          "correlation_id": null
        },
        "feedback": "trace"
      }
    }
  }'

Proceed only if the live decision meets your pass policy.

استعادة الفشل والتصعيد

إذا فشلت عملية التحقق أو التقييم:

Capability mismatch
- إعادة استعلام provider_check_schema_get وإصلاح عدم تطابق المقارنات/المعلمات/نوع النتيجة.
precheck hold or tool error
- تحقق من الحمولة مقابل شكل البيانات؛ تأكد من توافق معرفات الشروط مع مفاتيح الحمولة.
Live run hold/fail
- افحص runpack (runpack_export) أو استدعِ evidence_query (إذا كانت سياسة الكشف تسمح بذلك).
Trust lane mismatch
- إذا كانت السياسة تتطلب verified، فلا تقم بالموافقة على الأدلة التي تم التأكيد عليها فقط.
Unclear claim classification
- تصعيد إلى مالك السياسة البشري؛ الافتراضي هو gating_required = true للمطالبات عالية المخاطر.

غوص عميق خاص بالمزودين:

معجم

جرد المطالبات: قائمة قابلة للقراءة الآلية لمطالبات المرشحين وتصنيف البوابات. مصفوفة القدرات: قدرات المزود/التحقق المكتشفة من أدوات DG. خريطة حالة المطالبات: رسم بياني حتمي من المطالبات القابلة للبوابة إلى حالات DG. التحقق المسبق: محاكاة الأدلة المؤكدة، بدون تغيير حالة التشغيل. التشغيل المباشر: تقييم تم جلبه من قبل المزود يغير حالة التشغيل ويدعم تدقيق حزمة التشغيل. الإجراء الناتج: أي إجراء يغير الحالة الخارجية، يحرر المخرجات، أو يلتزم بقرار.