toulmin — محرك قواعد يحسب العقود

ظلت محركات القواعد لمدة 60 عامًا قائمة على نفس الفرضية: موضوع التحقق هو “حقيقة (fact)”.

يضع Drools كائنات Java كـ “fact” في working memory. ويتعامل Rego مع input كبيانات صحيحة بالفعل. ويفترض JSON Schema أن بنية المستند معطاة مسبقًا. جميعها تشترك في نفس الافتراض — البيانات الواردة هي حقائق.

لكن ما هو سبب وجود محرك القواعد أصلًا؟ إنه التحقق مما إذا كانت البيانات تستوفي القواعد. تسمية ما يحتاج إلى تحقق بـ “شيء صحيح بالفعل” هو تناقض.

ليست حقيقة بل ادعاء

موضوع التحقق ليس fact بل claim (ادعاء). تأكيد قد يكون صحيحًا أو خاطئًا. يجب أن يُحكم على صحته بواسطة القواعد.

JWT يتبع هذا المبدأ بالفعل. يسمي sub وexp وiss بـ “claims” وليس “facts”. إنها ادعاءات من مُصدر الرمز المميز. يجب التحقق من التوقيع، والتأكد من انتهاء الصلاحية، ومطابقة المُصدر قبل أن يمكن الوثوق بها.

هذه بنية تم تأسيسها عام 1958.

نموذج تولمن للحجاج

حلل Stephen Toulmin عام 1958 بنية الحجاج إلى 6 عناصر:

• Claim (ادعاء): موضوع الحكم. ما يجب التحقق من صحته أو كذبه.
• Ground (أساس): بيانات الأدلة المستخدمة في الحكم.
• Warrant (ضمان): القاعدة التي تحكم بأن الأساس يدعم الادعاء.
• Backing (سند): المبرر لسبب صحة القاعدة.
• Qualifier (محدد): درجة الثقة في الحكم.
• Rebuttal (دحض): الشروط الاستثنائية التي لا يصح فيها الادعاء.

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

ظلت محركات القواعد لمدة 60 عامًا في جانب المنطق الصوري. المدخل fact، والنتيجة allow/deny، والاستثناءات آلية منفصلة. أما تولمن فكان على الجانب المقابل. المدخل claim، والنتيجة درجة (degree)، والاستثناءات مدمجة.

المشكلة — أن كتاب تولمن كان على رف الفلسفة. لم يكن مرئيًا على رف محركات القواعد. حلقة مفقودة لمدة 60 عامًا.

لذلك بنيت محرك قواعد

toulmin هو تحويل نموذج تولمن للحجاج إلى محرك قواعد بلغة Go.

المتطلبات تتطور

لنرَ كيف يستجيب if-else وtoulmin لنفس التطور:

// الاثنين: "الوصول للمستخدمين المُصادق عليهم فقط، تطبيق حظر IP، إعفاء الشبكة الداخلية"
g := toulmin.NewGraph("api:access")
auth    := g.Warrant(isAuthenticated, nil, 1.0)
blocked := g.Rebuttal(isIPBlocked, nil, 1.0)
exempt  := g.Defeater(isInternalIP, nil, 1.0)
g.Defeat(blocked, auth)
g.Defeat(exempt, blocked)

// الثلاثاء: "إضافة Rate limiting"
limited := g.Rebuttal(isRateLimited, nil, 1.0)
g.Defeat(limited, auth)

// الأربعاء: "المستخدمون المميزون معفون من Rate limit"
premium := g.Defeater(isPremiumUser, nil, 1.0)
g.Defeat(premium, limited)

// الخميس: "أثناء الاستجابة للحوادث، حتى المميزون مقيدون"
incident := g.Rebuttal(isIncidentMode, nil, 1.0)
g.Defeat(incident, premium)

إضافة سطرين يوميًا، بدون تغيير الكود الحالي. نفس التطور بأسلوب if-else:

// الاثنين
if user != nil {
    if blockedIPs[ip] {
        if strings.HasPrefix(ip, "10.") {
            allow = true
        }
    } else {
        allow = true
    }
}

// الخميس — 4 مستويات تداخل، البنية غير قابلة للفهم
if user != nil {
    if blockedIPs[ip] {
        if strings.HasPrefix(ip, "10.") {
            allow = true
        }
    } else if isRateLimited(ip) {
        if isPremium(user) {
            if !incidentMode {
                allow = true
            }
        }
    } else {
        allow = true
    }
}

toulmin: سطران لكل متطلب، البنية ثابتة. if-else: إعادة هيكلة كاملة في كل مرة.

القواعد هي دوال Go

func(claim any, ground any, backing any) (bool, any)

• ground = مادة الحكم التي تتغير مع كل طلب (المستخدم، IP، السياق)
• backing = معيار الحكم الثابت عند إعلان الرسم البياني (العتبات، أسماء الأدوار، الإعدادات)
• الإرجاع = (نتيجة الحكم، الدليل). الدليل نوع حر حسب المجال.

func CheckOneFileOneFunc(claim, ground, backing any) (bool, any) {
    g := ground.(*FileGround)
    if len(g.Funcs) > 1 {
        return true, &Evidence{Got: len(g.Funcs), Expected: 1}
    }
    return false, nil
}

لا حاجة لتعلم لغة جديدة مثل Rego. اكتب دوال Go فقط.

backing — نفس الدالة، معايير حكم مختلفة

يمرر backing معيار حكم القاعدة كقيمة وقت التشغيل. تسجيل نفس الدالة بـ backing مختلف ينشئ قواعد منفصلة:

g := toulmin.NewGraph("access")
admin  := g.Warrant(isInRole, "admin", 1.0)
editor := g.Warrant(isInRole, "editor", 0.8)

g := toulmin.NewGraph("line-limit")
strict  := g.Warrant(CheckLineCount, &LineLimit{Max: 100}, 0.7)
relaxed := g.Warrant(CheckLineCount, &LineLimit{Max: 200}, 0.5)
g.Defeat(relaxed, strict)

إذا كان backing يساوي nil فهذا يعني أن القاعدة لا تحتاج إلى معيار حكم.

الاستثناءات تُعلن كرسم بياني

أعلن العلاقات بين القواعد باستخدام Graph Builder API والمحرك يتولى الباقي. الدالة هي المُعرّف. لا حاجة لأسماء نصية.

g := toulmin.NewGraph("filefunc")
w := g.Warrant(CheckOneFileOneFunc, nil, 1.0)
d := g.Defeater(TestFileException, nil, 1.0)
g.Defeat(d, w)

results, _ := g.Evaluate(claim, ground)

يمكن إعادة استخدام نفس الدالة في رسوم بيانية مختلفة بعلاقات هزيمة مختلفة:

strictGraph := toulmin.NewGraph("strict")
strictGraph.Warrant(CheckOneFileOneFunc, nil, 1.0)
// بدون استثناءات — حتى ملفات الاختبار غير مسموح بها

lenientGraph := toulmin.NewGraph("lenient")
w := lenientGraph.Warrant(CheckOneFileOneFunc, nil, 1.0)
r1 := lenientGraph.Rebuttal(TestFileException, nil, 1.0)
r2 := lenientGraph.Rebuttal(GeneratedFileException, nil, 0.8)
lenientGraph.Defeat(r1, w)
lenientGraph.Defeat(r2, w)
// استثناء لملفات الاختبار والملفات المُولّدة معًا

تتبع أساس الحكم

EvaluateTrace يتتبع ليس فقط verdict بل أيضًا أي القواعد تم تفعيلها وأي قاعدة هزمت أي قاعدة:

traced := g.EvaluateTrace(claim, ground)
// traced[0].Verdict: +0.6
// traced[0].Trace: [
//   {Name: "CheckOneFileOneFunc", Role: "warrant",  Activated: true,  Qualifier: 1.0},
//   {Name: "TestFileException",   Role: "rebuttal", Activated: true,  Qualifier: 1.0},
// ]

عندما يكون هناك عشرات القواعد، يمكن للإنسان قراءة “لماذا صدر هذا الـ verdict”.

الحكم يُحسب بمعادلة واحدة

تم تطبيق h-Categoriser لـ Amgoud (2013):

raw = w / (1 + Σ raw(attackers))
verdict = 2 × raw - 1

• +1.0 — انتهاك مؤكد
• 0.0 — حكم غير قابل للتحديد
• -1.0 — دحض مؤكد

عندما تُفعّل قاعدة تصبح warrant. وإذا فُعّل استثناء يصبح attacker. المعادلة تحسب قوة الطرفين وتُنتج verdict. ماذا لو كان هناك استثناء من الاستثناء؟ يصبح attacker للـ attacker فتُستعاد القاعدة الأصلية. مبدأ التعويض (Compensation) — خاصية لا يحققها إلا h-Categoriser.

القواعد لها ثلاث درجات قوة

تم تطبيق تصنيف Nute (1994):

القواعد الصارمة (Strict) ترفض أضلاع الهجوم. أما Defeater فتهاجم فقط بدون حكم خاص بها. هذا يعبّر هيكليًا عن مستوى إنفاذ القاعدة.

ما الفرق عن Rego؟

Rego واسع — لديه نظام بيئي متكامل مع Kubernetes وTerraform وEnvoy. أما toulmin فعميق — يمتلك ما لا يوجد في Rego (defeasibility، qualifier، backing).

إعادة موضعة Qualifier

في نموذج تولمن الأصلي، يُلحق Qualifier بـ Claim. “من المحتمل أن يُعطى هذا المريض البنسلين” — محدد جهوي يعبر عن درجة الثقة في الادعاء.

أعاد محرك toulmin موضعة Qualifier من Claim إلى كل Rule. في محرك القواعد، claim هو مجرد موضوع تحقق. “هذا الملف يحتوي على 3 دوال” — تحقق من واقع، وليس شيئًا تُلحق به درجة ثقة. ما يحدد جودة الحكم هو درجة ثقة القاعدة:

• “دالة واحدة لكل ملف” — qualifier 1.0 (قاعدة قاطعة)
• “يُنصح بأقل من 100 سطر” — qualifier 0.7 (قاعدة مرنة)

qualifier كل Rule يصبح الوزن الأولي w(a) في h-Categoriser، والـ verdict النهائي يحل محل الدور الذي كان Qualifier يؤديه في نموذج تولمن الأصلي — درجة الثقة في الحكم.

التحقق العملي: تحويل 22 قاعدة من filefunc إلى نموذج تولمن

filefunc هي أداة اصطلاح بنية الكود لتطوير Go المُحسّن لـ LLM. تم تحويل جميع القواعد الـ 22 إلى toulmin warrant.

تصنيف القوة

معظمها strict — اصطلاحات بنية الكود بطبيعتها تقلل الاستثناءات إلى الحد الأدنى.

النتائج الكمية

fullend انتقل من 87 ملفًا إلى 1,260. عدد الملفات انفجر لكن متوسط LOC انخفض من 244 إلى 25.4. جميع انتهاكات SRP البالغة 66 وانتهاكات depth البالغة 148 أصبحت صفرًا.

الأساس النظري

لا توجد نظرية أصيلة. جميعها أبحاث قائمة:

الأصالة تكمن في اكتشاف أنها تتصل. ما كان موجودًا لمدة 60 عامًا بشكل منفصل في الفلسفة (Toulmin) والمنطق (Nute) ونظرية الحجاج (Amgoud)، يلتقي في نقطة واحدة: محرك قواعد البرمجيات.

حساب العقد

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

toulmin نقل هذه البنية إلى الكود.

• Warrant = مادة قانونية
• Backing = الغرض التشريعي
• Strength = قاعدة آمرة مقابل قاعدة مكملة
• Rebuttal = مادة استثنائية
• Claim = قضية
• Ground = دليل
• h-Categoriser = حكم

أعلن العقد (warrant)، وأعلن الاستثناءات (rebuttal)، وأدخل الأدلة (ground)، فيُحسب الحكم (verdict).

ليس الإنسان من يحكم. المعادلة تحسب.

Acc(a) = w(a) / (1 + Σ Acc(attackers))

تعريف الرسم البياني بـ YAML

يمكن إعلان بنية الرسم البياني بـ YAML بدون كود Go وتوليد الكود:

graph: filefunc
rules:
  - name: CheckOneFileOneFunc
    role: warrant
    qualifier: 1.0
  - name: TestFileException
    role: rebuttal
    qualifier: 1.0
defeats:
  - from: TestFileException
    to: CheckOneFileOneFunc

toulmin graph filefunc.yaml    # graph_gen.go 생성

اكتب دوال القواعد بلغة Go فقط. بنية الرسم البياني يعلنها YAML.

MIT License. github.com/park-jun-woo/toulmin