## Lingering Questions - Does the "confirmed sources only" guardrail scale as the content map grows into the hundreds of entries, or does source-conflict/ambiguity increase with corpus size? - How will the team measure whether Learn Modern Press actually reduces repeat support tickets, once client usage data exists (explicitly unknown as of this talk)? - What is the actual maintenance cost trajectory as the framework and client base grow — does "2-3 hours per release" hold at 2x, 5x, 10x the current client count? - Does surfacing documentation directly inside the WordPress editor sidebar (the exploratory Layer 3) measurably change adoption compared to a standalone resource site? ## Article Ideas - A reusable "confirmed sources only, never invent" AI-documentation guardrail pattern piece, generalized beyond this one agency's case for any team building an AI-assisted knowledge base. - A piece on the "assistant proposes its own configuration improvements" meta-pattern (templates and the response-modes file were both credited to the AI itself) — a human-AI collaborative tooling design angle. ## Cross Reference - [[3. Resources/Permanent Notes/Training as a System Compounds Where a Session Decays]] — already exists from this source - [[3. Resources/Permanent Notes/AI Documentation Pipelines Need an Explicit Authority Source]] — atom 4's never-invent-settings guardrail is evidence for that note's claim rather than a separate one - [[3. Resources/Permanent Notes/AI-Facing Documentation Needs an Explicit Authority Boundary]] — the same authority question stated for the consuming agent; this source approaches it from the authoring side - [[3. Resources/MOCs/DevRel MOC]] — client training as a DevRel practice: systems that compound versus sessions that decay - [[3. Resources/Literature Notes/A DevRel-Led Funnel That Puts Developers First - Literature Note]] — the cross-link a prior pass flagged and could not resolve: both run the build-the-reusable-foundation-once logic, this one for training, that one for funnel design ## Fiction & Worldbuilding None. ## Vocabulary - **Content map**: a running markdown sitemap of every published doc topic with category/audience context, fed to the AI assistant - **UAT**: user acceptance testing — the client-facing verification process before a build ships - **Guardrail**: an explicit rule constraining an AI assistant's output (here: never invent, flag gaps instead) - **Modern Press**: the agency's internal custom WordPress framework (themes, plugins, blocks layered on core) ## Bib capsule Andrew Adam (QA engineer, Modern Tribe by Nexus) — "Building Training Systems, Not Sessions" — WordCamp talk, YouTube (https://www.youtube.com/watch?v=FKfdL7sK6Og), captured 2026-08-18 — a practitioner case study on why one-time client training sessions decay, and how a two-person team built "Learn Modern Press," a ~100-guide, AI-assisted shared documentation system for their internal WordPress framework. ## Author's thesis **Q1 — What is it about?** It's about why one-time client training events (launch-week sessions, static docs, recordings) fail to produce lasting competence, and how Adam's team reframed training as a maintained system instead — Learn Modern Press, a shared documentation resource covering both core WordPress and their custom framework as one undifferentiated system. **Q2 — How does it develop that?** Adam opens with the failure mode: clients don't know what they don't know until they're working in the live site, and any single training event goes stale the moment WordPress, the site, or the client's team changes, with turnover compounding the loss. His fix is to document the *foundational*, repeated-across-every-client material once and deeply, freeing human time for genuinely custom work. He then walks through how a two-person team actually built this in about a month: mapping 100+ topics, configuring an AI assistant with strict guardrails (only confirmed sources, never invent settings, flag gaps instead of guessing), and iterating that configuration through a human-in-the-loop feedback loop where the assistant itself proposed several of the eventual improvements. He closes on maintenance (triggered by WordPress release notes and internal framework changes, not client complaints) and a stated takeaway: training doesn't have to be a deliverable — it can live inside the tools people already use. ## Key arguments - Training decays because the underlying system (WordPress, the built site, the client's team) keeps changing after a one-time session ends — a static event has no mechanism to keep up. - Documenting the foundational, repeated-across-clients material once, deeply, lets a small team's human time concentrate on genuinely custom project work instead of re-explaining the same fundamentals per engagement. - An AI documentation assistant's reliability comes from an explicit, non-negotiable guardrail — never invent settings or labels, always flag a gap instead of guessing — refined through iterative human review, not from tool sophistication alone. ### Shift training from one-time sessions to systems > [!quote] ID:rw_atom1 > So this led us to shift our thinking from sessions to systems where a session is just one moment. A system can start before that moment and continue well when it has passed. So our idea was to make one shared and scalable training resource. The pivot point of the talk, right after the problem framing (training decay, client turnover) and just before the resource showcase — the talk's core reframe and thesis statement. Already promoted to a Permanent Note (see below). ### Document shared foundations once, go deep > [!quote] ID:rw_atom2 > that are the same and we document them once and we do it extremely well. Then the coverage can go much deeper. We can go as deep as we want and we can learn from our clients and improve our resource over time. This allows our own teams to focus on the custom work. Explains the mechanism by which depth becomes affordable — write once, reuse everywhere, and human time shifts to the custom work that actually needs it. ### AI documentation configuration improves through iteration, not instantly > [!quote] ID:rw_atom3 > really evolved with the work. And this is a super important part. No one is going to just create an assistant and it's just going to do what you need. It's going to be a process. The process doesn't take a long time, but it is a process. From the "how we built it" methodology section, right before describing the topic-by-topic feedback loop used to refine the assistant's configuration — an honest admission that the first configuration wasn't good enough. ### Never invent settings — missing info stays missing > [!quote] ID:rw_atom4 > it, it stays missing. Anything that we don't provide stays missing. The assistant doesn't fill in blanks. It will ask for more information. It'll flag gaps if they're there or it'll straight up omit, but never would it go off on its own and make assumptions. The single most important guardrail for controlling hallucination in the documentation assistant — directly reusable for any AI-assisted content pipeline. ### Training belongs in the tools people already use, not just as a deliverable > [!quote] ID:rw_atom5 > And that leaves me with a thought that I want to leave you all with. Training doesn't have to be just a deliverable. It can be built into the tools, the workflows, and the resources that people use every day. The talk's explicit closing takeaway, stated immediately before the call to action asking the audience to look at their own client support and training. Already promoted to a Permanent Note (see below). ## Permanent candidates - Atoms 1 and 5 were already promoted into [[3. Resources/Permanent Notes/Training as a System Compounds Where a Session Decays]] — no new Permanent Note needed here. - Atom 4 (never-invent-settings guardrail) overlaps closely with the vault's existing [[3. Resources/Permanent Notes/AI Documentation Pipelines Need an Explicit Authority Source]] — that note already covers this claim; this atom is evidence for it, not a new candidate. - Atom 2's "shared documentation trades upfront cost for compounding savings" framing was flagged in the source's own refactor appendix as a second candidate but reads as a restatement of atom 1's thesis rather than a distinct claim — stays at the literature level under the resonance filter. - Atom 3 (iterative configuration) stays as a literature-level process note — true and useful, but procedural rather than a durable general claim. ## Processing checklist - [ ] Confirm this note is linked from the DevRel MOC - [ ] Cross-check whether a "DevRel programs take years" or similar existing permanent note already covers the durable-system-vs-event framing, and link/differentiate if so - [ ] Review Learn Modern Press (learn.tri.be) directly for structural inspiration applicable to WPOCC or personal documentation projects