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

package/.agent/cookbook/rest-fetch.md

@@ -1,12 +1,12 @@
 ---
 title: "Capability: pull records from a third-party REST API on demand"
 summary: A capability walk for pull-based ingestion. Register a REST-API tool with its auth (Bearer here; an OAuth2 refresh-token variant is shown too), bind it to a contract and a Data Activation Client whose `tool_call` names the path to fetch, trigger a fetch (`api.dataActivationClients.runManually`), and verify the rows landed. The platform calls the API for you — no file to upload.
-industry: accounts_receivable
+industry: subscription
 slug: rest-fetch
 vitest_source:
-  - integration-tests/tests/accounts_receivable/run-dac-fetch.test.ts
+  - integration-tests/tests/subscription/run-dac-fetch.test.ts
   - integration-tests/tests/foundation/oauth2-dac-fetch.test.ts
-  - integration-tests/tests/accounts_receivable/bootstrap.test.ts
+  - integration-tests/tests/subscription/bootstrap.test.ts
 status: green
 ---
 
@@ -31,7 +31,7 @@ body) for the reference.
 
 # Walkthrough
 
-The `_setup/accounts_receivable.md` bootstrap left `api`, `tenantSlug`,
+The `_setup/subscription.md` bootstrap left `api`, `tenantSlug`,
 `datalakeSlug`, and `ctx.datalakeId` populated. The fetch targets a mock Stripe
 API; locally that is the integration stack's WireMock on `localhost:8080`.
 
@@ -84,17 +84,17 @@ vendored production Stripe customer + MDM templates.
 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: `Stripe REST Customer Contract ${runSuffix}`,
-  description: 'Stripe customer fetch → AccountsReceivable Customer.',
+  description: 'Stripe customer fetch → Subscription Customer.',
   resource_type: 'customer',
   template_config: { type: 'custom', body: customerTemplate },
   mdm_input_config: { type: 'custom', body: mdmTemplate },
@@ -240,7 +240,7 @@ if (!oauthTool.id) {
 
 - `data_activation_clients.md` §6.3 — `.runManually` + the pull-based reference
 - `tools.md` — the `rest_api` tool body, `bearer` vs `oauth2` auth
-- `_setup/accounts_receivable.md` — the bootstrap this walk starts from
-- `integration-tests/tests/accounts_receivable/run-dac-fetch.test.ts`,
+- `_setup/subscription.md` — the bootstrap this walk starts from
+- `integration-tests/tests/subscription/run-dac-fetch.test.ts`,
   `integration-tests/tests/foundation/oauth2-dac-fetch.test.ts` — the green tests
   these calls are lifted from

package/.agent/cookbook/sanctions-screening-with-agent-review.md

@@ -1,16 +1,16 @@
 ---
 title: Disambiguate gray-zone sanctions screenings via an LLM agent
 summary: End-to-end agent-driven workflow — a chat-completion LLM agent disambiguates gray-zone-scored sanctions screenings into a verified/blocked verdict, the workflow's decision interpolates that verdict, two SMS actions (one per verdict) fan out, and the run is verified row-by-row. A clearly-clear screening is filtered out before the agent ever sees it.
-industry: payment_risk
+industry: payments
 slug: sanctions-screening-with-agent-review
 vitest_source:
-  - integration-tests/tests/payment_risk/sanctions-review-workflow.test.ts
-  - integration-tests/tests/payment_risk/interoperability-contracts.test.ts
-  - integration-tests/tests/payment_risk/run-dac-single.test.ts
-  - integration-tests/tests/payment_risk/create-dac.test.ts
-  - integration-tests/tests/payment_risk/tools.test.ts
-  - integration-tests/tests/payment_risk/data-sources.test.ts
-  - integration-tests/tests/payment_risk/bootstrap.test.ts
+  - integration-tests/tests/payments/sanctions-review-workflow.test.ts
+  - integration-tests/tests/payments/interoperability-contracts.test.ts
+  - integration-tests/tests/payments/run-dac-single.test.ts
+  - integration-tests/tests/payments/create-dac.test.ts
+  - integration-tests/tests/payments/tools.test.ts
+  - integration-tests/tests/payments/data-sources.test.ts
+  - integration-tests/tests/payments/bootstrap.test.ts
 status: green
 ---
 
@@ -49,8 +49,8 @@ reaches the agent and fans out to a verdict-keyed SMS, the
 clearly-clear screening is filtered out before any agent call.
 
 The scenario is anchored to
-`platform/integration-tests/tests/payment_risk/sanctions-review-workflow.test.ts`
-— a green end-to-end test. The setup file `_setup/payment_risk.md`
+`platform/integration-tests/tests/payments/sanctions-review-workflow.test.ts`
+— a green end-to-end test. The setup file `_setup/payments.md`
 already provisioned the tenant + datalake + tenant-scoped client;
 this cookbook starts from there.
 
@@ -67,7 +67,7 @@ this cookbook starts from there.
 | Compliance Screening interop contract | build     |
 | Manual-upload DAC                   | build       |
 
-The setup file `_setup/payment_risk.md` already provisioned the
+The setup file `_setup/payments.md` already provisioned the
 tenant + datalake + tenant-scoped client; this cookbook starts
 from there.
 
@@ -355,7 +355,7 @@ ctx.manualUploadToolId = manualUploadToolResp.data.id!
 
 The interoperability contract is the row-shaping rule: a Liquid
 template that maps an inbound Atomic FI compliance-screening row
-into a payment-risk `ComplianceScreening` upsert. This cookbook
+into a payments `ComplianceScreening` upsert. This cookbook
 loads the production Atomic FI compliance-screening + MDM
 templates from the vendored fixtures directory.
 
@@ -370,17 +370,17 @@ master-data resolution keys on to find-or-create the LegalEntity
 const { readFileSync } = await import('node:fs')
 const { join } = await import('node:path')
 const csTemplate = readFileSync(
-  join(process.env.COOKBOOK_FIXTURES_DIR!, 'payment_risk/_compliance_screenings_payment_risk_compliance_screening.liquid'),
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'payments/_compliance_screenings_payments_compliance_screening.liquid'),
   'utf8',
 )
 const mdmTemplate = readFileSync(
-  join(process.env.COOKBOOK_FIXTURES_DIR!, 'payment_risk/_compliance_screenings_payment_risk_mdm.liquid'),
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'payments/_compliance_screenings_payments_mdm.liquid'),
   'utf8',
 )
 
 const contractResp = await api.interoperabilityContracts.create(tenantSlug, datalakeSlug, {
   name: `Cookbook Atomic FI Compliance Screening Contract ${runSuffix}`,
-  description: 'Atomic FI compliance-screenings → PaymentRisk ComplianceScreening (custom Liquid + MDM input).',
+  description: 'Atomic FI compliance-screenings → Payments ComplianceScreening (custom Liquid + MDM input).',
   resource_type: 'compliance_screening',
   template_config: { type: 'custom', body: csTemplate },
   mdm_input_config: { type: 'custom', body: mdmTemplate },
@@ -669,7 +669,7 @@ if (!verdictBody.includes('[verified]')) {
 # Rollback
 
 The cookbook doctest harness does not currently tear down created
-resources. The `_setup/payment_risk.md` setup file's
+resources. The `_setup/payments.md` setup file's
 runSuffix-scoped tenant / datalake / user names mean each run is
 naturally isolated; the seeded local DB is cheap to reset
 (`mix ecto.reset` on the platform repo).
@@ -678,7 +678,7 @@ naturally isolated; the seeded local DB is cheap to reset
 
 After this cookbook's thirteen steps run green:
 
-- A payment-risk tenant exists with a payment-risk-domain
+- A payments tenant exists with a payments-domain
   datalake
 - An SMS tool, a chat-completion LLM tool, a Sanctions Review AI
   agent (qwen3-vl:8b-instruct, verified/blocked response schema), and a
@@ -705,10 +705,10 @@ entirely — is demonstrated end-to-end, not merely provisioned.
 
 # See also
 
-- `_setup/payment_risk.md` — the inlined bootstrap that
+- `_setup/payments.md` — the inlined bootstrap that
   provisions the tenant + datalake this cookbook starts from
 - `kyc-notification-on-account-activation.md` — the
-  static-decision payment-risk cookbook; same SMS wiring, full
+  static-decision payments cookbook; same SMS wiring, full
   data-activation chain, no agent
 - `score-leads-with-llm-categorization.md`,
   `contact-us-triage-with-llm.md` — the foundation and healthcare
@@ -723,11 +723,11 @@ entirely — is demonstrated end-to-end, not merely provisioned.
   agent-output decision interpolation
 - `.agent/interoperability_contracts.md` — custom contract shape,
   `template_config` vs `mdm_input_config`
-- `.agent/cookbook/_fixtures/payment_risk/` — the vendored Atomic
+- `.agent/cookbook/_fixtures/payments/` — the vendored Atomic
   FI compliance-screening / MDM Liquid templates §007 loads
-- `integration-tests/tests/payment_risk/sanctions-review-workflow.test.ts` —
+- `integration-tests/tests/payments/sanctions-review-workflow.test.ts` —
   the anchor green test these snippets are lifted from
-- `integration-tests/tests/payment_risk/interoperability-contracts.test.ts`,
+- `integration-tests/tests/payments/interoperability-contracts.test.ts`,
   `run-dac-single.test.ts`, `create-dac.test.ts`, `tools.test.ts`,
   `data-sources.test.ts` — the per-resource create + ingest
   snippets §005–§010 are lifted from

package/.agent/cookbook/system-templates.md

@@ -1,11 +1,11 @@
 ---
 title: "Capability: discover the platform's built-in row-mapping templates"
 summary: A capability walk for system-template discovery. List the Liquid templates the platform ships for your datalake's data domain (`api.templates.systemTemplates`), read the human-readable catalog (`api.templates.metadata`), and pull one template's detail (`api.templates.metadataDetails`) — so you can start an interoperability contract from a platform template instead of hand-writing Liquid. Read-only; creates nothing.
-industry: accounts_receivable
+industry: subscription
 slug: system-templates
 vitest_source:
-  - integration-tests/tests/accounts_receivable/system-templates.test.ts
-  - integration-tests/tests/accounts_receivable/bootstrap.test.ts
+  - integration-tests/tests/subscription/system-templates.test.ts
+  - integration-tests/tests/subscription/bootstrap.test.ts
 status: green
 ---
 
@@ -19,8 +19,8 @@ from a vetted template instead of hand-written Liquid.
 
 - `systemTemplates(tenantSlug, datalakeSlug)` — the machine-readable list:
   `{ data: [{ path, content, output_schema }] }`. The list is **filtered to your
-  datalake's data domain** plus globals — a payment-risk or healthcare template
-  never appears in an accounts-receivable datalake.
+  datalake's data domain** plus globals — a payments or healthcare template
+  never appears in an subscription datalake.
 - `metadata(tenantSlug, datalakeSlug)` — the same catalog as a markdown summary.
 - `metadataDetails(tenantSlug, datalakeSlug, basename, intent)` — one template's
   detail by basename + intent.
@@ -31,18 +31,18 @@ differ by domain. See `templates.md` for the reference, and
 
 # Walkthrough
 
-The `_setup/accounts_receivable.md` bootstrap already provisioned the tenant +
+The `_setup/subscription.md` bootstrap already provisioned the tenant +
 datalake and left `api`, `tenantSlug`, and `datalakeSlug` populated. This walk
 starts from there.
 
 ## 001 — list the system templates in scope for this datalake
 
 `systemTemplates` returns every platform-shipped Liquid template visible to this
-datalake: the templates for its data domain (here, `accounts_receivable`) plus
+datalake: the templates for its data domain (here, `subscription`) plus
 domain-agnostic globals (e.g. the SNS delivery-status poller). Each entry has a
 `path`, the Liquid `content`, and an `output_schema` (`null` when the template
 has no companion schema). The list is domain-scoped — templates for other data
-domains (`healthcare`, `payment_risk`, `foundation`, …) are filtered out, so you
+domains (`healthcare`, `payments`, `foundation`, …) are filtered out, so you
 only see what is usable here.
 
 ```typescript
@@ -53,14 +53,14 @@ if (paths.length === 0) {
   throw new Error('expected the platform to ship at least one system template')
 }
 
-// The accounts-receivable anchor template is present...
-const arAnchor = 'data_activation/interoperability/accounts_receivable/stripe/customers_accounts_receivable_customer'
+// The subscription anchor template is present...
+const arAnchor = 'data_activation/interoperability/subscription/stripe/customers_subscription_customer'
 if (!paths.some((p) => p.includes(arAnchor))) {
   throw new Error(`expected the AR customer template (${arAnchor}) in the list`)
 }
 
 // ...and templates for other data domains are filtered out of an AR datalake.
-const otherDomains = ['healthcare', 'payment_risk', 'foundation', 'core_banking', 'service_commerce', 'trading']
+const otherDomains = ['healthcare', 'payments', 'foundation', 'core_banking', 'service_commerce', 'trading']
 const leaked = paths.filter((p) => otherDomains.some((d) => p.split('/').includes(d)))
 if (leaked.length > 0) {
   throw new Error(`cross-domain templates leaked into an AR datalake: ${leaked.join(', ')}`)
@@ -78,7 +78,7 @@ const { data: catalog } = await api.templates.metadata(tenantSlug, datalakeSlug)
 if (typeof catalog !== 'string' || catalog.length === 0) {
   throw new Error('expected a non-empty markdown template catalog')
 }
-if (!catalog.includes('customers_accounts_receivable_customer')) {
+if (!catalog.includes('customers_subscription_customer')) {
   throw new Error('expected the AR customer template named in the catalog markdown')
 }
 ```
@@ -95,7 +95,7 @@ copies the template into a contract's `template_config`.
 const { data: detail } = await api.templates.metadataDetails(
   tenantSlug,
   datalakeSlug,
-  'customers_accounts_receivable_customer',
+  'customers_subscription_customer',
   'data_activation_interoperability',
 )
 if (typeof detail !== 'string' || detail.length === 0) {
@@ -124,6 +124,6 @@ if (typeof detail !== 'string' || detail.length === 0) {
 
 - `templates.md` — the `api.templates.*` reference (wire shapes, intents)
 - `interoperability_contracts.md` — how a template becomes a live row mapping
-- `_setup/accounts_receivable.md` — the bootstrap this walk starts from
-- `integration-tests/tests/accounts_receivable/system-templates.test.ts` — the
+- `_setup/subscription.md` — the bootstrap this walk starts from
+- `integration-tests/tests/subscription/system-templates.test.ts` — the
   green test these calls are lifted from

package/.agent/cookbook/triage-prospects-by-priority.md

@@ -1,16 +1,16 @@
 ---
 title: Triage inbound AR prospects into priority bands via an LLM agent and route each to a tailored SMS
-summary: End-to-end agent-driven workflow over the accounts-receivable customer dataset — a chat-completion LLM agent classifies each customer into a priority band (high/medium/low) by account type, the workflow's decision interpolates the agent's band, three SMS actions (one per band) fan out, and the run is verified row-by-row so every Workflow Execution Log carries exactly one matched action and two skipped.
-industry: accounts_receivable
+summary: End-to-end agent-driven workflow over the subscription customer dataset — a chat-completion LLM agent classifies each customer into a priority band (high/medium/low) by account type, the workflow's decision interpolates the agent's band, three SMS actions (one per band) fan out, and the run is verified row-by-row so every Workflow Execution Log carries exactly one matched action and two skipped.
+industry: subscription
 slug: triage-prospects-by-priority
 vitest_source:
-  - integration-tests/tests/accounts_receivable/agent-lead-triage.test.ts
-  - integration-tests/tests/accounts_receivable/interoperability-contracts.test.ts
-  - integration-tests/tests/accounts_receivable/run-dac-single.test.ts
-  - integration-tests/tests/accounts_receivable/create-dac.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/agent-lead-triage.test.ts
+  - integration-tests/tests/subscription/interoperability-contracts.test.ts
+  - integration-tests/tests/subscription/run-dac-single.test.ts
+  - integration-tests/tests/subscription/create-dac.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
 ---
 
@@ -40,8 +40,8 @@ row-by-row — every Workflow Execution Log carries exactly one matched action
 and two `:skipped`.
 
 The scenario is anchored to
-`platform/integration-tests/tests/accounts_receivable/agent-lead-triage.test.ts`.
-The setup file `_setup/accounts_receivable.md` already provisioned the tenant +
+`platform/integration-tests/tests/subscription/agent-lead-triage.test.ts`.
+The setup file `_setup/subscription.md` already provisioned the tenant +
 datalake + tenant-scoped client; this cookbook starts from there.
 
 # Composition
@@ -230,17 +230,17 @@ which §008's context-mapping feeds the agent.
 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 contractResp = await api.interoperabilityContracts.create(tenantSlug, datalakeSlug, {
   name: `Cookbook 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 },
@@ -499,7 +499,7 @@ for (const wel of ourWels) {
 # Rollback
 
 The cookbook doctest harness does not currently tear down created resources. The
-`_setup/accounts_receivable.md` setup file's runSuffix-scoped names keep each run
+`_setup/subscription.md` setup file's runSuffix-scoped names keep each run
 isolated; the seeded local DB is cheap to reset (`mix ecto.reset` on the platform
 repo).
 
@@ -521,7 +521,7 @@ After this cookbook runs green:
 
 # See also
 
-- `_setup/accounts_receivable.md` — the inlined bootstrap this cookbook starts from
+- `_setup/subscription.md` — the inlined bootstrap this cookbook starts from
 - `dunning-sms-for-delinquent.md` — the static-decision AR counterpart (same
   customer chain, one fixed action, no agent)
 - `score-leads-with-llm-categorization.md` — the foundation analogue (leads into
@@ -529,5 +529,5 @@ After this cookbook runs green:
 - `ai-agent-invoke.md` — the capability doc for the agent + tool surface this uses
 - `.agent/workflows.md` — agent-driven workflow primitive; `workflow_ai_agents`,
   `context_mapping_config`, agent-output decision interpolation
-- `integration-tests/tests/accounts_receivable/agent-lead-triage.test.ts` — the
+- `integration-tests/tests/subscription/agent-lead-triage.test.ts` — the
   anchor green test these snippets are lifted from

package/.agent/cookbook/welcome-sms-for-customers.md

@@ -1,16 +1,16 @@
 ---
 title: Send a welcome SMS to newly contracted customers with a billing-portal link
 summary: End-to-end standard workflow — provision a Welcome SMS workflow over the AR customer dataset, ingest two Stripe customer rows (one with a phone on file, one without) through a customer interop contract, run the workflow so the phone filter routes each row, read the rendered SMS back from the message dataset, and close the connected-app reply loop. No agent, no LLM.
-industry: accounts_receivable
+industry: subscription
 slug: welcome-sms-for-customers
 vitest_source:
-  - integration-tests/tests/accounts_receivable/standard-workflow.test.ts
-  - integration-tests/tests/accounts_receivable/interoperability-contracts.test.ts
-  - integration-tests/tests/accounts_receivable/run-dac-single.test.ts
-  - integration-tests/tests/accounts_receivable/create-dac.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/standard-workflow.test.ts
+  - integration-tests/tests/subscription/interoperability-contracts.test.ts
+  - integration-tests/tests/subscription/run-dac-single.test.ts
+  - integration-tests/tests/subscription/create-dac.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
 ---
 
@@ -42,10 +42,10 @@ message dataset, and finally resolves the connected-app deep-link
 the SMS carries — closing the SMS → reply loop.
 
 The scenario is anchored to
-`platform/integration-tests/tests/accounts_receivable/standard-workflow.test.ts`
+`platform/integration-tests/tests/subscription/standard-workflow.test.ts`
 — a green end-to-end test (§1–§8) that exercises this exact shape.
 This cookbook is a prose re-presentation of what that test walks.
-The setup file `_setup/accounts_receivable.md` already provisioned
+The setup file `_setup/subscription.md` already provisioned
 the tenant, datalake, and industry-admin client; this cookbook
 starts from there.
 
@@ -61,7 +61,7 @@ starts from there.
 | Stripe Customer interop contract | build       |
 | Manual-upload DAC                | build       |
 
-The setup file `_setup/accounts_receivable.md` already
+The setup file `_setup/subscription.md` already
 provisioned the tenant + datalake + tenant-scoped client; this
 cookbook starts from there.
 
@@ -261,17 +261,17 @@ customer or an existing one.
 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 contractResp = await api.interoperabilityContracts.create(tenantSlug, datalakeSlug, {
   name: `Cookbook 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 },
@@ -549,7 +549,7 @@ if (!tracked.message?.opened_at || !tracked.message?.form_submitted_at) {
 # Rollback
 
 The cookbook doctest harness does not currently tear down created
-resources. The `_setup/accounts_receivable.md` setup file's
+resources. The `_setup/subscription.md` setup file's
 runSuffix-scoped tenant / datalake / user names mean each run is
 naturally isolated; the seeded local DB is cheap to reset
 (`mix ecto.reset` on the platform repo).
@@ -558,8 +558,8 @@ naturally isolated; the seeded local DB is cheap to reset
 
 After this cookbook's thirteen steps run green:
 
-- An accounts-receivable tenant exists with an
-  accounts-receivable-domain datalake
+- An subscription tenant exists with an
+  subscription-domain datalake
 - An SMS tool, a Welcome billing-portal connected app, and a
   Welcome SMS standard workflow (status `live`, `customer`
   dataset) are registered
@@ -583,7 +583,7 @@ end-to-end, not merely provisioned.
 
 # See also
 
-- `_setup/accounts_receivable.md` — the inlined bootstrap that
+- `_setup/subscription.md` — the inlined bootstrap that
   provisions the tenant + datalake this cookbook starts from
 - `dunning-sms-for-delinquent.md` — the sibling AR cookbook; same
   customer-dataset shape, a stricter phone + tax-id filter
@@ -597,11 +597,11 @@ end-to-end, not merely provisioned.
   interop contract → DAC ingestion chain
 - `.agent/workflows.md` — standard workflow primitive (filter +
   decision + actions), `context_datasets`, `workflows.run`
-- `.agent/cookbook/_fixtures/accounts_receivable/` — the vendored
+- `.agent/cookbook/_fixtures/subscription/` — the vendored
   Stripe customer / MDM Liquid templates §006 loads
-- `integration-tests/tests/accounts_receivable/standard-workflow.test.ts` —
+- `integration-tests/tests/subscription/standard-workflow.test.ts` —
   the anchor green test (§1–§8) these snippets are lifted from
-- `integration-tests/tests/accounts_receivable/interoperability-contracts.test.ts`,
+- `integration-tests/tests/subscription/interoperability-contracts.test.ts`,
   `run-dac-single.test.ts`, `create-dac.test.ts`, `tools.test.ts`,
   `data-sources.test.ts` — the per-resource create + ingest
   snippets §004–§009 are lifted from