Wiki-as-substrate: typed authority boundaries that scale across brands

The Master OS wiki has 336+ pages across 7 brand namespaces, a _global/ namespace for cross-brand doctrine, and an operations/ namespace for live system state. It is not a documentation graveyard — I use it daily as the primary memory substrate for the system.

What makes it different from every other wiki I’ve worked with is the authority model.

Typed write authority

Every page in the wiki belongs to a namespace. Every namespace has a designated writer. The designations are not conventions — they’re enforced by the system.

The Librarian agent writes wiki/<Brand>/. The Operator-Global agent writes wiki/_global/. The Master Archivist writes wiki/tasks/. The Session Orchestrator writes wiki/operations/. Scouts, distillers, and verifiers are read-only — they return structured outputs for other agents to act on.

The ticket executor that touches wiki pages doesn’t write directly. It delegates: brand content to the Librarian, cross-brand doctrine to Operator-Global. The authority chain is structural, not advisory.

Why does this matter? Because a wiki where anyone writes anything quickly becomes a wiki where no one can trust what they’re reading. If the Librarian writes wiki/Sandbox/business/pricing.md and the ticket executor also writes wiki/Sandbox/business/pricing.md, which version is canonical? The question doesn’t have a good answer.

Typed authority makes the answer deterministic: the Librarian version is canonical. Always.

Daily distillation

The wiki grows from verified signal, not from everything a model thought during a session. The distillation pipeline runs at the start of each new day:

1. scripts/distill.py gather assembles DistillationPayloads per brand — artifacts from yesterday’s session (merged ticket notes, research outputs, blocked ticket context, session logs).
2. Parallel distiller subagents classify each candidate as high/medium/low confidence.
3. distill.py route sends high-confidence findings to the Librarian or Operator-Global for immediate wiki write. Medium-confidence surfaces in the next session’s interview. Low-confidence stays in the daily ledger.

High confidence means: the finding was produced by a merged ticket (verified, pre-merge-gate-approved), or by research that was explicitly reviewed and ratified. Medium confidence means: plausible, but not verified by the system. Low confidence means: a model’s unverified inference.

The compound effect over time: the wiki accumulates verified knowledge without accumulating noise. Each day, the system knows more than it did yesterday about its own structure, its own decisions, and the domains it operates across.

Structural validation

python3 scripts/system_doctor.py --grade runs 19 checks on the system, including wiki structure checks: do all agent contracts exist, do they have correct frontmatter, are they registered? It also checks that wiki/operations/tickets.json (now migrated to SQLite) is internally consistent, that the distillation pipeline produced an output today, and that the hot cache is fresh.

A wiki that isn’t structurally validated is a wiki that degrades silently. You don’t notice the stale page until you make a decision based on it. Structural validation catches the degradation at the next session instead of at the next decision.

The practical implication for AI-native tools

If you’re building a system where AI agents need to share persistent memory across sessions, the memory substrate needs authority boundaries and validation — not just persistence. An LLM that can write to any page with no authority model will produce a wiki that’s full, fast, and unreliable in proportion to its fullness.

Typed authority + daily distillation + structural validation is the pattern that makes the wiki actually useful as a substrate rather than as a reference document that might be stale.

---

The wiki authority model is documented in wiki/CLAUDE-WIKI.md. The distillation pipeline is at scripts/distill.py in the Master OS.