Add advocacy and connection layer to creative accessibility path

README.md

@@ -103,6 +103,8 @@ Start with [`docs/CREATIVE_ACCESSIBILITY_PATH.md`](./docs/CREATIVE_ACCESSIBILITY
 
 Accessibility is a design constraint throughout the path, not a final module. External projects and organizations may be learning references, outreach contacts, or potential collaborators; they are not represented as Loptr Lab partners unless an explicit relationship exists.
 
+The path can continue into **Advocacy & Connection**: creators may learn to help another creator find relevant feedback, testing, collaboration, integration, distribution, or professional contacts. See [`docs/ADVOCACY_AND_CONNECTION.md`](./docs/ADVOCACY_AND_CONNECTION.md).
+
 ---
 
 ## Training Curriculum

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 work includes player research, professional development, community inclusion, and accessible gaming support.
+
+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.