# ADR 000014 GitHub GitBook Audiences GitBook **Date:** May 2026\ **Status:** Accepted\ **Decider:** NikiDigitals\ **Version:** GitBook — Thinking Layer *** ## The Correction Early in the design of the LES portfolio architecture, a rule was proposed: no doubles. One platform per document type. The intention was clean separation — avoid duplication, avoid contradiction, keep things simple. The rule was wrong. And it is worth explaining why, because the reasoning matters for how the portfolio is maintained over five years. ## The Problem with No Doubles A developer lands on the NikiDigitals GitHub repositories. They are evaluating the project as technical work. They open the LES master repository and find: a README, a context folder, and template files. No architecture documents. No decision records. No research. The documentation, they are told, is on GitBook. That is a broken experience. A developer visiting a GitHub repository expects documentation to live there. Sending them to a different platform to understand what they are looking at is friction. It signals that the repository is not self-contained — and self-contained repositories are a mark of professional discipline. Now reverse it. A researcher or architect lands on GitBook. They are reading about the LES architecture and want to understand the reasoning behind a significant decision. They find a tightly structured technical reference document — context, decision, rationale, consequences — written for someone who already understands the domain. The narrative context is missing. The intellectual journey that led to the decision is absent. The document is correct but it does not invite deeper engagement. Two different audiences. Two different failures. One rule caused both. ## The Decision Both platforms contain documentation. They are not copies of each other — they are two versions of the same content, written for different readers. GitHub receives a technical reference version: structured, concise, factual. A developer reading it understands what was decided and why in the minimum words necessary. GitBook receives a thinking-layer version: narrative, contextual, written as if explaining the decision to an intelligent professional who is encountering it for the first time. The taxonomy code is the same on both platforms. `ADR-000001` on GitHub and `ADR-000001` on GitBook cover the same decision. The platform distinguishes the version. The reader gets what they came for. ## What Stays GitHub-Only Three things never leave GitHub. The master context document is an internal project management tool — it has no reader-facing purpose. Template files are scaffolding — they exist to make writing easier, not to be read. Working drafts are in progress — they are published to GitBook only when they meet the three-point standard: complete, reader-facing, and standalone. ## The Discipline This Requires Writing two versions of every significant document takes more time than writing one. That is the honest cost of this decision. The return is a portfolio where every audience finds what they need in the format they expect — which is, ultimately, what a professional portfolio is for. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://nikidigitals.gitbook.io/les/03-architecture/decision-log/phase-0-foundation/adr-000014-github-gitbook-audiences-gitbook.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.