> Markdown version of https://agledger.ai/docs/guides/recipes/
> Full index of this site for AI assistants: https://agledger.ai/llms.txt

# Install an industry recipe

A recipe is a tested set of contract types for a whole domain workflow, packaged so you import it into your own Server and adapt it - a head start instead of designing every schema from a blank editor. It is a starting point you own, not a turnkey product. For what recipes are and which verticals exist, see the [recipes overview](/recipes/); this guide is the mechanical how-to for installing one.

The worked example here is the **insurance** auto-claims recipe, the validated reference vertical. Every recipe installs the same way.

## Get the recipe

Recipes ship as plain files in the [`agledger-ai/install`](https://github.com/agledger-ai/install) repository, alongside the rest of the deployment packaging. Clone it and change into the recipe directory:

```bash
git clone --branch v1.8.0 https://github.com/agledger-ai/install.git
cd install/examples/recipes/insurance
```

The directory is self-contained: a `types/` folder of contract-type registration bodies, a `register.sh` that loads them, a `notify.yaml` describing the webhook subscriptions the recipe expects, and a `README.md`.

## What you need first

- **A running AGLedger Server you administer.** If you do not have one yet, the [Compose quick install](/docs/install/compose/) gets you there in a few minutes.
- **An admin or platform key carrying the `schemas:write` scope.** Because you administer your own Server, you are the platform admin of it - registering these types *is* the install; there is no external registry or shared signing infrastructure. See [Authentication](/docs/guides/authentication/) for minting a key.

## Register the contract types

Point the recipe at your Server with two environment variables and run the loader. It registers each type with `POST /v1/schemas` in dependency order:

```bash
export AGLEDGER_API_URL=https://agledger.example.com
export AGLEDGER_API_KEY=agl_...   # admin/platform key with schemas:write
./register.sh
```

On a fresh org each type lands as a clean `v1`:

```
OK   201  meridian-claim-intake-v1  (lifecycle=notarize-only, v1)
OK   201  meridian-coverage-check-v1  (lifecycle=notarize-only, v1)
...
OK   201  meridian-authority-band-v1  (lifecycle=auto, v1)
OK   201  meridian-settlement-decision-v1  (lifecycle=principal, v1)
...
```

Schema writes are rate-limited to 10 per minute per key, and `register.sh` handles a 429 for you: it waits the `retryAfterSeconds` the Server states and tries again, up to five retries per type, printing `WAIT 429 <type>` each time it does. The two largest recipes register ten types, so a quiet org can still trip the limit; the wait is the script working, not stalling. Past five retries the type prints `FRIC 429 <type>`, the loader continues with the rest, and the script exits non-zero, leaving a partial install. Recover by registering the missing `types/*.json` individually once the window passes - each is a single `POST /v1/schemas` call - or by re-running the whole script.

Re-running the whole script is safe but not a no-op: re-registering a type that already landed registers a **new version** of it, even with an unchanged body, so after a partial install a full re-run leaves the already-landed types at v2 while the stragglers land at v1. Records are unaffected either way. An incompatible change is rejected by the type's compatibility mode and printed as friction rather than silently applied. The per-call mechanics - preview before persisting, compatibility modes, and versioning - are owned by [Define Custom Types](/docs/guides/schemas/#evolve-a-type-safely); `register.sh` is just a loop over `POST /v1/schemas`, so you can register the same `types/*.json` by hand or from CI if you prefer.

## What you installed

The insurance recipe is ten contract types. Eight are **notarize-only** - they record what happened and terminalize in one signed call (intake, coverage, damage and bodily-injury assessment, fraud score, SIU referral, settlement outcome, reserve). Two are **gates** whose output has to conform:

- **`meridian-authority-band-v1`** is an auto-gate: the **engine** compares the agent's proposed amount against an operator-configured ceiling and settles `FULFILLED` within authority or `FAILED` over it. The agent cannot assert its way past the ceiling, and an over-authority attempt is still recorded, attributed, and tamper-evident.
- **`meridian-settlement-decision-v1`** is a principal-gate: the human override path, entered only when the band check returned `FAILED`. A human supervisor renders the verdict.

Beyond that linear spine, the types model **multi-exposure** claims (one accident, several exposures settling independently under one claim number via `exposureId`), **reserves** with revision history, and **appeals**. The `README.md` in the recipe lays out the full table and the authority model.

## Wire up Notify

`notify.yaml` lists the webhook subscriptions the recipe expects - a claims-operations channel and an SIU/fraud channel. Create each one against your Server with `POST /v1/webhooks`, swapping the `example.com` URLs for endpoints you control. The signing secret is returned once at create time. The delivery, signing, and verification mechanics are in the [Webhooks guide](/docs/guides/webhooks/).

## Adapt it

Imported types are ordinary, editable contract types under your org - keep, edit, rename, or delete any of them. AGLedger ships a deliberately minimal core rather than opinionated built-in types, so a recipe is a head start you own, not a platform-managed type kept in lockstep with your business. Reshape the schemas, drop the steps you do not need, and add your own.

## Air-gapped

A recipe is files. Once the `install` directory is on the target host, `register.sh` talks only to the `AGLEDGER_API_URL` you give it - your own Server - and makes no outbound calls to any registry, our website, Docker Hub, or npm. Clone the repo on a connected machine, carry it across, and install offline.