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; 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 repository, alongside the rest of the deployment packaging. Clone it and change into the recipe directory:

git clone 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 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 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:

export AGLEDGER_API_URL=https://agledger.internal.example
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)
...

Re-running is safe: a backward-compatible change to a type registers a new version, and 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; 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.

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.

The insurance recipe was validated end-to-end against API v1.0.3 on live cloud infrastructure (cold blind-agent drivability, multiple agent models, scale, live Notify, and offline chain verification). The contract-type registration, versioning, and webhook shapes are owned by the API reference; confirm field-level detail there against your own Server.