> ## Documentation Index
> Fetch the complete documentation index at: https://docs.yoid.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Ecosystem Actors
> Who participates in the YOMA ecosystem, what they need, and how YoID serves them.
## The Three Roles
Every interaction in the YOMA ecosystem involves three roles: someone **issuing** a credential, someone **holding** it, and someone **verifying** it.
***
## Learning & Impact Partners (Issuers)
Partners that create verified proof of what youth have achieved.
| Type | Who | What YoID gives them |
| ----------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------------- |
| **Learning Providers** | Training organisations, ed-tech platforms (e.g. Umuzi) | Automated credential issuance via REST API. Proof of outcomes for funder reporting. |
| **Impact Partners** | Impact measurement orgs, funders, CSR programmes (e.g. DUCT) | Verified impact claims backed by cryptographic proof, tied to funder metrics. |
| **Government Partners** | National departments, regulatory bodies (e.g. DHA, DBE) | Digital-first credentialing that reduces fraud and verification bottlenecks. |
All issuer types use the same REST API — the only difference is the credential template they define.
***
## Youth (Holders)
Youth sit at the centre of the ecosystem — young people building pathways from learning to employment.
They hold credentials in a digital wallet and control what they share, with whom, and when. Youth don't call APIs — they interact through mobile wallet experiences.
* **Credential arrival**: Credentials land in the youth's wallet, even before they've activated their account
* **Consent prompts**: Verification requests show exactly what's being asked and by whom
* **Selective disclosure**: Youth choose which attributes to reveal on a per-request basis
Youth agency is the core principle. Every integration must preserve the youth's right to consent and control their own data.
***
## Employers & Opportunity Providers (Verifiers)
Partners that consume and verify credentials.
| Type | Who | What YoID gives them |
| ------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Employers** | Recruitment platforms, companies, staffing agencies | Instant cryptographic verification of candidate credentials. |
| **Opportunity Providers** | Scholarship administrators, bursary programmes, youth development funds | Automated eligibility verification against credential criteria. |
***
## How the Roles Connect
Umuzi issues **"Web Dev Completion"** to Thandi's wallet.
DUCT issues **"Impact Verified"** to Thandi's wallet.
Thandi **holds** credentials and **controls** disclosure.
She chooses what to share, with whom, and when.
JobJack requests **"Web Dev Completion"** from Thandi.
A scholarship programme checks **eligibility**.
### How Issuers and Verifiers Connect
When creating a credential template, the issuer provides a **`code`** (e.g. `course-completion`). The API returns a full **type** URI (the VCT). A verifier references that same URI in their presentation template to request matching credentials.
No direct relationship needed — the shared VCT is the bridge.
## Next Steps
How verifiable credentials work under the hood
Ready to build? Jump to the API integration guide