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. They build the world the agent must succeed in. They are not grading a finished model response (that is RLHF evaluation).

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.
• 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.”

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

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:

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 eval path
3. Trajectories and rewards close the loop for training and regression

For how environments score sessions, see Environments overview and 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
• RLHF evaluations
• Environments overview: where written tasks eventually run
• Policies