# Client-specific rubrics: teaching an AI assistant when to say "not enough information"

> A generic rubric only tells you whether an answer sounds good. To measure what the client actually needs, read real data with the client's domain expert, then check that the judge grades the way people do.

Original: https://fdetimes.net/en/guides/client-specific-rubrics-ai-refusals/

Anthropic's official documentation contains a surprisingly simple recommendation: tell the model explicitly that it is allowed to admit uncertainty. According to Anthropic, that alone can sharply reduce false information.

At the client's office, though, you face a harder question: what is the model allowed to say it doesn't know, and who decides whether an answer passes?

A generic rubric along the lines of "accurate, helpful, polite" cannot answer that. Every client has its own documents, its own risk tolerance and one person who understands the business far better than the engineering team. A good FDE turns that person's knowledge into criteria a machine can grade.

The steps below take a hypothetical insurance company from start to finish: write the refusal clause, collect labels from the expert, write the rubric, then check whether the judge grades the way a person would.

## What will you build, and what do you need?

Imagine that insurance company wants an assistant to help customer service staff look up policy terms. By the end you will have four things: a system prompt with a refusal clause, a three-line rubric, a set of test cases labelled by the expert, and two numbers that tell you how far the judge can be trusted.

Most important are real questions taken from tickets or logs, not ones you invent. You also need a few hours with a domain expert, in this example the head of the claims team.

Finally, you need an eval tool with LLM-as-judge, such as Promptfoo's `llm-rubric`, plus two different models: one to generate answers and one to grade them.

## Step 1: write the refusal clause before the rubric

A rubric can only grade what has been clearly asked for. Anthropic's example does exactly two things: it states the scope of the task, then gives the model a fixed fallback sentence for when the source lacks information. Applied to an insurance policy, that section might look like this (abridged):

```text
Answer only from the policy clauses provided,
not from general knowledge.
Every claim must include a verbatim quote from the clause.
If the clauses do not contain enough information, reply with exactly one sentence:
"I don't have enough information to assess this with certainty."
```

The first line is the technique of restricting the model to the documents provided. Anthropic also warns that this technique does not eliminate hallucinations entirely, so important outputs must still be checked. That is why you need a rubric.

**How to check:** ask three questions you are certain the policy does not cover. If the answer does not match the fallback sentence word for word, fix the prompt before going further.

## Step 2: read real data with the expert, don't guess the criteria

Hamel Husain advises writing the judge prompt only after looking at real data. He also advises handing the grading to one principal expert, and grading only pass or fail, with no elaborate scales or multiple metrics. On an FDE project, that person is the client's domain expert.

According to Husain, every grade must come with a handwritten comment. That comment must be detailed enough to serve as a few-shot example for the LLM judge. A simple label sheet looks like this:

```text
id | question                                | label | expert's comment
07 | Is storm flooding covered?              | fail  | Says "yes" but doesn't cite clause 4.2, which excludes tidal flooding
12 | How are after-hours visit fees charged? | fail  | The policy covers this in Appendix B, yet the assistant refused to answer
19 | Is pet cover included?                  | pass  | The policy doesn't mention it; the assistant used the fallback sentence correctly
```

Look at case 12. The expert penalises an unnecessary refusal just as hard as a made-up answer. Most hastily written rubrics miss this dimension.

## Step 3: turn the comments into a three-line rubric

Reread a few dozen comments and you will see they cluster around a handful of recurring errors. The first line comes from another Anthropic technique: every claim must come with a citation, and if no citation can be found, the claim must be withdrawn. The third line is inspired by OpenAI's Model Spec, which treats refusal as a last resort.

```text
An answer PASSES if and only if it meets all three conditions:
1. Every claim about coverage includes a verbatim quote
   from the clauses. A single unsourced claim is a FAIL.
2. If the clauses do not contain the answer, the correct output is the
   fallback sentence, with no added speculation.
3. If the clauses DO contain the answer, refusing is a FAIL.
```

**Key point:** A good rubric penalises both made-up answers and unnecessary refusals.

## Step 4: put the rubric into Promptfoo

Promptfoo describes `llm-rubric` as an assertion that uses a model to grade outputs against criteria you write. The abridged configuration below has two tests: the first uses the pass/fail rubric from Step 3, the second uses a partial-credit rubric.

```yaml
# Abridged for illustration
tests:
  - vars:
      question: "How are after-hours visit fees charged?"
    assert:
      - type: llm-rubric
        value: "<paste the three-line rubric from Step 3>"
  - vars:
      question: "Is storm flooding covered?"
    assert:
      - type: llm-rubric
        value: "<partial-credit rubric>"
        threshold: 0.8
```

The first test has no `threshold`, so Promptfoo decides pass or fail from the boolean `pass` field the judge returns. That is exactly what a pass/fail rubric needs.

The second test applies `threshold` to the judge's score from 0.0 to 1.0. Without that line, a partial-credit rubric is still graded on the `pass` field.

The 0.8 figure is only an example; choose it according to the level of risk the client can accept. One more detail from Anthropic's example: use a different model to grade, not the model that generated the answer.

## Step 5: does the judge grade like the expert?

Husain advises treating human labels as ground truth, then reporting True Positive Rate and True Negative Rate separately. Try the calculation on a hypothetical set of 40 cases. The expert passes 25 and fails 15.

Suppose the judge passes 24 of the 25 cases the expert passed, a TPR of 96%. But the judge fails only 9 of the 15 cases the expert failed, a TNR of 60%. Combined, agreement is 33 out of 40, or 82.5%, which sounds respectable.

That combined figure hides the most important point: of every 15 wrong answers, 6 slip past the judge. The next job is to open exactly those 6 cases and add the expert's matching comments to the judge prompt as few-shot examples.

Then close the loop: rerun the judge on the whole set and recompute both TPR and TNR. Keep a few failing cases aside that never go into the few-shot examples, because a judge correctly grading examples it has just been shown proves nothing. If TNR still doesn't move, the expert's comments are probably not specific enough, and you go back to Step 2.

To isolate refusals, you can use Arize Phoenix's Refusal evaluator. It detects when an LLM refuses, declines or evades a question. It tells you *whether* the assistant refused. Whether that refusal was *correct* is something only lines 2 and 3 of the rubric can answer.

## Once the judge is trustworthy, scale the test set

Anthropic's eval design guidance is clear: many automatically graded questions, even with slightly weaker signal, beat a few carefully hand-graded ones. Spend the expert's time calibrating the judge. Leave grading hundreds of answers to the machine.

As you scale, watch for four traps. The first is writing the rubric before reading the data. The telltale sign is a rubric full of words like "accurate" and "helpful" in which the expert recognises none of the errors they have actually caught. The fix is to go back to the label sheet and derive every rubric line from a real comment.

The next trap is a 1-to-5 scale. The sign is a team that argues endlessly over what counts as a 3 without ever settling it. Move to pass/fail as Husain advises, and let the nuance live in the comment.

The third trap is letting the generating model grade itself. The generator's errors and the judge's errors can then coincide, so you cannot tell them apart. The fix is simply to switch to a different grading model, then remeasure TPR and TNR.

The costliest trap is reporting only combined agreement. The sign is the 82.5% above: it looks fine while 6 wrong answers slip through. Every time you change the rubric or add few-shot examples, report both numbers separately.

## How does this skill show up on site and on a CV?

On the client's site, what earns trust in the assistant is not a slick demo but a set of 40 cases labelled by their own expert, with TPR and TNR alongside. When the client adds new documents, you only need to add cases and recalibrate the judge.

When reading FDE job descriptions, look for phrases such as "evals", "LLM-as-judge" or "working with subject-matter experts". On a CV, one concrete line carries far more weight than "experience with LLMs". For example: "built a pass/fail rubric with a domain expert, raising the judge's TNR from X to Y".

The cheapest way to learn is to do it on a personal project. Find someone who knows a domain better than you and ask them to grade 20 answers. Your first rubric won't be perfect, but at least it will measure against the client's own standard.

**Try this week:**

- Pick 20 real questions from the logs of an assistant you are working on, and ask a domain expert to grade each pass/fail with a one-sentence comment
- Add a refusal clause with a fixed fallback sentence to the system prompt, then test it with three questions the documents certainly don't cover
- Run the judge on those same 20 questions and compute TPR and TNR against the expert's labels

## Sources

- [Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations)

- [Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

- [LLM Rubric | Promptfoo](https://promptfoo.dev/docs/configuration/expected-outputs/model-graded/llm-rubric)

- [Refusal](https://arize.com/docs/phoenix/evaluation/pre-built-metrics/refusal)

- [Using LLM-as-a-Judge For Evaluation: A Complete Guide](https://hamel.dev/blog/posts/llm-judge/)

- [OpenAI Model Spec (2025/02/12)](https://model-spec.openai.com/2025-02-12.html)