philippeabraxas-jpg/tbp-networkنظرية وتنفيذ بروتوكول TBP لتأمين الذكاء الاصطناعي المتصل بالشبكة في الشبكات الصغيرة إلى الشبكات المفتوحة
تنفيذ على مستوى الشبكة لـ بروتوكول التحديد الغائي (TBP) — حوكمة موثّقة لإجراءات وكلاء الذكاء الاصطناعي عبر الشبكة، من جهاز واحد إلى عمليات نشر على مستوى المؤسسات وصولاً إلى نطاق الويب العالمي.
« التحكم في الوصول القائم يقرر ما إذا كان يُسمح لك بالدخول؛ أما TBP فيقرر ما يُسمح لك بفعله بعد الدخول — ويثبت ذلك. نحن نحكم القدرات، لا النماذج. »
لا شراكة بالثقة أبداً — فقط بمصافحة موثّقة. هذا ما يمثله هذا المستودع: المصافحة بين الكيانات (المواصفة §3) وكل ما يحيط بها — NAC وPEPs وسجلات الخلايا — مما يوسّع حوكمة TBP من جهاز واحد إلى شبكة من الكيانات التي عليها أن تثق ببعضها دون أن تثق ببعضها ببساطة.
ملاحظة حول اللغة: المواصفة المرجعية هي الآن
docs/spec-en-v1.0.md (بالإنجليزية) — هذا هو
رمز الوثيقة الذي ينبغي أن تُبنى عليه التدقيقات. مذكرة العمل الخاصة بالمؤلف —
أكثف، أقل خطية، مفيدة للتنقيب في منطق التصميم، لكنها ليست ما يُستشهد به — موجودة بلغتين:
docs/spec-v1.4.10.md (بالإنجليزية) و
docs/spec-v1.4.10.fr.md (الفرنسية الأصلية).
ينطبق الاصطلاح نفسه على كامل المستودع: كل وثيقة كُتبت أصلاً
بالفرنسية أصبح لها الآن نسخة إنجليزية أساسية في مسارها الأصلي، مع
الاحتفاظ بالنسخة الفرنسية الأصلية بجانبها باسم <name>.fr.md. لا يزال
المعجم (docs/glossaire.md) مصدره فرنسياً (§14 من الوثيقة الفرنسية هو
مصدر الحقيقة المصطلحي) مع عمود شرح بالإنجليزية
لتحسين القراءة — وهذا لم يتغير.
المواصفة الكاملة هي docs/spec-en-v1.0.md
— وهي مصدر الحقيقة لأي قرار تصميمي أو تكويني في
هذا المستودع. يكتفي هذا الملف التمهيدي بتلخيص ما يلزم للتوجّه؛
وعند الشك، تحكم المواصفة. مذكرة العمل
(docs/spec-v1.4.10.md، الترجمة الإنجليزية للأصل الفرنسي) ليست
محتوى ملغى — فهي البروتوكول نفسه، وقد طُوّر هناك أولاً — لكنها ليست
المرجع القابل للاستشهاد في المستقبل.
معالم مفيدة لقراءتها:
docs/glossaire.md — مصطلح معياري واحد لكل
مفهوم، يُستخدم باتساق عبر كود ووثائق هذا المستودع
(انظر CONTRIBUTING.md).البروتوكول نفسه — المواصفة، العقيدة الرسمية، التدقيقات العدائية،
التنفيذ الأساسي (توقيع HSM، سلسلة تدقيق Merkle، محرك سياسات OPA) —
يوجد في Responsible-Alliance-Protocol،
بترخيص Apache 2.0 (مفتوح)، وهو مُضمَّن داخل الشجرة هنا في tbp4.2.1/
كـ git submodule مثبّت على commit محدد — مؤشر، لا تفرّع:
هذا المستودع ليس أبداً المكان المناسب لرفع issue أو PR ضد ذلك
الكود، بل فقط ضد أجزاء النشر الشبكي أدناه. هذا المستودع
هو النشر على نطاق الشبكة للبروتوكول نفسه: NAC، وPEPs المحلية،
وسجلات الخلايا، والمصافحة بين الكيانات — الأجزاء اللازمة لنقل
TBP من جهاز واحد محكوم إلى شبكة محكومة. اعتباراً من هذا
الإشعار، كود هذا المستودع نفسه هو أيضاً Apache 2.0 (انظر الترخيص
أدناه) — الترخيص نفسه المستخدم للبروتوكول الأساسي، ترخيص واحد عبر كلا
المستودعين، لا ترخيصان. كان يستخدم سابقاً ترخيصاً مغلقاً خلال
مرحلة تجريبية أولية؛ وقد انتهت تلك المرحلة.
إبقاء الـ submodule محدثاً: لا يُحدّث tbp4.2.1/ نفسه —
فترقيته إلى commit أحدث من Responsible-Alliance-Protocol هي
إجراء متعمد وخاضع للمراجعة (cd tbp4.2.1 && git checkout <commit> && cd .. && git add tbp4.2.1 && git commit)، وليس تلقائياً أبداً. إن submodule
مثبّتاً يتخلف بصمت عن إصلاح أمني في المصدر أعلى منه أسوأ
من عدم وجود submodule إطلاقاً — تعامل مع ترقيته بالعناية نفسها التي توليها لأي
تحديث تبعية آخر، وتحقق من سجل التغييرات الخاص بالمستودع الأساسي أولاً.
tbp4.2.1/ Git submodule: the core protocol (Responsible-Alliance-Protocol,
pinned commit) — working implementation, tests, live at
invarian.fr; includes tbp-v4-hard-shield/ (the OPA policy
engine this repo's PEPs enforce against). Not copied: run
git submodule update --init to fetch it; source of truth
and issue tracker for this code stay in that repository.
docs/ Specification (spec-en-v1.0.md, reference; spec-v1.4.10.md +
spec-v1.4.10.fr.md, working note EN/FR), glossary, audits
figs/ Figures referenced by the spec (see MANIFEST.md)
policies/
├── README.md How to generate capabilities.json correctly
├── gen_capabilities.sh + validate_determinism.go Generation + determinism gate
└── rego/ Illustrative example Rego policies
config/
├── nftables/ Local PEP redirection + P1 router rules (§4.1, §5.1)
├── freeradius/ 802.1X / EAP-TLS + enrolment/revocation scripts (§5.1)
└── sysctl/ Generic kernel hardening
src/
├── pep/ Local policy enforcement point (§4.1, §4.1-bis, §4.3):
│ CWT/COSE token validation (Ed25519), memory-bounded
│ fail-closed anti-replay, clock-status degraded mode,
│ execution quotas, plan-as-contract gate, monitor→closed
│ modes, pepd daemon
│ └── postgres-extension/ Two-hook in-process PEP for PostgreSQL (§4.4)
├── broker/ Cell broker (§5.1): single entry point of the decision
│ flow — orchestration, token issuer, emission envelope,
│ HTTP server (brokerd), epoch/quorum/plan-contract wiring
├── cluster/ Multi-cell fencing (§7.2–§7.5): single-authority epochs
│ (m-of-n verified, monotone, equivocation-detected),
│ k-of-n quorum for class W, mirror/canary promotion
├── registry/ Cell registry (§6): Tessera POSIX cell log with signed
│ checkpoints, disk backpressure, anchoring + TSA,
│ attested state manifest, measured boot (§6.3)
├── supervision/ Independent monitor (§2, §6.2, §7.1): verified chain
│ reading (ChainWatcher), divergence alerting, failover
│ detection, read-only console, supervisord
├── telemetry/ Flow metadata exporters, anti-dribble (§4.1-bis)
└── translator/ Translator (§4.5): runtime hardening (hardened systemd
unit, seccomp allowlist, confinement audit) + controlled
degradation state machine (structured-only, no cloud
fallback; mirror failover / human escalation /
default-deny per system class) + quality measurement
(corpus replay, per-class FNR/FPR gate blocking CI,
stratified human sampling, TBTM1 registry leaf)
deploy/ Multi-machine deployment guides (router, cell, server,
supervisor) with per-machine checklists, monitor→closed
posture switch, and an executable selftest (82 controls)
scripts/genesis/ Genesis ceremony tooling (epoch 0, controller keys §12)
lab/ docker-compose PoC + containerlab P1 topology + netns
tests (802.1X fail-closed, MAB/IoT VLAN, OCSP remediation)
tests/
├── p1_friction/ Friction budget (§9.1): thresholds + Go harness + leading indicators
└── p2_redteam/ Attack scenarios (§13) + evidence-producing runner
.github/ Issue templates, CI (Rego determinism gate + lint)
**الحالة الحالية (اعتبارًا من 2026-09-22): كود الطرح مُنفَّذ ومُختبَر على طول المسار الكامل — genesis → fencing → registry → broker → PEP → supervision → translator → deployment.** كل حزمة في `src/` تحمل مجموعة اختباراتها الخاصة (اختبارات وحدة/تكامل بلغة Go، وPython لأدوات التدقيق والقياس)، ويُنفِّذ `deploy/selftest/` أدلة النشر من البداية إلى النهاية (**82 ضابطًا، 0 إخفاقات** — الدليل الذي ينحرف عن الكود يفشل هناك، لا عند المشغِّل). لا يوجد أي PR مفتوح ضد هذا المستودع في الوقت الحالي — فالمتراكمات التي كانت قيد التنفيذ (T25 التدهور المُتحكَّم فيه، T38 متانة السجل محدود-اللاتزامن، T26 قياس جودة المترجم) قد اندمجت جميعها. يبقى بندان مفتوحان ومُتابَعان عن قصد، ولا يعيق أيٌّ منهما التجربة التجريبية: الترجمة الإنجليزية للوثائق الفرنسية المتبقية ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83)، قيد التنفيذ — معظم `deploy/` و`docs/` لديها بالفعل نسخ إنجليزية أساسية، انظر "ملاحظة حول اللغة" أعلاه)، وطبقة ما بين النطاقات (المواصفة §13 — مؤجَّلة من قبل المواصفة نفسها، ومُتابَعة في [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) حتى يبقى "التأجيل" مرئيًا بدلًا من أن يكون غائبًا بصمت). وما هو **غير** موجود هنا عن قصد بعد ذلك: مجموعات المترجم الأصلية لكل لغة (التي ستُشكَّل عند التجربة التجريبية، §15 — فخط الأنابيب الذي يعيد تشغيلها ويبوّب عليها مبنيٌّ بالفعل) ومسار التصعيد بالتحكيم البشري (brokerd v1 يقبل فقط المترجم `structured`). لا تنشر `config/` كما هي — كل ملف هناك يقول ذلك صراحةً، ويستحق التكرار هنا أيضًا. والبروتوكول الذي يحكم كود الطرح هذا ليس هيكلًا عظميًا أيضًا: `tbp4.2.1/` يضم النواة العاملة (موقِّع HSM، سلسلة تدقيق Merkle، محرك سياسات OPA، الاختبارات، عملية المراجعة العدائية) داخل الشجرة عبر git submodule، مثبَّتة على commit محدد — موجودة هنا دون نسخها أو تكرارها.
## إرشادات الإعداد — من أين تبدأ
بناءً على تسلسل التنفيذ (§13) ونطاق التجربة التجريبية P1 (§13، §9.1: شبكة VLAN واحدة للخادم، موجِّه Debian، خليتان، 802.1X، سجل مركزي، تراجع مقيس في تجربة المستخدم = 0):
1. **Genesis والمفاتيح** (§7.2، §3.2) — قبل أي شيء آخر: مراسم genesis موقَّعة من نصاب المتحكِّم (m-of-n، HSM)، ومُثبَّتة خارج النطاق. يوفِّر [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) أدوات الحقبة-0 (بما في ذلك مسار التطوير)؛ أما المراسم نفسها فتبقى إجرائية، لا كود — لا شيء في هذا المستودع يحل محلها.
2. **Cluster fencing** (§7، §13 الخطوة 2) — إصدار الحقبة وتدويرها، نصاب المتحكِّم (k-of-n) لإجراءات الفئة-W، ترقية mirror/canary. مطلوب قبل أي نشر متعدد الخلايا، بما في ذلك تجربة P1 ذات الخليتين أدناه — خلية واحدة يمكنها تأجيل هذا، أما التجربة التجريبية فلا. مُنفَّذ في [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) (متتبِّع حقبة أحادي السلطة، النصاب، الترقية بإثبات الاستلام — لا يُحتفظ بأي مفتاح خاص هناك) ومربوط في broker ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + registry** — ثبِّت OPA، وولِّد `policies/capabilities.json` باتباع [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) (أزل `http.send` و`time.now_ns` قبل أي نشر، لا بعده أبدًا؛ `validate_determinism.go` وبوابة CI للحتمية يفرضان ذلك)، وشغِّله بـ `lab/docker-compose.yml` للتحرير على القواعد محليًا. البيان المُصادَق عليه والإقلاع المقيس (§6.3، §13 الخطوة 3) — يجب أن تكون حالة الخلية نفسها قابلة للإثبات قبل أن تكون قراراتها كذلك — مُنفَّذان في [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) إلى جانب سجل الخلية، والضغط الخلفي، والتثبيت.
4. **PEP** — أول محيط محكوم فعليًا (§13)، مُنفَّذ في [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): التحقق من الرموز (CWT/COSE، Ed25519)، مكافحة إعادة التشغيل محدودة الذاكرة وتفشل-مغلقة، وضع التدهور عند حالة الساعة، حصص التنفيذ، وبوابة الخطة-كعقد (§4.2، §13 الخطوة 4 — التحقق من الرمز وحده يحكم إجراءً واحدًا، لا الخطة متعددة الخطوات التي يوقِّعها المشغِّل فعليًا). اقرأ [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md)، و[`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft) لإعادة توجيه الشبكة من جهة Debian. **انشر في وضع المراقبة أولًا** (تسجيل، بلا حجب) — لا `closed` أبدًا عند الطرح الأول (المذهب §5.3)؛ إجراء تبديل الوضعية هو [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). بالنسبة إلى PostgreSQL، يوجد PEP داخل العملية بخطافين في [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC بالتوازي** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius): 802.1X/EAP-TLS بإعادة استخدام نفس PKI المستخدمة في المصافحة (§3)، مع فرض fail-closed على مستوى المحوِّل (وليس فقط على جانب RADIUS)، وبلا VLAN مُعيَّن من RADIUS في v1. مجموعات netns في `lab/tests/` تختبر مسارات fail-closed، وMAB/IoT-VLAN، ومعالجة OCSP.
6. **تقوية المضيف** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf) على كل جهاز يشغِّل مكوِّنًا من مكوِّنات TBP (broker، PEP، registry).
7. **المترجم أخيرًا** (§13) — بعد استقرار كل شيء آخر. مُسلَّم في [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): تقوية وقت التشغيل (غير جذر، cap-drop، seccomp — متميزة عن `dm-verity`، التي تحمي الصورة في حالة السكون، لا وقت التشغيل)، وآلة حالة التدهور المُتحكَّم فيه (structured فقط، بلا احتياطي سحابي)، وقياس الجودة (`measure.py` يعيد تشغيل المجموعة ويبوّب CI على تراجع FNR/FPR، و`tmetrics` يسجِّل النتيجة كورقة في السجل، T26، §4.5) — أما المجموعات نفسها فتُشكَّل عند التجربة التجريبية، ولا تُشحَن هنا.
8. **النشر متعدد الأجهزة** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md) هو نقطة الدخول (ماذا، أين، لماذا، المتطلبات المسبقة)؛ وهو يجمِّع الأدلة الخاصة بكل دور (موجِّه، خلية، خادم، مشرف) وقوائم القبول لكل جهاز. `deploy/selftest/` **ينفِّذ** الأدلة (`bash deploy/selftest/selftest.sh`، 82 ضابطًا، fail-closed) — شغِّله قبل لمس أي جهاز حقيقي.
في كل خطوة، قِس مقابل ميزانية الاحتكاك (§9.1) — انظر [`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) للحدود الدقيقة وأداة التشغيل القابلة للتنفيذ. تفشل التجربة التجريبية إذا تجاوز زمن الاستجابة أو معدل التحكيم هذه الحدود، حتى لو عمل كل شيء آخر.
## خارطة الطريق: مقاييس نشر بحجم مناسب
TBP نظام حوكمة معقد وكامل النطاق — cluster fencing، نصاب، مشرف مستقل، مترجم مُقوَّى، مصافحة بين الكيانات. ليست كل عملية نشر تحتاج كل ذلك. شركة صغيرة بخادم واحد تريد "ألا يتصرف أي وكيل ذكاء اصطناعي دون سبب قابل للإثبات ومسجَّل" لا تحتاج تجاوز فشل بخليتين أكثر مما تحتاج شبكة منزلية إلى SOC. الخطة هي تغليف ما هو موجود بالفعل في هذا المستودع في **أربعة مقاييس نشر**، كل منها مجموعة شاملة صارمة للسابق — نفس الأوليات في كل مكان (fail-closed، أوراق hash-only، المراقبة قبل الإغلاق)، والمزيد منها يُربَط معًا مع ارتفاع المقياس، والوضعية الأمنية — والتعقيد التشغيلي الذي تشتريه — يزدادان وفقًا لذلك:
- **المقياس 1 — جهاز واحد.** مضيف واحد، محيط محكوم واحد: `pepd` أمام الخدمة، وOPA sidecar محلي، وسجل `CellLog` واحد. بلا cluster fencing (لا شيء يُسيَّج بخلية واحدة)، بلا NAC (لا شيء يُقبَل على شبكة — إنه صندوق واحد)، بلا broker أو مشرف daemon. يتقلص genesis إلى زوج مفاتيح لمشغِّل واحد، موثَّق على هذا النحو بدلًا من التظاهر بمراسم نصاب ليست كذلك. أدنى تعقيد تشغيلي: اضبط قواعد OPA بشكل صحيح، وانشر في وضع المراقبة، وراقب ميزانية الاحتكاك، واكسب `closed`.
- **المقياس 2 — فريق صغير / موقع واحد.** حفنة من الأجهزة على شبكة LAN واحدة خلف `brokerd` واحد، وما زال سجلًا واحدًا (بلا fencing بعد — خلية موثوقة واحدة لا تزال كافية بهذا الحجم)، مع إضافة NAC (`config/freeradius/`، 802.1X عند المحوِّل) لقبول الأجهزة على القطاع، وتطبيق تقوية المضيف في كل مكان. daemon إضافي واحد، ونظام فرعي إضافي واحد، ونفس نموذج السجل كما في المقياس 1.
- **المقياس 3 — متعدد الخلايا المرن.** ما هو مبني وموثَّق بالكامل بالفعل كنشر التجربة التجريبية P1 أعلاه: خليتان أو أكثر، cluster fencing (إصدار/تدوير الحقبة، نصاب k-of-n لإجراءات الفئة-W، ترقية mirror/canary)، مشرف مستقل بوحدة تحكم للقراءة فقط، المترجم المُقوَّى مع التدهور المُتحكَّم فيه، تسلسل أدلة `deploy/` الكامل واختباره الذاتي بـ 82 ضابطًا. للمؤسسات التي لا تستطيع تحمُّل تعطُّل خلية واحدة، أو التي تبرِّر وكلاؤها المحكومون الأجهزة الإضافية.
- **المقياس الكامل — متعدد الكيانات.** المصافحة بين الكيانات (§3): إثبات السياسة، واستمرارية السجل، والحياة عبر الحدود التنظيمية، وليس فقط عبر خلايا المنظمة نفسها — اتحاد بين عمليات نشر TBP محكومة بشكل مستقل يجب أن تثق ببعضها دون أن تثق ببعضها. لم يُبدأ به عن قصد بعد؛ مُتابَع في [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) (T32) حتى يبقى مرئيًا كمرحلة لاحقة متميزة بدلًا من أن يكون غائبًا بصمت. هذا عمل بروتوكولي جديد فعليًا، وليس مجرد مزيد من الأجهزة تشغِّل ما هو موجود بالفعل.
**الصدق بشأن أين يقف هذا**: المقياس 3 مُسلَّم اليوم تحت اسم التجربة التجريبية P1 المستخدم في كل هذا README. المقياسان 1 و2 لم يُغلَّفا بعد كأدلتهما الخاصة — يمكن الوصول إليهما اليوم بنشر مجموعة فرعية مما هو موثَّق (تخطَّ cluster fencing وNAC للمقياس 1، وأضف NAC لكن أبقِ خلية واحدة للمقياس 2)، لكن هذا المسار غير مكتوب بعد، ولا شيء يمنع حاليًا أحدًا من ربطه بشكل صحيح بنفسه وفقًا لنفس المذهب. المقياس الكامل يتطلب كودًا جديدًا فعليًا (الإثباتات الثلاثة في §3)، وليس مجرد أدلة جديدة.
### العمل المخطط التالي
مسارا عمل، مُتابَعان كقضيتين منفصلتين لأنهما نوعان مختلفان من الجهد:
1. **أدلة النشر لكل مقياس، بالإضافة إلى أدوات إدارية بحجم كل مقياس** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)). تحويل المقاييس أعلاه إلى `deploy/scale-1.md` / `deploy/scale-2.md` — المقياس 3 لديه بالفعل تسلسل أدلته، وهو `deploy/apercu.md` والأدلة الخاصة بكل دور التي يجمِّعها — هو نصف هذا: مسار موثَّق ومغطَّى بالاختبار الذاتي لكل مقياس بدلًا من "دليل التجربة التجريبية، ناقص ما تكتشف أنه يجب تخطيه". والنصف الآخر هو أدوات موجهة للمشغِّل، وهي اليوم واجهة JSON للقراءة فقط (`src/supervision/console.go`: `/v1/arbitration`، `/v1/epoch`، `/v1/indicators`) بالإضافة إلى ملفات خام وواجهات سطر أوامر (سياسات Rego تُحرَّر يدويًا، `policies/gen_capabilities.sh` / `validate_determinism.go` للتحقق والإزالة قبل النشر؛ والسجل يُقرأ عبر المسح المُتحقَّق منه في `ChainWatcher`، المُختبَر في الاختبارات والاختبار الذاتي لكن بلا واجهة تصفح). هناك ثلاث أدوات مخصصة مخطط لها فوق ما هو موجود بالفعل، كل منها محدَّد النطاق بما يحتاجه مقياس معين فعليًا (مشغِّل المقياس 1 لا يحتاج عروض تحكيم متعددة الخلايا؛ أما مشغِّل المقياس 3 فيحتاجها):
- **لوحة تحكم للإشراف** فوق وحدة التحكم الحالية للقراءة فقط — موجهة للبشر، وما زالت للقراءة فقط بحكم البناء (§7.1 "المشرف يرى كل شيء، ولا يلمس شيئًا" ينتقل دون تغيير، D81)؛
- **محرر قواعد/سياسات** لحزمة OPA Rego — للتحرير، والاختبار مقابل نفس بوابات الحتمية وإزالة القدرات التي يفرضها `validate_determinism.go` بالفعل، والمقارنة مع ما هو منشور، قبل أن يصل أي شيء إلى الإنتاج؛
- **متصفح تدقيق** للسجل — للبحث والتصفية في تاريخ الأوراق (`KindDecision`، `KindTelemetry`، `KindQuorum`، …) بنفس إثبات نقطة التحقق القابل للتحقق من طرف ثالث الذي يقوم به `ChainWatcher` بالفعل برمجيًا، ليصبح مقروءًا لمُدقِّق بشري بدلًا من أن يكون تأكيدًا في اختبار.
2. **المواءمة مع المعايير — من نموذج سياسات خاص إلى نموذج قابل للتشغيل البيني** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)). تصنيف قواعد TBP (الفئات F/I/W/OUT، §5.3)، ومسار تدقيقها (أوراق hash-only مسجَّلة في Merkle، §6.2)، ومجموعة ضوابطها (fail-closed، المراقبة قبل الإغلاق، النصاب للإجراءات عالية المخاطر) هي اليوم خاصة بـ TBP — متسقة داخليًا ومُختبَرة، لكنها غير مربوطة بأي إطار خارجي يعرفه مُدقِّق أو منظِّم بالفعل. العمل هو تحديد المعايير القائمة (والناشئة) التي يتوافق معها هذا، وأين توجد الفجوات — لا افتراض أن أيًّا منها ينطبق، أو أن TBP يستوفيها بالفعل، دون إجراء هذا الربط أولًا. مرشحون يستحقون التقييم كنقطة بداية: **ISO/IEC 42001** (معيار نظام إدارة الذكاء الاصطناعي — الأقرب ملاءمةً لادعاء "حوكمة الذكاء الاصطناعي")، و**إطار NIST لإدارة مخاطر الذكاء الاصطناعي**، والتزامات **قانون الذكاء الاصطناعي الأوروبي** بالتسجيل والإشراف البشري للأنظمة عالية المخاطر (§4.1 الخاص بورقة-لكل-قرار و§4.2 الخاص بالتحكيم بالخطة-كعقد قريبان بنيويًا مما تطلبه المادتان 12/14 — غير مُتحقَّق منه، ويحتاج ربطًا حقيقيًا، لا افتراضًا)، و**NIST SP 800-207** (معمارية الثقة الصفرية — المواصفة تضع TBP بالفعل مقابل الثقة الصفرية في §3.3، والمقارنة الرسمية ضابطًا بضابط هي الخطوة التالية الطبيعية)، و**OSCAL** (صيغة NIST للضوابط/التقييم القابلة للقراءة آليًا — هدف تصدير معقول بحيث يمكن لمسار تدقيق TBP نفسه أن يغذِّي أدوات الامتثال القياسية بدلًا من طلب قارئ مخصص). هذا عمل بحثي وتوصيفي قبل أن يكون كودًا: المنتج هو تحليل فجوات، وحيث يوجد ربط حقيقي، إما كود محوِّل أو تكافؤ موثَّق — وليس إعادة كتابة محرك القواعد.
## الترخيص
ترخيص مزدوج، حسب الشجرة الفرعية:
- **`docs/` و`figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — حر للمشاركة والتعديل مع الإسناد.
- **كل ما عدا ذلك** (`config/`، `src/`، `policies/`، `lab/`، `tests/`، `deploy/`، `scripts/`، `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — نفس ترخيص البروتوكول الأساسي في [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol). كان هذا الكود بترخيص مغلق خلال مرحلة تجريبية أولية؛ تلك المرحلة انتهت — فالمشروع غير قابل للاستمرار إذا بُني وحده، وبروتوكول حوكمة مذهبه نفسه "أبدًا بالثقة، دائمًا بالإثبات القابل للتحقق" لا ينبغي أن يطلب الثقة في تنفيذه الخاص.
انظر [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) لكيفية المساهمة — الكود مشمول الآن، وليس الوثائق فقط — وللقواعد التي يجب اتباعها عند تحرير المواصفة (توحيد المصطلحات، الاستشهادات المُتحقَّق منها، سجل التغييرات).