# How Humanbased works


Humanbased connects people who need data with people who can collect, label, or verify it. A **Developer** commissions work or uses data. A **Contributor** claims tasks, completes the work, and follows the recorded outcome and earnings.

A developer can also work with existing data; creating a new Campaign is not a prerequisite for every use.

## Understand it as a collaborative project

If you know GitHub, think of a Campaign as a shared project: people work from clear instructions, submit contributions, and leave results that can be checked. This analogy explains collaboration. Humanbased's own participation requirements, review rules, data permissions, and payment records determine what happens to the work.

You can use Humanbased without programming or knowing GitHub. Start with the job you want to complete.

## Decide whether you need existing data or new work

For existing data, inspect available Marketplace entries or the results of a Campaign your organization already operates. Check the content and access conditions, then establish which records you are authorized to obtain. An empty listing, a description, or missing authorization means there is still a step to resolve before you have usable data.

For new collection, annotation, or verification work, a developer creates a **Campaign**. The Campaign brings together input material, instructions, the response interface, participation requirements, and budget. Contributors perform the work; the developer follows checks, acceptance, delivery, and the associated financial records.

## Turn a need into work people can complete

Suppose you need images classified according to a defined standard. This is an illustrative example, not an actual published Campaign. “Label these images” is insufficient: contributors need the available categories, guidance for ambiguous cases, an interface for their answers, and clear acceptance criteria.

1. Prepare the images and classification standard.
2. Configure the human-work step so contributors can see the material and submit a category. Add training or qualification requirements where needed.
3. Configure the checks, acceptance method, and path for accepted outputs to enter the intended dataset.
4. Set pay and budget, then complete testing and launch checks.
5. During operation, inspect submissions and review results before obtaining the delivered data you may use.

The work format, form, and processing flow should describe the same task. Review the contributor's instructions alongside the expected output, so a person knows what to submit and a reviewer knows what to assess.

## Evaluate the data and improve the next brief

After retrieving the authorized result, test it against the original need. In the image example, accepted classifications might still reveal that reflective packaging lacks a clear category. A developer can revise the next brief, examples, form, or acceptance criteria, then test and launch that revised work separately. Acceptance proves the configured work check passed; it does not prove a model improved. If existing delivered data already serves the need, check its access terms and records before commissioning more collection.

## Contribute and follow the outcome

Before joining a Campaign, check what you will do, whether you meet its requirements, and which results qualify for pay. After joining, claim a specific **Task** and follow its instructions.

Submitting creates a **Submission** record. Use **Contributions** to inspect its review result and feedback, and **Earnings** to check the financial record. If the Campaign requires a course or credential, complete that requirement and return to check its status.

## Keep learning, evidence, and results distinct

Learning prepares you for task standards. Credentials provide evidence for participation requirements. Reputation reflects recorded work performance. Each answers a different question; a reputation score does not replace a required course result or identity verification.

After the work, the developer follows the data result and access path. The contributor follows the submission and earnings. Acceptance, delivery, and payment each have their own state and supporting records.

Choose your next guide: [make your first contribution](/start/contributor-start), [commission new work](/start/developer-start), [get existing data](/start/data-start), or [connect an agent or API](/api). For the objects behind these paths, read [core concepts](/start/concepts).