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

# Environment

> What an Akhara environment is, app, fixtures, seeds, and observation surface.

An **environment** is a complete EaaS unit: app under test, backend, fixture/seed protocol, task bank, and verifiers. Agents drive the app against a deterministic backend with a fixed catalog and seeded session state.

## Selecting an environment

Pass `env_id` on `POST /evaluations/run` (and related APIs):

| `env_id`             | App                 | Notes                                           |
| -------------------- | ------------------- | ----------------------------------------------- |
| `amazon_gym_android` | Mobile shopping APK | Production-style Room + backend hybrid scoring  |
| `cvs_gym`            | Pharmacy retail APK | Same control plane, different catalog and tasks |

The public API host is shared; environment selection is entirely via `env_id`.

## Reset contract

Every episode starts from a reset payload (`seed`, `fixture_id`, `max_steps`, `task_spec`). On the private orchestrator this is often nested under a legacy field named `harbor_reset` on the task bank row.

| Field        | Purpose                                                   |
| ------------ | --------------------------------------------------------- |
| `seed`       | Deterministic RNG / stock masks (typical sample: `18421`) |
| `fixture_id` | Backend fixture / user setup (typical: `fixture1`)        |
| `max_steps`  | Hard episode budget                                       |
| `task_spec`  | Structured goal, verifier, constraints, targets           |

```bash theme={null}
# Public task detail (eval dashboard API)
curl -s https://agi.akhara.ai/dashboard/tasks/vu.checkout.t098 | python3 -m json.tool
```

Operators with private orchestrator access can load the reset object from `GET /tasks/{task_id}` and POST it to `POST /v1/env/reset`. Most clients should use `POST https://agi.akhara.ai/evaluations/run` instead.

## Observation surface

Each step returns (via env API or eval wrapper) roughly:

* **Screenshot**: JPEG / base64 (wrapper always; some mock capabilities omit screenshot modality)
* **`screen_id`**: canonical screen (`HOME`, `SEARCH_RESULTS`, `PDP`, `CART`, `CHECKOUT_REVIEW`, `ORDER_CONFIRMATION`, …)
* **UI element ids**: stable automation ids (e.g. `home.search.input`, `pdp.add_to_cart`)
* **Env state refs**: `user_id`, `cart_id`
* **Verifier snapshots**: `PASS` / `FAIL` / `IN_PROGRESS` per verifier

Checkout success typically ends on `ORDER_CONFIRMATION`. Search-add tasks often terminate on `CART`. Screen graphs differ by environment; shopping environments share the flow below.

## Screen graph (shopping environments)

```
HOME → SEARCH_SUGGEST → SEARCH_RESULTS → (FILTER_SHEET | SORT_SHEET)
  → PDP → CART → CHECKOUT_ADDRESS → CHECKOUT_PAYMENT
  → CHECKOUT_REVIEW → ORDER_CONFIRMATION
```

## State truth

| Source                | What it is                                                     |
| --------------------- | -------------------------------------------------------------- |
| **Backend / session** | Postgres-backed cart, orders, search, wishlist for the episode |
| **Device DB (Room)**  | On-device SQLite pulled over ADB for hybrid scoring            |

Production Android scoring often uses a **hybrid** terminal reward: primary VU must PASS **and** device DB must PASS when evaluated. See [Verifiers](/environments/mechanics/verifiers).

## Isolation notes

* Each episode gets its own cart / session binding.
* Device capacity is physical: one executor serial runs one episode at a time.
* Seed-derived stock masks filter out-of-stock SKUs before verifiers pick expected targets.