Blog
Approfondimenti tecnici

The wiki knowledge engine: rules, guidelines, and synthesis

Il modello a tre livelli del wiki engine: regole hard via codice, schema prompt per-archivio (advisory), campi strutturati - e la catena di precedenza in pratica. Dal census: F-WIKI-1.

Simmetric Team7 min di lettura11/10/2026
The wiki knowledge engine: rules, guidelines, and synthesis

Conoscenza che si organizza da sola, entro binari scritti

Quando le conversazioni vengono archiviate in una base di conoscenza condivisa, la domanda smette di essere "possiamo memorizzare pagine" e diventa "chi può scrivere cosa, dove, con quale voce". Il wiki engine di Simmetric Chat risponde con un modello d'istruzione a tre livelli per ogni archivio: regole applicate dal codice, un prompt editoriale per-archivio trasportato come dato, e i campi strutturati che descrivono come l'archivio deve comportarsi. Il modello mentale che resta: lo schema prompt per-archivio è per il wiki ciò che un CLAUDE.md è per un repository di codice - di natura advisor, potente in pratica, mai una legge.

Questo articolo è il walkthrough del progetto: i tre livelli, cosa ciascuno può e non può fare, la catena di precedenza quando sono in disaccordo, e i due skill builtin (wiki_query, wiki_write) che rendono vera la metà leggibile dalla macchina della promessa.

Livello 1: regole hard, applicate dal codice

Il primo livello è incondizionato e indipendente dalla configurazione - sorveglia tutto:

  1. La guardia del filesystem. validateWritablePath respinge ogni target di scrittura fuori da <archiveBase>/wiki/: il check anti-traversamento corre per primo, poi il check del prefisso wiki/. Un target fuori da wiki/ solleva un errore nominato, e sia createPage sia updatePage chiamano la guardia prima di qualunque write su file. raw_sources/ è immutabile per progettazione - nessun endpoint API scrive sotto quella directory.
  2. Lo specchio a livello di prompt. Un blocco sempre attivo è accodato a ogni prompt legato all'archivio, e la sua formulazione rispecchia la guardia del filesystem (raw_sources/ is immutable). Il modello non prova nemmeno la via d'uscita da wiki/ - e se lo facesse, il codice garantisce che nulla atterri.

L'accoppiata è voluta: il prompt tiene onesto il modello, il codice tiene sicuro il sistema. La fiducia vive nella seconda proprietà, non nella prima.

Livello 2: lo schema prompt per-archivio

Lo schema prompt (schemaPrompt) è un campo advisor testuale libero persistito nel JSON di configurazione dell'archivio:

  • Forma: fino a 10000 caratteri (≈2500 token) dentro lo schema di config dell'archivio - una chiave additiva, zero migrazioni.
  • Validazione: Zod su ogni scrittura via PUT /api/archives/:id/config; un payload oltre il tetto viene rifiutato con un 400 che nomina il campo.
  • Contract di lettura: un archivio senza riga memorizzata legge la config di default dello schema (il percorso di prima-scrittura); gli archivi con riga restituiscono il blob memorizzato alla lettera. I blob legacy oltre il tetto vengono troncati all'iniezione con un'annotazione esplicita, mai scissorati in silenzio o ri-validati.
  • Advisor per progettazione: il blocco entra nei prompt come DATO con un'etichetta advisor esplicita - mai come concessione di privilegio a livello di system prompt. Nessuna sanificazione oltre il tetto di lunghezza; le istruzioni contraddittorie sono un rischio di qualità accettato, mitigato dal testo d'aiuto e dal template nell'interfaccia.

Il livello 2 è dove vive la voce editoriale dell'organizzazione: convenzioni sui nomi, struttura delle pagine, attese sulle fonti. È una linea guide - e il motore la tratta esattamente così.

Livello 3: i campi strutturati

Persona, purpose, scope - la descrizione strutturata dell'archivio - vengono iniettati nel percorso dei prompt dalla configurazione esistente. Descrivono i default; il livello 2 li prevale quando parlano insieme.

La catena di precedenza

text
regole hard (codice) > schemaPrompt (advisor) > campi strutturati
  1. Lo schema prompt non può mai prevalere sulle regole hard - il prompt dichiara; il codice applica.
  2. In conflitto con i campi strutturati, lo schema prompt prende il sopravvento.
  3. Un archivio senza schema prompt si comporta come baseline più la regola hard - zero arricchimento, zero degrado.

La terza riga conta nel bilancio mentale dell'operatore: un campo advisor vuoto è una configurazione completa, non mancante. Non ci sono sezioni segnaposto vuote che incantano i prompt.

Dove atterra il blocco advisor

L'iniezione ha segature esplicite, ciascuna portata nel system prompt della richiesta dopo il blocco della search rule e prima del system prompt del workspace:

  • L'orchestratore del chat (entrambi i percorsi, streaming e non) - la regola hard sempre; il blocco advisor viaggia insieme quando l'archivio ne ha uno.
  • La pass di decisione della pipeline di sintesi - il blocco advisor prende il ruolo SYSTEM lì, mentre le pass precedenti (il retrieval, la stesura, il giudizio sulle contraddizioni) girano senza per progettazione.

wiki_query e wiki_write: i due builtin

I builtin wiki_query e wiki_write sono skill i cui percorsi di esecuzione non fanno nessuna chiamata LLM - il percorso di scrittura genera anteprime deterministiche interamente in codice. La conseguenza architetturale è netta: un'iniezione per-skill non raggiungerebbe nessun modello, quindi l'unica superficie LLM-facing del wiki è il system prompt dell'orchestratore. Il comportamento di scrittura del wiki = i tre livelli qui sopra; le funzioni di lettura/scrittura = codice semplice, sotto audit.

Perché questa forma regge

Tre proprietà, in combinazione:

  • Immutabilità alla base - raw_sources/ non può essere riscritto da nessuno, modello incluso (la guardia + il blocco sempre attivo).
  • Disciplina advisor - la guida editoriale entra come dato etichettato, controllabile al livello di config-edit, mai come privilegio.
  • Builtin deterministiche - le superficie di scrittura/lettura dell'archivio girano senza un modello, quindi le garanzie non dipendono dal giudizio del modello.

La promessa del motore è modesta e portante: la conoscenza si organizza da sola entro binari scritti, esattamente fin dove i binari lo decidono. L'operatore di Simmetric Chat resta l'autore dei binari - che è il punto silenzioso di tutto il progetto.

Per continuare

La guida porta il riferimento per l'operatore - le tabelle campo per campo e i contract degli endpoint - su /it/docs/wiki-knowledge-engine:

Provenance: Simmetric Chat docs/WIKI_SCHEMA_LAYER.md (v0.28.1, Phase 187/194), validateWritablePath in packages/server/src/utils/archivePath.ts, le segature d'iniezione dell'orchestratore, CHANGELOG.md v0.28.1 - allo stato documentale fissato dal census (SHA aca5b8ff).

Articoli correlati