Building Training Systems, Not Sessions | Andrew Adam  🔗 **Source:** [Building Training Systems, Not Sessions | Andrew Adam](https://www.youtube.com/watch?v=FKfdL7sK6Og) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Building Training Systems, Not Sessions | Andrew Adam > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [References](#-references) - [Summary](#-summary) - [Main Content](#-main-content) - [References (Primary Sources)](#-references-1) - [Paraphrase](#-paraphrase) - [Newsletter](#-newsletter) - [Action Items](#-action-items) - [Hypotheses](#-hypotheses) - [Methodology](#-methodology) - [Questions](#-questions) - [Future Research](#-future-research) - [Implications](#-implications) - [Learning Styles Assessment](#-learning-styles-assessment) - [Accessibility Assessment (WCAG 2.2 AA)](#-accessibility-assessment-wcag-22-aa) - [DEIB Assessment](#-deib-assessment) - [Logical Validity](#-logical-validity) - [DARVO Analysis](#️-darvo-analysis) - [Conclusion](#-conclusion) - [Refactor Appendix](#-refactor-appendix--building-training-systems-not-sessions--andrew-adam) ### 🔗 References - Andrew Adam — QA engineer, Modern Tribe by Nexus (speaker) - Modern Tribe / Nexus — the agency behind the "Modern Press" internal WordPress framework - Modern Press — Modern Tribe's internal WordPress framework (custom themes, plugins, blocks layered on core) - Learn Modern Press (learn.tri.be) — the shared training resource showcased in the talk - WordPress.org documentation — named as a trusted, allowed source for the AI assistant - Learn WordPress — named as an existing general WordPress learning resource the talk positions against - ChatGPT (custom GPT) — early tool used to build the documentation assistant - Claude (Claude Project) — the tool the team migrated to for the documentation assistant - Yoast, RankMath, Redirection — named plugins flagged as future documentation targets - WooCommerce — named as a future documentation target (e-commerce coverage) ## 📝 Summary - **What happened**: Andrew Adam (QA engineer, Modern Tribe by Nexus) gave a WordCamp talk on why one-time client training sessions fail to produce lasting competence, and how his team built "Learn Modern Press," a shared, AI-assisted documentation system covering ~100 guides for their internal WordPress framework (Modern Press). - **Why it matters**: The talk reframes training as infrastructure rather than an event — a durable, maintainable knowledge system that scales across client projects instead of being re-created (and re-forgotten) per engagement. It's a concrete, reproducible case study of AI-assisted technical documentation with strong guardrail design. - **Stakeholders**: Agency training/support/QA teams, client-facing editorial teams, WordPress agencies running multi-client custom frameworks, clients/end-users learning WordPress, WordPress Training and Community teams interested in scalable education models. - **Risks**: Over-reliance on AI-authored documentation without adequate human review; risk of "confirmed sources only" guardrails being loosened over time; maintenance debt if the two-person team scales client load faster than upkeep capacity; documentation drift if the underlying Modern Press framework changes faster than the review cycle. - **Bottom line**: A shared, foundational documentation system — authored by humans, drafted and scaled with a carefully guardrailed AI assistant — reduces repeated, inconsistent one-off training while freeing human experts to focus on project-specific and custom-feature support. ## 📖 Main Content ### 🗒️ Notes *(No timestamps are present in the captured transcript — video is not chaptered/timestamped in the source. Structure below follows the talk's own segment order.)* **1. The problem with one-time training** Adam opens by noting that training success at launch is deceptive — clients "don't know what they don't know" until they're actually working in the site. Questions surface days, weeks, or months later. He identifies the core issue as fragility: any single-format training (docs, live sessions, recordings) has limited depth, absorption is capped, and guidance goes stale the moment WordPress, the built site, or client workflows change. Client team turnover compounds this — new hires inherit the site but not the training context, forcing re-training. Consequences: underused features and content/accessibility drift from the design system. **2. From sessions to systems** Adam's proposed reframe: document the *foundational* guidance that repeats across every client project once, and do it deeply — freeing the team to focus human time on custom, project-specific work. He argues the timing is right because (a) WordPress's block/site editor has matured and is unlikely to require constant doc rewrites, and (b) AI is now capable enough to make building such a system practical even for a small team. He explicitly distinguishes this from existing general resources (WordPress.org docs, Learn WordPress) — those teach WordPress in general, not a specific agency's *implementation* of it, which is what clients actually need. **3. Showcase: Learn Modern Press** The team's public resource (learn.tri.be) covers ~100 guides spanning both core WordPress and their custom "Modern Press" framework, deliberately blurring the core/custom distinction so clients experience "one system." Content spans: WordPress basics and publishing foundations (navigation, editor workflows, post types vs. custom post types, taxonomies, user roles/administration); deep overviews of major systems (block editor, site editor, navigation, templates, patterns — with safety warnings on higher-risk areas); and deep block-level documentation (settings plus *when* to use a block and content rules, e.g., capping columns at four). Shared cross-block topics (dimensions, animations, borders/shadows) are documented once and cross-referenced to avoid duplication. Walkthrough videos accompany most guides, chosen because documentation serves deep lookup while video serves initial learning. **4. Accessibility as a first-class thread** Two-pronged approach: (a) accessibility guidance embedded contextually throughout normal docs (heading hierarchy inside the heading-block doc, alt text inside the image-block doc) so users discover it at the point of relevance; (b) a dedicated "accessible content" section going deeper, including a publishing checklist and guidance on screen readers and keyboard navigation. **5. Extending into project delivery** The resource also absorbed the team's User Acceptance Testing (UAT) process and worksheets — previously built per-project — so ~80% of UAT guidance can now simply be referenced rather than recreated, saving time and familiarizing clients with a tool they'll use long-term. **6. The three-layer model** Layer 1: shared foundation (Learn Modern Press itself). Layer 2: project-specific guidance/training sessions (still necessary, but now a smaller share of total effort). Layer 3 (exploratory/in development): in-context support — surfacing shared docs directly inside the WordPress editor sidebar (non-AI, just contextual linking/video snippets), an AI chat assistant grounded in the trusted resource, and a longer-term AI-assisted page/section builder. **7. How it was built — planning** Two people, roughly a month, part-time. They mapped 100+ topics, built categories, deliberately split out shared/duplicated topics early, grouped rarely-used one-off blocks (terms, author, post-date) into the workflows where they naturally appear (e.g., post templates) rather than giving them standalone pages, and prioritized starting with *easier* topics to learn the documentation structure before tackling harder ones. **8. AI assistant configuration** Core configuration elements: an established assistant role, context about how WordPress works with the Modern Press framework, voice/tone/formatting rules (reused from an existing assistant), governance/decision rules (when to ask for more info, what never to assume), multiple "response modes" for different audiences, and attached reference files — baseline templates per doc type, "gold standard" example docs, and a running content map (a markdown sitemap of every published topic with category/audience context). Adam stresses the content map's size directly correlated with output quality. **9. Iteration and guardrails** The configuration was not good on the first attempt — quality "evolved with the work" through a feedback loop: draft → human review/edit → decisions fed back into the *assistant's own* proposed configuration changes (several ideas, including template flexibility and the "response modes" file, originated from the assistant itself, not the humans). Early sessions covered multiple topics for context-building; later, one topic per session became standard once the config stabilized (~10 blocks in). The most important guardrail: only use confirmed sources (client-provided notes, WordPress.org docs, explicitly approved references) — the assistant is instructed to never invent settings, labels, or paths; missing info stays missing, flagged as a gap, rather than fabricated. Human review remained mandatory throughout ("we're still going to find little opportunities to tighten things up"). **10. Editorial workflow and tooling** Workflow: source notes (often just bullet points) → Google Docs → AI draft → human revision loop (six-to-seven rounds early on, down to zero-to-one rounds later) → publish → video afterward (documentation shipped first so video production didn't bottleneck it). Markdown was flagged as a key enabler — portable across the AI tool, Google Docs, and WordPress without reformatting friction. **11. Maintenance** Two main update triggers: internal Modern Press framework change/scope notes, and WordPress core release notes/field guides. Both get fed to the assistant, which flags which existing docs likely need updates; humans then update each flagged topic individually — AI accelerates identification and drafting, but "people still own it." Adam reports maintenance after a couple of WordPress releases has been manageable at roughly 2–3 hours of follow-up work per release. **12. Closing thought / Q&A** Adam's stated takeaway: "training doesn't have to be just a deliverable" — it can be embedded into the tools and workflows people already use. Audience Q&A covered: topic selection wasn't formally driven by client FAQ data (informed by team experience instead); the resource is new/early in client rollout with positive initial reaction, biggest uptake so far from onboarding new team members at existing clients; the assistant runs as a straightforward Claude Project (migrated from an earlier custom GPT) with no developer/infrastructure build — hallucination control came almost entirely from the "confirmed sources only, never invent settings" rule; ongoing maintenance load is considered manageable for their team size; next documentation targets are plugins (Redirection, Yoast, RankMath) and WooCommerce/e-commerce. ## 📚 References - **Learn Modern Press** (learn.tri.be) — the primary source/case study referenced throughout; named directly and described as public. - **WordPress.org documentation** — named explicitly as a trusted, pre-approved source the AI assistant is permitted to draw from. - **Learn WordPress** — named explicitly as an existing general-purpose WordPress education resource, used as a contrast case ("these resources teach WordPress... but they don't teach our sites"). - **Claude (Claude Project)** and **ChatGPT (custom GPT)** — named as the two AI tools evaluated/used to build and run the documentation assistant. - General mentions (not deeply sourced): WordPress core release notes and field guides; internal Modern Tribe developer/scope notes. ## 🗣️ Paraphrase Andrew Adam argues that agencies training clients on custom WordPress builds tend to over-invest in one-time events — launch-week sessions, static docs, recorded walkthroughs — that inevitably decay because WordPress, the site, and the client's team all keep changing after the training ends, leaving new hires undertrained and features underused; his proposed fix is to stop treating training as a deliverable and start treating it as a system, meaning a shared, continuously maintained knowledge base that documents the foundational, repeatable parts of an agency's own custom framework once and in depth, freeing human experts to spend their limited time on the genuinely custom, project-specific problems that actually need a live human; he illustrates this with his own team's resource, Learn Modern Press, roughly 100 guides plus companion videos covering both core WordPress and their internal "Modern Press" framework as one undifferentiated system, extending even into their client UAT process, and layered with an emerging third tier of in-editor, AI-mediated support; the more interesting part of his talk, though, is the mechanics of how a two-person team built and now maintains this at scale using a carefully configured AI assistant — one governed by strict guardrails (only cite pre-approved sources, never invent UI labels or settings, always flag gaps instead of guessing) that was iteratively refined through a human-in-the-loop feedback cycle, where the assistant itself proposed several of the configuration improvements that made the system work, and where ongoing upkeep is now triggered by WordPress release notes and internal framework change logs rather than ad hoc client complaints. ## 📰 Newsletter Your client training doc is going stale the moment you hit publish — and Andrew Adam (Modern Tribe/Nexus) has receipts. His WordCamp talk makes the case for swapping one-off training sessions for a living "training system": one shared, deeply-documented resource (learn.tri.be) covering ~100 guides across core WordPress and his team's custom Modern Press framework, built by two people in about a month with an aggressively guardrailed AI assistant that's forbidden from ever inventing a setting it wasn't told about. The real story isn't the AI — it's the governance: confirmed-sources-only, human review on every draft, and a feedback loop where the assistant itself proposed half the configuration fixes. Training, Community, and Support folks: this is a reusable blueprint for turning "we keep answering the same questions" into an actual asset. Bonus points for baking accessibility guidance directly into block-level docs instead of bolting it on as an afterword. ## ✅ Action Items **Training** - Evaluate building (or piloting) a "shared foundation" doc layer for repeatable WordPress/theme-framework guidance, separate from project-specific/custom training, following Adam's three-layer model. - Adopt the "confirmed sources only / never invent settings, flag gaps instead" guardrail pattern for any AI-assisted documentation generation work. - Consider a markdown-based content map (sitemap + audience/context metadata) as a low-effort way to give an AI documentation assistant system-level awareness. **Community** - Consider whether a public model resource (like Learn Modern Press) could be referenced or cited as a case study in WordPress Training Team or Community Team materials on scalable client/contributor education. - Note the explicit contrast Adam draws between general resources (WordPress.org docs, Learn WordPress) and implementation-specific documentation — relevant to any Community/Training discussion about the limits of generic educational content for custom builds. **Core / Core Performance / Core AI / Core Program Team / Mobile / Playground / Marketing / Support / Design / Documentation / Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins / The WPOCC / FAIR** - Not applicable — talk is agency-specific (Modern Tribe's internal framework and client documentation process) and does not address these subteams' scope directly. ## 🧪 Hypotheses 1. Documentation that is co-authored by an AI assistant configured with a "never invent, flag gaps" rule will contain measurably fewer factual errors (incorrect UI labels/settings/paths) than documentation drafted by the same assistant without that constraint. 2. Client teams given access to a shared, always-current documentation system will submit fewer repeat/basic-tier support questions over time than client teams relying solely on one-time launch training. 3. A documentation assistant's output quality correlates positively with the size/completeness of its reference "content map" (sitemap-style context file). 4. Embedding accessibility guidance contextually within task-specific docs (e.g., alt text inside the image-block doc) produces higher voluntary accessibility compliance from content editors than a single standalone accessibility section. 5. Splitting AI documentation-drafting sessions into one-topic-per-session (post-stabilization) produces more consistent output quality than multi-topic sessions, once a template/config is mature. 6. Tying documentation maintenance triggers to structured external events (WordPress core release notes, internal framework changelogs) produces more reliable upkeep than triggering updates from ad hoc client-reported staleness. ## 📊 Methodology Not an empirical study — this is a practitioner case-study/experience talk. Adam's "evidence" is anecdotal and internal: his team's own before/after workflow observations (e.g., revision rounds dropping from six-to-seven to zero-to-one over time), rough resource sizing (~100 guides, two people, ~one month), and self-reported client reaction ("glowing," described as early/limited rollout with no data yet on usage patterns — explicitly stated as still TBD in Q&A). No controlled comparison, survey data, or usage analytics are presented; claims about effectiveness are experiential rather than measured. ## ❓ 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? - What happens to documentation quality and hallucination rates if a less disciplined team skips the iterative feedback-loop phase and tries to configure the assistant correctly on the first attempt? - How will the team measure whether Learn Modern Press actually reduces repeat support tickets, once client usage data exists (the presenter admitted this is currently unknown)? - Does surfacing documentation directly inside the WordPress editor sidebar (Layer 3) measurably change adoption compared to a standalone resource site? - 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? - How does the model handle documentation for genuinely custom, one-off client features that don't fit the "shared foundation vs. project-specific" split cleanly? ## 🔮 Future Research - A follow-up case study once Learn Modern Press has enough usage/telemetry data to report actual support-ticket reduction, client engagement patterns, or time-to-competence metrics. - Comparative study of AI-assisted vs. traditionally-authored technical documentation for hallucination rate, factual accuracy, and staleness over a matched time period. - Investigation into the "assistant proposes its own configuration improvements" pattern Adam describes — is this reliably reproducible with other LLMs/tools, and how does a team validate that AI-suggested config changes are sound before adopting them? - Study of the AI-assisted in-editor chat/builder (Layer 3) once it moves out of exploratory status — adoption, trust, and error rates for AI-generated pages/sections grounded in a documentation corpus. ## 💡 Implications - **Practice**: Agencies running repeatable custom WordPress frameworks across many clients have a plausible, resource-light model (two people, ~1 month) for converting scattered per-project training into durable shared infrastructure — the guardrail-and-feedback-loop pattern described is directly reusable. - **Policy**: Suggests agencies should formalize "confirmed sources only" governance for any AI-assisted client-facing content, not just documentation, given the acknowledged early hallucination problem before guardrails were tightened. - **Education**: Reinforces a documentation-plus-video dual format (deep reference vs. onboarding) as complementary rather than redundant — relevant to WordPress Training Team content design. - **Funding/resourcing**: Demonstrates a plausible ROI case for agencies to invest small, dedicated team time (not full engineering builds) into documentation systems rather than continuously re-running live training — relevant to internal budgeting conversations about support/training headcount. ## 🧠 Learning Styles Assessment - **Visual** — Strong: Live slide deck (implied, screenshots/showcase of the resource), plus explicit mention of walkthrough videos accompanying most guides. - **Aural** — Moderate: The talk itself is a spoken presentation with Q&A, but the source captured here is transcript-only (no visual/audio delivery cues retained). - **Verbal** (reading/writing) — Strong: The core deliverable discussed (Learn Modern Press) is a text-based documentation system; the talk itself is dense with structured verbal explanation. - **Kinesthetic** — Weak: No hands-on exercise, live demo, or interactive component in the talk itself (explicitly stated: "we're not doing a live demo"). - **Logical** — Strong: Talk is structured around a clear problem → reframe → system → mechanics → guardrails → results progression with explicit cause-effect reasoning throughout. - **Social** — Moderate: Includes a live Q&A segment with real audience exchange, and the underlying subject (client training) is inherently relational, but the talk is a one-to-many lecture format. - **Solitary** — Strong: The described documentation system itself is designed for self-paced, independent client learning ("work more confidently and independently"). - **Naturalistic** — Weak: No content relating to pattern recognition in natural/physical systems; not applicable to this subject matter. - **Reading level estimate**: Approximately Grade 9–11 (conversational professional register, industry jargon like "block editor," "site editor," "taxonomy," "UAT" assumed familiar to a WordPress-practitioner audience). ## 📊 Accessibility Assessment (WCAG 2.2 AA) - **Text alternatives**: Not assessable from transcript alone — original video/slide alt-text and captioning quality can't be verified from this captured source. - **Adaptable / reflow**: Not applicable to this transcript-based analysis — pertains to the video platform's/Reader's own rendering, not the talk content. - **Distinguishable**: Not assessable — no visual/contrast data available from transcript. - **Predictable navigation**: Not applicable — single-video source, not a multi-page navigable resource. (Notably, the talk's *subject*, Learn Modern Press, reportedly includes navigational/categorization structure, but that resource itself wasn't audited here.) - **Input assistance**: Not applicable — no form or interactive input in this source. - **Time-based media**: A transcript was captured and is the basis of this entire analysis, confirming caption/transcript availability for this video. No indication of a separate synchronized-caption track (SRT/VTT) or audio description being reviewed; only the plain transcript was available in Reader. - **Compatible / parsing**: Not applicable to transcript content — pertains to underlying HTML/ARIA structure of the original video page, not assessed here. - **Content-level note**: The talk itself models good accessibility practice by discussing WCAG-relevant guidance (heading hierarchy, alt text, screen reader/keyboard navigation) as a running thread within its own documentation case study — a positive, if secondhand, signal. ## 🌍 DEIB Assessment - **Cultural breadth**: Narrow — talk is scoped entirely to one U.S. agency's internal process; no international, multilingual, or cross-cultural training considerations are raised. - **Inclusive language**: Neutral/professional throughout; no exclusionary language observed. Client-facing language philosophy (avoiding jargon, "editor-friendly guidance" over "technical guidance") reflects an inclusive instructional design instinct, though framed as a business goal rather than an explicit DEIB goal. - **Neurodiversity support**: Not directly addressed, though the dual documentation-plus-video format and the "flag gaps, don't guess" AI guardrail indirectly support varied processing styles and reduce cognitive load from inconsistent information. - **Representation**: Single presenter, single company case study; no diversity of contributor voices, client demographics, or team composition discussed. - **Psychological safety**: Not a focus of the talk's content, though the "human review is still required" stance and explicit crediting of the AI assistant's own configuration suggestions reflect a collaborative, non-defensive posture toward the tooling — a mild positive signal but not a DEIB-specific one. ## ✅ Logical Validity - **Strong reasoning present**: The problem framing (training decays because the underlying system keeps changing) is well-supported by specific, concrete failure modes (client turnover, feature underuse, accessibility drift) rather than vague assertion. The build methodology section is unusually transparent about iteration, including admitting the initial AI configuration "was not good enough" — this is honest, falsifiable-sounding reporting rather than a polished success narrative. - **Named fallacies**: - *Hasty generalization (mild)*: Adam extrapolates "our clients love it" and "reaction has been glowing" from what he himself describes as an early, small rollout with no usage data yet — presenting anecdotal early reaction as validation of the model's success. **Fix**: Caveat the claim explicitly as preliminary/anecdotal until usage/support-ticket data exists (which, to his credit, he does partially do in the Q&A when pressed). - *Survivorship framing (mild)*: The talk describes what worked in the final configuration without equally detailing the failed intermediate attempts (e.g., "it wasn't great" for the first configuration is mentioned but not detailed) — this can make the process look more linear/replicable than it likely was. **Fix**: A companion "what didn't work" section would strengthen the case study's practical value for imitators. - **Tone of voice**: Practitioner-conversational, self-deprecating at points ("I'm going to keep going" — acknowledging talk length), transparent about limitations and unknowns rather than purely promotional; reads as an honest field report rather than a sales pitch, despite showcasing a proprietary resource. ## 🛡️ DARVO Analysis Not applicable — no accusation, conflict, or defensive dynamic exists in this source. The talk is a straightforward practitioner case study/how-to presentation with no adversarial context; DARVO (Deny, Attack, Reverse Victim and Offender) requires a response to an accusation of wrongdoing, which is absent here. ## 🎯 Conclusion - **Bottom line**: Andrew Adam presents a credible, resource-light blueprint for converting fragile, one-time client training into a durable "shared training system" — documenting an agency's repeatable framework once, deeply, and using a tightly guardrailed AI assistant (confirmed-sources-only, never-invent-settings, human-in-the-loop feedback) to make that scale achievable for a two-person team in about a month. - **Practical next steps**: 1. For agencies with a repeatable custom framework: map recurring topics, split shared vs. one-off content, and start with the easiest topics to validate documentation structure before scaling up. 2. Configure any AI documentation assistant with explicit source-confirmation and no-invention rules from day one, rather than discovering the need after hallucination problems surface. 3. Treat the assistant's own configuration suggestions as a legitimate input — the iterative human-AI feedback loop was itself credited as a key success factor. 4. Tie maintenance triggers to structured external signals (release notes, internal changelogs) rather than waiting for staleness to be noticed by clients. ## 🔄 Refactor Appendix — Building Training Systems, Not Sessions | Andrew Adam > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] 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. **Context & use**: Appears at the pivot point of the talk, right after the problem framing (training decay, client turnover) and just before the resource showcase. This is the talk's core reframe and thesis statement. **Tags**: #bmf **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] 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. **Context & use**: Follows Adam's definition of a "shared training system" — explains the mechanism by which depth becomes affordable (write once, reuse everywhere, freeing time for custom work). **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] 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. **Context & use**: Mid-talk, during the "how we built it" methodology section, right before describing the topic-by-topic feedback loop used to refine the AI assistant's configuration. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] 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. **Context & use**: In the guardrails section, describing the single most important rule for controlling hallucination in the AI documentation assistant. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H5] 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. **Context & use**: The talk's explicit closing takeaway line, stated immediately before the call to action asking the audience to look at their own client support/training. **Tags**: #bmf **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### Shared documentation systems trade upfront authoring cost for compounding support savings **Claim**: A single, deeply-documented shared foundation layer reduces an agency's repeated per-client training cost over time by letting human effort concentrate on genuinely custom work instead of re-explaining the same fundamentals. **Evidence pointer**: rw_atom2 (H2 — "document them once... go much deeper") **Scope & conditions**: Applies specifically to agencies/teams running a consistent, repeatable underlying framework or toolset across multiple clients or engagements — not applicable to fully bespoke, one-off builds with no shared foundation. **Links**: - [[3. Resources/Literature Notes/A DevRel-Led Funnel That Puts Developers First - Literature Note]] — because applies-in the same "build the reusable foundation once, let it compound across many audiences" logic used in DevRel funnel design (target confirmed 2026-09-05: Leon Adato, HackerNoon). <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - Compare Adam's "confirmed sources only / never invent" AI guardrail pattern against other DevRel/documentation AI workflows already logged in the vault — is this pattern already captured elsewhere, or novel to this source? - The "assistant proposes its own configuration improvements" loop (templates, response-modes file both credited to the AI itself) is an interesting meta-pattern worth flagging for a future note on human-AI collaborative tooling design. ### → Things 3 (max 2 actions) - [ ] Review Learn Modern Press (learn.tri.be) directly for structural/UX inspiration applicable to WPOCC or personal documentation projects. - [ ] Cross-check whether DevRel-programs-take-years permanent note already covers the "training as durable system vs. one-time event" framing — link or differentiate during synthesis pass. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Building Training Systems, Not Sessions Andrew Adam.md|Building Training Systems, Not Sessions | Andrew Adam by Andrew Adam]] ## Highlights - '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. We're not building the same websites. We're building custom websites, but our teams can now focus on supporting our clients where they need it the most quite often with those custom features. ' ([View Highlight](https://read.readwise.io/read/01m0arzcnqy1smef8wfyw94frk)) - Note: Mechanism: document shared foundations once so human time shifts to custom work. - Tags: atom/literature/h1 - '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. Shared in the sense that it applies to all of our clients and scalable in the sense that we can improve it, expand it and adapt it for our specific client's custom needs. ' ([View Highlight](https://read.readwise.io/read/01m0arz39ztf7gjraysq4trpr8)) - Note: Core thesis: reframing training from a one-time session to a durable system. - Tags: atom/literature/h1 - '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. So, we started with a few simple topics. We chose a simple block, a bit more complex block, and a custom block. Working through these helped us establish the structure and the depth of the documentation that we were looking for. And we did this with a feedback loop. This is a key part. The AI ' ([View Highlight](https://read.readwise.io/read/01m0arzpz9a51rt65yrz149z53)) - Note: AI assistant configuration quality improved iteratively, not on first attempt. - Tags: atom/literature/h1 - '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. This was helpful for our workflow, but there were times that we wanted more and we would just ask the agent for guidance. And as our configuration and documentation evolved, the answers we would get back were also much more helpful. Even still, with all of these ' ([View Highlight](https://read.readwise.io/read/01m0as015qexmhyaqxetayckjn)) - Note: Key hallucination-control guardrail: never invent settings, flag gaps instead. - Tags: atom/literature/h1 - 'and maintainable. 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. If there's one thing that I hope you take away from this talk is to just look internally at your own support for your clients and the training that you offer and consider if AI opens opportunities. What does it ' ([View Highlight](https://read.readwise.io/read/01m0as0aqmc21payzasy48c3jm)) - Note: Closing takeaway line: training belongs in the tools people already use. - Tags: atom/literature/h1