Interroger la connaissance gouvernée depuis votre assistant
Claude Code, Cursor ou VS Code lisent la connaissance gouvernée par le serveur MCP d'Ailu : un fait, son voisinage, un chemin, pourquoi une relation existe, ce qui en dépend. Ils peuvent aussi proposer un fait, que quelqu'un d'autre valide. Avec votre identité : ce que vous ne pouvez pas lire n'existe pas pour ces outils.
Avant de commencer
Le serveur MCP local transmet votre jeton et votre organisation au plan de contrôle (voir Réglages › Accès développeur). Aucun outil ci-dessous ne fait répondre un modèle de langage ni ne consomme de crédit.
Les outils
| Outil | Ce qui revient | Exemple d'appel |
|---|---|---|
| brain_query | Le voisinage d'une question : { seeds, facts, relations, capped, budget: { tokens, used, omitted } }. Chaque relation est une ligne. | brain_query { "question": "Qui valide les remboursements ?", "depth": 2, "tokenBudget": 1500 } |
| brain_get | Un fait : { id, type, name, status, provenance, confidence, source, period, episodes }. | brain_get { "id": "policy:remboursements" } |
| brain_neighbors | Les faits à 1–4 relations : { from, depth, neighbors }, filtrables par type. | brain_neighbors { "id": "policy:remboursements", "depth": 2, "types": ["person"] } |
| brain_path | Le plus court chemin, 8 relations au plus : { from, to, maxHops, undirected, path: { nodes, hops } } — ou « No visible path ». | brain_path { "from": "code:pay.ts", "to": "person:jeanne", "maxHops": 4 } |
| brain_explain | Pourquoi une relation existe : { edge, ends, episodes, decisions, contradictions }. | brain_explain { "fromId": "code:pay.ts", "toId": "policy:remboursements", "type": "IMPLEMENTS" } |
| brain_affected | Ce qui dépend d'un fait : { entity, depth, facts, citedBy, usedBy }. | brain_affected { "id": "policy:remboursements", "depth": 2 } |
| brain_stats | La connaissance gouvernée d'un coup d'œil : { facts, relations, byStatus, byProvenance, byType, isolated }. | brain_stats {} |
| get_context | Les faits les plus connectés et leurs relations : { entities, relations, totalEntities, totalRelations }. | get_context { "limit": 40 } |
| brain_propose | Une proposition, jamais un fait : { status: pending, created, relation, proposalId, review } — ou status: active si la relation existe déjà. | brain_propose { "subject": "person:jeanne", "relation": "OWNS", "object": "policy:remboursements", "source": "Manuel 2026, §4", "justification": "Nommée responsable de la politique." } |
Lire une relation
brain_query écrit chaque relation sur une ligne : A —TYPE [provenance, statut]→ B (source). A et B sont les identifiants des faits, ceux que brain_get et brain_explain attendent. La provenance dit d'où vient la relation : extracted (lue dans le code), inferred (proposée par un modèle), ambiguous (en attente d'une décision), curated (posée par une personne). La source est le titre du document lu (à défaut, son nom de fichier), nommé seulement si vous pouvez lire sa collection ; sinon « no source ».
Le budget et le moment
- La question rappelle les faits les plus proches, comme la recherche de l'espace de travail.
- Le voisinage s'étend dans les deux sens : depth de 1 à 3 relations (2 par défaut), maxNodes de 1 à 100 faits (40 par défaut).
- La réponse tient dans tokenBudget, de 200 à 8000 tokens (2000 par défaut, environ quatre caractères par token) : les faits les plus proches d'abord, et budget.omitted compte ce qui a été laissé.
- asOf montre le graphe tel qu'il valait dans le monde à une date ; knownAt, tel qu'Ailu le tenait à un instant — une lecture d'audit, réservée aux approbateurs et aux propriétaires.
Proposer un fait
brain_propose ne fait que proposer : la relation subject —relation→ object entre deux faits actifs que vous pouvez lire attend dans la file Connaissance › À valider, avec qui l'a proposée, pourquoi et où vous l'avez lue. Tant qu'elle attend, aucun outil ni aucun agent ne la lit.
- Proposer demande le rôle approbateur ou propriétaire, comme l'extraction ; un lecteur est refusé.
- Un autre approbateur de votre organisation la valide ou la refuse ; vous ne validez jamais votre propre proposition, ni votre assistant à votre place. Sa décision est signée dans la chaîne d'attestations de la connaissance gouvernée.
- Proposée deux fois, c'est la même proposition qui revient : jamais une seconde. Déjà dans la connaissance gouvernée, la réponse le dit et rien n'est proposé.
- Le type de relation est un de ceux de l'ontologie de votre organisation, quand elle en a déclaré ; collection, si vous la donnez, est une collection que vous pouvez lire.
- Vingt propositions par minute au plus.
Ce que les outils ne montrent pas
Un fait tiré d'une collection réservée à une équipe dont vous n'êtes pas n'est ni rappelé, ni parcouru, ni nommé : brain_get répond qu'il n'existe pas, brain_path qu'il n'y a « aucun chemin visible », jamais lequel, et brain_propose ne propose rien à son sujet. La connaissance gouvernée d'une autre organisation n'est jamais lue.
Pas encore
Bientôtbrain_community : les faits d'une communauté de la connaissance gouvernée et son résumé.