Guidelines & uploads

Two uploads help our team build exactly what you want: your guidelines and, if you have it, your raw data.

Attach guidelines

Upload your brief or dataset specs as a PDF, Zip, or Word file (up to 20 MB). Your guidelines are the single most important factor in getting a dataset you can actually use. They tell our labelers exactly what "correct" looks like, so the more precise they are, the better the result and the fewer revision cycles you'll need.

How to write great labeling guidelines

Good guidelines remove ambiguity. A labeler should be able to read them and label an item the same way you would, without guessing. Here's what to include:

1. State the goal and the use case

Open with one or two sentences on what the dataset is for. Labelers make better judgement calls when they understand the intent.

Example: "This data will train a model to detect defective products on a factory line. When unsure, prefer flagging a possible defect over missing one."

2. Define every label precisely

For each label or class, give a clear definition in plain language. Don't assume the name is self-explanatory. Spell out exactly what does and does not belong in each category.

Label name — exactly as it should appear
Definition — what it means, in one or two sentences
Include — what counts as this label
Exclude — what looks similar but should not get this label

3. Show examples, including the hard ones

Examples are worth more than definitions. For each label, give a few positive examples, and crucially a few edge cases and near-misses. The items labelers disagree on are almost always the ambiguous ones, so decide those for them in advance.

Clear positives — obvious cases of each label
Edge cases — borderline items and how you want them handled
Negatives / near-misses — things that look right but aren't
Counter-examples — common mistakes to avoid

For image, video, or document work, an annotated example next to a wrong one resolves more confusion than any description. Take a bounding-box task: the difference between "correct" and "wrong" is obvious in a picture, but hard to pin down in words.

One correct annotation vs. three common mistakes

A single labelled diagram like this, showing a tight, correct box beside boxes that are too loose, that cut off the object, or that miss it entirely, tells a labeler exactly what you expect. Do the same for whichever task you have: spans for text, masks for segmentation, fields for documents.

Sample annotated data is the single most valuable thing you can provide. Even a handful of correctly labelled examples, often called a gold set, does more to align our team with your intent than pages of written rules. If you can label just 10 to 20 items yourself and include them with your guidelines, your dataset will come back far closer to what you wanted, with fewer revision cycles.

4. Give rules for ambiguity and conflicts

Tell labelers what to do when an item is unclear or could fit more than one label. A few decisions to make for them:

What to do when two labels could both apply (pick one? allow multiple? a priority order?)
What to do with low-quality, blurry, or partial items
Whether there's a "none of the above" / "unsure" option, and when to use it
How to handle items in a different language or outside the expected scope

5. Specify the format and taxonomy

Be explicit about the shape of the output so it matches what your pipeline expects:

Label set — the full list of allowed labels or classes
Annotation type — e.g. bounding boxes, polygons, segmentation masks, keypoints, spans, classification, transcription, ranking
Granularity — per item, per region, per token, per frame
Multiple labels — whether an item can have more than one
Output format — JSONL, CSV, COCO, and any field names you need

6. Note quality and compliance requirements

If you have specific quality bars or sensitivities, say so up front:

Target accuracy or agreement level, if you have one
Any PII or sensitive content to redact, skip, or handle carefully
Domain expertise required (for example medical, legal, or a specific language)
Anything that is a hard "do not" for your project

A simple structure that works: 1) goal and use case · 2) the label set · 3) one definition + examples block per label · 4) edge-case and conflict rules · 5) output format · 6) quality and compliance notes. Start small and add edge cases as you think of them.

Upload raw dataset

If you already have raw data to be labeled, drag and drop it here (up to 5 GB; text, image, audio, or video). If you don't have data yet, that's fine, our team can source it as part of your request.

If your dataset is too large to upload, or hosted elsewhere, tick "I've already uploaded my dataset to my own platform" and share the access link in your guidelines. Don't forget to actually grant access, or work can't start.

Use your own labeling platform

Already have a labeling environment set up with your own vendor? We can work directly inside it. If your team uses a tool like Encord, Label Studio, CVAT, Labelbox, V7, SuperAnnotate, Roboflow, or any similar platform, our annotators can plug straight into your existing setup instead of using ours.

To integrate, you just share access:

Invite our team to your project, or provide accounts / seats on your platform
Point us to the data and the label schema already configured there
Note any platform-specific instructions in your guidelines (project names, workflows, review steps)

Mention this in your guidelines, or turn on "I need an annotation platform set up for my project" in the request form if you'd rather we set one up for you instead.

Working in your own platform keeps the labeled data, audit trail, and review workflow entirely within your environment, which is helpful when you have existing pipelines or specific governance requirements.

When everything's ready and you have enough credits, select Submit. You'll get a confirmation that your request has been received.