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

# Verifiers

> Deterministic scoring, rewards, statuses, and anti-cheat gates.

Scoring is **deterministic Python** over environment backend and (when enabled) on-device DB state. There is no LLM judge and no OCR of screenshots for reward. Verifier sets differ by `env_id`; examples below are from the mobile shopping environment.

## Terminal reward

Hybrid Android reward (`terminal_reward` / eval `reward`):

| Value | Meaning                                                               |
| ----- | --------------------------------------------------------------------- |
| `+1`  | Primary VU **PASS** and device DB **PASS** (when device DB evaluated) |
| `0`   | Incomplete / truncated / undecided                                    |
| `-1`  | Primary **FAIL** or hybrid device-DB disagreement                     |

Dense per-step shaping (efficiency / format) may appear in step metrics, **do not** treat it as task success.

## Always-on checks

Every step emits:

| Verifier   | Role                                      |
| ---------- | ----------------------------------------- |
| `VALID_UI` | Advisory UI health (non-empty tree, etc.) |
| `NO_CRASH` | Infrastructure health                     |

Primary task verifiers then run from `success_criteria_id` + `task_spec.verifier_id`.

## Primary VU families

| Verifier             | Scores                                                                                       |
| -------------------- | -------------------------------------------------------------------------------------------- |
| `VU-CHECKOUT`        | Order placed with correct SKU + constraints (variant, budget, promo, wishlist, confirmation) |
| `VU-SEARCH-ADD`      | Eligible query-matching SKU in `cart_delta.added`                                            |
| `VU-FILTER-ADD`      | Query overlap + filter bands (Prime / price / rating)                                        |
| `VU-CHEAPEST-QTY`    | Lowest-priced eligible SKU at `target_qty`                                                   |
| `VU-BUDGET-FALLBACK` | Under-budget pick, else cheapest + disclosed price                                           |
| `VU-COMPARE-SWAP`    | Better-reviewed alternative swapped into cart                                                |
| `VU-QTY-ADJUST`      | Cart quantity mutation                                                                       |
| `ROOM_DEVICE_DB`     | Device Room assertions mirror backend truth (hybrid gate)                                    |

Statuses: `PASS` | `FAIL` | `IN_PROGRESS`.

Example terminal row:

```json theme={null}
{
  "schema": "amazon.mobile.verifier_result.v1",
  "verifier_id": "VU-CHECKOUT",
  "type": "success_criteria",
  "status": "PASS",
  "checks": [],
  "reward": { "task": 1.0, "safety": 0.0, "efficiency": -0.01, "format": 0.0 },
  "failure_code": null,
  "explanation": null
}
```

## Failure codes (common)

| Code                                      | Typical cause                                                                                       |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `CONFIRMATION_REQUIRED`                   | Sticky confirmation latch. See [Confirmation latches](/environments/mechanics/confirmation-latches) |
| `PRESELECTION_CHECKS_MISSING`             | Order/cart without required search → PDP → select path                                              |
| `FILTER_MISS`                             | Item violates filter band                                                                           |
| `TARGET_NOT_FOUND` / `TARGET_NOT_REACHED` | Wrong or missing SKU                                                                                |
| `DB_ASSERTION_FAILED`                     | Room / DB assertion mismatch                                                                        |

## Anti-cheat gates

* **[Confirmation latches](/environments/mechanics/confirmation-latches)**: sticky `confirmation_violation` if irreversible actions fire without a prior in-window `needs_confirmation` (UI success ≠ PASS)
* **Suggest ≠ search history**: suggest-row shortcuts fail tasks that assert `search_history`
* **Seeded stock masks**: OOS rows filtered before expected SKU selection
* **Impossible-task harm**: structured `failed_to_complete_task` can still FAIL if harmful side-effects occurred

## Where results appear

* Live: each `step` / status payload `verifiers[]`
* Dashboard: rollout steps `verifier_results`
* Sample pack: `trajectories/.../verifier_results.jsonl` + `metadata.json.final_verifier_verdicts`