The wiki knowledge engine: rules, guidelines, and synthesis

Knowledge that organizes itself, within written rails

When conversations get archived into a shared knowledge base, the question stops being "can we store pages" and becomes "who can write what, where, in whose voice". Simmetric Chat's wiki engine answers with a three-layer instruction model for every archive: rules enforced by code, a per-archive editorial prompt carried as data, and the structured fields that describe how the archive should behave. The mental model that sticks: the per-archive schema prompt is to the wiki what a CLAUDE.md is to a code repository - advisory by nature, powerful in practice, never a law.

This article is the design walkthrough: the three layers, what each can and cannot do, the precedence chain when they disagree, and the two built-in skills (wiki_query, wiki_write) that make the machine-readable half of the promise true.

Layer 1: hard rules, enforced by code

The first layer is unconditional and config-independent - it guards everything:

1. The filesystem guard. validateWritablePath rejects any write target outside <archiveBase>/wiki/: the anti-traversal check runs first, then the wiki/-prefix check. A target outside wiki/ throws a named error, and both createPage and updatePage call the guard before any file write. raw_sources/ is immutable by design - no API endpoint writes under it.
2. The prompt-layer mirror. An always-on block is appended to every archive-bound prompt, and its wording mirrors the filesystem guard (raw_sources/ is immutable). The model never even attempts the way out of wiki/ - and if it did, the code guarantees nothing lands.

The pairing is deliberate: the prompt keeps the model honest, the code keeps the system safe. Trust lives in the second property, not the first.

Layer 2: the per-archive schema prompt

The schema prompt (schemaPrompt) is a free-text advisory field persisted in the archive's config JSON:

• Shape: up to 10000 characters (≈2500 tokens) inside the archive's config schema - an additive key, zero migrations.
• Validation: Zod on every write via PUT /api/archives/:id/config; an over-cap payload is rejected with a 400 naming the field.
• Read contract: an archive with no stored row reads its schema-default config (the first-save hydration path); archives with a row return the stored blob verbatim. Legacy blobs over the cap are truncated at injection with an explicit annotation rather than silently clipped or re-validated.
• Advisory by design: the block enters prompts as DATA with an explicit advisory label - never as a system-prompt privilege grant. No sanitization beyond the length cap; contradictory instructions are an accepted quality risk, mitigated by helper text and the template in the UI.

Layer 2 is where the organization's editorial voice lives: naming conventions, page structure, source expectations. It is guidance - and the engine treats it exactly as such.

Layer 3: structured fields

Persona, purpose, scope - the archive's structured description - are config-injected into the prompt path by the existing behavior. They describe defaults; layer 2 overrides them when both speak.

The precedence chain

hard rules (code) > schemaPrompt (advisory) > structured fields

1. The schema prompt can never override the hard rules - the prompt declares; the code enforces.
2. On conflict with the structured fields, the schema prompt takes precedence.
3. An archive without a schema prompt behaves as baseline plus the hard rule - zero enhancement, zero degradation.

That third row matters for the operator's mental ledger: an empty advisory field is a completed configuration, not a missing one. There are no empty placeholder sections haunting the prompts.

Where the advisory block lands

The injection has explicit seams, each carried in the request's system prompt after the search rule block and before the workspace's own system prompt:

• The chat orchestrator (both streaming and non-streaming paths) - the hard rule always; the advisory block rides along when the archive has one.
• The synthesis pipeline's decision pass - the advisory block rides the SYSTEM role there, while the earlier passes (retrieval, drafting, contradiction judging) run without it by design.

wiki_query and wiki_write: the two built-ins

The builtins wiki_query and wiki_write are skills whose execution paths make no LLM call - the write path generates deterministic previews entirely in code. That has a sharp architectural consequence: per-skill injection would reach no model, so the wiki's only LLM-facing surface is the orchestrator's system prompt. The wiki's writing behavior = the three layers above; the wiki's reading/writing functions = plain, auditable code.

Why this shape holds up

Three properties, in combination:

• Immutability at the bottom - raw_sources/ can't be rewritten by anyone, model included (the guard + the always-on block).
• Advisory discipline - editorial guidance enters as labeled data, auditable at the config-edit level, never as privilege.
• Deterministic built-ins - the archive's own write/read surfaces run without a model, so the guarantees don't depend on the model's judgment.

The engine's promise is modest and load-bearing: knowledge organizes itself within written rails, exactly as far as the rails decide. Simmetric Chat's operator stays the author of the rails - which is the quiet point of the whole design.

Reading on

• Request a demo

The guide carries the operator reference - the field-level tables and the endpoint contracts - at /en/docs/wiki-knowledge-engine:

• Wiki knowledge engine - the guide
• The plain-language version
• Facts in this post: FACT-CENSUS.md row F-WIKI-1 (the Wiki Schema Layer: authored, finalized, audited against the live code at the v0.25 gate)

Provenance: Simmetric Chat docs/WIKI_SCHEMA_LAYER.md (v0.28.1, Phase 187/194), validateWritablePath in packages/server/src/utils/archivePath.ts, the orchestrator's injection seams, CHANGELOG.md v0.28.1 - at the census's pinned docs state (SHA aca5b8ff).