diff --git a/README.md b/README.md
index 810dae2..1d487b4 100644
--- a/README.md
+++ b/README.md
@@ -89,6 +89,18 @@ These contracts are spelled out in full so that "my interpretation of the rule w
 
 ---
 
+## Creative Accessibility Path
+
+The training program is broader than the TypeScript exercise: it is a pathway for **accessible creative experimentation and asset production**. The goal is for graduates to leave with things they made—tools, adaptations, creative assets, experiments, or documented techniques—that can be useful to independent artists and communities or serve as portfolio evidence when approaching game developers.
+
+Start with [`docs/CREATIVE_ACCESSIBILITY_PATH.md`](./docs/CREATIVE_ACCESSIBILITY_PATH.md).
+
+**LIMITATION → ADAPTATION → EXPERIMENT → CREATION → SHARE**
+
+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.
+
+---
+
 ## Training Curriculum
 
 This exercise is the hands-on centerpiece of **Track A: Prototype Engineer** below. If you're working through this as part of a VRS training plan or self-directed learning path, the full curriculum progression is:
diff --git a/docs/CREATIVE_ACCESSIBILITY_PATH.md b/docs/CREATIVE_ACCESSIBILITY_PATH.md
new file mode 100644
index 0000000..2584e5c
--- /dev/null
+++ b/docs/CREATIVE_ACCESSIBILITY_PATH.md
@@ -0,0 +1,221 @@
+# Creative Accessibility Path
+
+## Purpose
+
+Loptr Lab training is an **asset-production and creative-accessibility pathway**.
+
+The goal is not simply to complete a coding exercise or qualify for work inside Loptr Lab. A graduate should leave with things they made: accessible tools, adaptations, creative assets, experiments, or documented techniques that can be useful to an independent artist/community or demonstrate capability to other game developers.
+
+> **You don't graduate with a certificate. You graduate with things you made.**
+
+The central loop is:
+
+**LIMITATION → ADAPTATION → EXPERIMENT → CREATION → SHARE**
+
+A limitation may be physical, cognitive, sensory, financial, technical, or workflow-related. The pathway treats that constraint as a design question rather than a reason to exclude the creator.
+
+## The Graduate Outcome
+
+A graduate should be able to:
+
+1. Identify a creative technique they want to explore.
+2. Identify what makes the conventional tool or workflow difficult or inaccessible.
+3. Adapt an existing tool, workflow, interface, controller, or environment—or build a small one.
+4. Use that adaptation to create something original.
+5. Integrate the result into a real game, creative tool, artist workflow, or community context.
+6. Document what was made, why it works, accessibility considerations, provenance, and licensing.
+7. Package the result so another person can use it or a developer/artist can evaluate it.
+
+A finished artifact should answer:
+
+- **What did I make?**
+- **What technique does it enable?**
+- **What barrier did I address?**
+- **How does someone use it?**
+- **Where does it work?**
+- **What are its limitations?**
+- **What are the rights/license?**
+- **Can another person reproduce, adapt, or build on it?**
+
+## The Path
+
+### 1. EXPLORE
+
+Learn a technique, tool, game, creative workflow, or medium.
+
+Examples include rhythm mapping, interactive audio, game mechanics, shader/material work, animation, narrative systems, controller configuration, assistive interfaces, and modding.
+
+### 2. ADAPT
+
+Ask what prevents full participation in the conventional workflow.
+
+The answer might be:
+
+- input method;
+- timing or motor demands;
+- visual presentation;
+- audio presentation;
+- cognitive load;
+- interface complexity;
+- hardware availability;
+- documentation quality;
+- cost;
+- environment or workflow assumptions.
+
+Build the smallest useful adaptation.
+
+### 3. MAKE
+
+Use the adapted workflow to produce an original artifact.
+
+The artifact may be code, a map/chart, a game mechanic, an audiovisual experience, a controller/interface prototype, a technical-art asset, a narrative component, or another creative work.
+
+### 4. INTEGRATE
+
+Put the artifact into context.
+
+A graduate should demonstrate the result in at least one real environment where possible—not merely as an isolated file.
+
+### 5. DOCUMENT
+
+Publish enough evidence for another person to understand and evaluate the work:
+
+- README or equivalent;
+- screenshots/video where useful;
+- implementation notes;
+- accessibility notes;
+- known limitations;
+- provenance;
+- license;
+- attribution requirements.
+
+### 6. SHARE
+
+Choose the appropriate destination:
+
+**Create for someone**
+
+Deliver a usable asset or tool for an independent artist, creator, community, or collaborator.
+
+**Create for your portfolio**
+
+Package the work so another game developer can understand the creative problem, technical decisions, accessibility considerations, and demonstrated result.
+
+**Contribute**
+
+Where the project accepts outside work, contribute through its documented process and permissions.
+
+### 7. BUILD
+
+For graduates who want larger production experience, move from a finished artifact into scoped collaboration, larger systems, or production work.
+
+This is an optional continuation—not the definition of graduation.
+
+## Learning Environments
+
+The pathway may use Loptr Lab projects, external projects, community tools, and hardware experiments.
+
+Examples include:
+
+| Environment | Technique | Accessibility question | Possible artifact |
+|---|---|---|---|
+| Rhythm-game tooling | Charting, arrangement, timing | Can the creator explore rhythm without conventional instrumental or input demands? | Chart, map, workflow, or playable prototype |
+| Beat Saber / rhythm mapping | Music interpretation, gesture | Can gesture and difficulty be adapted to the creator? | Beatmap or mapping workflow |
+| Clone Hero ecosystem | Charting, arrangement, modding | Can a creator experiment with musical structure through an alternate interface? | Chart/package, tool, or documented workflow |
+| PIXIE Creator OS | Creative-tool interaction | Can the interface/workflow be adapted to different cognitive or physical needs? | Creator tool, interface, plugin, or workflow |
+| Adaptive hardware | Physical interaction | Can a conventional controller be replaced or reconfigured? | Controller/interface prototype |
+| Veiled Dominion | Rules, systems, accessibility | Can complex systems be made deterministic, testable, and accessible? | Engine contribution, test suite, mechanic, or technical-art asset |
+
+External environments are learning references or integration targets unless a separate agreement establishes a formal relationship.
+
+## Accessibility Is a Constraint on the Whole Path
+
+Accessibility is not a final checklist.
+
+At every stage, ask:
+
+**Can I enter?  
+Can I experiment?  
+Can I make something?  
+Can I understand what happened?  
+Can somebody else use what I made?**
+
+An adaptation does not have to become a universal solution. The useful question is whether the creator can document who it helps, what it changes, and where it does not work.
+
+## Advocate / Connector Model
+
+The initiative can develop an **advocate/connector** function whose job is to help creative people and developers find one another around concrete work.
+
+An advocate may:
+
+- introduce the initiative to accessibility organizations;
+- connect creators with disabled-player and accessibility communities;
+- identify developers interested in accessible tools or creator-made assets;
+- help graduates present finished artifacts;
+- surface relevant community events, modding communities, hardware communities, and creative networks;
+- gather feedback on whether an artifact solves a real problem.
+
+An advocate is **not** an employment-placement promise and does not speak for an external organization without authorization.
+
+External organizations may be:
+
+- reference organizations;
+- outreach contacts;
+- research/consultation contacts;
+- potential collaborators;
+- community channels.
+
+Those statuses must remain distinct until a relationship is actually established.
+
+## Example External Accessibility Reference
+
+[The AbleGamers Charity](https://ablegamers.org/) is an example of an organization whose public work includes developer accessibility training, relationships with game developers, adaptive technology, and mechanisms for connecting disabled players with game companies.
+
+A future outreach conversation could ask whether the Creative Accessibility Path's model—helping creators identify barriers, adapt tools, create artifacts, and share the results—would be useful from their perspective.
+
+**This document does not represent AbleGamers as a Loptr Lab partner, sponsor, evaluator, or endorser.**
+
+## Evidence Over Claims
+
+The pathway should prefer:
+
+> Here is what I made.  
+> Here is the barrier I addressed.  
+> Here is how the adaptation works.  
+> Here is the result in context.  
+> Here is what another person can do with it.
+
+over:
+
+> I completed training.
+
+A graduate's portfolio is therefore part of the learning outcome, not an optional marketing exercise.
+
+## Relationship to the Existing Technical Exercise
+
+The TypeScript/Jest exercise in this repository remains useful as a technical learning module.
+
+It should be understood as **one environment inside the larger path**, not the definition of the program.
+
+It teaches:
+
+- reading tests as contracts;
+- state and movement logic;
+- deterministic behavior;
+- reaction systems;
+- documentation of design tradeoffs.
+
+Those skills can support later asset production and production collaboration.
+
+They do not require the graduate to become a Veiled Dominion contributor.
+
+## Status and Governance
+
+This pathway does not change the authority of the Veiled Dominion rulebook or canon.
+
+- Training exercises remain training exercises.
+- External projects remain external unless formally adopted.
+- Experimental work remains experimental until the relevant project's governance promotes it.
+- Accessibility claims should be documented from evidence and lived/user feedback rather than assumed.
+- Partnerships and endorsements require explicit agreement.
+