@alvera-ai/platform-sdk 0.10.0-rc.2 → 0.10.0-rc.21

package/.agent/cookbook/dunning-sms-for-delinquent.md

@@ -0,0 +1,619 @@
+---
+title: Send a payment-reminder SMS to delinquent customers with a pay-invoice link
+summary: End-to-end standard workflow — provision a Dunning SMS workflow over the AR customer dataset, ingest two Stripe customer rows (one phone + tax-id verified, one missing tax-id) through a customer interop contract, run the workflow so the SMS-reachable-and-KYC-complete 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
+slug: dunning-sms-for-delinquent
+vitest_source:
+  - integration-tests/tests/accounts_receivable/dunning-sms-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
+status: green
+---
+
+# Problem
+
+When an invoice goes unpaid, the billing team wants to send a
+payment-reminder ("dunning") SMS with a self-serve pay link — but
+only to customers it is both *allowed* and *able* to contact. The
+customer must be SMS-reachable (a phone on file) and KYC-complete
+(a verified tax id). A customer missing either precondition should
+be skipped, not errored, and certainly not chased.
+
+The classic implementation queries the customers table, branches
+on phone-present and tax-id-present, and hands the survivors to an
+SMS sender — with both preconditions living in application code.
+
+The Alvera platform's standard workflow primitive keeps both
+checks inside the platform. An AR `customer` dataset is the
+workflow's event source; a pure-Liquid filter gates on
+`customer.phone and customer.tax_id`; a single SMS action carries
+a deep-link to a connected-app payment portal. The
+reachable-and-verified decision is a one-line filter, not a code
+branch.
+
+This cookbook walks the **whole** scenario, not just the
+provisioning: it creates the workflow, ingests two Stripe-shaped
+customer rows through the production data-activation chain (one
+phone + tax-id verified, one missing the tax id), runs the
+workflow so the filter routes each row, reads the rendered dunning
+SMS back out of the 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/dunning-sms-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 tenant, datalake, and industry-admin client; this cookbook
+starts from there.
+
+# Composition
+
+| Resource provisioned             | Owner       |
+|----------------------------------|-------------|
+| SMS tool (SNS-backed)            | build       |
+| Dunning payment-portal connected app | build   |
+| Dunning SMS workflow             | build       |
+| Stripe data source               | build       |
+| Manual Upload tool               | build       |
+| Stripe Customer interop contract | build       |
+| Manual-upload DAC                | build       |
+
+The setup file `_setup/accounts_receivable.md` already
+provisioned the tenant + datalake + tenant-scoped client; this
+cookbook starts from there.
+
+# Walkthrough
+
+## 001 — create the SMS tool
+
+The Dunning SMS workflow's action invokes an SMS tool. The tool's
+`body.tool_body_type: 'sns'` means it routes via AWS SNS; local
+dev points it at LocalStack on `http://localhost:4566` via
+`endpoint_url` so no real AWS credentials are needed. The
+`intent: 'sms'` tags this tool for workflow actions that send SMS
+(versus `data_exchange` for ingestion tools).
+
+```typescript
+const smsToolResp = await api.tools.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook SMS Tool ${runSuffix}`,
+  description: 'SNS-backed SMS dispatcher for the Dunning SMS workflow, wired to LocalStack.',
+  intent: 'sms',
+  status: 'active',
+  datalake_id: ctx.datalakeId,
+  body: {
+    tool_body_type: 'sns',
+    auth_method: 'access_key',
+    region: 'us-east-1',
+    phone_number: '+15551234567',
+    endpoint_url: 'http://localhost:4566',
+    access_key_id: 'test',
+    secret_access_key: 'test',
+  },
+})
+toolId = smsToolResp.data.id!
+```
+
+## 002 — create the Dunning payment-portal connected app
+
+The workflow's SMS action carries a deep-link to a connected-app
+page so the customer can open the self-serve payment portal. The
+connected app is a thin registration of the portal's URL and
+mode; the actual page is hosted outside the platform
+(`mode: 'self_hosted'`). The server-derived `slug` is captured for
+the resolve-page call in §013.
+
+```typescript
+const connectedAppResp = await api.connectedApps.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook Dunning Payment Portal ${runSuffix}`,
+  description: 'Self-serve invoice payment portal linked from the outbound dunning SMS.',
+  mode: 'self_hosted',
+  urls: [
+    {
+      url: 'https://dunning.example.local',
+      is_primary: true,
+      label: 'production',
+    },
+  ],
+})
+connectedAppId = connectedAppResp.data.id!
+ctx.connectedAppSlug = connectedAppResp.data.slug!
+```
+
+## 003 — create the Dunning SMS workflow
+
+The workflow has the standard shape: a filter (Liquid; passes
+customers who are both SMS-reachable *and* KYC-complete —
+`customer.phone and customer.tax_id`), a decision (a literal
+Liquid array naming one decision key), and one SMS action. The
+SMS body references `{{ customer.customer_number }}` so the
+recipient sees which account is overdue, and
+`{{ connected_app_form_url }}` so the platform can bake in the
+`/t/<token>` pay-link.
+
+Two details matter. `dataset_type: 'customer'` makes the AR
+customer dataset the event source; the workflow context injects
+the regulated customer row under the `customer` key, so the
+filter reads `customer.phone` and `customer.tax_id` directly. A
+`context_datasets` entry queries the `message` dataset for any
+dunning SMS already sent to this customer in the last thirty days
+— the platform's built-in guard against dunning the same customer
+twice in a billing cycle. On a fresh tenant that lookup returns
+empty, which is harmless.
+
+```typescript
+const FILTER_BODY = '{% if customer.phone and customer.tax_id %}true{% endif %}'
+const DECISION_KEY = 'send_dunning_sms'
+const DECISION_BODY = `["${DECISION_KEY}"]`
+const DECISION_OUTPUT_SCHEMA = '{"type":"array","items":{"type":"string"}}'
+const SMS_TO_TEMPLATE = '{{ mdm_output.regulated_customer.phone }}'
+const SMS_BODY_TEMPLATE =
+  'Hi {{ mdm_output.regulated_customer.name }}, an invoice on account ' +
+  '{{ customer.customer_number }} needs your attention. ' +
+  'Pay now: {{ connected_app_form_url }}'
+
+const workflowResp = await api.workflows.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook Dunning SMS Workflow ${runSuffix}`,
+  description: 'Sends a payment-reminder SMS to delinquent contracted customers with a self-serve pay link.',
+  dataset_type: 'customer',
+  status: 'live',
+  filter_config: {
+    type: 'custom',
+    body: FILTER_BODY,
+    output_schema: '{"type":"boolean"}',
+  },
+  decision_config: {
+    type: 'custom',
+    body: DECISION_BODY,
+    output_schema: DECISION_OUTPUT_SCHEMA,
+  },
+  context_datasets: [
+    {
+      dataset_type: 'message',
+      where_clause:
+        `rm.customer_id = '{{ customer_id }}' AND rm.decision_key = '${DECISION_KEY}' ` +
+        "AND rm.sent_at > NOW() - INTERVAL '30 days'",
+      limit: 1,
+      position: 0,
+    },
+  ],
+  actions: [
+    {
+      action_type: 'sms',
+      tool_id: toolId,
+      decision_key: DECISION_KEY,
+      position: 0,
+      trigger_template: 'now',
+      idempotency_template: '{{ customer_id }}-{{ decision_key }}-{{ "" | uuid }}',
+      connected_app_id: connectedAppId,
+      connected_app_route: '/portal/pay',
+      connected_app_metadata_template:
+        '{"customer_id":"{{ mdm_output.customer.id }}","customer_number":"{{ customer.customer_number }}"}',
+      tool_call: {
+        tool_call_type: 'sms_request',
+        to: { type: 'custom', body: SMS_TO_TEMPLATE },
+        body: { type: 'custom', body: SMS_BODY_TEMPLATE },
+        sms_type: 'transactional',
+      },
+    },
+  ],
+})
+workflowId = workflowResp.data.id!
+ctx.workflowSlug = workflowResp.data.slug!
+```
+
+## 004 — create the Stripe data source
+
+A workflow runs on rows; rows arrive through the data-activation
+chain. The chain's first link is a `DataSource` — a registration
+of where the rows originate. The `uri` is the system-of-record
+address; it flows into each ingested row's `source_uri`, which
+the customer template renders onto the MDM identifier `system`
+URN.
+
+```typescript
+const dataSourceResp = await api.dataSources.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook Stripe Source ${runSuffix}`,
+  uri: 'stripe.example.com',
+  description: 'Stripe billing system — origin of the customer rows the dunning workflow runs on.',
+  status: 'active',
+  is_default: false,
+})
+dataSourceId = dataSourceResp.data.id!
+```
+
+## 005 — create the Manual Upload tool
+
+The Data Activation Client needs a tool. For inline-JSON ingest a
+`manual_upload` tool is the minimal choice — `intent:
+'data_exchange'` distinguishes it from the SMS tool, and
+`tool_body_type: 'manual_upload'` needs no endpoint or credential
+wiring (the rows arrive in the ingest call body, not by the tool
+fetching them).
+
+```typescript
+const manualUploadToolResp = await api.tools.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook Manual Upload Tool ${runSuffix}`,
+  description: 'Manual-upload data-exchange tool — backs the DAC that ingests Stripe customer rows.',
+  intent: 'data_exchange',
+  status: 'active',
+  datalake_id: ctx.datalakeId,
+  data_source_id: dataSourceId,
+  body: { tool_body_type: 'manual_upload' },
+})
+ctx.manualUploadToolId = manualUploadToolResp.data.id!
+```
+
+## 006 — create the Stripe Customer interoperability contract
+
+The interoperability contract is the row-shaping rule: a Liquid
+template that maps an inbound Stripe customer row into an AR
+`Customer` upsert. This cookbook loads the production Stripe
+customer + MDM templates from the vendored fixtures directory
+rather than inlining the Liquid.
+
+Two template slots matter. `template_config` shapes the Customer
+resource — including the nested `regulated_customer` object that
+carries the PII fields (`name`, `email`, `phone`, `tax_id`).
+`mdm_input_config` shapes the MDM input — the identifier
+(`customer_number`), name, and contact fields the platform's
+master-data resolution keys on to decide whether this is a new
+customer or an existing one.
+
+```typescript
+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'),
+  'utf8',
+)
+const mdmTemplate = readFileSync(
+  join(process.env.COOKBOOK_FIXTURES_DIR!, 'accounts_receivable/_customers_accounts_receivable_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).',
+  resource_type: 'customer',
+  template_config: { type: 'custom', body: customerTemplate },
+  mdm_input_config: { type: 'custom', body: mdmTemplate },
+  generic_table_id: null,
+})
+interopContractId = contractResp.data.id!
+```
+
+## 007 — create the manual-upload DAC
+
+The Data Activation Client binds the three preceding pieces — the
+manual-upload tool, the data source, and the interop contract —
+into one ingestion endpoint. `tool_call.tool_call_type:
+'manual_upload'` selects the inline-JSON ingest path. The
+server-derived `slug` is the handle §008 ingests rows against.
+
+```typescript
+const dacResp = await api.dataActivationClients.create(tenantSlug, datalakeSlug, {
+  name: `Cookbook Stripe Customer DAC ${runSuffix}`,
+  description: 'Manual-upload DAC — ingests Stripe customer rows into Customer via the interop contract.',
+  tool_id: ctx.manualUploadToolId,
+  data_source_id: dataSourceId,
+  tool_call: { tool_call_type: 'manual_upload' },
+  interoperability_contract_ids: [interopContractId],
+})
+dacId = dacResp.data.id!
+ctx.dacSlug = dacResp.data.slug!
+```
+
+## 008 — ingest two Stripe customer rows
+
+Two rows, ingested as inline JSON through the manual-upload DAC.
+Both carry a phone number; they differ in `tax_id`. The first row
+is KYC-complete — it has a verified tax id — so the filter
+(`customer.phone and customer.tax_id`) will pass it. The second
+omits `tax_id` entirely; even though it has a phone, the filter
+must reject it. Each ingest call gets its own batch id; both are
+pinned for the run scope in §010.
+
+```typescript
+const phone4 = String(Date.now()).slice(-4)
+
+const verifiedRow = {
+  customer_number: `CUST-KYC-${runSuffix}`,
+  customer_type: 'individual',
+  status: 'contracted',
+  name: 'Priya Anand',
+  email: `priya-${runSuffix}@example.com`,
+  phone: `+1202555${phone4}`,
+  tax_id: '123-45-6789',
+  currency: 'USD',
+  delinquent: 'true',
+}
+const unverifiedRow = {
+  customer_number: `CUST-NOKYC-${runSuffix}`,
+  customer_type: 'individual',
+  status: 'contracted',
+  name: 'Daniel Foster',
+  email: `daniel-${runSuffix}@example.com`,
+  phone: `+1203555${phone4}`,
+  currency: 'USD',
+  delinquent: 'true',
+  // tax_id intentionally absent — the workflow filter must reject this row
+}
+
+const [verifiedIngest, unverifiedIngest] = await Promise.all([
+  api.dataActivationClients.ingest(tenantSlug, datalakeSlug, ctx.dacSlug, { data: verifiedRow }),
+  api.dataActivationClients.ingest(tenantSlug, datalakeSlug, ctx.dacSlug, { data: unverifiedRow }),
+])
+ctx.batchVerified = verifiedIngest.data.batch_id!
+ctx.batchUnverified = unverifiedIngest.data.batch_id!
+```
+
+## 009 — wait for both ingest batches to reach steady-state
+
+Ingestion is async — the DAC enqueues per-row jobs that the
+`BatchMergeWorker` drains into the regulated customer table. Poll
+the DAC's activation logs until both batches show a row with
+`rows_ingested >= 1` and a non-empty `output_files` array (the
+merged Parquet landed in object storage). Only then is it safe to
+run the workflow against these rows.
+
+```typescript
+const targetBatches = new Set([ctx.batchVerified, ctx.batchUnverified])
+const deadline = Date.now() + 90_000
+let greenCount = 0
+while (Date.now() < deadline) {
+  const { data } = await api.dataActivationClients.logs.list(tenantSlug, datalakeSlug, ctx.dacSlug)
+  const green = new Set<string>()
+  for (const row of (data.data ?? []) as Array<Record<string, unknown>>) {
+    const b = row.batch_id
+    if (typeof b !== 'string' || !targetBatches.has(b)) continue
+    if (typeof row.rows_ingested !== 'number' || row.rows_ingested < 1) continue
+    const files = row.output_files
+    if (!Array.isArray(files) || files.length === 0) continue
+    green.add(b)
+  }
+  greenCount = green.size
+  if (greenCount === targetBatches.size) break
+  await new Promise((r) => setTimeout(r, 1_000))
+}
+if (greenCount !== targetBatches.size) {
+  throw new Error(`only ${greenCount}/2 customer batches reached steady-state within 90s`)
+}
+```
+
+## 010 — run the workflow against the two batches
+
+`workflows.run` with `manual_override: false` evaluates the
+filter, so the `customer.phone and customer.tax_id` filter
+genuinely routes each row. The SQL where-clause scopes the run to
+exactly the two batches §008 ingested (`ra` is the
+regulated-customer alias the run-query exposes).
+
+The SMS action's `trigger_template: 'now'` dispatches the action
+immediately rather than scheduling it, so the run reaches a
+terminal status on its own — poll `batchLogs.refresh` until it
+leaves `:pending`. A `:partial` status is expected and fine here:
+one row passed and one was filtered.
+
+```typescript
+const runResp = await api.workflows.run(tenantSlug, datalakeSlug, ctx.workflowSlug, {
+  sql_where_clause: `ra.batch_id IN ('${ctx.batchVerified}', '${ctx.batchUnverified}')`,
+  mode: 'live',
+  manual_override: false,
+})
+ctx.runLogId = runResp.data.workflow_run_log_id!
+ctx.runBatchId = runResp.data.batch_id!
+
+const deadline = Date.now() + 120_000
+let status: string | null = null
+while (Date.now() < deadline) {
+  const { data: log } = await api.workflows.batchLogs.refresh(tenantSlug, datalakeSlug, ctx.workflowSlug, ctx.runLogId)
+  status = log.status ?? null
+  if (status && status !== 'pending') break
+  await new Promise((r) => setTimeout(r, 2_000))
+}
+if (status === 'failed') throw new Error('workflow run reached :failed')
+if (!status || status === 'pending') {
+  throw new Error('workflow run did not leave :pending within 120s')
+}
+```
+
+## 011 — verify the filter routed: verified passes, unverified is filtered
+
+Each row produced a Workflow Execution Log. The KYC-complete
+customer (phone + tax id) passes the filter, so its WEL is
+`:executing` or `:completed`. The customer missing the tax id
+fails the filter, so its WEL is `:filtered`. A run where both
+passed — or both were filtered — would mean the filter is not
+actually evaluating both `customer.phone` and `customer.tax_id`.
+
+```typescript
+const { data: wfLogs } = await api.workflows.workflowLogs.list(tenantSlug, datalakeSlug, ctx.workflowSlug)
+const ourWels = (wfLogs.data ?? []).filter(
+  (w) => (w as { batch_id?: string }).batch_id === ctx.runBatchId,
+)
+if (ourWels.length !== 2) {
+  throw new Error(`expected 2 WELs for the run, got ${ourWels.length}`)
+}
+
+const byStatus: Record<string, number> = {}
+for (const w of ourWels) {
+  const st = (w as { status?: string }).status ?? 'unknown'
+  byStatus[st] = (byStatus[st] ?? 0) + 1
+}
+const passCount = (byStatus.executing ?? 0) + (byStatus.completed ?? 0)
+if (passCount !== 1) {
+  throw new Error(`expected 1 pass-branch WEL, got ${passCount} — distribution ${JSON.stringify(byStatus)}`)
+}
+if ((byStatus.filtered ?? 0) !== 1) {
+  throw new Error(
+    `expected 1 :filtered WEL (the tax-id-missing customer) — distribution ${JSON.stringify(byStatus)}`,
+  )
+}
+```
+
+## 012 — read the rendered dunning SMS back from the message dataset
+
+A `trigger_template: 'now'` action that passed the filter fires
+immediately and persists a row in the regulated `message`
+dataset, carrying the fully-rendered SMS body. Search that
+dataset scoped to this workflow, poll until the row appears, and
+extract the `/t/<token>` shortlink the platform baked into the
+body when it minted the connected-app page token.
+
+```typescript
+const { data: userSearch } = await api.datasets.createUserSearch(tenantSlug, datalakeSlug, 'message', {
+  search_query: `rm.workflow_id = '${workflowId}'`,
+})
+if (userSearch.status !== 'completed') {
+  throw new Error(`message user-search status=${userSearch.status} error=${userSearch.error_message ?? '(none)'}`)
+}
+
+const deadline = Date.now() + 45_000
+let messages: Array<Record<string, unknown>> = []
+while (Date.now() < deadline && messages.length === 0) {
+  const { data } = await api.datasets.search(tenantSlug, datalakeSlug, 'message', {
+    userSearchId: userSearch.id!,
+    dataAccessMode: 'regulated',
+  })
+  messages = (data.data ?? []) as Array<Record<string, unknown>>
+  if (messages.length === 0) await new Promise((r) => setTimeout(r, 1_000))
+}
+if (messages.length === 0) {
+  throw new Error('no dunning SMS message persisted for the workflow within 45s')
+}
+
+const withLink = messages
+  .map((m) => String(m.body ?? ''))
+  .find((body) => body.includes('/t/') && body.includes('needs your attention'))
+if (!withLink) {
+  throw new Error(`no rendered dunning body with a /t/ link — bodies: ${JSON.stringify(messages.map((m) => m.body))}`)
+}
+const tokenMatch = withLink.match(/\/t\/([A-Za-z0-9_-]+)/)
+if (!tokenMatch) {
+  throw new Error(`no /t/<token> in rendered body: ${withLink}`)
+}
+ctx.dunningShortPath = tokenMatch[1]!
+```
+
+## 013 — resolve the connected-app deep-link and post tracking
+
+The `/t/<token>` shortlink the SMS carries resolves via
+`connectedApps.resolvePage` — the `route_path` must match the
+action's `connected_app_route`. Posting `opened_at` +
+`form_submitted_at` via `updateMessageTracking` then mirrors what
+the connected-app frontend does when the customer opens the
+payment portal, closing the SMS → reply loop end-to-end.
+
+```typescript
+const { data: resolved } = await api.connectedApps.resolvePage(tenantSlug, datalakeSlug, ctx.connectedAppSlug, {
+  short_path: ctx.dunningShortPath,
+  user_agent: 'cookbook-doctest/dunning-sms',
+})
+if (resolved.route_path !== '/portal/pay') {
+  throw new Error(`resolvePage route_path mismatch: ${resolved.route_path}`)
+}
+if (!(resolved.message?.body ?? '').includes('needs your attention')) {
+  throw new Error('resolved page message body missing the dunning copy')
+}
+
+const now = new Date().toISOString()
+const { data: tracked } = await api.connectedApps.updateMessageTracking(tenantSlug, datalakeSlug, ctx.connectedAppSlug, {
+  short_path: ctx.dunningShortPath,
+  opened_at: now,
+  form_submitted_at: now,
+})
+if (!tracked.message?.opened_at || !tracked.message?.form_submitted_at) {
+  throw new Error('message tracking did not persist opened_at + form_submitted_at')
+}
+```
+
+# Branches
+
+- **The unverified customer is filtered, not failed** — §011
+  asserts the tax-id-missing customer's WEL is `:filtered`, a
+  distinct terminal status from `:failed`. A filtered row is a
+  *correct* outcome: the workflow looked at it, the
+  `customer.phone and customer.tax_id` filter rendered empty
+  because one conjunct was falsy, and the platform recorded the
+  row as intentionally skipped. No SMS runs for a filtered row —
+  exactly the business rule (never dun a customer whose KYC is
+  incomplete).
+- **Both conjuncts are load-bearing** — the filter is an `and` of
+  two preconditions. The §008 unverified row has a phone, so it
+  is the *tax-id* conjunct that fails it. A row missing the phone
+  instead would fail the same filter on the other conjunct. The
+  anchor vitest's §8 proves the opposite extreme: a filter gated
+  on a sentinel no customer can satisfy filters *every* row.
+- **The thirty-day recency guard** — §003's `context_datasets`
+  entry queries the `message` dataset for a prior dunning SMS to
+  the same customer in the last 30 days. On this fresh tenant it
+  returns empty, so the action runs. On a tenant with history, a
+  recent prior dunning message would make the action skip — the
+  platform's built-in guard against dunning the same customer
+  repeatedly within one billing cycle.
+
+# Rollback
+
+The cookbook doctest harness does not currently tear down created
+resources. The `_setup/accounts_receivable.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).
+
+# Outcome
+
+After this cookbook's thirteen steps run green:
+
+- An accounts-receivable tenant exists with an
+  accounts-receivable-domain datalake
+- An SMS tool, a Dunning payment-portal connected app, and a
+  Dunning SMS standard workflow (status `live`, `customer`
+  dataset) are registered
+- A Stripe data source, a Manual Upload tool, a Stripe Customer
+  interop contract, and a manual-upload DAC form a working
+  ingestion chain
+- Two customers have been ingested through that chain — one
+  KYC-complete, one missing a tax id
+- Running the workflow routed them correctly: the verified
+  customer passed the phone + tax-id filter and dispatched an
+  SMS; the unverified customer was `:filtered`
+- The rendered dunning SMS is readable from the `message`
+  dataset, carrying the "needs your attention" copy with the
+  overdue account number and a `/t/` deep-link
+- The connected-app deep-link the SMS carried resolves, and
+  message tracking records the open + form-submit timestamps
+
+The business outcome — a payment-reminder SMS sent to a reachable
+and KYC-complete delinquent customer, with a working pay-invoice
+link — is demonstrated end-to-end, not merely provisioned.
+
+# See also
+
+- `_setup/accounts_receivable.md` — the inlined bootstrap that
+  provisions the tenant + datalake this cookbook starts from
+- `welcome-sms-for-customers.md` — the sibling AR cookbook; same
+  customer-dataset shape, a simpler phone-only filter
+- `.agent/tools.md` — SMS (`tool_body_type: sns`) and
+  manual-upload tool body shapes; intent classification
+- `.agent/connected_apps.md` — connected-app registration + the
+  resolve-page / message-tracking reply loop
+- `.agent/interoperability_contracts.md` — custom contract shape,
+  `template_config` vs `mdm_input_config`
+- `.agent/data_activation_clients.md` — data source → tool →
+  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
+  Stripe customer / MDM Liquid templates §006 loads
+- `integration-tests/tests/accounts_receivable/dunning-sms-workflow.test.ts` —
+  the anchor green test (§1–§8) these snippets are lifted from
+- `integration-tests/tests/accounts_receivable/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