Evaluation measures how the model behaves on typical inputs. Red teaming does the opposite: it hunts for the inputs that make the model misbehave. An expert deliberately probes for failures, jailbreaks, unsafe outputs, and the brittle edges, and documents how to reproduce each one. The deliverable is not a score, it is a set of reproducible failure cases.
Why adversarial work is different
A grader asks is this output good. A red teamer asks what input would make this output bad. That shift in stance changes who is suited to the work and how you measure it. You are not sampling average behaviour; you are searching the tail, and a single well-documented failure can be worth more than a thousand passing cases.
What a good failure case contains
A finding is only useful if someone else can reproduce it. A strong red-team case records the exact input, the harmful or incorrect output, why it is a problem, and the conditions under which it triggers. Vague reports (the model can be unsafe) do not help; a specific, repeatable prompt-and-output pair does. Reproducibility is what lets your team fix the issue and prove the fix held.
Who should red team
Effective red teaming often needs domain expertise, not just adversarial instinct. A security researcher finds different failures than a clinician or a lawyer, because each knows where their field hides danger. For high-risk domains, credentialed experts probing the model surface the failures that actually matter to that context, the ones a generalist would never think to try.
Where red teaming fits
Run it before a release, whenever you ship a capability that could be misused, and as an ongoing practice rather than a one-off. The failure cases feed two things at once: your safety evaluations (so you can measure whether a class of failure is getting rarer) and your fixes (so you know what to patch). It is the stress test at the end of the loop, before the model reaches users.
On Pathwize
A red teaming task on Pathwize routes probing work to credential-verified experts and captures each failure case with a signed trail: who found it, the input, the output, and the conditions. You get an auditable record of what was tested and what broke, which is exactly the evidence a safety review and, increasingly, a regulator expects. Create one from the AI tasks console.