# ADR 2026 05 19 **File:** ADR-2026-05-19.md\ **Author:** Nicolette Martine Langendam — NikiDigitals\ **Location:** LES-Master/docs/decisions/\ **Decisions covered:** ADR-000097 through ADR-000099\ **Session type:** LES-MENTOR — Portfolio Architecture & AI Integration Brainstorm *** ## Context This file records all decisions made on 19 May 2026 during a structured brainstorm on AI integration strategy and portfolio architecture. Three decisions emerged: the AI Integration Principle governing how AI is incorporated into LES, the LES Labs architecture for sandbox and learning projects, and the standalone project convention for independent NikiDigitals builds. *** ## Strategic Decisions ### ADR-000097 — AI Integration Principle **Decision:** A formal AI Integration Principle is established governing all AI incorporation into the LES system. The principle has four components: build philosophy, evaluation criteria, industry monitoring, and documentation routing. #### Component 1 — Build Philosophy AI is integrated into LES as a top layer, added after the underlying system foundation is solid. AI is never integrated prematurely or in place of foundational architectural work. Before any AI tool or framework is used in production within LES, it is built at small scale in a LES-LABS sandbox. The sandbox build is the price of admission — not a throwaway exercise, but the mechanism by which genuine understanding is acquired. Once understanding is verified, the industry standard tool is used in production where it makes sense. This applies uniformly across all AI capabilities: | Capability | Sandbox | Production | | ---------------------- | ------------------------------------------------------------------- | ---------------------------------------------- | | LLM | Train a small model — understand weights, loss functions, inference | Azure OpenAI Service | | Agent orchestration | Build an orchestrator from scratch | LangChain / Azure AI Foundry where appropriate | | Vector search / memory | Build a basic retrieval system manually | Azure AI Search | | Embeddings | Generate and query manually | Azure OpenAI embeddings | The distinction between sandbox and production is not capability versus incompetence — it is learning versus operating. The sandbox teaches. The production tool performs. Both are necessary. Neither replaces the other. #### Component 2 — Evaluation Criteria AI integration is justified only when all four criteria are met: | Criterion | Question | | ------------------ | ------------------------------------------------------------------------------------------------------------- | | Real value | Does it reduce manual effort, improve decision quality, or enable something previously impossible? | | Reliability | Is it stable enough for production use, or is it a demo that breaks under real conditions? | | Auditability | Can the output be explained, traced, and audited? For finance specifically — can it withstand audit scrutiny? | | Cost justification | Does the benefit outweigh compute cost, maintenance burden, and added system complexity? | Hype, novelty, and industry trend alone do not satisfy any of these criteria. An AI capability that is trending but fails one criterion is not integrated. #### Component 3 — Industry Monitoring AI developments are monitored quarterly across four domains: | Domain | Rationale | | --------------------------------- | ----------------------------------------------------------------------------- | | Finance AI | Direct application to LES-FIN and the Finance Transformation Architect target | | ERP and enterprise systems AI | What D365, ServiceNow, and SAP are shipping and why | | Agentic systems and orchestration | Directly feeds LES-AGT design decisions | | Azure AI and OpenAI updates | Primary platform — releases and deprecations must be tracked | Sources: Microsoft Build announcements, Azure update feeds, OpenAI release notes, peer-reviewed research via Zotero, LinkedIn signal from practitioners in the field. Not tech press headlines. Findings are catalogued in Zotero under `05 — AI & Multi-agent Systems`, synthesised in Obsidian, and published in the GitBook Research section. #### Component 4 — Documentation Routing | AI work type | Documentation home | | ------------------- | ----------------------------------------------------- | | Industry monitoring | Zotero + Obsidian + GitBook Research section | | LES AI development | LES-INT and LES-AGT repos + GitBook AI Agents section | | Sandbox builds | LES-LABS repos + GitBook Labs section | **Rationale:** A Finance Transformation Architect who advises organisations on AI systems must understand those systems from the inside. Using pre-packaged AI tools without understanding their internals produces a practitioner who can assemble but not design. The sandbox-before-production rule closes this gap. The evaluation criteria prevent integration driven by hype rather than value. The monitoring cadence ensures the architecture remains current without becoming reactive to every trend. **Consequences:** All future AI integration decisions in LES are evaluated against these criteria. Sandbox builds precede all production AI integrations. Quarterly AI review added to the programme calendar from Y1Q1. *** ## Architecture Decisions ### ADR-000098 — LES Labs Architecture Established **Decision:** A dedicated sandbox and learning project architecture is established under the LES Labs brand. LES Labs is the home for all hands-on learning builds across all domains — not exclusively AI. **GitHub naming convention:** `LES-LABS-[TOPIC]-[NNN]` Examples: * `LES-LABS-LLM-001` — small language model training experiment * `LES-LABS-AGT-001` — agent orchestration built from scratch * `LES-LABS-SQL-001` — database schema experiments * `LES-LABS-API-001` — FastAPI development * `LES-LABS-PWR-001` — Power BI data model experiments * `LES-LABS-JAVA-001` — Java OOP exercises beyond OU **GitBook section:** Labs — one sub-page per sandbox project documenting context, approach, what was learned, and outcome. **Portfolio treatment:** One NikiDigitals Labs card on the portfolio page — linking to the GitHub collection and the GitBook Labs section. Individual sandbox repos are not given individual portfolio cards — the Labs card is the aggregation point. **Context:** The five-step learning methodology requires a sandbox at Step 3 for every concept. Previously there was no defined home for sandbox outputs — they risked being throwaway exercises undocumented and invisible to the portfolio. LES Labs creates a permanent, public, structured home for every sandbox build. **Rationale:** One repo per sandbox rather than a single repo with folders. Each sandbox is a standalone demonstrable piece of work. GitHub shows activity at repo level — a folder buried inside a repo does not. Each repo can be linked directly from GitBook and referenced in articles and professional conversations. The naming convention groups them visually on the GitHub profile and makes the progression over time visible. LES Labs covers all domains — not only AI — because the learning methodology applies universally. A SQL schema experiment, a Java OOP exercise, and an LLM training sandbox are all the same thing: Step 3 of the methodology applied to a specific concept. **Consequences:** LES-LABS repos created as sandboxes begin in the programme. GitBook Labs section to be created in the current session. Portfolio page to be updated with NikiDigitals Labs card. Mentor instruction updated — Step 3 sandbox outputs are always committed to LES-LABS repos. ### ADR-000099 — Standalone Projects Architecture Established **Decision:** A standalone project architecture is established for independent NikiDigitals builds that are separate from LES modules and separate from LES Labs sandboxes. **GitHub naming convention:** `ND-[PROJECT-NAME]` **GitBook section:** Projects — one sub-page per standalone project. **Portfolio treatment:** Full portfolio card per public project using the three-button template (GitBook, GitHub, LinkedIn). **Context:** The portfolio review identified that NikiDigitals will produce projects beyond LES — formal education builds, externship deliverables, tools, and other standalone work. These needed a defined home, naming convention, and documentation treatment that distinguishes them from both the LES flagship and the LES Labs sandboxes. **Standalone project types and treatment:** | Project type | GitHub | Portfolio | | ------------------------------------------------ | ------------------------- | -------------------------------------------- | | Academic — restricted (TMA, assessed submission) | Private repo | Case study write-up only — no code published | | Academic — demonstrable build | Public repo — `ND-[NAME]` | Full card | | Externship — under NDA | Not published | Experience section reference only | | Externship — public | Public repo — `ND-[NAME]` | Full card | | NikiDigitals tool or application | Public repo — `ND-[NAME]` | Full card | **Rationale:** The distinction between LES Labs and standalone projects is purpose. A LES Labs repo is a learning sandbox — its purpose is to build understanding of a concept. A standalone project is a complete, purposeful build — its purpose is to solve a problem, fulfil a brief, or produce a deliverable. They are documented differently because they serve different audiences and demonstrate different things. Volume estimate: two to three standalone projects in Year 1. Many over five years. The structure scales without modification. **Consequences:** GitHub profile structure now has three visually distinct groups — `LES-[MODULE]`, `LES-LABS-[TOPIC]-[NNN]`, and `ND-[PROJECT-NAME]`. GitBook Projects section to be created. Portfolio page to receive standalone project cards as projects are completed and made public. *** ## Operational Decisions ### ADR-000100 — Contact Page White Gap Resolved **Decision:** The cosmetic white gap at the bottom of the nikidigitals.com Contact page has been resolved. Issue closed. **Context:** A small white gap at the bottom of the Contact page was identified during the responsive pass and logged as a low-priority cosmetic issue. Resolved 19 May 2026. **Consequences:** Issue removed from the active task list. Phase 0 cosmetic items fully resolved. --- # 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-2026-05-19.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.