> ## 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.

# Domain writing for RL environments

> How invited specialists author scenarios, goals, and success criteria that become tasks in your org’s Akhara RL environments.

Domain writing is the enterprise task-authoring pipeline: your specialists create material **only in their specialty** that later runs as graded work inside [Environments](/environments). They build the world the agent must succeed in. They are not grading a finished model response (that is [RLHF evaluation](/talent/guidance/rlhf-evaluations)).

This workflow is part of the Akhara solution your org runs. Invited experts follow the same standards so writing hands off cleanly into task banks and verifiers.

## What experts produce

Projects vary, but most writing packs ask for some of:

| Artifact                        | Purpose in the environment                                         |
| ------------------------------- | ------------------------------------------------------------------ |
| **Scenario / seed**             | Starting state: user goal, constraints, fixtures, catalog facts    |
| **Task instruction**            | What the agent is told to accomplish                               |
| **Success criteria**            | Observable conditions for pass (state, not prose vibes)            |
| **Failure modes**               | Common wrong paths you want scoring to catch                       |
| **Confirmation / safety notes** | Irreversible actions that need an explicit confirm step            |
| **Gold outline** (optional)     | A valid high-level solution path, not a script the agent must copy |

Downstream, Akhara turns approved writing into environment tasks, verifiers, and sometimes sample trajectories. Write so a verifier engineer can implement checks without guessing intent.

## Stay in domain

* Only accept writing projects that match specialties on the expert [profile](/talent/how-to/setup-profile).
* Prefer concrete, checkable facts from the practice area (catalog rules, clinical workflows, retail policies, etc.).
* If the brief drifts outside expertise, stop and flag it. Do not invent adjacent-domain content.

## Writing success criteria

Good success criteria are **stateful and binary**:

* Prefer: “Cart contains SKU X with qty 2 and a saved shipping address in CA.”
* Prefer: “Visit booked with Dr. Jones on the stated date; no duplicate booking.”
* Avoid: “Agent was helpful” or “User seems satisfied.”

Include negatives when they matter:

* “Must not place the order without a prior confirmation turn.”
* “Must not disclose another patient’s identifiers.”

<Tip>
  If you cannot say how a machine would check your criterion from app/session state, rewrite it until you can.
</Tip>

## Scenario quality checklist

Before submitting a writing item, confirm:

1. Single primary goal: one clear win condition
2. Constraints listed (budget, location, policy, safety)
3. Ambiguities intentional or removed: no accidental underspec
4. Success criteria map to observable outcomes
5. At least one realistic failure mode called out
6. No PHI / secrets / real customer data: use synthetic fixtures only
7. Language matches the project style guide

## Example sketch (shopping-style)

Not every project uses retail; this shows the shape:

```text theme={null}
Goal: Buy two units of item "Wireless Mouse M2" under $40 each,
      ship to the saved home address, place the order.

Constraints:
- Prefer Amazon-fulfilled if both options exist
- Do not use gift cards
- Confirm before place order

Success:
- Order exists with M2 qty=2
- Unit price ≤ 40
- Shipping address = saved home
- Confirmation emitted before place_order

Fail if:
- Wrong SKU variant
- Qty ≠ 2
- Order placed with no confirmation
```

Your domain pack will replace products, clinical entities, or policies. Keep the same precision.

## Handoff into Environments

Approved writing feeds your org’s environment task banks:

1. Specs land as tasks and success criteria your team (or Akhara) implements as verifiers
2. Agents run against those tasks via the [Environments](/environments) eval path
3. Trajectories and rewards close the loop for training and regression

For how environments score sessions, see [Environments overview](/environments) and [task definitions](/environments/mechanics/task-definitions).

## How writing differs from RLHF work

|                | Domain writing                     | RLHF evaluation                     |
| -------------- | ---------------------------------- | ----------------------------------- |
| Experts create | Tasks / scenarios / criteria       | Labels on model outputs             |
| Time horizon   | Upstream of training and env banks | On live or batch model samples      |
| Quality bar    | Implementable, unambiguous specs   | Consistent preferences + rationales |

Many invited specialists do both. Switch mindset when the task type changes.

## Related

* [Reviewing agent runs](/talent/guidance/reviewing-agent-runs)
* [RLHF evaluations](/talent/guidance/rlhf-evaluations)
* [Environments overview](/environments): where written tasks eventually run
* [Policies](/talent/policies/overview)