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

# Latching

> How a dormant policy snaps onto a consequential step and returns a binding verdict.

Latching is the behavior that distinguishes Akhara from a prompt guardrail. A
policy is **dormant by default** and carries no cost until an agent attempts the
specific consequential action it governs. At that moment it **latches** onto the
step and the agent cannot proceed without a verdict.

## The effective policy set

For any `authorize` call, the PDP evaluates the union of the always-on baseline
and the policies attached to that agent:

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

```mermaid theme={null}
flowchart TB
    subgraph Base["Enterprise baseline: always attached"]
        L0["latch-0 · User Confirmation"]
        L1["latch-1 · Regulated Product & Substance"]
        L2["latch-2 · High-Risk Recommendation Escalation"]
        L3["latch-3 · Eligibility & Coverage"]
        L4["latch-4 · Refund & Billing Exception"]
        L5["latch-5 · Payment & Funds Movement"]
    end
    subgraph Agent["Attached to support-ai"]
        P0["pci-0 · Cardholder Data Protection"]
        R3["reliability-3 · Human Escalation on Risk"]
    end
    Base --> EFF["Effective set the PDP evaluates"]
    Agent --> EFF
```

## When a latch fires

Evaluation happens at the five [enforcement stages](/control-plane/concepts/architecture#the-five-enforcement-stages).
The engine matches the stage, the content, and (for actions) the normalized
tool name against each attached policy.

```mermaid theme={null}
flowchart TD
    S["authorize(stage, content, tool)"] --> N{"Known stage?"}
    N -- no --> FC["BLOCK · Fail-Closed Defaults"]
    N -- yes --> M{"Any latch matches<br/>this step?"}
    M -- no --> AL["ALLOW · continue"]
    M -- yes --> V["Evaluate matched latch<br/>→ ALLOW / WARN / BLOCK / ESCALATE"]
    V --> EV["Write verdict to evidence feed"]
```

## Worked example: the refund latch

`latch-4` (Refund & Billing Exception Authorization) governs the
`refund_payment` tool. Watch it stay dormant, then latch:

<Steps>
  <Step title="Answering an order question, dormant">
    `checkOutput("your order shipped Tuesday")` matches no consequential
    action. Verdict: `ALLOW`. `latch-4` never fires.
  </Step>

  <Step title="Refund requested, latch engages">
    `authorizeAction("refund_payment", { orderId, amount })` matches
    `latch-4`. The PDP checks the amount against the auto-approval limit and
    the session's verification state.
  </Step>

  <Step title="Verdict binds the action">
    * Within limit, identity verified → `ALLOW` **+ `permitId`**
    * Over the limit → `ESCALATE` (route to a supervisor)
    * Identity not verified → `BLOCK`
  </Step>

  <Step title="Permit gates the side effect">
    `paymentService.submit(refund, permitId)` refuses to run without the
    permit, so a blocked/escalated action can't leak through.
  </Step>
</Steps>

For the same lifecycle applied to prescriptions, card cancellation, and claim
payouts, see the [cookbooks](/control-plane/cookbooks/healthcare).

## Tool normalization

Latches match on a **canonical** tool name, so your agent's naming doesn't have
to match the catalog. The PDP trims, lowercases, and applies aliases before
matching:

| Your agent emits     | Akhara matches   |
| -------------------- | ---------------- |
| `issue_refund`       | `refund_payment` |
| `refund_order`       | `refund_payment` |
| `check_order_status` | `order_status`   |
| `account_update`     | `update_account` |

Declare tools with whatever names your agent already uses. See
[Agents](/control-plane/onboarding/agents).