Démarrer

Architecture

acf-mcp est un serveur stdio local-first, déterministe, sans appel LLM interne. Base de connaissances versionnée et signée Ed25519. Trois modules en pipeline : entrée → moteur de règles → pied de page signé. Latence typique inférieure à 10 ms par appel.

iNote

acf-mcp n’appelle aucun LLM en interne. Chaque sortie est produite par un moteur de règles déterministe sur une base de connaissances signée. C’est la garantie d’auditabilité qui rend le standard opposable à un auditeur ou un tribunal.

Principes de conception

Local-first — transport stdio par défaut, lancé par le client à la demande, aucun appel réseau sortant en fonctionnement nominal.
Déterministe — même entrée + même version de doctrine ⇒ même sortie, byte-pour-byte. Pas de température, pas de seed aléatoire, pas de LLM.
Signé bout-en-bout — chaque sortie embarque doctrine_hash, doctrine_signature (Ed25519) et doctrine_public_key. Vérification hors-ligne possible.
Versionné — la base de connaissances est figée par release (doctrine_version + doctrine_hash). Aucune dérive silencieuse possible.

Pipeline de traitement

Chaque appel d’outil traverse trois modules dans cet ordre strict. La latence cumulée typique est inférieure à 10 ms (lecture disque mise en cache, index lunr en mémoire, signature Ed25519 constante).

text

client (Claude Desktop, Cursor, ...)
   |
   |  stdio JSON-RPC (MCP)
   v
+-------------------------------------------+
|  acf-mcp server (Node.js >= 18)           |
|                                           |
|  1. input validation (zod schemas)        |
|     |                                     |
|     v                                     |
|  2. rule engine (deterministic matcher)   |
|     - loads rules/*.json at startup       |
|     - lunr index for READ tools           |
|     |                                     |
|     v                                     |
|  3. signed footer (Ed25519)               |
|     - doctrine_hash + doctrine_signature  |
|     - generated_at + regulatory_snapshot  |
+-------------------------------------------+
   |
   v
deterministic, signed JSON output

1. Validation d’entrée

Chaque outil déclare un schéma zod. Les champs enum (par exemple autonomy_level ∈ {N0,N1,N2,N3}) sont validés contre la liste canonique de la doctrine. Une description ou un domaine d’usage trop court (< 20 caractères) est rejeté immédiatement, sans appel au moteur.

2. Moteur de règles

Le moteur charge ses fichiers de règles JSON depuis le disque au démarrage. Pour les outils REASON, c’est un pattern matcher déterministe (table de correspondances entrée canonique → fragment de doctrine). Pour les outils READ, c’est un index lunr en mémoire (recherche plein-texte sur le corpus signé).

3. Pied de page signé

Le résultat du moteur est sérialisé canoniquement (JCS — RFC 8785), hashé SHA-256, signé Ed25519 avec la clé de doctrine, puis enveloppé dans un objet qui embarque doctrine_version, doctrine_hash, doctrine_signature, doctrine_public_key, regulatory_snapshot et generated_at.

Voir la page signatures de doctrine pour le détail cryptographique et trois implémentations de vérification.

Ressources MCP

Les ressources sont des fichiers markdown avec frontmatter YAML, servis sous des URI canoniques acf://… . Le frontmatter porte la version, le hash et la signature ; le corps porte le contenu pédagogique. Le serveur ne fait que streamer ces fichiers.

text

acf://principles/p1-traceability
acf://fiches/acf-08-decision-register
acf://glossary/ddao
acf://regulator/eu-ai-act/article-26

Performance

Latence typique outil REASON : 2–6 ms (validation + lookup + signature).
Latence typique outil READ : 4–9 ms (requête lunr + sérialisation).
Empreinte mémoire serveur : ~80 MB au démarrage (corpus + index).
Aucun appel réseau en mode stdio nominal. Aucun appel LLM, jamais.

Limites assumées

acf-mcp produit une qualification préliminaire opposable, pas un avis juridique. Le serveur ne valide pas la conformité d’un agent — il fournit la base de connaissances signée, les outils de raisonnement et la trace cryptographique. La décision finale reste celle du DDAO (Designated Deployer of Autonomous Operations) ou du juriste compétent.