# Governance Framework Overview *Document code: LES-GOV | Section: 02 — Project Governance | Phase 0 | May 2026* LES applies a set of governance disciplines throughout the programme. These are not bureaucratic formalities — they are the practices that distinguish a professional build from a personal project. This page provides an orientation to those disciplines. The authoritative source for each is the Project Plan (`LES-PLAN-v2.3`), published in full in the Vision & Strategy section of this GitBook. *** ### Decision Recording Every significant architectural, strategic, technology, and operational decision is recorded as an Architecture Decision Record (ADR). **Convention:** One dated file per day — `ADR-YYYY-MM-DD.md`. All decisions made on a given day are grouped within that single file, organised by subject. Decisions of significant consequence are recorded before implementation begins — not after. **Internal structure of each ADR file:** * Architecture Decisions * Strategic Decisions * Technology Decisions * Operational Decisions Each entry contains a decision statement and rationale. For high-impact decisions, alternatives considered and anticipated consequences are also documented. The Decision Log is described in full on the [Decision Log Overview](https://app.gitbook.com/o/tbne7ZtUlyqO49hsY3QC/s/Nb5M0j365A1RgeUSUy4w/decision-log/decision-log-overview) page. *** ### Progress Tracking The master context document (`LES-Master/_context/master-context.md`) is updated every session. It holds the current state of the project: completed tasks, active decisions, open sessions, and the phase checklist. It is the single source of truth for where the project stands at any point in time. *** ### Phase Gate Process LES is developed in five sequential phases. No phase begins before its predecessor is sufficiently complete. At the close of each phase, a formal gate review is conducted before the next phase begins. The gate review assesses: * Have all phase deliverables been completed to the defined quality standard? * Is the documentation for this phase complete and published? * Have the phase certifications been achieved, or is a clear plan in place? * Has the phase retrospective been written and committed? * Is the next phase plan sufficiently detailed to begin? Phase gate criteria for each phase are defined in the Project Plan (`LES-PLAN-v2.3`) — Five-Year Phase Plan. *** ### Change Management Changes to project scope, architecture, or phase plan follow a defined process: 1. Change is identified and described in writing 2. Impact on scope, timeline, and architecture is assessed 3. Decision is recorded as an ADR with full rationale 4. Master context document and roadmap are updated 5. Change is committed to GitHub with the appropriate commit message No significant change is implemented without a corresponding ADR. *** ### Documentation Governance LES produces documentation across four platforms, each serving a distinct audience. The governance of the documentation architecture defines what is published where, and at what trigger point. | Trigger | GitHub | GitBook | Website | LinkedIn | | ----------------------------------------------- | ----------------------- | --------------------------------- | ------------------ | --------------- | | A decision made about architecture or direction | Log in context doc | Write reasoning and trade-offs | No | Possibly | | A concept learned and understood | No | Write learning note or reflection | No | Possibly | | A platform or tool set up | Commit config or README | Document what it is and why | No | No | | A module or feature built | Commit the code | Document design and decisions | No | No | | A phase completed | Tag the release | Write phase retrospective | Update milestones | Yes | | A certification earned | No | Note in learning record | Update if relevant | Yes | | A significant research finding | No | Full academic-style entry | No | Yes — condensed | | A public-facing milestone reached | — | — | Major update | Yes | GitBook entries are produced at defined trigger points only (Decision 23). Content is published when it is ready and when it serves the reader — not as a running commentary on work in progress. *** ### Quality Standards Quality standards in LES are defined across three areas. Full detail is in the Project Plan (`LES-PLAN-v2.3`) — Quality Standards. **Documentation** * Written in UK English throughout * Academic and professional tone in all GitBook content * Every GitBook page is self-contained — a reader who arrives without prior context can follow it * Every document includes version information * No document is considered published until reviewed for clarity and completeness * All documents carry a reference code from the taxonomy **Code** * All code is version controlled — nothing exists only on a local machine * Commit messages follow the convention: `[Session type] — [description]` * Sensitive data — credentials, personal financial data, health data — is never committed to a repository * Infrastructure is always defined as code in LES-INFRA. No manual Azure portal configuration that is not also captured in code. **Architecture** * No architectural decision is implemented without a corresponding ADR * The complete data model is designed before any module is built * Diagrams follow confirmed standards: C4 Model (architecture), BPMN 2.0 (process), ERD (data), Azure Architecture icons (infrastructure) — all produced in draw\.io *** ### Security by Design Security is a foundational principle, not a phase deliverable (Decision 8). It is considered at every architectural decision from Phase 0 onward — not added after the fact. In Phase 0, the practical security action taken was the creation of a secrets register (`LES-SEC-000001`), committed to GitHub to establish the habit and the pattern. The LES-SEC security and governance framework is a Phase 3 deliverable — it does not yet exist. *** ### Scope Definition **In scope:** * Design, build, and operation of all ten LES modules * Azure-native cloud infrastructure * Documentation across all four portfolio layers * Microsoft technology certification pathway * Finance domain knowledge through parallel formal education * Academic research and publication * NikiDigitals professional portfolio presence **Out of scope:** * Multi-user or multi-tenant architecture * Mobile application development * Third-party integrations beyond the Microsoft ecosystem * Commercial product features or monetisation * Social or collaborative features *** ### Related Pages * [Project Overview](https://app.gitbook.com/o/tbne7ZtUlyqO49hsY3QC/s/Nb5M0j365A1RgeUSUy4w/01-vision-and-strategy/project-overview) * [Decision Log Overview](https://app.gitbook.com/o/tbne7ZtUlyqO49hsY3QC/s/Nb5M0j365A1RgeUSUy4w/decision-log/decision-log-overview) * [Session & Chat Protocol](https://app.gitbook.com/o/tbne7ZtUlyqO49hsY3QC/s/Nb5M0j365A1RgeUSUy4w/01-vision-and-strategy/session-and-chat-protocol) * **GitHub:** [github.com/NikiDigitals](https://github.com/NikiDigitals) * **Website:** [nikidigitals.com](https://nikidigitals.com) --- # 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/02-project-governance/governance-framework-overview.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.