# Cookbook fixtures

Vendored Liquid templates, CSV bodies, and sample documents the
[cookbook recipes](../) and [capability docs](../) load at runtime via
`fs.readFileSync`. Organized by industry so the corpus stays
self-describing — an agent crawling this directory can list
every fixture available to every recipe in a given industry
by reading one path.

Two kinds of fixture live here: **Liquid templates** (row-mapping
templates an interoperability contract loads) and **data fixtures**
(CSV bodies and sample PDFs/images a capability walk uploads or ingests).

## Convention

Cookbook code reads fixtures via the
`COOKBOOK_FIXTURES_DIR` environment variable. The validator
(`make validate-cookbook`) exports this variable to the spawned
`bun test` process; any operator script that runs cookbook code
directly must set the same variable to the absolute path of
this directory.

```typescript
import fs from 'node:fs'
import path from 'node:path'

const LE_TEMPLATE = fs.readFileSync(
  path.join(
    process.env.COOKBOOK_FIXTURES_DIR!,
    'organic-marketing/_lead_submissions_foundation_legal_entity.liquid',
  ),
  'utf8',
)
```

Same env-var pattern as the `ALVERA_BASE_URL` /
`ALVERA_ROOT_EMAIL` / `ALVERA_ROOT_PASSWORD` credentials the
generated specs already consume.

## Why fixtures instead of inline templates

Inlining each template verbatim inside the cookbook markdown
would bloat each recipe to several hundred extra lines of
Liquid noise, which obscures the cookbook's actual lesson (the
sequence of SDK calls plus the assertions). Loading templates
by path preserves cookbook readability AND keeps recipes
executable — the cookbook is shipped as part of the
`@alvera-ai/platform-sdk` npm package, the fixtures ship
alongside it via the package's `files: [.agent]` field, and
the env-var dereference works for any consumer that installed
the package.

## Provenance

Each template is a verbatim copy of the template the platform
ships for that feed, vendored here so the cookbook corpus is
self-contained at npm-install time.

When the platform's template changes, re-copy the file here and
re-run `make validate-cookbook` to confirm the cookbook still
passes against the new template shape.

## Per-industry inventory

### `foundation/`

| File | Consumed by cookbook(s) |
|---|---|
| `_lead_submissions_foundation_legal_entity.liquid` | `birthday-greeting-sms-trigger`, `score-leads-with-llm-categorization` |
| `_lead_submissions_foundation_generic_table.liquid` | `score-leads-with-llm-categorization` |
| `_lead_submissions_foundation_mdm.liquid` | `score-leads-with-llm-categorization` |

### `healthcare/`

| File | Consumed by cookbook(s) |
|---|---|
| `_cahps_appointments_healthcare_patient.liquid` | `appointment-review-sms-workflow` |
| `_cahps_appointments_healthcare_appointment.liquid` | `appointment-review-sms-workflow` |
| `_cahps_appointments_healthcare_mdm.liquid` | `appointment-review-sms-workflow` |
| `sample_two_page.pdf` (data) | `ai-agent-invoke` |
| `memorandum-of-association-01.png` (data) | `ai-agent-invoke` |

The `contact-us-triage-with-llm` cookbook ingests into a generic
table via the auto-provisioned identity contract, so it loads no
vendored template.

### `subscription/`

| File | Consumed by cookbook(s) |
|---|---|
| `_customers_subscription_customer.liquid` | `welcome-sms-for-customers`, `dunning-sms-for-delinquent`, `bulk-ingest`, `rest-fetch` |
| `_customers_subscription_mdm.liquid` | `welcome-sms-for-customers`, `dunning-sms-for-delinquent`, `bulk-ingest`, `rest-fetch` |
| `stripe_customers_batch1.csv` (data) | `bulk-ingest` |

### `payments/`

| File | Consumed by cookbook(s) |
|---|---|
| `_payment_accounts_payments_payment_account.liquid` | `kyc-notification-on-account-activation` |
| `_payment_accounts_payments_mdm.liquid` | `kyc-notification-on-account-activation` |
| `_compliance_screenings_payments_compliance_screening.liquid` | `sanctions-screening-with-agent-review` |
| `_compliance_screenings_payments_mdm.liquid` | `sanctions-screening-with-agent-review` |