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

# Cookbook: insurance

> Gate claim payouts on adjuster approval, an in-force policy, and a verified payee, with escalation above a threshold.

A claims agent walks policyholders through filing, checks status, and can
trigger a payout once a claim is approved. Moving money against a claim is the
consequential action: it requires an adjuster's approval on file, a policy that
is in force, and a verified payee. Large payouts always go to a human.

This cookbook shows a latch with all four [verdicts](/control-plane/concepts/verdicts)
in play: `ALLOW` with a permit, `BLOCK` on missing prerequisites, `ESCALATE`
above a threshold, and `WARN` at the text stages.

## The scenario

* Agent `claims-ai` with tools `claim_status`, `update_claim`, `pay_claim`.
* The consequential action is `pay_claim`. Status checks and documentation
  updates never engage the payout latch.
* The runtime passes the claim's state (approval, policy status, payee
  verification, amount) as `args`, so the PDP decides on the full context. See
  [what crosses to the PDP](/control-plane/concepts/interception#what-crosses-to-the-pdp).

## The policy in prose

> A claim payout may be executed only when a licensed adjuster has approved the
> claim, the policy is in force as of the loss date, and the payee account has
> been verified. Payouts above \$25,000 require human sign-off regardless of
> approval state. A payout missing any prerequisite is blocked.

## Crafted into a policy pack

```json theme={null}
{
  "id": "insurance-0",
  "name": "Claims Payout Authorization",
  "family": "insurance",
  "blurb": "Approval, coverage, and payee checks in front of claim payouts.",
  "tags": ["claims", "payouts", "action"],
  "checks": [
    "Adjuster approval on file",
    "Policy in force at loss date",
    "Payee account verified",
    "Amount within agent payout threshold"
  ],
  "verdicts": [
    { "verdict": "ALLOW", "when": "approved, in force, payee verified, amount within threshold" },
    { "verdict": "ESCALATE", "when": "amount exceeds threshold" },
    { "verdict": "BLOCK", "when": "approval, coverage, or payee verification missing" }
  ],
  "requirements": ["State unfair claims practices acts", "Carrier claims-handling guidelines"]
}
```

```bash theme={null}
akhara policies attach claims-ai insurance-0 reliability-3
```

## Authorize a payout

An approved, in-force, verified claim under the threshold:

```bash theme={null}
curl -s https://api.akhara.dev/api/policy/authorize \
  -H "authorization: Bearer $AKHARA_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "agentId": "claims-ai",
    "session": "sess_demo",
    "stage": "action",
    "tool": "pay_claim",
    "args": {
      "claimId": "clm_5108",
      "amount": 4820.00,
      "adjuster_approved": true,
      "policy_in_force": true,
      "payee_verified": true
    }
  }' | jq
```

```json theme={null}
{
  "verdict": "ALLOW",
  "stage": "action",
  "policyId": "insurance-0",
  "rule": "Claims Payout Authorization",
  "reason": "Adjuster approval, coverage, payee verification confirmed; amount within threshold",
  "tool": "pay_claim",
  "permitId": "permit_6b02f9a7",
  "attachedPolicyIds": ["latch-0", "latch-5", "insurance-0", "reliability-3"]
}
```

The payout service requires the one-time `permitId`, so nothing pays out on a
code path that skipped authorization.

## Escalate above the threshold

The same claim at \$48,200 crosses the threshold. Approval state does not
matter; the latch routes it to a human:

```json theme={null}
{
  "verdict": "ESCALATE",
  "stage": "action",
  "policyId": "insurance-0",
  "rule": "Claims Payout Authorization",
  "reason": "Amount exceeds agent payout threshold; human sign-off required",
  "tool": "pay_claim",
  "permitId": null,
  "attachedPolicyIds": ["latch-0", "latch-5", "insurance-0", "reliability-3"]
}
```

Your runtime holds the payout pending a reviewer; nothing executes while the
decision is `ESCALATE`. A missing prerequisite, for example
`payee_verified: false`, returns `BLOCK` instead.

## What the latch does at runtime

During filing and status conversations, `insurance-0` is dormant. It engages
only on `pay_claim`, evaluates the claim state the runtime passed, and every
outcome, including the escalations a regulator will ask about, lands in the
evidence feed as a signed, joinable record tied to the session's trajectory.
See [Audit and evidence](/control-plane/concepts/evidence).