Most human data work falls into a handful of shapes. Once you can name them, planning a data programme gets a lot easier, because each shape answers a different question about your model. On Pathwize you create work as one of four task types: RLHF / Preference, Evaluation / Grading, Red teaming, and Domain judgment / SFT. This guide explains what each one is for and how to combine them.
1. Preference (RLHF)
In a preference task, an expert sees two model outputs for the same prompt and picks the better one, with a short rationale. The output is a comparison, not a score. This is the raw material for reward models and RLHF: you are teaching the model what humans prefer, one pairwise judgment at a time.
Reach for preference tasks when quality is comparative rather than absolute, when two answers can both be defensible and you want the model to learn the tie-breakers a good expert applies.
2. Evaluation (grading)
An evaluation task scores a single output against a rubric, either pass/fail or on a scale. The rubric is the whole game: it turns a vague sense of quality into a repeatable measurement that different graders apply the same way.
Use evaluation when you need a number you can track over time, a benchmark for a release, a regression check, or a quality gate. Preference tells you which is better; evaluation tells you how good, against a fixed standard.
3. Red teaming
Red teaming asks experts to probe the model for failures: jailbreaks, unsafe outputs, and the edges where it breaks. The goal is not to grade normal behaviour but to find the inputs that produce bad behaviour, and to document how.
Use it before a release, whenever you ship a capability that could be misused, and as an ongoing safety practice. The deliverable is a set of reproducible failure cases, which feed both your safety evaluations and your fixes.
4. Domain judgment (SFT)
Here the expert writes the ideal answer, or the authoritative judgment, for each item. This is supervised fine-tuning data at its source: not a comparison and not a score, but the gold response itself, authored by someone qualified to produce it.
Use domain judgment when the model needs to learn from correct examples in a specialised field (medicine, law, frontier maths, security) and only a credentialed expert can say what correct looks like.
How they fit together
A mature programme uses all four. Domain judgment builds the gold set the model learns from. Preference tunes its behaviour toward what experts favour. Evaluation measures whether any of it worked. Red teaming stress-tests the result before it ships. They are stages in a loop, not competing options.
The thread that runs through all four is the same one behind everything we build: every judgment should carry a signed, reproducible trail, so you can prove who produced it and under what instructions. Pick the task type that answers your question, and keep the provenance whichever you choose.