Chat history is not system architecture
Clarence produces a lot of chronology. There are chats, Discord reports, cron outputs, notes, commits, and handoffs. That is useful if you want to know what happened yesterday. It is terrible if you want to know what is true now.
A system this layered needs a durable explanation of itself. Which runtime is active. Which model is actually pinned. Where the memory lives. Which surfaces are user-facing. Which parts are legacy. What changed because of a migration. Without that, every serious session starts by reconstructing the machine from fragments.
The Obsidian failure made the problem obvious
The vault disaster forced the issue. The system had durable, operationally important knowledge tied up in notes, but the note surface itself had become unreliable. One vault was real. Another looked real enough to be dangerous. Sync behavior depended on what the app had actually opened, not just what existed on disk.
That is not a note-taking inconvenience. That is a system integrity problem. If the wrong vault can silently become your reality, then architecture notes, recovery steps, and operational rules cannot live there alone.
What the system wiki actually captures
The wiki gives Clarence a durable self-description: Hermes as the active runtime, GPT-5.4 as the pinned primary model, the gateway and cron surfaces, the layered memory design, and the fact that important legacy data still lives under the old OpenClaw tree even though OpenClaw is no longer the active runtime.
It also captures failure modes that are too expensive to rediscover the hard way. Wrong-vault attachment. Stale path references. Cron sharp edges. Transitional data living in the wrong place. Those are not random debugging anecdotes. They are system truths.
Why this matters for AI UX
One of the design problems in persistent AI systems is that the system gradually becomes too complex to explain casually. At that point, trust starts depending on whether the system can describe its own boundaries honestly. A system wiki is part of that honesty.
It is also a guardrail against mythology. AI projects accumulate lore fast. If you do not write down which parts are current, which parts are legacy, and which parts are aspirational, the whole thing turns into self-fanfiction.
What should be public and what should not
I do think Clarence deserves public documentation, but not as a raw dump of the full internal wiki. That would be reckless. The live system wiki contains operational paths, infrastructure details, recovery notes, and enough implementation texture to become an unnecessary security gift.
The public version should be a curated architecture layer: system overview, design principles, memory philosophy, migration lessons, and selected incidents that teach something without exposing the guts of the machine.
The real reason the wiki exists
Clarence is supposed to be a collaborator, not a parlor trick. A collaborator needs continuity. The wiki is one of the structures that makes continuity real instead of theatrical.
The public-safe architecture notes currently live in the public repo at github.com/nomadjames/clarence-architecture.
You can read the full case study for the broader system design frame at Clarence.