Curos's approach to model evaluations

This is the post we link people to when they ask how Curos decides a model is ready. It is the plain-language version of our evaluations page, and it is worth writing because the process is the product: a non-profit’s safety claim is only as good as its published receipts.

The four layers

Every model before release runs through four kinds of evaluation:

Capability benchmarks — what the model can do: knowledge, reasoning, math, code, long-context work. These are the numbers on the model pages. They are a precondition for risk, not a measure of it.

Safety evals — tests for behaviors we have committed not to ship: following instructions that would cause real harm, providing reliable information on dangerous capabilities, behaving deceptively. These evals are adversarial by construction. We assume the model will fail somewhere, and the job is to find where.

Honesty evals — whether the model overstates its confidence, invents sources, or refuses to say “I don’t know.” Users cannot verify every answer, so honesty is a safety property. Our internal OversightQA and Curos-Helpfulness evals live here.

Red-teaming — humans trying to break the model on purpose. Internal teams, and since last year, the community through public red-teaming windows. Our research on this shows public participants find a different class of failures than internal teams — context- and values-based ones — which is why we now treat it as a standing part of the cycle.

The gates

Passing the suite is necessary but not sufficient. The Safety & Evaluations Committee — with members outside the evaluations team — reviews the results and signs off, or does not. The committee has delayed two releases. A gate that never blocks anything is decoration, and we built ours to be used.

What we publish

Every release comes with an evaluation report: the suite, the numbers, the red-team findings, and explicitly what we did not test and why. The report is the announcement.

What we do not claim

Evaluations cannot prove safety. They bound our confidence and make our judgments checkable. New behaviors appear after deployment — which is why we publish incident postmortems, and why the community can report problems. That is the design. We would rather be right slowly than confident quickly.

All news →