# Core concepts


Humanbased uses different objects for a data project, a specific piece of work, and a submitted result. Keeping them distinct helps you identify what you joined, what you are working on, and which record to inspect afterward.

| Object | What it represents | What to check | Read more |
| --- | --- | --- | --- |
| Campaign | A developer's data-production project and its settings | The work, participation requirements, execution, and checks | [A Campaign organizes the work](/start/concepts#a-campaign-organizes-the-work) |
| Task | A specific item a contributor claims or enters | Input material, instructions, claim state, and submission | [A Task is the work in front of you](/start/concepts#a-task-is-the-work-in-front-of-you) |
| Submission | The record created when work is submitted | Saved content, processing state, outcome, and available next actions | [A Submission records what was handed in](/start/concepts#a-submission-records-what-was-handed-in) |
| Pipeline | The steps a Campaign's work passes through, built in Builder | How outputs pass through checks and move to the next stage | [A Pipeline connects the steps](/start/concepts#a-pipeline-connects-the-steps) |
| Organization | The Developer-side unit that holds Campaigns, data access, and funds | Which organization is active, and your role in it | [Developer organizations](/collaboration/organization) |
| Team | A relationship among Contributors that leaves each member's Submissions and Earnings their own | Whether a team relationship applies to you | [Contributor teams](/collaboration/team) |
| Entry Gate | The workflow step that holds a Campaign's joining requirements | Agreements, courses, profile conditions, and invite codes | [Entry Gate](/tasks/workflow#entry-gate) |
| Delivered data | The authorized output a Developer can retrieve, with its own delivery and access state | Whether an accepted Submission has been delivered | [From submission to data delivery](/data/delivery) |
| Reputation | A 0–100 score built from a Contributor's recorded work; it sets their tier and pay factor | The factors behind the score and the rule version | [Understand and manage your reputation](/learning/reputation) |

Across these pages, the first mention of one of these names carries a dotted underline: hover over it or focus it for the one-line meaning above, and select it to open the page in the last column.

Your **Account** identifies you. A Developer works within an **Organization** that holds its Campaigns, data access, and funds; membership and role determine what you can manage. A Contributor claims and submits their own Task. A Contributor **Team** is a separate relationship and does not transfer that person's Submission or Earnings to a manager. See [accounts](/start/account) and [Developer organizations](/collaboration/organization).

A Submission is the source record of what a person handed in. An acceptance result says how that work was judged. **Delivered data** is the authorized output a Developer can retrieve, possibly with fields mapped from the Submission; it has its own delivery and access state. Read [submission, acceptance, and delivery](/data/delivery) before treating a visible answer as data your system has received.

## A Campaign organizes the work

A Campaign groups work under a common need and rules. It can involve multiple steps, participation requirements, and ways of processing results. After joining a Campaign, a contributor still needs to enter a specific Task before starting work.

Campaign state and Submission state answer different questions. Pausing a Campaign does not erase records that were already submitted. Check the Campaign to understand whether work can continue; check the Submission for the outcome of existing work.

To commission work, start with [publishing a Campaign](/tasks/publish). To join one, check [participation requirements](/learning/eligibility).

## A Task is the work in front of you

A Task supplies the material and instructions for the contributor's current work. Check availability, quota, holding time, and any required conditions before starting.

Seeing an opportunity in the list does not mean you have claimed it. Confirm that you entered an active task. If the task cannot be claimed, use its current state to determine the next step.

[Claim, save, and submit a Task](/tasks/participate) gives the Contributor path.

## A Submission records what was handed in

After submitting, contributors use **Contributions** to follow the saved record and its processing state. They can inspect details and use an appeal or redo action when it is available for that result.

A submission receipt establishes that the work was recorded. Acceptance, delivery, and withdrawable earnings require their own outcomes. When this documentation describes a result, it identifies whether that result belongs to review, data delivery, or money.

[Follow a Submission result](/tasks/results) to inspect its recorded state and available actions.

## A Pipeline connects the steps

The Pipeline, built in Builder, connects the work to what happens after it. A contribution may be the output of one step, followed by checks, transformation, or acceptance.

Developers need to understand the complete processing path. Contributors primarily need the parts that affect their current work, outcome, and available next action. When a record offers lineage, inspect each stage's recorded state; the existence of a processing chain does not show that every stage has finished.

See [configure a workflow](/tasks/workflow) for its steps and [inspect provenance](/data/lineage) for the records that connect them.