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

# How it works

> How the Akhara products work together: author verifiers and rubrics at build time, gate changes in CI, verify at runtime, and feed production back into evals.

Akhara is one lifecycle across four products. You author checks before you build, gate every agent change in CI, enforce policy while the agent runs, and feed what production teaches you back into the checks. This page walks the loop end to end and shows which artifacts move between products.

## The lifecycle

```mermaid theme={null}
flowchart LR
  B["Build<br/>author rubrics, tasks,<br/>verifiers, policies"] --> G["Gate<br/>eval suites and simulation<br/>runs in CI"]
  G --> R["Run<br/>gateway verdicts and<br/>signed evidence"]
  R --> L["Learn<br/>experts audit runs,<br/>tighten the checks"]
  L --> B
```

| Stage | Product                                                                                                                                            | Key artifacts                                   |
| ----- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Build | [Evaluation](/evaluation/docs/introduction), [Environments](/environments), [Control plane](/control-plane), [Expert Review](/talent/introduction) | Datasets, rubrics, tasks, verifiers, policies   |
| Gate  | [Evaluation](/evaluation/docs/tutorials/ci-cd), [Environments](/environments/api/evaluations)                                                      | Scores, terminal rewards, pass/fail gates       |
| Run   | [Control plane](/control-plane)                                                                                                                    | Verdicts, permits, signed evidence              |
| Learn | [Expert Review](/talent/introduction), [Evaluation](/evaluation/docs/introduction)                                                                 | Audited trajectories, updated rubrics and tasks |

## Build: author the checks

Everything downstream runs on artifacts you author from your own policies, regulations, and domain knowledge:

* **Datasets and rubrics** in Evaluation define what good looks like before you build. See [datasets](/evaluation/api-reference/datasets/overview) and [rubrics](/evaluation/api-reference/rubrics/overview).
* **Tasks and verifiers** in Environments turn those definitions into scored, simulated episodes. Each environment bundles an app, backend, [task definitions](/environments/mechanics/task-definitions), and [verifiers](/environments/mechanics/verifiers) that score session and device state.
* **Policies** in the control plane encode which actions are consequential and what must hold before they execute, including [latches](/control-plane/concepts/latching) that activate only on the action they govern. See [policy authoring](/control-plane/onboarding/policies) and [verifier crafting](/control-plane/onboarding/verifiers).
* **Domain writing** from Expert Review: your invited specialists author scenarios and success criteria in their specialty, which feed the Environments task banks. See [domain writing](/talent/guidance/domain-writing).

Artifacts are versioned, so a CI result and a runtime verdict can both point at the exact revision that produced them. See [evaluation versioning](/evaluation/docs/evaluation-framework/versioning).

## Gate: every change runs the suite

Before an agent change ships, it clears two kinds of pre-deployment checks:

1. **Eval suites** run against the Evaluation API and a threshold check fails the pipeline when scores regress. See [CI/CD quality gates](/evaluation/docs/tutorials/ci-cd).
2. **Simulation runs** in Environments score multi-step behavior in realistic, stateful apps: you call the [eval API](/environments/api/evaluations) at `https://agi.akhara.ai`, and each episode returns a terminal reward of `+1`, `0`, or `-1` plus a full trajectory. See [scores and stats](/environments/results/scores-and-stats).

A change that clears both gates is promoted. The same policies you tested against are the ones the gateway enforces once the agent is live, so there is no gap between what CI measured and what production allows.

## Run: the gateway verifies every step

At runtime, your agent passes through the Akhara gateway on every step. The PEP (an SDK in your runtime) intercepts inputs, model output, deliveries, and consequential tool calls, and asks the PDP at `https://api.akhara.dev` for a verdict: `ALLOW`, `WARN`, `BLOCK`, or `ESCALATE`. On `ALLOW` for a consequential action, the PDP mints a one-time permit; downstream services should refuse to execute without one. The PDP decides and never executes tools itself, and enforcement is [fail-closed](/control-plane/concepts/fail-closed) by default.

```mermaid theme={null}
flowchart LR
  U["Users"] --> AG["Your agent"]
  subgraph AKH ["Akhara"]
    GW["Gateway<br/>PEP enforces, PDP decides"] --> EVD[("Signed evidence")]
    EVD --> FB["Expert Review<br/>and Evaluation"]
  end
  AG -->|"proposes step"| GW
  GW -->|"verdict + permit"| AG
  AG -->|"allowed steps only"| EXT["External models,<br/>tools, and APIs"]
  style AKH fill:none,stroke:#0F0F0F,stroke-width:1px
```

Every verdict is written to an append-only evidence feed. You can [seal a decision](/control-plane/api-reference/endpoint/sign-record) and later [verify it](/control-plane/api-reference/endpoint/verify-record), so audit does not depend on trusting the logs. See the control plane [architecture](/control-plane/concepts/architecture) for the full request lifecycle.

## Learn: production feeds the next iteration

The evidence trail and captured trajectories close the loop:

* Your org-invited specialists in Expert Review [review agent runs](/talent/guidance/reviewing-agent-runs): trajectories, scores, failures, and policy-sensitive cases the automated checks flagged or missed.
* Their findings tighten rubrics, tasks, and policies, which flow back into the build-time artifacts.
* The next CI run gates against the updated suites, so a regression that production surfaced is caught before it ships again.

## What moves between products

| Artifact                | Produced by                       | Consumed by               |
| ----------------------- | --------------------------------- | ------------------------- |
| Datasets and rubrics    | Evaluation, with expert input     | CI gates, expert review   |
| Tasks and verifiers     | Environments, with domain writing | Simulation runs in CI     |
| Policies and latches    | Control plane authoring           | PDP verdicts at runtime   |
| Trajectories and scores | Environments and gateway runs     | Evaluation, Expert Review |
| Signed evidence         | Control plane at runtime          | Audit, Expert Review      |

For per-term definitions across the suite, see the [glossary](/home/glossary).