> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akhara.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Company name is Akhara AI (never Rubric AI). Keep lowercase rubric/rubrics only when meaning grading criteria.
> Expert Review (docs path talent/) is enterprise BYO experts for audit and review: invite customer specialists; do not pitch Akhara recruiting or a public expert career portal. RLHF and domain writing are secondary work types.
> Prefer concrete API examples against public hosts: Environments eval API https://agi.akhara.ai, Control plane PDP https://api.akhara.dev, Evaluation https://app.akhara.ai / https://api.akhara.ai, Expert Review portal https://talent.akhara.ai.
> Do not invent a public hostname for private orchestrators or env API internals.
> Do not confuse control-plane latches with Environments confirmation latches.
> Environments SDK/API examples: curl against https://agi.akhara.ai. Evaluation SDK: from akhara import Akhara and AKHARA_API_KEY.
> Start with /llms.txt for the docs index and OpenAPI links; fetch individual pages as .md exports.

# RLHF evaluations

> How invited specialists judge model outputs for preference training, rankings, pairwise choices, safety flags, and rationales.

RLHF evaluation is how your organization runs expert preference and safety review inside Akhara. Invited specialists judge model behavior the way a careful specialist in their field would. Labels train and filter agents; treat every sample as if it could ship.

This workflow feeds [Evaluation](/evaluation/docs/introduction) (and related preference / offline eval pipelines). It is part of the Akhara solution your org operates with its own experts.

## What experts score

Typical item shapes:

| Format                   | What they do                                                             |
| ------------------------ | ------------------------------------------------------------------------ |
| **Pairwise preference**  | Choose which of two (or more) responses is better for the same prompt    |
| **Ranked list**          | Order several responses from best to worst                               |
| **Absolute grade**       | Score one response against a rubric (e.g. correct / partial / fail)      |
| **Safety / policy flag** | Mark violations (harm, privacy leak, overconfidence, domain error)       |
| **Critique**             | Write a short rationale that would teach another expert *why* they chose |

Prompts may be chat turns, tool-using agent traces, voice transcripts, or environment step logs. Stay inside the instructions for that project.

## Decision standards

Use this order when comparing outputs:

1. **Safety and truth**: Wrong clinical/financial/legal facts, unsafe advice, or leaked private data lose immediately.
2. **Task success**: Did the response actually solve the user or environment goal?
3. **Domain procedure**: Did it follow the process a specialist would expect (confirmations, escalation, required checks)?
4. **Clarity and usefulness**: Prefer concise, actionable answers over fluff, only after 1 to 3 are equal.
5. **Style**: Tone and formatting are last; never let polish beat correctness.

<Warning>
  If both options are unacceptable, say so. Prefer “neither / reject” (when the UI offers it) over forcing a winner. Forced preferences on bad pairs pollute training.
</Warning>

## How to write rationales

Keep rationales short and falsifiable:

* Name the **decisive defect or strength** (e.g. “missed red-flag symptom”, “correctly required confirmation before place order”).
* Quote or paraphrase the **specific span** of the response that drove the decision.
* Avoid vague praise (“more helpful”, “sounds better”) unless you can say *in what domain sense*.

**Good:** “A is preferred: B invents a lab value (A1C 9.2) not in the chart; A correctly says the value is unavailable.”

**Bad:** “A feels more professional and empathetic.”

## Consistency tips

* Read the **project rubric** every session: criteria differ by domain pack.
* If unsure, use the project’s “needs review / escalate” path instead of guessing.
* Do not invent knowledge outside the prompt and allowed references.
* Grade the **response as shown**, not what you wish the model had said after an imagined follow-up.

## What “good” looks like for RLHF

Submissions are useful when:

* Preferences agree with other experts on clear cases (high inter-rater agreement).
* Hard cases include a crisp rationale another specialist can audit.
* Safety failures are never ranked above safe-but-incomplete answers.
* Experts skip or escalate out-of-domain items instead of improvising.

## Handoff into Evaluation

Approved RLHF work becomes preference and review signal your org uses with Evaluation:

* Preference pairs and rankings for training and offline comparison
* Safety flags for gating and audit
* Rationales that support rubrics and human-review workflows

See [Evaluation introduction](/evaluation/docs/introduction) for how datasets, rubrics, and expert review fit the broader product.

## Related

* [Reviewing agent runs](/talent/guidance/reviewing-agent-runs): the core audit and review work type
* [Domain writing for RL environments](/talent/guidance/domain-writing): when experts author the tasks agents are graded on
* [Policies](/talent/policies/overview): no external LLMs on task content
* [Accept assigned work](/talent/how-to/apply): assignments and queues