The Community Mixboard: A Simple Community Design Tool  🔗 **Source:** [The Community Mixboard: A Simple Community Design Tool](https://davidspinks.substack.com/p/the-community-mixboard-a-simple-community) > [!note]+ Document Notes > tags: [community-design, community-strategy, community-building, facilitation, emergent-systems] > author: davidspinks.substack.com > source: substack.com > reference: https://davidspinks.substack.com/p/the-community-mixboard-a-simple-community > date created: 2026-09-08 > > > [!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: The Community Mixboard: A Simple Community Design Tool > <!-- deep-read:sections start --> ## 📝 Summary - Core argument: community design decisions (structure, cadence, barrier to entry, challenge intensity, and others) aren't binary or "correct" — they're sliders on a spectrum, each with real tradeoffs, and the "right" answer is always "it depends" on what the community's founder is trying to create. - The named tool — "The Community Mixboard" — is a visual (a set of labeled sliders, e.g. Structure: loose↔tight, Cadence: daily↔occasional, Barrier to Entry: low↔high, Challenge: gentle↔aggressive) the author uses in client strategy work, in a workshop ("Emergent Community Design"), and offers as a blank fill-in-yourself template. - Provenance: the author credits Wes Kao's Maven course as the origin of the "mixboard" framing, applied to community design specifically for the author's own workshop. - Central framing device: "emergent community design" — the premise that you don't build a community directly, you build a container and community has a chance to emerge inside it; the sliders describe how the container is tuned, not the outcome itself. - Risk named explicitly: harm comes not from where a slider sits, but from being unconscious of where it's set, or from a mismatch between stated intention and actual sliders ("This is a community where everyone has an equal voice!" while the founder retains final say). - Bottom line: the mixboard is a diagnostic/design conversation tool, not a scoring rubric — its value is making implicit design choices explicit and revisable, and the author frames sliders as needing continuous re-tuning as a community matures, not a one-time setup. ## 📖 Main Content The piece opens with a specific anecdote — a strategy call with a founder asking a cluster of common launch questions (pricing, live vs. async, growth pace, founder-centrality, entry barrier) — and uses the author's own admitted "underwhelming answer" ("It depends") as the setup for introducing the mixboard as a way to make that answer useful rather than dismissive. **What the mixboard is.** A visual borrowed in concept from Wes Kao's Maven course (an audio-mixing-board metaphor), adapted specifically to community design variables. The author names it as a working tool used in two contexts: client engagements during the design phase of a new community program, and as an audit tool for visualizing an *existing* community's dynamics. It was built for the author's "Emergent Community Design" workshop and, per the article, was a standout slide there. Named sliders discussed in the body: Structure (loose ↔ tight), Cadence (daily ↔ occasional/less frequent), Barrier to Entry (low ↔ high/curated), and Challenge (gentle ↔ aggressive/brutally honest feedback). The post states a blank, fillable version exists at the end of the piece and as a downloadable PDF worksheet — neither the visual itself nor the worksheet's actual content is present in this text-only capture (see Accessibility Assessment and Learning Styles Assessment for what that means for a Reader-first version of this piece). **The emergent-design premise.** The article's structural claim: "we don't build communities; we build containers where community has a chance to emerge." This reframes every slider position as an indirect lever — moving Structure right doesn't produce a specific outcome, it changes the odds of what might emerge and forecloses other possibilities (the tradeoff named explicitly: tighter structure → more predictable outcomes, less room for spontaneity). The author extends this to describe how outcomes can invert expectations: adding rules to improve behavior can provoke rebellion instead; removing structure to enable creativity can instead produce paralysis from lack of scaffolding. The stated response to this unpredictability isn't more control, it's treating slider placement as a hypothesis to test, not a lever with a guaranteed output. **Not everything is a spectrum.** The article draws an explicit boundary around the slider metaphor: business model, legal structure, and platform choice are framed as menu selections, not sliders — discrete choices rather than continuous ones. Crafting a purpose, defining an ideal community persona, and designing the specific member experience are named as creative exercises rather than either sliders or menu items, with a pointer to the author's separate "7Ps of Community" framework (linked, hosted at cmxhub.com) for those. **Where harm comes from.** The article is specific that no slider position is inherently good or bad — "big" isn't better than "small," "one-off" isn't worse than "long-running." Harm is located specifically in *unconsciousness*: not knowing where your sliders actually sit, or a gap between the stated design ("everyone has an equal voice") and the actual one (founder retains final say, or is uncomfortable enough with losing control to unconsciously undermine members' own initiative). The prescribed fix is explicit, legible design choices communicated clearly enough that members can self-select in or out — framed as harm reduction through transparency rather than through picking "correct" slider values. **Sliders move over time.** The closing third of the piece extends the metaphor from a one-time-setup mixing console to a live DJ set — "you don't just choose one mix for a song and leave the sliders where they are." Structure that's needed early (to establish norms) can be loosened once norms become habit; barrier to entry set intentionally low or high at launch can shift as the founder senses the community wants to grow; a stiff community can get more play deliberately dialed in. The author also names a distinct dynamic: sometimes the community itself starts moving a slider (unprompted growth pressure, a push for more/less structure), and the facilitator's job is choosing whether to let that happen or hold the container at its original setting. **Closing framing and CTA.** The piece ends by returning to the opening anecdote — the founder call ended with the founder having "clear answers... not because I told her what to do, but because she could see there is no one right way to do this" — positioning the mixboard as a clarity tool, not a prescriptive one. The post closes with prompts for readers to use with their own blank mixboard (why here, what I hope emerges, what this might prevent), an invitation to share completed mixboards by email, and a soft pitch for the author's 1-1 and group coaching offerings linked to a personal site. ## 🗒️ Notes Dense notes without timestamp subheadings (this is an article, not a transcript). - The mixboard's actual slider count and full label set aren't fully enumerable from this capture — the piece names four sliders in worked examples (Structure, Cadence, Barrier to Entry, Challenge) but references "sliders" plurally throughout in a way that implies the visual has more than these four; the image itself (not present in this text capture) would be needed to get the complete list. - The "Warm Demander" concept, credited in the article to the author's wife (a middle school teacher), is presented as an illustrative example of the general point that most design tensions have a middle-ground answer rather than a binary one — it isn't itself a mixboard slider, but functions as supporting evidence for the "spectrum, not binary" thesis. - The piece explicitly separates three categories of community-design decision: spectrum/slider (Structure, Cadence, Barrier to Entry, Challenge), menu/discrete (business model, legal structure, platform), and creative/generative (purpose, persona, member experience — deferred to the linked 7Ps framework). This three-way split is a stronger organizing structure than "everything is a slider," and is easy to miss on a skim. - No data, survey, or case-study evidence is cited anywhere in the piece — every claim is presented as the author's practitioner experience (workshop delivery, client calls) rather than research. This is consistent with the newsletter's format (a practitioner essay, not a research piece) but worth flagging plainly rather than implying rigor the source doesn't claim for itself. ## 📚 References - [How communities emerge (prior post, self-referenced)](https://davidspinks.substack.com/p/how-communities-emerge) - [Wes Kao — Substack profile](https://open.substack.com/users/4005715-wes-kao?utm_source=mentions) - [Maven](https://maven.com/) - [What is emergent community design (prior post, self-referenced)](https://davidspinks.substack.com/p/what-is-emergent-community-design?triedRedirect=true) - [The 7Ps of Community](https://www.cmxhub.com/blog/the-7ps-of-community) - [Community Mixboard PDF worksheet (Google Drive)](https://drive.google.com/file/d/1kJ6ln2mDjMFnWgtBXIkZd7PwX2CqI56V/view?usp=sharing) - [Contact (email link)](https://www.davidspinks.com/contact) - [DavidSpinks.com](http://davidspinks.com) Checked via `paras2.py --links` before writing this section. Of 14 raw link matches, 6 are the post's own inline embedded images (Substack CDN image-fetch URLs, not citations) and are excluded above; the remainder are almost entirely self-referential (two prior posts by the same author, the author's own contact page and site) or promotional (the coaching pitch). The only genuinely external, non-self citations are Wes Kao/Maven (the acknowledged source of the "mixboard" concept) and the 7Ps of Community piece on cmxhub.com. This is a practitioner essay with light external sourcing, not a research-backed piece — worth naming plainly rather than implying broader citation than exists. ## 🗣️ Paraphrase - Community design choices — how structured, how frequent, how open, how intense — aren't right-or-wrong; they're sliders with real tradeoffs, and harm comes from setting them unconsciously or from a gap between what you say the community is and how you're actually running it. - You don't design a community once; you tune it continuously, the way a live producer rides the sliders through a song rather than setting them once at the start. ## 📰 Newsletter A useful reframe for anyone running a Discord, a Slack community, a WordPress meetup program, or a contributor cohort: David Spinks' "Community Mixboard" treats structure, cadence, barrier to entry, and challenge intensity as sliders with tradeoffs, not right answers. The line worth sitting with: harm doesn't come from where you set the dial, it comes from not knowing where it's set, or promising "everyone has an equal voice" while quietly keeping final say. Worth 5 minutes for anyone designing or auditing a community program, including WordCamp organizing teams and open-source contributor onboarding. ## ✅ Action Items #### DevRel - Apply the four named sliders to an existing or planned developer community program (a contributor Slack, an ambassador cohort, office hours) as an explicit design/audit exercise — the article frames this as useful both for launch design and for auditing something already running. - Use the "unconscious slider vs. stated intention" framing as a check on program messaging: does the program's stated openness/voice match its actual moderation and decision-making structure? #### OSPO Not applicable to this source — no license, governance-charter, or compliance content; the framework is about program design tone, not policy structure. #### Community - Run the mixboard exercise (Structure, Cadence, Barrier to Entry, Challenge, plus any others surfaced by the linked visual) as a facilitated conversation with a community team before launching or relaunching a program, per the article's stated client-engagement use case. - Treat slider positions as revisable rather than fixed at launch — the article's DJ-console framing argues explicitly against a "set once" mental model, which maps directly onto reviewing community program settings (moderation strictness, entry requirements, event cadence) on a recurring cadence rather than only at launch. #### WordPress - The framework generalizes to WordPress community structures worth naming explicitly: Structure maps to how tightly a contributor team's workflow is defined (Trac/GitHub process rigor vs. informal collaboration); Barrier to Entry maps to how contributor onboarding is gated (good-first-issue programs vs. open commit access); Cadence maps to release/meeting rhythm (weekly team chats vs. async-only coordination) — useful as a lightweight lens for reviewing a WordPress core team's or a meetup group's current operating norms. #### The WPOCC - The mixboard is a plausible facilitation tool for The WPOCC's own program design work — using it to make explicit, and periodically revisit, where funding transparency, fellowship structure, and grantee autonomy sliders currently sit, rather than treating those as fixed at program launch. #### FAIR Not applicable to this source — no technical governance, provenance, or covenant content; the framework addresses interpersonal/program design, not infrastructure. ## 🧪 Hypotheses 1. Communities whose stated values (in onboarding copy, community guidelines) diverge measurably from their actual operating norms (moderation strictness, founder decision authority) show higher member churn or lower trust-survey scores than communities where stated and actual norms match, regardless of which specific slider values are chosen. 2. Community programs that revisit their structural settings (barrier to entry, cadence, structure) on an explicit recurring cadence outperform ones that set them once at launch and leave them static, on member-reported satisfaction or retention. ### 📊 Methodology - Hypothesis 1: code a sample of community guidelines/onboarding docs for stated openness/voice claims, separately code actual decision-making structure (who has final say, documented or observed), and correlate the gap size against available churn or satisfaction survey data. - Hypothesis 2: compare retention or engagement metrics across communities that document periodic program-design reviews (changelog of policy/structure changes) against those with no evidence of post-launch structural revision, controlling for community age and size. ### ❓ Questions - What is the full slider set on the actual Community Mixboard visual — this capture confirms at least four (Structure, Cadence, Barrier to Entry, Challenge) but the prose implies more are shown in the image itself. - How does the author's own "7Ps of Community" framework (linked, for the menu/creative-choice categories) relate structurally to the mixboard sliders — are they meant to be used together in a single workshop, or are they separate tools for separate design phases? - Is there any published before/after case study of a community that used the mixboard and changed a specific slider, with a measurable outcome — or is the tool's value entirely in the design conversation it prompts, independent of measurable results? ### 🔮 Future Research - A direct comparison of the Community Mixboard against other named community-design frameworks (the article's own 7Ps of Community, or established frameworks like Richard Millington's FeverBee community-design models) would clarify what's novel here versus what's a repackaging of existing practitioner frameworks under a new visual metaphor. - Testing the mixboard as a facilitation exercise with a real WordPress community team (a meetup group, a contributor squad, or a WPOCC program) and documenting what surfaces would validate or complicate the tool's claimed diagnostic value beyond the anecdotal single-founder-call example given here. ### 💡 Implications - For DevRel/community practice: the mixboard offers a shared vocabulary for a conversation ("where's Barrier to Entry set, and is that a deliberate choice?") that's often implicit and undiscussed inside a team — its value may be primarily in forcing that conversation to happen at all, independent of where any slider ends up. - For education/training: the workshop origin ("Emergent Community Design") suggests this is meant to be taught live and interactively, which is a gap if the primary artifact available (this newsletter post) is text/image-only without the workshop's facilitation. - For funding/governance: the "stated intention vs. actual slider position" framing is directly applicable to program transparency work — a useful lens for any grant or fellowship program (including The WPOCC's) auditing whether its own stated values match its actual decision-making structure. ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid grade approx. 8–9 — conversational register, short paragraphs, direct address to the reader, minimal jargon beyond the coined "mixboard" and "emergent community design" terms (both defined in-text). #### 👀 Visual learners - Present: the article is built entirely around a visual (the mixboard image itself, plus a blank fill-in version) — but neither the diagram nor its full slider set is captured in this text-only version. Two large embedded images (1536×1024, per the captured HTML) are almost certainly the filled and blank mixboard visuals, and both carry an empty `alt` attribute (see Accessibility Assessment) — meaning a text-first or screen-reader reading of this piece cannot recover the central artifact the whole essay is built around. - Improve: a text-based enumeration of all slider labels and their two poles (not just the four discussed in prose) would let a non-visual reader use the tool without the image. #### 🔊 Aural learners - Not applicable to this source — text-only newsletter post, no audio version referenced. #### 🗣️ Verbal learners - Present: strong — the DJ/mixing-board metaphor is sustained and extended coherently across the whole piece (setup, application, revision-over-time), and the "container, not community" framing is a clear, reusable definition. #### 🧩 Kinesthetic learners - Present: the closing reflection prompts ("I'm choosing to put the slider here because...") and the offered blank/printable worksheet are direct hands-on exercises. - Improve: since the worksheet itself sits behind an external Google Drive link rather than being inline, a reader working purely from the Reader capture can't complete the exercise without leaving the app. #### 🧠 Logical learners - Present: moderate — the three-way categorization (spectrum vs. menu vs. creative-exercise decisions) is a clean logical structure, though it's introduced late and briefly relative to how much space the spectrum framing gets. #### 🧑‍🤝‍🧑 Social learners - Present: the piece explicitly invites readers to share completed mixboards by email and poses discussion questions at the close, designed to prompt reader response. #### 🧘‍♀️ Solitary learners - Present: the reflection-prompt structure supports independent, self-paced use of the tool without needing a group or facilitator. #### 🌿 Naturalistic learners - Not applicable to this source — no ecological or environmental framing; forcing one would misrepresent the content. ## 📊 Accessibility Assessment #### Screen reader semantics - Present: the article text itself is structured in short, discrete paragraphs that would read cleanly through a screen reader as plain prose. - **Finding**: the captured HTML contains 6 `<img>` elements. Two are large (1536×1024) content images — almost certainly the filled and blank Community Mixboard visuals, which the entire essay is organized around — and both carry `alt=""` with `"alt":null` in the embedded Substack image metadata. The other four images (940×100, ~7KB each) are near-identical dimensions consistent with section-divider graphics and also carry empty/null alt data. None of the six images in this capture have descriptive alt text. #### Keyboard navigation - Not applicable to this source at the content level — this is a static newsletter post; interactive behavior depends on the live Substack template, not the article body captured here. #### Contrast and readability - Not applicable to this source — no styling was captured, only semantic HTML/text; contrast can't be assessed from this capture. #### Text resizing and reflow - Not applicable to this source — not assessable from a text capture without the live page's CSS. #### Media and captions - Not applicable to this source — no audio or video media, only static images. #### Forms and interactions - Not applicable to this source — no forms in the article body (the reflection prompts are prose, not an embedded form). #### Standards reference - The absent/empty alt text on the mixboard visuals — the article's central artifact — maps to WCAG 1.1.1 (Text Alternatives), Level A. This is a materially larger accessibility gap than a decorative image would be: the mixboard image is informational content the essay repeatedly references ("as I move the sliders left and right on the mixboard, I can imagine..."), not decoration, so an empty or missing alt text here leaves a screen-reader or text-only reader unable to access the framework's actual visual layout. ## 🌍 DEIB Assessment #### Cultural breadth - Not applicable to this source — no multi-region or cross-cultural examples; the piece is written from a single practitioner's US-based coaching-client context. #### Inclusive language - Present: gender-neutral throughout when referring to community members and founders generically; the one specific founder in the anecdote is referred to as "she," consistent with a described real interaction rather than an inferred pronoun. #### Neurodiversity support - Present: short paragraphs, a consistent recurring metaphor (mixboard/DJ), and explicit reflection prompts at the end all support chunked, predictable processing — reasonably accessible content structure even though the accessibility of the actual images is a separate, unaddressed gap (see Accessibility Assessment). #### Representation - Present: the piece names a specific "Rabbi Darkside" as a DJ example (a real, named individual, credited positively) and the author's wife (a middle school teacher, uncredited by name) as the source of the "Warm Demander" concept — both are incidental references, not a broader representation strategy. #### Psychological safety - Present: the framing throughout explicitly avoids "correct answer" language ("None of what emerges will be 'better' or 'worse'") and treats founder uncertainty ("It depends") as a legitimate, expected starting point rather than a failure — this is a deliberately low-pressure register for readers who may feel behind on community strategy. ## ✅ Logical Validity #### Strong reasoning - Analogical: the sustained DJ-mixing-board metaphor is used consistently and extended logically (initial setup → live adjustment → community sometimes moving its own sliders) rather than introduced once and dropped, which is a well-constructed analogy relative to typical practitioner-essay quality. - Structural: the explicit three-way split (spectrum decisions vs. menu decisions vs. creative decisions) is a genuinely useful logical distinction that prevents the "everything is a slider" overreach a weaker version of this framework might make. #### Fallacies - **Unfalsifiable framing risk**: "There isn't one right way to do any of this... none of what emerges will be 'better' or 'worse'" is a claim that, taken literally, makes the framework unfalsifiable — any outcome can be retroactively explained as "an emergent result of where the sliders were." This isn't flagged as bad-faith reasoning (it's a common and often reasonable stance in community/facilitation practice, and the article does allow that harm can result from unconscious settings), but it does mean the piece offers no criteria by which a slider choice could be judged wrong in advance, only in hindsight via the unconsciousness/mismatch framing. - No other named fallacies identified — the piece doesn't make causal claims strong enough to be tested against the evidence it provides (it's explicitly presented as practitioner heuristic, not research). #### Tone of voice - Warm, direct, second-person, occasionally self-deprecating ("Yuck, right? No one likes hearing that. So not helpful, Spinks.") — consistent with a newsletter/coaching-adjacent voice aimed at founders and community leads rather than a research or trade-press register. ## 🛡️ DARVO Analysis Not applicable to this source — no accusation, denial, or interpersonal conflict dynamic; this is a practitioner framework essay, not a dispute account. ## 🎯 Conclusion The Community Mixboard reframes community-design decisions as continuously-adjustable sliders rather than one-time binary choices, with the article's most durable insight being that harm comes from unconscious or misrepresented slider settings, not from any particular setting itself. The framework's biggest practical gap in this capture is structural, not conceptual: the tool is fundamentally visual (an image-based diagram and worksheet), and this text-first capture carries no accessible alt text for either the filled or blank mixboard image, so the artifact the entire essay is organized around isn't recoverable from a screen reader or text-only reading of this specific version. ## 🔄 Refactor Appendix — The Community Mixboard: A Simple Community Design Tool > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). Short source (9.6K chars) — 3 atoms, at the floor-to-mid range given the piece is a single sustained framework rather than several distinct claims. ### 📚 Literature Atoms (H3) #### [H1] The Community Mixboard visualizes community design as adjustable sliders > [!quote] ID:rw_01m20gafzjjpdackfa2d82s8st > "A helpful tool for visualizing the different decisions you can make for designing your community, and their tradeoffs, is called 'The Community Mixboard'. I use this with clients when we're in the design phase of creating a new community program, or to audit and get a visual of an existing community's dynamics." Names the article's central artifact and its two stated use cases: new-program design and existing-program audit. Origin credited to Wes Kao's Maven course concept, adapted to community-specific variables (Structure, Cadence, Barrier to Entry, Challenge, and others not fully enumerable from this text capture). Tags: `#atom/literature/h1` #### [H2] Emergent community design builds containers, not outcomes > [!quote] ID:rw_01m20gafzjjpdackfa2d82s8st > "The core premise of emergent community design is that we don't build communities; we build containers where community has a chance to emerge." The structural premise the mixboard sliders operationalize — design choices influence the odds of what emerges without controlling it directly, which is why the article treats slider placement as a hypothesis to test rather than a lever with a guaranteed output. Tags: `#atom/literature/h2` #### [H3] Harm comes from unconscious slider placement, not from any particular setting > [!quote] ID:rw_01m20gafzjjpdackfa2d82s8st > "I think where we tend to cause harm is when we're not conscious of where we're placing these sliders, or when our actions don't match our intentions." The article's clearest ethical claim, and its answer to the unfalsifiability risk noted in Logical Validity: no slider position is inherently good or bad, but a mismatch between stated community values and actual operating structure (e.g., claimed equal voice vs. retained founder control) is where the framework locates real harm. Tags: `#atom/literature/h3` ### 🧠 Permanent Candidates (H4) #### [P1] Program design frameworks should separate spectrum, menu, and creative decisions Not every design decision in a program (community, product, or organizational) belongs on a slider — some are discrete menu choices (platform, legal structure) and some are open creative exercises (purpose, persona) — and conflating all three into "everything is a spectrum" or "everything is a checklist" produces worse design conversations than naming which category a given decision actually belongs to. Links: [[Community Mixboard]] · [[7Ps of Community]] Tags: `#atom/zettel/z1` #### [P2] A program's stated values are only meaningful if audited against its actual decision structure Any program (a community, a grant fund, a governance body) that publishes values language ("everyone has a voice," "fully transparent") needs a periodic, explicit check of whether its actual decision-making structure matches that language — the gap itself, not the specific structure chosen, is what erodes trust and causes harm. Links: [[The Community Mixboard: A Simple Community Design Tool#H3]] · [[Program transparency audits]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - Find or request the full slider list from the actual Community Mixboard visual — this capture confirms only four of what's implied to be a longer list `#atom/fleeting/f1` ### → Things 3 (max 2 actions) - [ ] Run the mixboard's spectrum/menu/creative three-way split as a facilitated exercise for a WordPress community or WPOCC program review `#action/h1` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Community Mixboard A Simple Community Design Tool.md|The Community Mixboard: A Simple Community Design Tool by davidspinks.substack.com]] ## Highlights - A helpful tool for visualizing the different decisions you can make for designing your community, and their tradeoffs, is called “The Community Mixboard”. I use this with clients when we’re in the design phase of creating a new community program, or to audit and get a visual of an existing community’s dynamics. ([View Highlight](https://read.readwise.io/read/01m20gv04979sfmvm2dxb1asnx)) - Note: H1 — names the article's central artifact and its two use cases: new-program design and existing-program audit. #atom/literature/h1 - Tags: atom/literature/h1 - The core premise of emergent community design is that we don’t build communities; we build containers where community has a chance to emerge. ([View Highlight](https://read.readwise.io/read/01m20gv2vdnhrzpzghcznt2fwz)) - Note: H2 — the structural premise the mixboard sliders operationalize: design influences odds, not guaranteed outcomes. #atom/literature/h2 - Tags: atom/literature/h2 - I think where we tend to cause harm is when we’re not conscious of where we’re placing these sliders, or when our actions don’t match our intentions. ([View Highlight](https://read.readwise.io/read/01m20gv5h0dcctg859hs8r3zh2)) - Note: H3 — locates harm in unconsciousness/mismatch rather than in any particular slider setting; the framework's clearest ethical claim. #atom/literature/h3 - Tags: atom/literature/h3