# Proof of Work

Proof of Work is any real output you build, submit, and have validated by peers. It's what makes your Karma meaningful and your profile credible.

*Certificates say you were present. Proof of Work says you built something.* That one difference is the foundation of everything μLearn does. A certificate is issued by an institution. It signals completion of a defined curriculum. It tells you someone attended.

A Proof of Work is validated by a community. It signals real output produced under real conditions. It tells you someone built something and others confirmed it was good.

### <mark style="color:$primary;">What Counts as Proof of Work</mark>

A Proof of Work is any verifiable output that demonstrates skill, effort, or contribution. It is not self-reported it must be submitted and validated.

Examples across domains:

<mark style="color:$primary;">**Tech**</mark>

* A GitHub repository built during a Learning Circle
* A working prototype submitted for a challenge
* A data analysis with documented methodology

<mark style="color:$primary;">**Design**</mark>

* A design file submitted for a challenge
* A UI/UX case study with process documentation
* A motion piece or visual system

<mark style="color:$primary;">**Research & Writing**</mark>

* A research brief submitted for a partner challenge
* A blog post written for an Interest Group
* A documentation contribution to the μLearn ecosystem

<mark style="color:$primary;">**Community & Leadership**</mark>

* A workshop facilitated for a campus node
* A Learning Circle session led and documented
* A mentoring session with documented outcomes

<mark style="color:$primary;">**Initiative-Linked**</mark>

* A product prototype built during In50Hours
* A submission to Top 100 with peer review scores
* A project delivered through μMent

### <mark style="color:$primary;">How Submission Works</mark>

Every PoW submission follows the same process:

1. You complete a task or challenge
2. You submit your output a link, file, or structured form through the μLearn platform
3. Your submission is automatically tagged to your μID, your Interest Group, your task type, and your domain
4. Your submission enters the validation queue

### <mark style="color:$primary;">What Happens After You Submit</mark>

Submission is not approval. Your work gets reviewed.

```
Submit → System Check → Peer or Lead Review
              ↓                    ↓
          Rejected             Approved → Karma Awarded
              ↓
      Revision Requested
              ↓
      Resubmit → Review Again
              ↓
      Escalate to Core Team (if disputed)
```

**Rejection is not failure. It is the system working.**

You revise. You resubmit. You get better. That loop is the learning not a detour around it.

### <mark style="color:$primary;">Who Reviews Your Work</mark>

<table><thead><tr><th width="200.3333740234375">Reviewer</th><th>When They Review</th></tr></thead><tbody><tr><td><strong>Peers</strong></td><td>Standard tasks, everyday submissions</td></tr><tr><td><strong>IG Lead</strong></td><td>Domain-specific or high-value work</td></tr><tr><td><strong>Mentor</strong></td><td>Advanced projects, initiative-level outputs</td></tr><tr><td><strong>System</strong></td><td>Every submission format, completeness, duplicate detection</td></tr><tr><td><strong>Core Team</strong></td><td>Disputes, escalations, edge cases</td></tr></tbody></table>

### <mark style="color:$primary;">Quality Expectations</mark>

PoW is not just about submitting it is about the quality of what you submit.

* Every task has a **minimum quality bar** defined by the IG Lead, Think Tank or initiative owner
* Incomplete or low-effort submissions are **returned for revision** not rejected permanently
* Consistently low-quality submissions may trigger a **review flag** on your μID

The quality bar is not there to gatekeep. It is there to ensure that every Karma point earned actually means something.

### <mark style="color:$primary;">What PoW Builds Over Time</mark>

Every validated Proof of Work:

* Earns you **Karma** - the contribution signal that grows your level and unlocks opportunities
* Updates your **μID** - adding to your permanent, portable record of real work
* Builds your **domain credibility** a timeline of growth that companies and mentors can see

A learner with 50 validated PoW submissions in product design has a portfolio that no certificate can replicate. That is what consistent Proof of Work builds.

### <mark style="color:$primary;">Manual Intervention Points</mark>

{% hint style="info" %}
**Dispute a rejection:** If you believe your submission was unfairly rejected, [escalate via this form](https://mulearn.org/contact). Your IG Lead reviews first. Unresolved disputes go to the core team.
{% endhint %}

{% hint style="info" %}
**Report validation issues:** If a reviewer is consistently unfair or inactive, flag via [support form](https://mulearn.org/contact).
{% endhint %}

→ To understand how Karma is calculated from your PoW, go to [**Karma**](/core-concepts/karma.md)

→ To see how your PoW builds your permanent record, go to [**μID**](/core-concepts/mid.md)

→ To understand the full validation system, go to [**Validation**](/core-concepts/validation.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mulearn.org/core-concepts/proof-of-work.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.