# Doctrine Room Architecture > Activate whenever a multi-project operation needs a governance layer — a dedicated space where the rules for how work gets done are written, separate from the spaces where work ships. Trigger on "my projects are inconsistent," "I keep re-deciding the same things," designing workspace or project structures for complex operations, standing up operating doctrine for a team or solo operation, or any moment the same standards question gets answered differently in different places. Fire because operations that scale past a handful of projects without a doctrine layer pay a hidden tax: every project re-litigates decisions the operation already made, and drift compounds quietly until the projects no longer resemble each other. - Skill: `forexgod21/doctrine-room-architecture` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add forexgod21/doctrine-room-architecture` - Raw SKILL.md: https://api.skillmd.com/api/skills/forexgod21/doctrine-room-architecture/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: CC BY 4.0 - Author: Forexgod21 (https://skillmd.com/u/forexgod21) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/forexgod21/doctrine-room-architecture --- # Doctrine Room Architecture **Attribution:** YourVisionYourCreation LLC — yourvisionyourcreation.com **Doctrine class:** YVYC original — productivity category --- ## Universal So-What Every operation past a certain size has doctrine — the question is whether it is written in one governed place or scattered across a hundred decisions nobody can find. The doctrine room is the meta-layer: one space that does not ship products, and instead produces the rules, standards, and architectural decisions that make every OTHER space hold its shape. The projects build the products. The doctrine room builds the operation. --- ## Core Doctrine ### 1. The Two-Layer Separation The architecture has exactly two layers, and the boundary is the discipline: | Layer | Produces | Examples | |---|---|---| | **Doctrine room** | Rules, standards, governance, cross-project decisions, org design | Naming conventions, quality standards, authority maps, voice doctrine, escalation protocols | | **Project rooms** | Deliverables | The book, the app, the campaign, the codebase, the filing | - The doctrine room does not ship deliverables. A tactical task arriving there is a signal: either it carries a strategic implication worth extracting (extract it, then route the task), or it is misrouted (route it). - Project rooms do not write ecosystem rules. A rule invented inside one project applies to one project until the doctrine room adopts it — that adoption step is what keeps "how we do things" singular. ### 2. What Belongs in the Doctrine Room The room's legitimate workload: - **Doctrine architecture:** the operating rules themselves — written, versioned, named - **Cross-project synthesis:** patterns emerging across projects, captured at the level where they apply to all - **Org and authority design:** what roles exist (human and agent), what gets built next, where decisions live - **Strategic decisions:** anything affecting multiple projects, the long horizon, or the operation's identity - **Standards at the meta-layer:** not one logo — the design system; not one document — the voice and format doctrine - **New forms:** when no existing structure fits the actual work, the doctrine room is where the new structure gets invented and named ### 3. The Doctrine Lifecycle Rules are artifacts with a lifecycle, not vibes with seniority: 1. **Observed:** a pattern or friction appears in project work 2. **Drafted:** the doctrine room writes the candidate rule — what it governs, what it replaces, why 3. **Adopted:** the rule is versioned, dated, and enters the canon 4. **Propagated:** project rooms receive it — the propagation step is real work and is tracked, because an unadopted rule governing nothing is a document, not doctrine 5. **Reviewed:** rules carry review triggers — a rule that fights reality repeatedly returns to the room for revision or retirement ### 4. The Decision Ledger The room's most valuable artifact: - Every cross-project decision is recorded: the decision, the date, the reasoning, the alternatives declined - The ledger kills the re-litigation tax — "why do we do it this way" has an answer with a date on it, and revisiting a decision becomes a deliberate act against the record rather than an accidental drift - Decisions record their reversibility: standing law, default- until-challenged, or experiment-with-a-review-date — not all doctrine carries the same weight, and marking the weight prevents both ossification and chaos ### 5. Doctrine Quality Standards Doctrine is written to be USED under load: - Every rule states what it governs, what it requires, and what failure looks like — a rule without a visible failure mode cannot be enforced, only admired - Named memorably: rules that get invoked by name get followed; rules that require paragraph-lookup get forgotten - Concise enough to hold in working memory during real work — doctrine that only works when the document is open is reference material wearing doctrine's uniform - Anchored with canonical examples where ambiguity is likely — the example IS part of the rule ### 6. The Room's Own Governance The meta-layer governs itself last but not least: - The doctrine room has an owner — one authority who adopts, revises, and retires (in a solo operation, the operator; in a team, named, not assumed) - The canon has a single home and a current version — doctrine scattered across chats, docs, and memory is scattered authority - A handoff standard exists: a new collaborator (human or AI) entering the operation can be pointed at the canon and be functional — the doctrine room's ultimate test is whether the operation's "how" survives transmission --- ## Common Failure Modes | Failure | Cause | Correction | |---|---|---| | Same decision re-made monthly | No decision ledger | Ledger with dates, reasoning, and declined alternatives | | Projects drift apart quietly | Rules invented per-project, never unified | Adoption step — one canon, propagated | | Doctrine room becomes a junk drawer | Tactical work absorbed instead of routed | Two-layer boundary; extract the strategic, route the task | | Rules exist, nobody follows them | Unpropagated, unnamed, or unenforceable | Lifecycle step 4 tracked; named rules with visible failure modes | | Doctrine ossifies against reality | No review triggers | Rules carry weight class and review conditions | | The "how" lives in one person's head | No canonical home, no handoff standard | Single-home canon; transmission is the test | --- ## Non-Negotiables 1. The doctrine layer and the delivery layer stay separate. 2. Rules enter the canon through the lifecycle — observed, drafted, adopted, propagated, reviewed. 3. Every cross-project decision lands in the ledger with its date and reasoning. 4. Every rule states its failure mode or it cannot be enforced. 5. The canon has one home, one current version, one owner. 6. The operation's "how" must survive transmission to a newcomer. --- *YourVisionYourCreation LLC — yourvisionyourcreation.com* *Licensed under CC BY 4.0*