From 0cd97da24a01d5c7aef21db07d07b744379a3eab Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Thu, 17 Sep 2026 18:10:55 -0500 Subject: [PATCH 1/3] Add advocacy and connection layer to creative accessibility path --- docs/ADVOCACY_AND_CONNECTION.md | 163 ++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 docs/ADVOCACY_AND_CONNECTION.md diff --git a/docs/ADVOCACY_AND_CONNECTION.md b/docs/ADVOCACY_AND_CONNECTION.md new file mode 100644 index 0000000..96c3b82 --- /dev/null +++ b/docs/ADVOCACY_AND_CONNECTION.md @@ -0,0 +1,163 @@ +# Advocacy & Connection + +## Purpose + +Advocacy is a continuation of the Creative Accessibility Path, not a separate credential. + +A creator who has made and documented an accessible tool, adaptation, asset, or experiment can help another person find a useful next connection: an artist, game developer, accessibility community, tester, hardware maker, educator, or creative community. + +The basic relationship is: + +**CREATOR → ADVOCATE → DEVELOPER / ARTIST / COMMUNITY** + +The advocate's job is to make a concrete piece of work easier to discover and understand. + +## What an Advocate Does + +An advocate may: + +- identify people or communities for whom a finished artifact could be useful; +- introduce creators to developers, artists, testers, educators, or accessibility communities; +- explain the creative problem and the adaptation without speaking for the creator; +- help prepare a concise portfolio/demo package; +- surface opportunities for playtesting, user research, collaboration, or feedback; +- help a creator document accessibility considerations and known limitations; +- follow up on introductions and record useful outcomes; +- help another creator navigate a barrier they have already encountered. + +The advocate is a **connector**, not a gatekeeper. + +## What an Advocate Does Not Do + +An advocate does not: + +- promise employment; +- promise funding; +- promise inclusion in a game; +- promise endorsement; +- claim a partnership that has not been agreed; +- speak on behalf of an external organization without authorization; +- represent a developer's interest without permission; +- guarantee that an accessibility adaptation works for everyone; +- turn a creator's lived experience into a universal claim. + +When an opportunity is paid, volunteer, research, playtesting, educational, promotional, or otherwise conditional, its actual terms should be stated accurately. + +## The Evidence Package + +Before outreach, the creator and advocate should be able to show: + +1. **The artifact** — what was actually made. +2. **The technique** — what creative activity it enables. +3. **The barrier** — what made the conventional workflow difficult. +4. **The adaptation** — what changed. +5. **The result** — evidence in context where possible. +6. **The limitations** — what is not solved. +7. **The rights** — ownership, provenance, license, attribution, and permissions. +8. **The ask** — feedback, testing, collaboration, integration, distribution, or another specific next step. + +The advocate should lead with evidence rather than a claim about the creator. + +## Connection Types + +Record the purpose of a connection explicitly. + +| Connection | Purpose | +|---|---| +| Feedback | Ask someone with relevant experience to review the artifact | +| Playtest / User Research | Observe how people interact with the work | +| Collaboration | Explore making something together | +| Integration | Discuss whether an asset or tool fits an existing project | +| Distribution | Find an appropriate community or channel for sharing | +| Mentorship | Connect a creator with someone who can teach a specific technique | +| Professional Presentation | Help package work for a developer or artist to evaluate | +| Accessibility Consultation | Seek informed feedback on an accessibility question | +| Community Support | Connect creators with peers facing similar barriers | + +A connection type is not a promise that the recipient will accept the proposal. + +## External Organizations + +Accessibility organizations, disability communities, adaptive-technology makers, game-development groups, educational programs, and creative communities may be valuable references or outreach contacts. + +Their status must be recorded accurately: + +- **REFERENCE** — public material informs the pathway. +- **OUTREACH** — an introduction or inquiry has been made. +- **CONVERSATION** — an exchange is underway. +- **COLLABORATION PROPOSED** — a concrete collaboration has been discussed. +- **PARTNER** — an actual relationship has been agreed. +- **ENDORSEMENT** — use only when explicitly granted. + +Do not collapse these statuses into a generic “partner” label. + +### AbleGamers as a Reference Example + +The AbleGamers Charity is a useful external reference for the model because its public team structure includes peer counseling, community and inclusion, user research, professional development, and game-accessibility work. + +That makes it a reasonable organization to introduce the initiative to **for perspective**, while keeping the relationship status at the actual state of contact. + +Nothing in this document represents AbleGamers as a Loptr Lab partner, sponsor, evaluator, employer, or endorser. + +## Advocate Safety + +Creators retain control over their work and participation. + +An advocate should: + +- ask before sharing private information or unpublished work; +- use the creator's preferred public attribution; +- avoid exposing disability or medical information that the creator has not chosen to disclose; +- confirm whether a work is ready for public sharing; +- distinguish creator statements from advocate interpretation; +- preserve licenses and attribution requirements; +- record meaningful consent for introductions when appropriate; +- respect a decline without treating it as a failure. + +Accessibility advocacy should expand a creator's choices, not replace them. + +## From Artifact to Introduction + +A practical sequence is: + +**MAKE** → finish the artifact +**DOCUMENT** → make it understandable +**PACKAGE** → make it presentable +**IDENTIFY** → find relevant people +**ASK** → make one concrete request +**CONNECT** → introduce with permission +**FOLLOW UP** → record the outcome +**LEARN** → feed the result back into the Path + +An unsuccessful introduction is still useful evidence if the reason and next lesson are documented. + +## Advocate Graduate Outcome + +Someone completing this layer should be able to say: + +> I can identify a creative barrier, help build or document an accessible way around it, explain what was made, and connect that work with people who may be able to use, test, improve, integrate, or build upon it. + +That is the intended capability—not a promise of employment or placement. + +## Relationship to Creative Accessibility Path + +This document extends the Creative Accessibility Path. + +The overall progression is: + +**EXPLORE → ADAPT → MAKE → INTEGRATE → DOCUMENT → SHARE → CONNECT → BUILD** + +Not every creator needs to continue through every stage. A finished, well-documented artifact is already a valid outcome. + +## Governance + +This document describes training and outreach practice. It does not change: + +- the authority of any game's rulebook; +- canonical game rules; +- external organizations' policies; +- contributor licensing; +- employment terms; +- accessibility standards established by other organizations. + +External relationships require explicit agreement and should be represented according to their actual status. From b8d4737ab86e99a596ae0b3f84fd0e9939224d37 Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Thu, 17 Sep 2026 18:11:38 -0500 Subject: [PATCH 2/3] Add advocacy and creative accessibility navigation --- README.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 810dae2..3e7819f 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,18 @@ Veiled Dominion's four-player rules authority remains [`Loptr-Lab/veiled-dominion-engine`](https://github.com/Loptr-Lab/veiled-dominion-engine). Duet remains a separate accessibility artifact and experimental mechanics lab. See [`RESEARCH_AND_CANON_BOUNDARY.md`](./RESEARCH_AND_CANON_BOUNDARY.md). +## Creative Accessibility Path + +The training pathway is broader than the TypeScript exercise. Its graduate outcome is **asset production and creative access**: participants leave with things they made—tools, adaptations, experiments, creative assets, or documented techniques that can be used by an independent artist, shared with a community, or presented to a game developer. + +The working loop is **LIMITATION → ADAPTATION → EXPERIMENT → CREATION → SHARE**. Accessibility is a design constraint throughout the path, not a final module. + +See [`docs/CREATIVE_ACCESSIBILITY_PATH.md`](./docs/CREATIVE_ACCESSIBILITY_PATH.md) and [`docs/ADVOCACY_AND_CONNECTION.md`](./docs/ADVOCACY_AND_CONNECTION.md). + +The path continues from sharing into **Advocacy & Connection**: creators may learn to help another creator find relevant feedback, testing, collaboration, integration, distribution, or professional contacts. External organizations are referenced only at their actual relationship status; no partnership or endorsement is implied without explicit agreement. + +**You don't graduate with a certificate. You graduate with things you made—and with the ability to help the next creator get past a barrier.** + ## 📍 State Workforce & Vocational Rehabilitation Intake State workforce agencies (VR offices, local Workforce Development Boards) operate under different application workflows and funding eligibility rules. @@ -132,7 +144,7 @@ Shader programming for the engine's signature visual effects (Death's void mater ## Where This Leads -Finishing this exercise well is a real, gradable signal — see `REVIEWER_SCORECARD.md` for exactly what's being evaluated and how. From here, contributors typically move into Track B or C, or directly into scoped engine-repo tasks. +Finishing this exercise well is a real, gradable signal — see `REVIEWER_SCORECARD.md` for exactly what's being evaluated. From here, contributors typically move into Track B or C, or directly into scoped engine-repo tasks. | Course / Resource | Tracks | Why | | :--- | :--- | :--- | @@ -149,6 +161,8 @@ Finishing this exercise well is a real, gradable signal — see `REVIEWER_SCOREC - **Engine repo:** [github.com/Loptr-Lab/veiled-dominion-engine](https://github.com/Loptr-Lab/veiled-dominion-engine) — the real game - **Full game design doc:** `docs/design/GDD.md` in the engine repo - **Accessibility engineering specs:** `docs/ENGINE_ACCESSIBILITY_A11Y_PARADOX.md` and `docs/ENGINE_ACCESSIBILITY_AUDIO_AURA.md` in the engine repo +- **Creative Accessibility Path:** [`docs/CREATIVE_ACCESSIBILITY_PATH.md`](./docs/CREATIVE_ACCESSIBILITY_PATH.md) +- **Advocacy & Connection:** [`docs/ADVOCACY_AND_CONNECTION.md`](./docs/ADVOCACY_AND_CONNECTION.md) - **Contributor safety:** [`CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md`](./CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md) — consent, vetting, staged access, exit terms, and variant review gates - **Variant governance:** [workflow](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/VARIANT_CREATION_WORKFLOW.md), [template](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/VARIANT_TEMPLATE.md), and [worked example](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/examples/DREAD_PRESSURE.md) in the engine repository From b8998271fbb0317f861b674f5f63daef00d3b1fe Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Thu, 17 Sep 2026 18:11:44 -0500 Subject: [PATCH 3/3] Add advocacy and creative accessibility navigation --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 3e7819f..3b64023 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,17 @@ # Veiled Dominion — Candidate Exercise & Training Curriculum +## Creative Accessibility Path + +The training pathway is broader than the TypeScript exercise. Its graduate outcome is **asset production and creative access**: participants leave with things they made—tools, adaptations, experiments, creative assets, or documented techniques that can be used by an independent artist, shared with a community, or presented to a game developer. + +The working loop is **LIMITATION → ADAPTATION → EXPERIMENT → CREATION → SHARE**. Accessibility is a design constraint throughout the path, not a final module. + +See [`docs/CREATIVE_ACCESSIBILITY_PATH.md`](./docs/CREATIVE_ACCESSIBILITY_PATH.md) and [`docs/ADVOCACY_AND_CONNECTION.md`](./docs/ADVOCACY_AND_CONNECTION.md). + +The path continues from sharing into **Advocacy & Connection**: creators may learn to help another creator find relevant feedback, testing, collaboration, integration, distribution, or professional contacts. External organizations are referenced only at their actual relationship status; no partnership or endorsement is implied without explicit agreement. + +**You don't graduate with a certificate. You graduate with things you made—and with the ability to help the next creator get past a barrier.** + ## Repo Identity **This is not the canonical game engine.** This repository (`Loptr-Lab/training`) contains a standalone TypeScript systems exercise used for candidate evaluation and workforce-training pathways. Ember, Tide, Root, Gale, Burning, and Steam are training abstractions, not Veiled Dominion canon.