Case study / Knowledge systems & information architecture
Broken Compass Knowledge
The documentation was scattered everywhere.
Player guides, development architecture, operational knowledge, roadmaps, Word documents, Markdown, Google Drive material, and historical documentation lived in different places. Putting it all into another wiki sounded like the obvious answer.
Great. Now the mess is in one place.
Explore the live systemThe problem / 01
A document being findable doesn't mean it can be trusted.
I needed to know what someone should be able to find, whether it was still true, where it came from, who would maintain it, and who was allowed to see it. In some cases, a person should not even know restricted knowledge exists.
Those questions changed the shape of the project. Storage was one part of a larger system involving identity, authorization, retrieval, ownership, and the lifecycle of knowledge.
The architecture / 02
Authorization before retrieval.
A Public player, Developer, and Administrator do not search one giant corpus and have unauthorized results removed afterward. Identity determines the knowledge universe available to browse, search, and render in the first place.
Identity in use / 03
The same system, with a different knowledge universe.
Broken Compass already uses Discord for identity and organizational roles. Logged out, only Public knowledge exists to the system. Restricted categories stay out of navigation, direct retrieval, and search. Authentication makes knowledge available according to a person's actual Discord roles, without a second account and permissions system to maintain.
Maintenance / 04
Someone has to maintain the damn thing.
Repository-based authoring would have kept documentation dependent on technical maintainers. I built a Document Manager so authorized contributors can maintain canonical Markdown without editing the repository directly. It supports drafts, publishing, immutable versions, provenance, managed assets, audience-aware sections, and role-aware preview.
A reader can recognize a problem without having the authority or context to rewrite canonical knowledge. Readers can flag an issue for review; authorized contributors can then update the source and publish it.
The reader / 05
Knowledge has to work for the person reading it.
The reader renders canonical content for the authorized audience and keeps review close to use. A person encountering a problem can flag it where it occurs.
Migration / 06
Existing doesn't automatically mean canonical.
I collected and classified the source corpus before migration. Source material and provenance were preserved where appropriate; missing information was documented instead of invented. A HOLD decision kept material out of production knowledge when finding it was not enough to justify publishing it.
The point was to decide what the knowledge represented, who it was for, and whether it was ready to be maintained as canonical information.
AI collaboration / 07
Generate → Challenge → Verify → Refine.
AI collaborators helped with architecture, critique, corpus investigation, implementation, migration, testing, and deployment. I remained responsible for direction, evidence, validation, and acceptance.
During architecture validation, one collaborator said it could not validate the proposal because it did not have enough of the documentation corpus. That was the correct answer. I went and got the corpus. When evidence was missing, the next step was to obtain it rather than manufacture certainty.
Production / 08
Logged out: Public. Logged in: Development and Administrator. Logged out again: gone.
This is a live system running on PostgreSQL and a private Node service behind Apache and TLS. Discord OAuth connects it to the community's actual role structure. No separate knowledge account or manual administrator selector is needed. Before deployment, 113 automated tests passed.
The interesting part wasn't building a documentation website. It was figuring out what kind of system the documentation actually needed.