Platform Skeleton (Mini Palantir) तक पहुँचना: लोकल Graph-RAG + cognitive middleware + बाहरी collaboration की शुरुआत JAMES v0.3.0 (open source, alpha)

एक-पंक्ति सारांश

सिक्योरिटी को design principle की तरह लेने वाला 100% लोकल Graph-RAG knowledge engine।
v0.3.0 Platform Skeleton(2026-05-17) तक पहुँचते हुए, cognitive middleware layer
अब सिर्फ डिज़ाइन नहीं बल्कि कोड के रूप में main पर चढ़ी हुई स्थिति में है।

• GitHub: https://github.com/Hashevolution/James-RAG-Evol
• वर्तमान संस्करण: v0.3.0 (Foundation Hardening 6/6 axes पास, 2026-05-13 gate clear)
• लाइसेंस: MIT
• बाहरी सत्यापन: OpenSSF Best Practices passing बैज (Tiered 111%, project #12806)
• उपनाम: "Mini Palantir" (Palantir, Palantir Technologies का ट्रेडमार्क है, JAMES से सीधा संबंध नहीं — यह सिर्फ typed-graph + audit trail preservation पैटर्न से मिलती-जुलती एक उपमा है)

[IMG] JAMES 3D ontology visualization

v0.2 → v0.3, 9 दिनों में क्या बदला

1. cognitive middleware layer Phase 2 main पर स्थापित
   • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
   • verification, planning, और tool routing अब design doc नहीं बल्कि import किए जा सकने वाले modules हैं
2. Knowledge Cascade Phase A → E: 213 entities / 656 relations का production migration पूरा
3. 3-stage security pipeline बरकरार: input pre_check → retrieval ABAC → output post_filter + PII mask
4. self-evolution audit log: हर patch में approver_username रहता है, bypass असंभव
5. bcrypt password + SHA-256 transparent migration(PR #173), ruff F-class baseline + GitHub Actions lint workflow(PR #205)

बाहर क्या हुआ (इस बात का सबूत कि यह अकेले नहीं बनाया गया)

• Ali Afana (Provia के संस्थापक, dev.to Featured) के साथ पहली बाहरी collaboration जारी — LinkedIn DM 6 turns + dev.to comment thread
  • संयुक्त कार्य: 83-item injection regression suite अलग करना, v0.3 Gemma 4 variant bench (E4B / 26B MoE / 31B Dense)
  • संयुक्त output: injection-fixtures schema v1.1 (PR #311 → #317 → #322, Ali द्वारा सुझाए गए normalization invariants·expected_block_stage·catalog_context सभी परिलक्षित, diff-log में स्रोत स्पष्ट)
  • pre-registration: 3×3 evaluation plan (3 variants × 3 temperatures × 1 prompt structure, 4 hypotheses + decision matrix, एक भी single cell चलने से पहले PR #315 से lock)
  • बाहरी implementer touchpoint: LLM Provider contract (PR #316, 6 required behaviors + reserved kwargs/env vars, ~30-line Gemini API backend sketch शामिल)
• दूसरे collaboration candidate — Matija Fućek(@mfucek_, naumu.ai) ने 3D visualization tweet के reply में अपने project (plug-and-play company brain app) का demo साझा किया, collaboration channel खुला
• Gemma 4 Challenge के 2 tracks में submission पूरा:
  • Build with Gemma 4: Building a Mini Palantir on gemma4:e4b
  • Write with Gemma 4: 5 empty responses from gemma4:e4b. 4 hypotheses. 0 root cause. — fair-witness फ़ॉर्मेट, विफलता को सजाए बिना रिपोर्ट किया गया

ईमानदार सीमाएँ (alpha चरण, छिपाने जैसा कुछ नहीं)

• cognitive middleware Phase 2 main पर आ चुका है, लेकिन multi-user·large-scale load validation v0.4 gate पर है
• multimodal, LLaVA·Whisper·ffmpeg तक wired है (working prototype). retrieval integration v0.3.x ~ v0.4
• self-evolution scaffold single-user environment में सत्यापित, multi-approver workflow अभी सत्यापित नहीं
• Gemma 4 E4B ने cognitive stage में 5 बार empty response दिए, और 4 hypotheses में से कोई भी root cause तय नहीं कर पाया (Write track लेख में जैसा है वैसा ही सार्वजनिक)

इसका उपयोग कहाँ हो सकता है

• जब आप internal wiki/notes को बाहरी API पर भेजे बिना सिर्फ लोकल में संभालना चाहते हों
• ऐसे RAG demo/research जहाँ reasoning path (A --[CAUSES]--> X --[REQUIRES]--> Y जैसे typed graph_path) response के साथ graph के रूप में दिखना चाहिए
• security RAG pattern reference (3-stage pipeline, instruction isolation, bcrypt migration, ruff baseline — सब PR स्तर पर सार्वजनिक)
• उन लोगों के लिए जिन्हें plugin entry point चाहिए — JAMES_PLUGINS loader और Backend Protocol v0.3.x में stabilize हो रहे हैं

शुरू करें

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # GPU नहीं है तो इससे शुरू करें  
python server_llmwiki.py   # http://localhost:8000

[skanxhakr12]

नमस्ते। सवाल हमेशा स्वागतयोग्य हैं —

नीचे system design स्तर की तुलना है।

JAMES (v0.3.0) की मौजूदा architecture इस प्रकार है।

1. Formal query language लेयर का अभाव — core/retrieval_engine.py में hybrid search dense embedding + BM25 + keyword + name की 4-way score fusion का उपयोग करता है, और NL queries को SPARQL/RDF/SQL जैसी formal languages में convert नहीं करता। Embedding और BM25 scores सीधे candidate nodes चुनने में उपयोग होते हैं।

2. LLM response NL में — core/reasoning/modes/chat.py में LLM NL prompt लेकर NL text में जवाब बनाता है, और कोई formal-language intermediate stage नहीं है।

3. KG update मानव approval gate से अलग किया गया है — core/change_request.py की module docstring की पहली पंक्ति में स्पष्ट है: "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." यानी LLM के response के आधार पर अपने-आप KG में add/modify/remove करने का रास्ता सिस्टम में है ही नहीं। wiki_edit पर भी admin privilege gate है, और change_request के propose → review → apply flow को enforce किया जाता है (संबंधित CLAUDE.md §3, ARCHITECTURE.md §5.6 देखें)।

कृपया यह भी ध्यान में रखें कि JAMES अभी pre-commercial alpha चरण में है।

अगर आप अतिरिक्त रूप से और गहरा analysis चाहते हैं, तो GitHub Issue में साथ देखकर अच्छा लगेगा।

मेरा मानना है कि विविध feedback ही वह सबसे मूल्यवान चीज़ है जो project की design choices की ईमानदारी से समीक्षा करने में मदद करती है। धन्यवाद।