# ADR 000011 GitBook Trigger Points GitBook **Date:** May 2026\ **Status:** Accepted\ **Decider:** NikiDigitals\ **Version:** GitBook — Thinking Layer *** ## The Question GitBook is the thinking layer. It exists to document the reasoning behind the project at a standard that a serious technical or academic reader finds worth their time. The question is: when does something warrant a GitBook entry, and when does it not? ## The Decision GitBook entries are written at defined trigger points only. Not every session produces a GitBook entry. Not every task completion, progress update, or configuration change belongs here. The triggers that warrant a GitBook entry: * A significant architectural decision is made and the reasoning is complete * A concept is genuinely understood through study — not just encountered, but understood well enough to explain * A module or feature is completed, and the design choices behind it are worth documenting * A phase is completed, and a retrospective reflects honestly on what was built, learned, and what comes next * A research finding of substance emerges — something that changes or deepens the project's direction * A governance framework is established that defines how the project operates The triggers that do not warrant a GitBook entry: * Routine session progress * Minor task completions * Administrative updates to internal documents * Configuration changes without design significance * Work in progress without a concluded finding ## Why This Standard Exists A GitBook that contains fifty entries of mixed quality is less credible than one that contains twenty entries of consistent rigour. Volume without substance signals that the author cannot distinguish between what is worth saying and what is simply activity. For a portfolio targeting a senior professional audience in finance systems, that distinction matters. There is also a practical reason. Documentation is not the work — it records and communicates the work. The ratio of building to documenting should remain high, particularly in the early phases where infrastructure and foundation are the priority. A trigger point framework protects that ratio without sacrificing quality. ## The Standard a GitBook Entry Must Meet Before anything is published to GitBook, it answers yes to three questions: **Is it complete?** Not a draft, not work in progress, not a placeholder. **Is it reader-facing?** Written for someone who does not have the internal context of the project — who encounters it cold and should be able to understand it without additional explanation. **Is it standalone?** Does it make sense independently, without requiring the reader to have read anything else first? If any answer is no, it stays in GitHub as a working draft until it is ready. --- # 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-000011-gitbook-trigger-points-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.