@alvera-ai/platform-sdk 0.12.1 → 0.13.0-next.gf3d2a4a

package/.agent/cookbook/_setup/{payment_risk.md → payments.md}

@@ -1,23 +1,23 @@
 ---
-title: Payment-risk industry bootstrap setup
-summary: Auth as root, sign up + confirm a fresh industry-admin user, create a payment-risk tenant + datalake. Shared by every payment-risk scenario cookbook.
-industry: payment_risk
-slug: payment_risk
+title: Payments industry bootstrap setup
+summary: Auth as root, sign up + confirm a fresh industry-admin user, create a payments tenant + datalake. Shared by every payments scenario cookbook.
+industry: payments
+slug: payments
 vitest_source:
-  - integration-tests/tests/payment_risk/bootstrap.test.ts
+  - integration-tests/tests/payments/bootstrap.test.ts
 status: green
 ---
 
 # Problem
 
-Every payment-risk scenario cookbook needs the same starting
-point: a fresh tenant on the platform with a payment-risk-domain
+Every payments scenario cookbook needs the same starting
+point: a fresh tenant on the platform with a payments-domain
 datalake attached, accessed by an industry-admin user. Authoring
 this prelude inline inside every scenario cookbook would
 duplicate the auth + tenant + datalake chain across two cookbooks
 (and six more across the other industries). The validator
 auto-discovers this file from each cookbook's
-`industry: payment_risk` front-matter and inlines its numbered
+`industry: payments` front-matter and inlines its numbered
 steps ahead of the scenario's own, so the generated bun:test spec
 is hermetic without the cookbook author having to copy-paste this
 prelude.
@@ -28,21 +28,23 @@ prelude.
 |-------------------------------|-------------|
 | Root session                  | setup       |
 | Industry-admin user (`sarah`) | setup       |
-| Payment-risk tenant            | setup       |
-| Payment-risk datalake          | setup       |
+| Payments tenant            | setup       |
+| Payments datalake          | setup       |
 
 # Walkthrough
 
 ## 001 — root admin signs in and provisions a fresh industry-admin user
 
 Authenticate as the platform's root admin (`admin@dev.local` /
-`devpassword` in local dev). Then sign up a per-run industry-admin
+`devpassword` in local dev) via the tenantless bootstrap login —
+keyless by structural necessity (no tenant exists yet to scope a
+key to), and a dev/test-only surface. Then sign up a per-run industry-admin
 user (`sarah`) under a unique email derived from `runSuffix`, and
 confirm them so they can sign in. Both the signup and the confirm
 endpoints require root scope.
 
 ```typescript
-ctx.rootSession = await createSession({
+ctx.rootSession = await createBootstrapSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: process.env.ALVERA_ROOT_EMAIL!,
   password: process.env.ALVERA_ROOT_PASSWORD!,
@@ -50,12 +52,13 @@ ctx.rootSession = await createSession({
 ctx.rootApi = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: ctx.rootSession.sessionToken,
+  apiKey: '',
 })
 
 ctx.sarahEmail = `cookbook-sarah-${runSuffix}@dev.local`
 ctx.sarahPassword = 'CookbookPass1!'
 
-const signUpResp = await ctx.rootApi.auth.signUp({
+const signUpResp = await ctx.rootApi.admin.signUp({
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
   first_name: 'Cookbook',
@@ -65,16 +68,16 @@ ctx.sarahUserId = signUpResp.data.id
 await ctx.rootApi.admin.confirmUser(ctx.sarahUserId)
 ```
 
-## 002 — sarah signs in (tenantless) and creates the payment-risk tenant
+## 002 — sarah signs in (tenantless) and creates the payments tenant
 
 Sarah signs in for the first time without a tenant scope (no
 tenant exists yet for her), then immediately creates a fresh
-payment-risk tenant. The tenant's server-derived `slug` is
+payments tenant. The tenant's server-derived `slug` is
 captured into the closure-scoped `tenantSlug` slot for downstream
 steps.
 
 ```typescript
-ctx.sarahTenantlessSession = await createSession({
+ctx.sarahTenantlessSession = await createBootstrapSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
@@ -82,10 +85,11 @@ ctx.sarahTenantlessSession = await createSession({
 ctx.sarahTenantlessApi = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: ctx.sarahTenantlessSession.sessionToken,
+  apiKey: '',
 })
 
 const tenantResp = await ctx.sarahTenantlessApi.tenants.create({
-  name: `Cookbook Payment Risk ${runSuffix}`,
+  name: `Cookbook Payments ${runSuffix}`,
 })
 tenantSlug = tenantResp.data.slug!
 ```
@@ -98,24 +102,37 @@ is assigned to the closure-scoped `api` slot so the scenario
 cookbook's steps inherit it via inlining.
 
 ```typescript
+// A tenant-scoped login requires X-API-Key — mint a public_api key for
+// the fresh tenant via the platform-admin side door (root Bearer). In the
+// web console this is Settings -> API Keys; any of the tenant's keys
+// satisfies the login gate, and the minted Bearer inherits this key's
+// origin policy.
+const { data: mintedKey } = await ctx.rootApi.admin.createTenantApiKey(tenantSlug, {
+  name: `Cookbook Bootstrap Key ${runSuffix}`,
+  data_access_mode: 'unregulated',
+})
+ctx.tenantApiKey = mintedKey.api_key
+
 const sarahTenantSession = await createSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
   tenantSlug,
+  apiKey: ctx.tenantApiKey,
 })
 api = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: sarahTenantSession.sessionToken,
+  apiKey: ctx.tenantApiKey,
 })
 ```
 
-## 004 — sarah creates the payment-risk datalake
+## 004 — sarah creates the payments datalake
 
-Provision a payment-risk-domain datalake on the new tenant. The
+Provision a payments-domain datalake on the new tenant. The
 DB schemas are scoped to the cookbook run via `runSuffix` so
 parallel cookbook runs do not collide on schema names. Local-dev
-defaults (`postgres` on `localhost:5432`, `alvera_dev_payment_risk`)
+defaults (`postgres` on `localhost:5432`, `alvera_dev_payments`)
 match the seeded `dev.exs` setup; LocalStack S3
 (`localhost:4566`) serves the unregulated + regulated buckets.
 The datalake's server-derived `slug` is captured into
@@ -126,7 +143,7 @@ const DB_HOST = 'localhost'
 const DB_PORT = 5432
 const DB_USER = 'postgres'
 const DB_PASS = 'postgres'
-const DB_NAME = 'alvera_dev_payment_risk'
+const DB_NAME = 'alvera_dev_payments'
 const UNREG_SCHEMA = `cookbook_${runSuffix}_unreg`
 const REG_SCHEMA = `cookbook_${runSuffix}_reg`
 
@@ -139,9 +156,9 @@ const S3 = {
 }
 
 const datalakeResp = await api.datalakes.create(tenantSlug, {
-  name: `Cookbook Payment Risk Datalake ${runSuffix}`,
-  description: 'Payment-risk datalake provisioned by cookbook doctest.',
-  data_domain: 'payment_risk',
+  name: `Cookbook Payments Datalake ${runSuffix}`,
+  description: 'Payments datalake provisioned by cookbook doctest.',
+  data_domain: 'payments',
   timezone: 'America/New_York',
   pool_size: 5,
 
@@ -179,8 +196,8 @@ const datalakeResp = await api.datalakes.create(tenantSlug, {
   regulated_data_db_reader_pass: DB_PASS,
   regulated_data_db_reader_enable_ssl: false,
 
-  unregulated_cloud_storage: { ...S3, bucket: 'payment-risk-lake-unregulated' },
-  regulated_cloud_storage: { ...S3, bucket: 'payment-risk-lake-regulated' },
+  unregulated_cloud_storage: { ...S3, bucket: 'payments-lake-unregulated' },
+  regulated_cloud_storage: { ...S3, bucket: 'payments-lake-regulated' },
 })
 datalakeSlug = datalakeResp.data.slug!
 // `tools.create` and a few other endpoints accept the datalake by
@@ -220,7 +237,7 @@ user. Downstream resource creates (tools, workflows) only need
 `datalakeId` to be persisted (which it is the moment §004
 returns), but any scenario step that ingests into the
 regulated/unregulated DBs or runs a dataset search requires
-`status: 'ready'`. Polling here makes every payment-risk scenario
+`status: 'ready'`. Polling here makes every payments scenario
 cookbook deterministic regardless of how long the cold migration
 takes on a given host; the loop exits the moment the datalake
 reaches `:ready`, so the 5-minute cap is paid only in failure
@@ -260,15 +277,18 @@ After this setup runs, the closure-scoped slots are populated as:
 
 - `api` — a tenant-scoped `PlatformApi` client authenticated as
   the industry-admin user
-- `tenantSlug` — server-derived slug of the fresh payment-risk
+- `tenantSlug` — server-derived slug of the fresh payments
   tenant
-- `datalakeSlug` — server-derived slug of the fresh payment-risk
+- `datalakeSlug` — server-derived slug of the fresh payments
   datalake
 - `ctx.sarahEmail` / `ctx.sarahPassword` — the per-run admin
   credentials (kept on `ctx` because no scenario cookbook needs
   to re-authenticate by default)
+- `ctx.tenantApiKey` — the tenant's publishable API key (minted in
+  setup via `admin.createTenantApiKey`); thread it into any
+  additional tenant-scoped `createSession` a scenario performs
 
-Scenario cookbooks under `industry: payment_risk` start at their
+Scenario cookbooks under `industry: payments` start at their
 own `§001` with these slots already populated.
 
 # See also
@@ -277,7 +297,7 @@ own `§001` with these slots already populated.
   unregulated tier configuration)
 - `.agent/AGENTS.md` § SDK auth + client construction — root vs
   tenantless vs tenant-scoped session scopes
-- `integration-tests/tests/payment_risk/bootstrap.test.ts` — the
+- `integration-tests/tests/payments/bootstrap.test.ts` — the
   green test these snippets are lifted from (the sibling datalake
   creation and the sanity probes are out of scope for this lean
   cookbook setup)

package/.agent/cookbook/_setup/{accounts_receivable.md → subscription.md}

@@ -1,23 +1,23 @@
 ---
-title: Accounts-receivable industry bootstrap setup
-summary: Auth as root, sign up + confirm a fresh industry-admin user, create an accounts-receivable tenant + datalake. Shared by every accounts-receivable scenario cookbook.
-industry: accounts_receivable
-slug: accounts_receivable
+title: Subscription industry bootstrap setup
+summary: Auth as root, sign up + confirm a fresh industry-admin user, create an subscription tenant + datalake. Shared by every subscription scenario cookbook.
+industry: subscription
+slug: subscription
 vitest_source:
-  - integration-tests/tests/accounts_receivable/bootstrap.test.ts
+  - integration-tests/tests/subscription/bootstrap.test.ts
 status: green
 ---
 
 # Problem
 
-Every accounts-receivable scenario cookbook needs the same
+Every subscription scenario cookbook needs the same
 starting point: a fresh tenant on the platform with an
-accounts-receivable-domain datalake attached, accessed by an
+subscription-domain datalake attached, accessed by an
 industry-admin user. Authoring this prelude inline inside every
 scenario cookbook would duplicate the auth + tenant + datalake
 chain across two cookbooks (and six more across the other
 industries). The validator auto-discovers this file from each
-cookbook's `industry: accounts_receivable` front-matter and
+cookbook's `industry: subscription` front-matter and
 inlines its numbered steps ahead of the scenario's own, so the
 generated bun:test spec is hermetic without the cookbook author
 having to copy-paste this prelude.
@@ -28,21 +28,23 @@ having to copy-paste this prelude.
 |-------------------------------|-------------|
 | Root session                  | setup       |
 | Industry-admin user (`sarah`) | setup       |
-| Accounts-receivable tenant     | setup       |
-| Accounts-receivable datalake   | setup       |
+| Subscription tenant     | setup       |
+| Subscription datalake   | setup       |
 
 # Walkthrough
 
 ## 001 — root admin signs in and provisions a fresh industry-admin user
 
 Authenticate as the platform's root admin (`admin@dev.local` /
-`devpassword` in local dev). Then sign up a per-run industry-admin
+`devpassword` in local dev) via the tenantless bootstrap login —
+keyless by structural necessity (no tenant exists yet to scope a
+key to), and a dev/test-only surface. Then sign up a per-run industry-admin
 user (`sarah`) under a unique email derived from `runSuffix`, and
 confirm them so they can sign in. Both the signup and the confirm
 endpoints require root scope.
 
 ```typescript
-ctx.rootSession = await createSession({
+ctx.rootSession = await createBootstrapSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: process.env.ALVERA_ROOT_EMAIL!,
   password: process.env.ALVERA_ROOT_PASSWORD!,
@@ -50,12 +52,13 @@ ctx.rootSession = await createSession({
 ctx.rootApi = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: ctx.rootSession.sessionToken,
+  apiKey: '',
 })
 
 ctx.sarahEmail = `cookbook-sarah-${runSuffix}@dev.local`
 ctx.sarahPassword = 'CookbookPass1!'
 
-const signUpResp = await ctx.rootApi.auth.signUp({
+const signUpResp = await ctx.rootApi.admin.signUp({
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
   first_name: 'Cookbook',
@@ -65,16 +68,16 @@ ctx.sarahUserId = signUpResp.data.id
 await ctx.rootApi.admin.confirmUser(ctx.sarahUserId)
 ```
 
-## 002 — sarah signs in (tenantless) and creates the accounts-receivable tenant
+## 002 — sarah signs in (tenantless) and creates the subscription tenant
 
 Sarah signs in for the first time without a tenant scope (no
 tenant exists yet for her), then immediately creates a fresh
-accounts-receivable tenant. The tenant's server-derived `slug` is
+subscription tenant. The tenant's server-derived `slug` is
 captured into the closure-scoped `tenantSlug` slot for downstream
 steps.
 
 ```typescript
-ctx.sarahTenantlessSession = await createSession({
+ctx.sarahTenantlessSession = await createBootstrapSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
@@ -82,10 +85,11 @@ ctx.sarahTenantlessSession = await createSession({
 ctx.sarahTenantlessApi = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: ctx.sarahTenantlessSession.sessionToken,
+  apiKey: '',
 })
 
 const tenantResp = await ctx.sarahTenantlessApi.tenants.create({
-  name: `Cookbook Accounts Receivable ${runSuffix}`,
+  name: `Cookbook Subscription ${runSuffix}`,
 })
 tenantSlug = tenantResp.data.slug!
 ```
@@ -98,25 +102,38 @@ is assigned to the closure-scoped `api` slot so the scenario
 cookbook's steps inherit it via inlining.
 
 ```typescript
+// A tenant-scoped login requires X-API-Key — mint a public_api key for
+// the fresh tenant via the platform-admin side door (root Bearer). In the
+// web console this is Settings -> API Keys; any of the tenant's keys
+// satisfies the login gate, and the minted Bearer inherits this key's
+// origin policy.
+const { data: mintedKey } = await ctx.rootApi.admin.createTenantApiKey(tenantSlug, {
+  name: `Cookbook Bootstrap Key ${runSuffix}`,
+  data_access_mode: 'unregulated',
+})
+ctx.tenantApiKey = mintedKey.api_key
+
 const sarahTenantSession = await createSession({
   baseUrl: process.env.ALVERA_BASE_URL!,
   email: ctx.sarahEmail,
   password: ctx.sarahPassword,
   tenantSlug,
+  apiKey: ctx.tenantApiKey,
 })
 api = createIsolatedPlatformApi({
   baseUrl: process.env.ALVERA_BASE_URL!,
   sessionToken: sarahTenantSession.sessionToken,
+  apiKey: ctx.tenantApiKey,
 })
 ```
 
-## 004 — sarah creates the accounts-receivable datalake
+## 004 — sarah creates the subscription datalake
 
-Provision an accounts-receivable-domain datalake on the new
+Provision an subscription-domain datalake on the new
 tenant. The DB schemas are scoped to the cookbook run via
 `runSuffix` so parallel cookbook runs do not collide on schema
 names. Local-dev defaults (`postgres` on `localhost:5432`,
-`alvera_dev_accounts_receivable`) match the seeded `dev.exs`
+`alvera_dev_subscription`) match the seeded `dev.exs`
 setup; LocalStack S3 (`localhost:4566`) serves the unregulated +
 regulated buckets. The datalake's server-derived `slug` is
 captured into `datalakeSlug`.
@@ -126,7 +143,7 @@ const DB_HOST = 'localhost'
 const DB_PORT = 5432
 const DB_USER = 'postgres'
 const DB_PASS = 'postgres'
-const DB_NAME = 'alvera_dev_accounts_receivable'
+const DB_NAME = 'alvera_dev_subscription'
 const UNREG_SCHEMA = `cookbook_${runSuffix}_unreg`
 const REG_SCHEMA = `cookbook_${runSuffix}_reg`
 
@@ -139,9 +156,9 @@ const S3 = {
 }
 
 const datalakeResp = await api.datalakes.create(tenantSlug, {
-  name: `Cookbook Accounts Receivable Datalake ${runSuffix}`,
-  description: 'Accounts-receivable datalake provisioned by cookbook doctest.',
-  data_domain: 'accounts_receivable',
+  name: `Cookbook Subscription Datalake ${runSuffix}`,
+  description: 'Subscription datalake provisioned by cookbook doctest.',
+  data_domain: 'subscription',
   timezone: 'America/New_York',
   pool_size: 5,
 
@@ -179,8 +196,8 @@ const datalakeResp = await api.datalakes.create(tenantSlug, {
   regulated_data_db_reader_pass: DB_PASS,
   regulated_data_db_reader_enable_ssl: false,
 
-  unregulated_cloud_storage: { ...S3, bucket: 'accounts-receivable-lake-unregulated' },
-  regulated_cloud_storage: { ...S3, bucket: 'accounts-receivable-lake-regulated' },
+  unregulated_cloud_storage: { ...S3, bucket: 'subscription-lake-unregulated' },
+  regulated_cloud_storage: { ...S3, bucket: 'subscription-lake-regulated' },
 })
 datalakeSlug = datalakeResp.data.slug!
 // `tools.create` and a few other endpoints accept the datalake by
@@ -219,7 +236,7 @@ service-account bot user. Downstream resource creates (tools,
 workflows) only need `datalakeId` to be persisted (which it is
 the moment §004 returns), but any scenario step that ingests into
 the regulated/unregulated DBs or runs a dataset search requires
-`status: 'ready'`. Polling here makes every accounts-receivable
+`status: 'ready'`. Polling here makes every subscription
 scenario cookbook deterministic regardless of how long the cold
 migration takes on a given host; the loop exits the moment the
 datalake reaches `:ready`, so the 5-minute cap is paid only in
@@ -260,14 +277,17 @@ After this setup runs, the closure-scoped slots are populated as:
 - `api` — a tenant-scoped `PlatformApi` client authenticated as
   the industry-admin user
 - `tenantSlug` — server-derived slug of the fresh
-  accounts-receivable tenant
+  subscription tenant
 - `datalakeSlug` — server-derived slug of the fresh
-  accounts-receivable datalake
+  subscription datalake
 - `ctx.sarahEmail` / `ctx.sarahPassword` — the per-run admin
   credentials (kept on `ctx` because no scenario cookbook needs
   to re-authenticate by default)
+- `ctx.tenantApiKey` — the tenant's publishable API key (minted in
+  setup via `admin.createTenantApiKey`); thread it into any
+  additional tenant-scoped `createSession` a scenario performs
 
-Scenario cookbooks under `industry: accounts_receivable` start at
+Scenario cookbooks under `industry: subscription` start at
 their own `§001` with these slots already populated.
 
 # See also
@@ -276,7 +296,7 @@ their own `§001` with these slots already populated.
   unregulated tier configuration)
 - `.agent/AGENTS.md` § SDK auth + client construction — root vs
   tenantless vs tenant-scoped session scopes
-- `integration-tests/tests/accounts_receivable/bootstrap.test.ts` —
+- `integration-tests/tests/subscription/bootstrap.test.ts` —
   the green test these snippets are lifted from (the sibling
   datalake creation and the sanity probes are out of scope for
   this lean cookbook setup)

package/.agent/cookbook/action-status-updaters.md

@@ -1,11 +1,11 @@
 ---
 title: "Capability: reconcile delivery status of the messages you send"
 summary: A capability walk for action status updaters. Register a poller tool that reads a delivery-log source (here CloudWatch via LocalStack) and an action status updater that runs on a cron, maps log events back to the messages that produced them, and updates their status (`api.actionStatusUpdaters.create`). So a "sent" SMS becomes "delivered" / "failed" without you polling by hand.
-industry: accounts_receivable
+industry: subscription
 slug: action-status-updaters
 vitest_source:
-  - integration-tests/tests/accounts_receivable/action-status-updaters.test.ts
-  - integration-tests/tests/accounts_receivable/bootstrap.test.ts
+  - integration-tests/tests/subscription/action-status-updaters.test.ts
+  - integration-tests/tests/subscription/bootstrap.test.ts
 status: green
 ---
 
@@ -30,7 +30,7 @@ poller-tool body.
 
 # Walkthrough
 
-The `_setup/accounts_receivable.md` bootstrap left `api`, `tenantSlug`,
+The `_setup/subscription.md` bootstrap left `api`, `tenantSlug`,
 `datalakeSlug`, and `ctx.datalakeId` populated.
 
 ## 001 — register a data source for the tools
@@ -105,9 +105,11 @@ ctx.cwToolId = cwTool.id!
 
 The ASU ties it together: a `cron_expression` schedule, the `updater_tool_id`
 (the poller), the `sender_tool_ids` it reconciles for, and an `updater_body`
-naming the log group + the time window (Liquid `now` filters). The
-`message_config` Liquid loops the fetched `events` and emits, per event, the
-`external_id` of the message to update and the `set_params` (the new `status`).
+naming the log group + the time window. On `start_time`/`end_time`, `now` is a
+variable holding unix milliseconds — pipe it through `minutes_ago`. The
+`message_config` Liquid is rendered ONCE PER EVENT, with the event itself as the
+assigns (there is no `events` list to loop), and emits a FLAT object: the
+`external_id` of the message to update plus the fields to set at the top level.
 
 ```typescript
 const { data: asu } = await api.actionStatusUpdaters.create(tenantSlug, datalakeSlug, {
@@ -125,7 +127,7 @@ const { data: asu } = await api.actionStatusUpdaters.create(tenantSlug, datalake
   },
   message_config: {
     type: 'custom',
-    body: '{% for event in events %}{"external_id": "{{ event.message_id }}", "set_params": {"status": "{{ event.status }}"}}{% endfor %}',
+    body: '{"external_id": "{{ notification.messageId }}", "status": "delivered"}',
   },
 })
 actionStatusUpdaterId = asu.id!
@@ -158,7 +160,7 @@ const { data: ck } = await api.actionStatusUpdaters.checksum(tenantSlug, datalak
   },
   message_config: {
     type: 'custom',
-    body: '{% for event in events %}{"external_id": "{{ event.message_id }}", "set_params": {"status": "{{ event.status }}"}}{% endfor %}',
+    body: '{"external_id": "{{ notification.messageId }}", "status": "delivered"}',
   },
 })
 if (typeof ck.checksum !== 'string' || ck.checksum.length === 0) {
@@ -193,13 +195,18 @@ if (typeof detail !== 'string' || detail.length === 0) {
 - **The poller tool's intent is `status_poller`, not the sender's intent.** The
   reconciler reads logs; it doesn't send. `sender_tool_ids` is the separate list
   of sender tools whose messages it updates.
-- **`message_config` maps events back to messages by `external_id`.** The Liquid
-  emits, per fetched event, the `external_id` of the message to touch and the
-  `set_params` to apply. Get the `external_id` field name wrong and nothing
-  updates.
-- **The schedule is a cron, evaluated platform-side.** Creating the ASU registers
-  the schedule; you don't trigger it. The `updater_body` time window
-  (`{{ now | minutes_ago: 45 }}` … `{{ now }}`) bounds each run's log query.
+- **`message_config` renders once per event, and emits a FLAT object.** The event
+  is the assigns — there is no `events` list to loop — and every top-level key
+  that is not `external_id` IS the update (`status`, `delivered_at`, …). There is
+  no `set_params` wrapper. Both mistakes are rejected at create.
+- **The schedule is a cron, evaluated platform-side, and you CANNOT trigger it.**
+  Creating the ASU registers the schedule. The `updater_body` window
+  (`{{ now | minutes_ago: 45 }}` … `{{ now }}`) bounds each run's log query, and
+  must render to unix milliseconds — `now` is a variable here, not the ISO-8601
+  `now` filter.
+- **If it doesn't reconcile, read `last_run_error` and then ESCALATE.** There is
+  no manual trigger and no per-run log (known limitation). Don't rewrite the
+  config and wait for another cron tick — see `action_status_updaters.md` §7.
 - **`checksum` parity is your drift signal.** The fingerprint of the desired body
   must match the stored row's; a mismatch means the resource drifted.
 
@@ -207,6 +214,6 @@ if (typeof detail !== 'string' || detail.length === 0) {
 
 - `action_status_updaters.md` — wire shape, `updater_body` variants, `message_config`
 - `tools.md` — `sns` sender body + `cloud_watch_log_group` poller body
-- `_setup/accounts_receivable.md` — the bootstrap this walk starts from
-- `integration-tests/tests/accounts_receivable/action-status-updaters.test.ts` —
+- `_setup/subscription.md` — the bootstrap this walk starts from
+- `integration-tests/tests/subscription/action-status-updaters.test.ts` —
   the green test these calls are lifted from

package/.agent/cookbook/bulk-ingest.md

@@ -1,15 +1,15 @@
 ---
 title: "Capability: load a whole file of records in one upload"
 summary: A capability walk for bulk file ingestion. Stand up an ingestion chain (data source → manual-upload tool → interop contract → DAC), mint a presigned upload URL (`api.datalakes.createUploadLink`), PUT a CSV to it, enqueue the file (`api.dataActivationClients.ingestFile`), discover the batch the worker allocates by diffing the logs, and verify every row landed (`api.datasets.search`). For backfills and exports — not row-at-a-time.
-industry: accounts_receivable
+industry: subscription
 slug: bulk-ingest
 vitest_source:
-  - integration-tests/tests/accounts_receivable/run-dac-bulk.test.ts
-  - integration-tests/tests/accounts_receivable/create-dac.test.ts
-  - integration-tests/tests/accounts_receivable/interoperability-contracts.test.ts
-  - integration-tests/tests/accounts_receivable/tools.test.ts
-  - integration-tests/tests/accounts_receivable/data-sources.test.ts
-  - integration-tests/tests/accounts_receivable/bootstrap.test.ts
+  - integration-tests/tests/subscription/run-dac-bulk.test.ts
+  - integration-tests/tests/subscription/create-dac.test.ts
+  - integration-tests/tests/subscription/interoperability-contracts.test.ts
+  - integration-tests/tests/subscription/tools.test.ts
+  - integration-tests/tests/subscription/data-sources.test.ts
+  - integration-tests/tests/subscription/bootstrap.test.ts
 status: green
 ---
 
@@ -33,7 +33,7 @@ entry point differs. This is **global** to every datalake. See
 
 # Walkthrough
 
-The `_setup/accounts_receivable.md` bootstrap left `api`, `tenantSlug`,
+The `_setup/subscription.md` bootstrap left `api`, `tenantSlug`,
 `datalakeSlug`, and `ctx.datalakeId` populated. Steps 001–004 build the same
 ingestion chain any AR cookbook uses; 005–008 are the bulk-specific part.
 
@@ -81,17 +81,17 @@ rather than inlining them.
 const { readFileSync } = await import('node:fs')
 const { join } = await import('node:path')
 const customerTemplate = readFileSync(
-  join(process.env.COOKBOOK_FIXTURES_DIR!, 'accounts_receivable/_customers_accounts_receivable_customer.liquid'),
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'subscription/_customers_subscription_customer.liquid'),
   'utf8',
 )
 const mdmTemplate = readFileSync(
-  join(process.env.COOKBOOK_FIXTURES_DIR!, 'accounts_receivable/_customers_accounts_receivable_mdm.liquid'),
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'subscription/_customers_subscription_mdm.liquid'),
   'utf8',
 )
 
 const { data: contract } = await api.interoperabilityContracts.create(tenantSlug, datalakeSlug, {
   name: `Bulk Stripe Customer Contract ${runSuffix}`,
-  description: 'Stripe customers → AccountsReceivable Customer (custom Liquid + MDM input).',
+  description: 'Stripe customers → Subscription Customer (custom Liquid + MDM input).',
   resource_type: 'customer',
   template_config: { type: 'custom', body: customerTemplate },
   mdm_input_config: { type: 'custom', body: mdmTemplate },
@@ -130,7 +130,7 @@ vendored 4-row Stripe customer export.
 const { readFileSync } = await import('node:fs')
 const { join } = await import('node:path')
 const csvBody = readFileSync(
-  join(process.env.COOKBOOK_FIXTURES_DIR!, 'accounts_receivable/stripe_customers_batch1.csv'),
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'subscription/stripe_customers_batch1.csv'),
   'utf8',
 )
 
@@ -248,7 +248,7 @@ if (rows.length < 4) {
 
 - `data_activation_clients.md` §6.2 — `.ingestFile` reference + the bulk flow
 - `datalakes.md` — `createUploadLink` (presigned upload) reference
-- `_setup/accounts_receivable.md` — the bootstrap this walk starts from
-- `_fixtures/accounts_receivable/` — the vendored Stripe customer CSV + Liquid
-- `integration-tests/tests/accounts_receivable/run-dac-bulk.test.ts` — the green
+- `_setup/subscription.md` — the bootstrap this walk starts from
+- `_fixtures/subscription/` — the vendored Stripe customer CSV + Liquid
+- `integration-tests/tests/subscription/run-dac-bulk.test.ts` — the green
   test these calls are lifted from