TBP-NETWORK

नेटवर्क-स्तरीय कार्यान्वयन टेलियोलॉजिकल बाउंडिंग प्रोटोकॉल (TBP) का — एक मशीन से लेकर WWW स्केल तक के एंटरप्राइज़ परिनियोजनों तक, नेटवर्क पर AI एजेंट क्रियाओं का प्रमाणित शासन।

« मौजूदा एक्सेस कंट्रोल तय करता है कि आप अंदर आ सकते हैं या नहीं; 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 है — यह इस रिपॉज़िटरी में किसी भी डिज़ाइन या कॉन्फ़िगरेशन निर्णय के लिए सत्य-स्रोत है। यह README केवल उतना सारांश देता है जितना दिशा-निर्देश के लिए आवश्यक है; संदेह होने पर, विनिर्देश ही मान्य होता है। कार्यशील नोट (docs/spec-v1.4.10.md, फ़्रेंच मूल का अंग्रेज़ी अनुवाद) सामग्री की दृष्टि से अप्रचलित नहीं है — यह वही प्रोटोकॉल है, जो पहले वहीं विकसित हुआ — परंतु आगे के लिए यह उद्धरणीय संदर्भ नहीं है।

इसे पढ़ने के लिए उपयोगी स्थल-चिह्न:

§1 सिद्धांत — दस अपरिहार्य नियम।
§13 कार्यान्वयन क्रम — अनुसरण करने का क्रम (HSM → OPA → PEP → NAC → अनुवादक), और पायलट P1 का सटीक दायरा।
§9.1 घर्षण बजट — विलंबता और मध्यस्थता-दर की सीमाएँ जो निर्धारित करती हैं कि कोई TBP परिनियोजन वास्तव में कार्य कर रहा है या नहीं; प्रत्येक कॉन्फ़िगरेशन निर्णय के लिए इन्हें ध्यान में रखें।
docs/glossaire.md — प्रति अवधारणा एक विहित शब्द, जिसका उपयोग इस रिपॉज़िटरी के कोड और दस्तावेज़ों में एकरूपता से किया जाना चाहिए (देखें CONTRIBUTING.md)।

मुख्य TBP रिपॉज़िटरी से संबंध

प्रोटोकॉल स्वयं — विनिर्देश, औपचारिक सिद्धांत, प्रतिकूल ऑडिट, मुख्य कार्यान्वयन (HSM हस्ताक्षर, Merkle ऑडिट श्रृंखला, OPA नीति इंजन) — Responsible-Alliance-Protocol में स्थित है, Apache 2.0 (खुला) के अंतर्गत लाइसेंस प्राप्त, और यहाँ इन-ट्री tbp4.2.1/ पर एक git सबमॉड्यूल के रूप में एक विशिष्ट कमिट पर पिन किया गया है — एक संकेतक, फ़ोर्क नहीं: यह रिपॉज़िटरी उस कोड के विरुद्ध कभी भी issue या PR दर्ज करने का स्थान नहीं है, केवल नीचे दिए गए नेटवर्क-रोलआउट भागों के विरुद्ध। यह रिपॉज़िटरी उसी प्रोटोकॉल का नेटवर्क-स्केल रोलआउट है: NAC, स्थानीय PEPs, सेल रजिस्ट्रियाँ, अंतर-इकाई हैंडशेक — वे भाग जो TBP को एक शासित मशीन से एक शासित नेटवर्क तक ले जाने के लिए आवश्यक हैं। इस सूचना के अनुसार, इस रिपॉज़िटरी का अपना कोड भी Apache 2.0 है (नीचे लाइसेंसिंग देखें) — मुख्य प्रोटोकॉल के समान लाइसेंस, दोनों रिपॉज़िटरियों में एक ही लाइसेंस, दो नहीं। इसने पहले एक प्रारंभिक पायलट चरण के दौरान एक बंद लाइसेंस का उपयोग किया था; वह चरण समाप्त हो चुका है।

सबमॉड्यूल को अद्यतन रखना: tbp4.2.1/ स्वयं को अद्यतन नहीं करता — इसे Responsible-Alliance-Protocol के किसी नए कमिट पर बढ़ाना एक जानबूझकर, समीक्षित क्रिया है (cd tbp4.2.1 && git checkout <commit> && cd .. && git add tbp4.2.1 && git commit), कभी स्वचालित नहीं। एक पिन किया गया सबमॉड्यूल जो अपस्ट्रीम में किसी सुरक्षा फ़िक्स से चुपचाप पीछे रह जाता है, बिना सबमॉड्यूल के भी बदतर है — इसे बढ़ाने को किसी भी अन्य निर्भरता अद्यतन की तरह ही सावधानी से करें, और पहले मुख्य रिपॉज़िटरी का अपना चेंजलॉग देखें।

रिपॉज़िटरी संरचना```

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 सबमॉड्यूल के माध्यम से इन-ट्री वेंडर करता है, एक विशिष्ट कमिट पर पिन किया हुआ — यहाँ उपस्थित है बिना कॉपी या डुप्लिकेट किए।

## कॉन्फ़िगरेशन मार्गदर्शन — कहाँ से शुरू करें

कार्यान्वयन अनुक्रम (§13) और पायलट P1 दायरे (§13, §9.1: 1 सर्वर VLAN, Debian राउटर, 2 सेल, 802.1X, केंद्रीय रजिस्ट्री, मापित उपयोगकर्ता-अनुभव प्रतिगमन = 0) के आधार पर:

1. **Genesis और कुंजियाँ** (§7.2, §3.2) — किसी भी चीज़ से पहले: नियंत्रक कोरम (m-of-n, HSM) द्वारा हस्ताक्षरित एक genesis समारोह, आउट-ऑफ-बैंड एंकर किया हुआ। [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) एपॉक-0 टूलिंग प्रदान करता है (dev पथ सहित); समारोह स्वयं प्रक्रियात्मक है, कोड नहीं — इस रिपॉज़िटरी में कुछ भी इसे प्रतिस्थापित नहीं करता।
2. **क्लस्टर फ़ेंसिंग** (§7, §13 चरण 2) — एपॉक जारी करना और रोटेशन, class-W क्रियाओं के लिए नियंत्रक कोरम (k-of-n), मिरर/कैनरी प्रोमोशन। किसी भी मल्टी-सेल डिप्लॉयमेंट से पहले आवश्यक, जिसमें नीचे दिया गया 2-सेल P1 पायलट भी शामिल है — एकल सेल इसे स्थगित कर सकता है, पायलट नहीं। [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) में लागू (एकल-प्राधिकार एपॉक ट्रैकर, कोरम, प्राप्ति-प्रमाण द्वारा प्रोमोशन — वहाँ कोई निजी कुंजी नहीं रखी जाती) और ब्रोकर ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)) में जुड़ा हुआ।
3. **OPA + रजिस्ट्री** — OPA इंस्टॉल करें, [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) का अनुसरण करते हुए `policies/capabilities.json` जनरेट करें (किसी भी डिप्लॉयमेंट से पहले `http.send` और `time.now_ns` हटाएँ, बाद में कभी नहीं; `validate_determinism.go` और determinism 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), मेमोरी-सीमित fail-closed एंटी-रीप्ले, क्लॉक-स्टेटस अवनत मोड, निष्पादन कोटा, और प्लान-एज़-कॉन्ट्रैक्ट गेट (§4.2, §13 चरण 4 — अकेला टोकन सत्यापन एकल क्रिया को नियंत्रित करता है, उस बहु-चरणीय प्लान को नहीं जिस पर ऑपरेटर वास्तव में हस्ताक्षर करता है)। [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md), और Debian-पक्ष नेटवर्क रीडायरेक्शन के लिए [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft) पढ़ें। **पहले मॉनिटर मोड में डिप्लॉय करें** (लॉग करें, अवरोध नहीं) — पहले रोलआउट पर कभी `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 जो हैंडशेक (§3) के समान PKI का पुनः उपयोग करता है, fail-closed स्विच स्तर पर लागू (केवल RADIUS पक्ष पर नहीं), v1 में कोई RADIUS-निर्धारित VLAN नहीं। `lab/tests/` netns सूट fail-closed, MAB/IoT-VLAN और OCSP-उपचार पथों का अभ्यास करते हैं।
6. **होस्ट हार्डनिंग** — TBP घटक (ब्रोकर, PEP, रजिस्ट्री) चलाने वाली प्रत्येक मशीन पर [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)।
7. **अनुवादक सबसे अंत में** (§13) — जब बाकी सब स्थिर हो जाए। [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator) में वितरित: रनटाइम हार्डनिंग (नॉन-रूट, cap-drop, seccomp — `dm-verity` से भिन्न, जो आराम की स्थिति में इमेज की रक्षा करता है, रनटाइम की नहीं), नियंत्रित-अवनति स्टेट मशीन (केवल-संरचित, कोई क्लाउड फ़ॉलबैक नहीं), और गुणवत्ता मापन (`measure.py` कॉर्पस को रीप्ले करता है और FNR/FPR प्रतिगमन पर CI को गेट करता है, `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 एक जटिल, पूर्ण-स्तरीय शासन प्रणाली है — क्लस्टर फ़ेंसिंग, कोरम, एक स्वतंत्र सुपरवाइज़र, एक हार्डन किया हुआ अनुवादक, एक अंतर-इकाई हैंडशेक। हर डिप्लॉयमेंट को यह सब नहीं चाहिए। एक एकल-सर्वर छोटा व्यवसाय जो चाहता है "कोई AI एजेंट प्रमाणित, लॉग किए गए कारण के बिना कार्य न करे" को दो-सेल फ़ेलओवर की उतनी ही आवश्यकता नहीं जितनी एक होम नेटवर्क को SOC की। योजना इस रिपॉज़िटरी में पहले से मौजूद चीज़ों को **चार डिप्लॉयमेंट स्केल** में पैकेज करने की है, प्रत्येक पिछले का सख्त सुपरसेट — समान प्रिमिटिव्स पूरे समय (fail-closed, केवल-हैश लीफ, closed से पहले monitor), स्केल बढ़ने के साथ उनमें से अधिक एक साथ जुड़े हुए, और सुरक्षा पोस्चर — तथा उसे खरीदने वाली परिचालन जटिलता — तदनुसार बढ़ती हुई:

- **स्केल 1 — एकल मशीन।** एक होस्ट, एक शासित परिधि: सेवा के सामने `pepd`, एक स्थानीय OPA साइडकार, एक एकल `CellLog` रजिस्ट्री। कोई क्लस्टर फ़ेंसिंग नहीं (एक सेल के साथ बाड़ लगाने को कुछ नहीं), कोई NAC नहीं (नेटवर्क पर प्रवेश कराने को कुछ नहीं — यह एक बॉक्स है), कोई ब्रोकर या सुपरवाइज़र डेमॉन नहीं। Genesis एकल ऑपरेटर कीपेयर में सिमट जाता है, जिसे वैसा ही प्रलेखित किया जाता है बजाय उस कोरम समारोह का अभिनय करने के जो वह है ही नहीं। न्यूनतम परिचालन जटिलता: OPA नियम सही करें, मॉनिटर मोड में डिप्लॉय करें, घर्षण बजट देखें, `closed` अर्जित करें।
- **स्केल 2 — छोटी टीम / एकल साइट।** एक LAN पर कुछ मशीनें एक `brokerd` के पीछे, अभी भी एकल रजिस्ट्री (अभी तक कोई फ़ेंसिंग नहीं — इस आकार पर एक प्राधिकारिक सेल अभी भी पर्याप्त है), NAC जोड़ा गया (`config/freeradius/`, स्विच पर 802.1X) मशीनों को सेगमेंट पर प्रवेश कराने के लिए, होस्ट हार्डनिंग हर जगह लागू। एक और डेमॉन, एक और सबसिस्टम, स्केल 1 जैसा ही रजिस्ट्री मॉडल।
- **स्केल 3 — लचीला मल्टी-सेल।** जो पहले से पूरी तरह बना और प्रलेखित है ऊपर पायलट P1 डिप्लॉयमेंट के रूप में: 2+ सेल, क्लस्टर फ़ेंसिंग (एपॉक जारी करना/रोटेशन, class-W क्रियाओं के लिए k-of-n कोरम, मिरर/कैनरी प्रोमोशन), रीड-ओनली कंसोल वाला एक स्वतंत्र सुपरवाइज़र, नियंत्रित अवनति वाला हार्डन किया हुआ अनुवादक, पूरा `deploy/` गाइड अनुक्रम और उसका 82-नियंत्रण selftest। उन संगठनों के लिए जो एक सेल के डाउन होने को सहन नहीं कर सकते, या जिनके शासित एजेंट अतिरिक्त मशीनों को उचित ठहराते हैं।
- **स्केल पूर्ण — बहु-इकाई।** अंतर-इकाई हैंडशेक (§3): संगठनात्मक सीमाओं के आर-पार नीति, इतिहास निरंतरता, और जीवंतता सिद्ध करना, न कि केवल एक ही संगठन के सेलों के आर-पार — स्वतंत्र रूप से शासित TBP डिप्लॉयमेंट्स के बीच फ़ेडरेशन जिन्हें एक-दूसरे पर भरोसा किए बिना एक-दूसरे पर भरोसा करना होता है। जानबूझकर अभी शुरू नहीं किया गया; [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) (T32) में ट्रैक किया गया ताकि यह चुपचाप अनुपस्थित होने के बजाय एक बाद के, भिन्न चरण के रूप में दृश्यमान रहे। यह वास्तव में नया प्रोटोकॉल कार्य है, न कि केवल अधिक मशीनें जो पहले से मौजूद चीज़ें चला रही हों।

**यह कहाँ खड़ा है, इस पर ईमानदारी**: स्केल 3 आज इस README में प्रयुक्त पायलट-P1 नाम के अंतर्गत वितरित है। स्केल 1 और 2 अभी तक अपने स्वयं के गाइड के रूप में पैकेज नहीं किए गए हैं — वे आज जो प्रलेखित है उसका एक उपसमुच्चय डिप्लॉय करके पहुँचने योग्य हैं (स्केल 1 के लिए क्लस्टर फ़ेंसिंग और NAC छोड़ें, स्केल 2 के लिए NAC जोड़ें पर एक सेल रखें), लेकिन वह पथ अभी लिखा नहीं गया है, और वर्तमान में कोई किसी को उसी सिद्धांत के अधीन अपने दम पर इसे सही ढंग से जोड़ने से नहीं रोकता। स्केल पूर्ण के लिए वास्तविक नया कोड (§3 के तीन प्रमाण) चाहिए, केवल नए गाइड नहीं।

### अगला नियोजित कार्य

दो कार्य धाराएँ, अलग-अलग मुद्दों के रूप में ट्रैक की गईं क्योंकि वे भिन्न प्रकार के प्रयास हैं:

1. **प्रति-स्केल डिप्लॉयमेंट गाइड, साथ ही प्रत्येक स्केल के अनुरूप एडमिन टूलिंग** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86))। ऊपर दिए गए स्केल को `deploy/scale-1.md` / `deploy/scale-2.md` में बदलना — स्केल 3 का गाइड अनुक्रम पहले से है, वह `deploy/apercu.md` और उससे संश्लेषित प्रति-भूमिका गाइड हैं — इसका आधा हिस्सा है: प्रति स्केल एक प्रलेखित, selftest-कवर पथ, न कि "पायलट गाइड, घटा दें जो आप छोड़ने का पता लगाते हैं"। दूसरा आधा ऑपरेटर-उन्मुख टूलिंग है, जो आज एक रीड-ओनली JSON API (`src/supervision/console.go`: `/v1/arbitration`, `/v1/epoch`, `/v1/indicators`) के साथ-साथ कच्ची फ़ाइलें और CLI हैं (Rego नीतियाँ हाथ से संपादित, `policies/gen_capabilities.sh` / `validate_determinism.go` डिप्लॉय से पहले सत्यापन और स्ट्रिपिंग के लिए; रजिस्ट्री `ChainWatcher` के सत्यापित स्कैन द्वारा पढ़ी जाती है, जिसका अभ्यास टेस्ट और selftest में होता है पर कोई ब्राउज़िंग UI नहीं)। पहले से मौजूद चीज़ों के ऊपर तीन समर्पित उपकरण नियोजित हैं, प्रत्येक उस विशेष स्केल की वास्तविक आवश्यकता के अनुरूप (स्केल-1 ऑपरेटर को मल्टी-सेल मध्यस्थता दृश्यों की आवश्यकता नहीं; स्केल-3 वाले को है):
   - मौजूदा रीड-ओनली कंसोल के ऊपर एक **सुपरविज़न डैशबोर्ड** — मानव-उन्मुख, रचना से अभी भी रीड-ओनली (§7.1 "सुपरवाइज़र सब कुछ देखता है, कुछ भी नहीं छूता" अपरिवर्तित रूप से लागू, D81);
   - OPA Rego बंडल के लिए एक **नियम/नीति संपादक** — संपादित करें, उन्हीं determinism और capability-stripping गेटों के विरुद्ध परीक्षण करें जिन्हें `validate_determinism.go` पहले से लागू करता है, और जो डिप्लॉय है उसके विरुद्ध diff करें, इससे पहले कि कुछ भी उत्पादन तक पहुँचे;
   - रजिस्ट्री के लिए एक **ऑडिट ब्राउज़र** — लीफ इतिहास (`KindDecision`, `KindTelemetry`, `KindQuorum`, …) को उसी तृतीय-पक्ष-सत्यापनीय चेकपॉइंट प्रमाण के साथ खोजें और फ़िल्टर करें जो `ChainWatcher` पहले से प्रोग्रामेटिक रूप से करता है, जिसे टेस्ट असेर्शन के बजाय मानव ऑडिटर के लिए सुपाठ्य बनाया गया।
2. **मानक संरेखण — एक स्वामित्व वाले नीति मॉडल से एक अंतर-संचालनीय मॉडल की ओर** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87))। TBP का नियम वर्गीकरण (वर्ग F/I/W/OUT, §5.3), इसका ऑडिट ट्रेल (केवल-हैश Merkle-लॉग्ड लीफ, §6.2), और इसका नियंत्रण सेट (fail-closed, monitor-before-closed, उच्च-दांव क्रियाओं के लिए कोरम) आज TBP-विशिष्ट हैं — आंतरिक रूप से सुसंगत और परीक्षित, पर किसी बाहरी ढाँचे से मैप नहीं किए गए जिसे कोई ऑडिटर या नियामक पहले से पहचानता हो। कार्य यह पहचानना है कि यह किन मौजूदा (और उभरते) मानकों से मैप होता है, और अंतराल कहाँ हैं — यह मानने के लिए नहीं कि इनमें से कोई भी लागू होता है, या TBP पहले से उन्हें संतुष्ट करता है, बिना पहले वह मैपिंग किए। प्रारंभिक बिंदु के रूप में मूल्यांकन योग्य उम्मीदवार: **ISO/IEC 42001** (AI प्रबंधन प्रणाली मानक — "AI शासन" दावे के लिए निकटतम उपयुक्त), **NIST AI Risk Management Framework**, उच्च-जोखिम प्रणालियों के लिए **EU AI Act** के लॉगिंग और मानव-निरीक्षण दायित्व (§4.1 का प्रति-निर्णय लीफ और §4.2 की प्लान-एज़-कॉन्ट्रैक्ट मध्यस्थता संरचनात्मक रूप से अनुच्छेद 12/14 की माँगों के निकट हैं — असत्यापित, वास्तविक मैपिंग चाहिए, अनुमान नहीं), **NIST SP 800-207** (Zero Trust Architecture — विनिर्देश पहले से §3.3 में TBP को Zero Trust के विरुद्ध स्थापित करता है, नियंत्रण-दर-नियंत्रण औपचारिक तुलना स्वाभाविक अगला कदम है), और **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) देखें।

TBP-NETWORK

सबसे लोकप्रिय

TBP-NETWORK

यहाँ से शुरू करें

मुख्य TBP रिपॉज़िटरी से संबंध

रिपॉज़िटरी संरचना```