The wiki knowledge engine: rules, guidelines, and synthesis

Une connaissance qui s'organise elle-même, sur des rails écrits

Quand les conversations sont archivées dans une base de connaissances partagée, la question cesse d'être « peut-on mémoriser des pages » et devient « qui peut écrire quoi, où, dans quelle voix ». Le wiki engine de Simmetric Chat répond par un modèle d'instruction à trois couches pour chaque archive : des règles appliquées par le code, un prompt éditorial par archive porté comme donnée, et les champs structurés qui décrivent le comportement attendu. Le modèle mental qui tient : le schema prompt par archive est au wiki ce qu'un CLAUDE.md est à un dépôt de code - consultatif par nature, puissant en pratique, jamais une loi.

Cet article est la visite du design : les trois couches, ce que chacune peut et ne peut pas faire, la chaîne de précédence quand elles s'opposent, et les deux skills intégrés (wiki_query, wiki_write) qui rendent vraie la moitié lisible par la machine de la promesse.

Couche 1 : règles strictes, appliquées par le code

La première couche est inconditionnelle et indépendante de la configuration - elle surveille tout :

1. La garde du système de fichiers. validateWritablePath rejette toute cible d'écriture hors de <archiveBase>/wiki/ : le contrôle anti-traversement s'exécute d'abord, puis le contrôle du préfixe wiki/. Une cible hors de wiki/ lève une erreur nommée, et createPage comme updatePage appellent la garde avant tout write fichier. raw_sources/ est immuable de conception - aucun endpoint d'API n'écrit sous cette directory.
2. Le miroir au niveau du prompt. Un bloc toujours actif est ajouté à chaque prompt lié à une archive, et sa formulation fait écho à la garde du système de fichiers (raw_sources/ is immutable). Le modèle n'entreprend même pas la sortie de wiki/ - et s'il le faisait, le code garantit que rien n'atterrit.

L'appariement est délibéré : le prompt garde le modèle honnête, le code garde le système sûr. La confiance vit dans la deuxième propriété, pas dans la première.

Couche 2 : le schema prompt par archive

Le schema prompt (schemaPrompt) est un champ consultatif de texte libre persisté dans le JSON de configuration de l'archive :

• Forme : jusqu'à 10000 caractères (≈2500 tokens) dans le schéma de config de l'archive - une clé additive, zéro migration.
• Validation : Zod à chaque écriture via PUT /api/archives/:id/config ; un payload au-delà du plafond est rejeté avec un 400 nommant le champ.
• Contract de lecture : une archive sans ligne stockée lit la config par défaut du schéma (le chemin de première écriture) ; les archives avec une ligne renvoient le blob stocké à la lettre. Les blobs legacy au-delà du plafond sont tronqués à l'injection avec une annotation explicite, jamais taillés en silence ni re-validés.
• Consultatif de conception : le bloc entre dans les prompts comme DONNÉE avec une étiquette consultative explicite - jamais comme une concession de privilège au niveau du system prompt. Aucune sanitisation au-delà du plafond de longueur ; les instructions contradictoires sont un risque qualité accepté, mitigé par le texte d'aide et le modèle dans l'interface.

La couche 2 est là où vit la voix éditoriale de l'organisation : conventions de nommage, structure des pages, attentes sur les sources. C'est de la conduite - et le moteur la traite exactement comme telle.

Couche 3 : les champs structurés

Persona, purpose, scope - la description structurée de l'archive - sont injectés dans le chemin des prompts par la configuration existante. Ils décrivent des défauts ; la couche 2 les emporte quand les deux parlent ensemble.

La chaîne de précédence

règles strictes (code) > schemaPrompt (consultatif) > champs structurés

1. Le schema prompt ne peut jamais emporter sur les règles strictes - le prompt déclare ; le code applique.
2. En conflit avec les champs structurés, le schema prompt prend le pas.
3. Une archive sans schema prompt se comporte comme baseline plus la règle stricte - zéro enrichissement, zéro dégradation.

La troisième ligne compte dans le registre mental de l'opérateur : un champ consultatif vide est une configuration complète, pas manquante. Il n'y a pas de sections en placeholder vides qui hantent les prompts.

Où atterrit le bloc consultatif

L'injection a des seams explicites, chacune portée dans le system prompt de la requête après le bloc de la règle de recherche et avant le system prompt du workspace :

• L'orchestrateur du chat (les deux chemins, streaming et non) - la règle stricte toujours ; le bloc consultatif voyage avec quand l'archive en a un.
• La passe de décision de la pipeline de synthèse - le bloc consultatif prend le rôle SYSTEM là, tandis que les passes précédentes (retrieval, rédaction, jugement des contradictions) tournent sans, de conception.

wiki_query et wiki_write : les deux intégrés

Les builtin wiki_query et wiki_write sont des skills dont les chemins d'exécution ne font aucun appel LLM - le chemin d'écriture produit des aperçus déterministes entièrement en code. Conséquence architecturale nette : une injection par skill n'atteindrait aucun modèle, si bien que la seule surface-facing LLM du wiki est le system prompt de l'orchestrateur. Le comportement d'écriture du wiki = les trois couches ci-dessus ; les fonctions de lecture/écriture = du code simple, auditable.

Pourquoi cette forme tient debout

Trois propriétés, en combinaison :

• Immuabilité à la base - raw_sources/ ne peut être réécrit par personne, modèle inclus (la garde + le bloc toujours actif).
• La discipline consultative - la conduite éditoriale entre comme donnée étiquetée, contrôlable au niveau de l'édition de config, jamais comme privilège.
• Les builtin déterministes - les surfaces d'écriture/lecture de l'archive tournent sans modèle, donc les garanties ne dépendent pas du jugement du modèle.

La promesse du moteur est modeste et porteuse : la connaissance s'organise elle-même sur des rails écrits, exactement aussi loin que les rails le décident. L'opérateur de Simmetric Chat reste l'auteur des rails - ce qui est le point silencieux de tout le design.

Pour continuer

Le guide porte la référence opérateur - les tables champ par champ et les contract d'endpoints - sur /fr/docs/wiki-knowledge-engine :

• Wiki knowledge engine - le guide
• Faits de ce billet : ligne FACT-CENSUS.md F-WIKI-1 (la Wiki Schema Layer : écrite, finalisée, vérifiée contre le code vivant à la gate v0.25)

Provenance : Simmetric Chat docs/WIKI_SCHEMA_LAYER.md (v0.28.1, Phase 187/194), validateWritablePath dans packages/server/src/utils/archivePath.ts, les seams d'injection de l'orchestrateur, CHANGELOG.md v0.28.1 - à l'état documentaire épinglé par le census (SHA aca5b8ff).