Atteinte du Platform Skeleton (Mini Palantir) : lancement de Graph-RAG local + middleware cognitif + collaboration externe avec JAMES v0.3.0 (open source, alpha)

Résumé en une ligne

Un moteur de connaissances Graph-RAG 100 % local, conçu avec la sécurité comme principe de design.
Avec l’arrivée de v0.3.0 Platform Skeleton (2026-05-17), la couche de middleware cognitif
n’est plus un simple design mais du code intégré à la branche principale.

• GitHub : https://github.com/Hashevolution/James-RAG-Evol
• Version actuelle : v0.3.0 (Foundation Hardening validé sur 6/6 axes, gate franchie le 2026-05-13)
• Licence : MIT
• Validation externe : badge OpenSSF Best Practices passing (Tiered 111 %, projet #12806)
• Surnom : "Mini Palantir" (Palantir est une marque de Palantir Technologies, sans lien direct avec JAMES — seulement une métaphore car le motif typed-graph + conservation des traces d’audit s’en rapproche)

[IMG] Visualisation 3D de l’ontologie JAMES

v0.2 → v0.3 : qu’est-ce qui a changé en 9 jours ?

1. La Phase 2 de la couche de middleware cognitif est désormais intégrée à la branche principale
   • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
   • la vérification, la planification et le routage d’outils ne sont plus des design docs, mais des modules importables
2. Knowledge Cascade Phase A → E : migration en production terminée pour 213 entités / 656 relations
3. Pipeline de sécurité en 3 étapes maintenu : entrée pre_check → recherche ABAC → sortie post_filter + masque PII
4. Journal d’audit d’auto-évolution : tous les patches ont un approver_username, contournement impossible
5. Mots de passe bcrypt + migration transparente SHA-256 (PR #173), baseline ruff F-class + workflow de lint GitHub Actions (PR #205)

Ce qui s’est passé à l’extérieur (preuve que ce n’est pas construit seul)

• Première collaboration externe en cours avec Ali Afana (fondateur de Provia, dev.to Featured) — 6 échanges en DM sur LinkedIn + thread de commentaires sur dev.to
  • Travail commun : séparation d’une suite de régression d’injection de 83 items, benchmark des variantes Gemma 4 pour v0.3 (E4B / 26B MoE / 31B Dense)
  • Livrable commun : injection-fixtures schema v1.1 (PR #311 → #317 → #322, avec prise en compte des invariants de normalisation proposés par Ali, de expected_block_stage et de catalog_context, source indiquée dans le diff-log)
  • Pré-enregistrement : plan d’évaluation 3×3 (3 variantes × 3 températures × 1 structure de prompt, 4 hypothèses + decision matrix, verrouillé par PR #315 avant l’exécution de la moindre cellule)
  • Point d’entrée pour implémenteurs externes : LLM Provider contract (PR #316, 6 comportements requis + kwargs/env vars réservées, avec une esquisse de backend Gemini API d’environ 30 lignes)
• Deuxième candidat à la collaboration — Matija Fućek(@mfucek_, naumu.ai) a répondu au tweet sur la visualisation 3D en partageant une démo de son propre projet (application de cerveau d’entreprise plug-and-play), ouvrant un canal de collaboration
• Soumission terminée sur 2 tracks du Gemma 4 Challenge :
  • 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. — au format fair-witness, avec un compte rendu de l’échec sans l’embellir

Limites assumées (stade alpha, rien à cacher)

• La Phase 2 du middleware cognitif est intégrée à la branche principale, mais la validation multi-utilisateur et sous forte charge est une gate v0.4
• Le multimodal est câblé jusqu’à LLaVA·Whisper·ffmpeg (working prototype). L’intégration retrieval est prévue entre v0.3.x et v0.4
• Le scaffold d’auto-évolution est validé dans un environnement mono-utilisateur, le workflow multi-approbateurs n’a pas été validé
• Gemma 4 E4B a produit 5 réponses vides pendant l’étape cognitive, et aucune des 4 hypothèses n’a permis d’identifier la root cause à ce stade (publié tel quel dans l’article du track Write)

À quoi cela peut servir

• Quand vous voulez traiter un wiki ou des notes internes uniquement en local, sans les envoyer à une API externe
• Pour une démo ou une recherche RAG où le chemin de raisonnement (un typed graph_path du type A --[CAUSES]--> X --[REQUIRES]--> Y) doit être exposé sous forme de graphe avec la réponse
• Comme référence de patterns de sécurité pour le RAG (pipeline en 3 étapes, isolation des instructions, migration bcrypt, baseline ruff — tout est publié PR par PR)
• Pour ceux qui ont besoin d’un point d’entrée Plugin — le loader JAMES_PLUGINS et le Backend Protocol sont en cours de stabilisation en v0.3.x

Pour commencer

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # commencez par ceci si vous n’avez pas de GPU  
python server_llmwiki.py   # http://localhost:8000```

[skanxhakr12]

Bonjour. Les questions sont les bienvenues à tout moment —

Voici ci-dessous une comparaison au niveau du design système.

L’architecture actuelle de JAMES (v0.3.0) est la suivante.

1. Absence d’une couche de formal query language — la recherche hybride de core/retrieval_engine.py utilise une fusion de scores à 4 voies entre dense embedding + BM25 + keyword + name, et ne convertit pas les requêtes en langage naturel en langage formel comme SPARQL/RDF/SQL. Les scores d’embedding et de BM25 sont utilisés tels quels pour sélectionner les nœuds candidats.

2. Réponses du LLM en NL — dans core/reasoning/modes/chat.py, le LLM reçoit un prompt en NL et génère une réponse textuelle en NL, sans étape intermédiaire en langage formel.

3. Les mises à jour du KG sont séparées par une gate d’approbation humaine — cela est indiqué dès la première phrase de la docstring du module core/change_request.py : "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." Autrement dit, il n’existe pas dans le système de chemin permettant d’ajouter/modifier/supprimer automatiquement dans le KG sur la base de la réponse du LLM. wiki_edit dispose lui aussi d’une gate de privilèges admin, et impose le flux propose → review → apply de change_request (voir aussi CLAUDE.md §3, ARCHITECTURE.md §5.6).

Merci de garder à l’esprit que JAMES en est à une phase alpha non commerciale.

Par ailleurs, si vous souhaitez une analyse plus approfondie, ce serait avec plaisir de l’examiner ensemble dans une GitHub Issue.

Je pense que les retours variés sont ce qu’il y a de plus précieux pour permettre un examen honnête des choix de design du projet. Merci.