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

# Policies

> Latch domain policies onto an agent on top of the always-on enterprise baseline.

Policies are declarative. Each one names the consequential actions it governs,
the verifiers it runs, and the verdict every situation maps to, so a latch's
behavior is auditable *before* it ever fires.

## Baseline vs. attached

Every workspace carries an **enterprise baseline** that sits under every agent
and cannot be un-latched:

| ID        | Latch                                       |
| --------- | ------------------------------------------- |
| `latch-0` | User Confirmation Policy                    |
| `latch-1` | Regulated Product & Substance Authorization |
| `latch-2` | High-Risk Recommendation Escalation         |
| `latch-3` | Eligibility & Coverage Determination        |
| `latch-4` | Refund & Billing Exception Authorization    |
| `latch-5` | Payment & Funds Movement Authorization      |

On top of the baseline you **attach** domain packs per agent. The effective set
the PDP evaluates is the union:

```
attachedPolicyIds = ENTERPRISE_BASELINE_POLICY_IDS ∪ agent.policyIds
```

Common packs: `pci-0` (Cardholder Data Protection), `reliability-3` (Human
Escalation on Risk), `reliability-4` (Fail-Closed Defaults), plus industry
families such as `healthcare-*`, `finance-*`, and `insurance-*`. The
[cookbooks](/control-plane/cookbooks/healthcare) show the industry packs in
context.

## Attach policies

<CodeGroup>
  ```bash CLI theme={null}
  akhara policies attach support-ai pci-0 reliability-3
  ```

  ```http HTTP theme={null}
  PUT /api/agents/support-ai/policies
  Content-Type: application/json

  { "policyIds": ["pci-0", "reliability-3"] }
  ```
</CodeGroup>

Policy IDs follow `family-index` (`pci-0`, `healthcare-2`) or `custom_<slug>`
for org-authored packs.

## From policy to verifier

A pack starts as policy prose (a regulation, a contract clause, an internal
rule) and is crafted into machine-checkable parts:

1. **Extract the conditions.** Each obligation in the prose becomes one
   testable check, a [verifier](/control-plane/onboarding/verifiers).
2. **Map the verdicts.** Decide ahead of time which situations `ALLOW`, `WARN`
   (with a rewrite), `BLOCK`, or `ESCALATE`.
3. **Name the actions it governs.** The pack latches only onto those
   consequential actions; everything else passes through untouched.

## Anatomy of a policy pack

```json theme={null}
{
  "id": "pci-0",
  "name": "Cardholder Data Protection",
  "family": "pci",
  "blurb": "Masking and minimization of cardholder data on customer surfaces.",
  "tags": ["PCI", "cardholder-data", "context-egress"],
  "checks": [
    "PAN masked before display",
    "No CVV in output or logs",
    "Cardholder data minimized on context egress"
  ],
  "verdicts": [
    { "verdict": "BLOCK", "when": "output contains an unmasked PAN or any CVV" },
    { "verdict": "WARN",  "when": "context egress includes non-essential cardholder fields",
      "rewrite": "redact non-essential cardholder data" },
    { "verdict": "ALLOW", "when": "cardholder data is masked and scoped to the task" }
  ],
  "requirements": ["PCI DSS 3.3", "PCI DSS 3.4"]
}
```

| Field            | Purpose                                                                                                           |
| ---------------- | ----------------------------------------------------------------------------------------------------------------- |
| `checks[]`       | Each string becomes a runtime **verifier** in the registry. See [Verifiers](/control-plane/onboarding/verifiers). |
| `verdicts[]`     | The verdict-behavior mapping: what fires and when.                                                                |
| `requirements[]` | Source law/reg/contract, shown at the bottom of the pack in the console.                                          |

## The verdict-behavior mapping

This is the part enterprises care most about: it makes the latch's decision
legible ahead of time. Each policy exposes its `ALLOW / WARN / BLOCK / ESCALATE`
conditions so reviewers can see exactly when an agent will be stopped.

```mermaid theme={null}
flowchart LR
    subgraph pci-0
        direction TB
        A["cardholder data masked & scoped"] -->|ALLOW| a1["deliver"]
        W["egress includes non-essential fields"] -->|WARN| w1["rewrite + deliver"]
        B["unmasked PAN in output"] -->|BLOCK| b1["withhold"]
    end
```

## Baseline behavior by stage (reference deployment)

How the shipped policies decide at each [stage](/control-plane/concepts/architecture#the-five-enforcement-stages):

| Stage            | Behavior                                                                                                                                                                     |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `input`          | Requests for prohibited or regulated products → `BLOCK` (`latch-1`); otherwise `ALLOW`.                                                                                      |
| `context_egress` | With a privacy pack attached, minimize sensitive fields → `WARN` + rewritten content; otherwise `ALLOW`.                                                                     |
| `output`         | Cross-customer personal data → `BLOCK` (`latch-0`); high-risk recommendation language → `WARN` (`latch-2`); emergency language → `ESCALATE` (`reliability-3`); else `ALLOW`. |
| `delivery`       | Empty content → `BLOCK`; otherwise `ALLOW`.                                                                                                                                  |
| `action`         | Only declared consequential tools are eligible; the governing latch's checks → `BLOCK` / `ESCALATE` / `ALLOW` + permit.                                                      |

## Custom policies

Packs authored in the console are stored client-side
(`localStorage: akhara-custom-policies`) for design and preview. To make a custom
pack **enforce at runtime**, publish it so the PDP loads it server-side. See the
[publish flow](/control-plane/onboarding/tasks#publish).

<Card title="Next: craft verifiers" icon="clipboard-check" href="/control-plane/onboarding/verifiers">
  Author the individual checks your policies run.
</Card>