@alvera-ai/platform-sdk 0.17.0 → 0.18.0

package/.agent/cookbook/_fixtures/organic-marketing/_lead_submissions_foundation_legal_entity.liquid

@@ -0,0 +1,80 @@
+{% comment %}
+  Foundation Airflow Lead Form → Foundation LegalEntity attrs.
+
+  Maps a single lead-form row into a `LegalEntity` upsert payload. Used by
+  a contract whose `resource_type` is `"legal_entity"` and whose
+  `mdm_input_config` is `{ type: "null" }` — the row IS the subject, so
+  there is nothing to resolve and the legal entity is written directly.
+  Identifier dedupe in `Platform.Datasets.LegalEntities.upsert_legal_entity/5`
+  collapses repeat submissions sharing the same digital identifier (the
+  verified email) onto one legal-entity row.
+
+  ONE WRITER PER SUBJECT. That dedupe is a find-or-create against a unique
+  index on `(uri, id_type, id_number)` that deliberately omits the legal
+  entity, so two contracts resolving the same subject at the same instant
+  do not each succeed — the loser is refused. This template is safe on its
+  own client; pair it with a generic-table contract and they must be
+  sequenced, never bound to one client together.
+
+  ## Branches
+    * `legal_entity_type: "individual"` when `company` is empty
+    * `legal_entity_type: "business"`   when `company` is non-empty
+      (the company name becomes `business_name` and the submitter's name
+      is dropped — businesses don't carry first/last on the LE row)
+
+  ## Identifications
+    * One identification per row: `id_type: "digital_identifier"`,
+      `uri: <p.source_uri>` — the system-of-record URI, which the Data
+      Activation Client injects from the configured `data_source.uri` —
+      and `id_number: <email>`. There is one schema and it holds the real
+      value; masking is infrastructure (the tokenized and redacted lakes),
+      not a second set of attrs to write into.
+
+    * NOTE the key names. A LegalEntity identification is
+      `id_type` / `id_number` / `uri`, which is what this template writes.
+      An MDMInput identifier — what a contract's `mdm_input_config`
+      renders — is `uri` / `type` / `value`. Unknown keys are dropped
+      rather than refused, so the wrong shape resolves nothing and fails
+      as a bare `mdm_dispatcher_error` naming no field.
+{% endcomment %}
+{% assign p = msg %}
+{% assign le_type = "individual" %}
+{% if p.company and p.company != "" %}{% assign le_type = "business" %}{% endif %}
+{% assign name_parts = p.name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "{{ le_type }}",
+  "role": "direct",
+  {% if le_type == "business" %}"business_name": "{{ p.company | json_escape }}",{% endif %}
+  {% if le_type == "individual" and first_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if le_type == "individual" and last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% endif %}
+  {% comment %}
+    Optional date_of_birth + phone_numbers, flat like every other
+    field. There is ONE LegalEntity schema now and it declares both —
+    `field(:date_of_birth, MaskedDate)` and
+    `has_many(:phone_numbers, LegalEntityPhoneNumber)`. GH-859 removed
+    the public/regulated pair of schemas, and with it the nested
+    `regulated_legal_entity` block this template used to carry:
+    masking is infrastructure — the tokenized and redacted lakes —
+    not a second schema to write into. A column holds its real value.
+
+    `date_of_birth` is rendered as ISO 8601 YYYY-MM-DD; if the CSV
+    column is absent, the {% if %} guard renders nothing and
+    :date_of_birth stays nil.
+
+    `phone_numbers` renders as a single-element list — matches the
+    one-phone-per-lead shape of inbound lead-capture forms. Absent
+    column leaves the has_many empty.
+  {% endcomment %}
+  {% if p.date_of_birth and p.date_of_birth != "" %}"date_of_birth": "{{ p.date_of_birth | json_escape }}",{% endif %}
+  {% if p.phone and p.phone != "" %}"phone_numbers": [{ "phone_number": "{{ p.phone | json_escape }}" }],{% endif %}
+  "identifications": [
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | json_escape }}",
+      "id_number": "{{ p.email | json_escape }}"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/{foundation → organic-marketing}/_lead_submissions_foundation_mdm.liquid

@@ -13,7 +13,7 @@
        whose `find_legal_entity_by_identifications/2` dedupe path collapses
        repeat resolves sharing the same `(id_type, id_number, uri)` triple
        onto the SAME LegalEntity row written by Contract A.
-    3. Pins the resulting GT event's `mdm_subject_id == legal_entity.id`.
+    3. Pins the resulting GT event's `legal_entity_id == legal_entity.id`.
 
   The verifying platform URI flows from `data_source.uri` injected by DAC
   as `source_uri` — same upstream channel as Contract A's LE template, so
@@ -42,6 +42,7 @@
   "identifiers": [
     {
       "system": "{{ p.source_uri | json_escape }}",
+      "type": "digital_identifier",
       "value": "{{ p.email | json_escape }}"
     }
   ]

package/.agent/cookbook/_fixtures/payments-compliance/_compliance_screenings_generic_table.liquid

@@ -0,0 +1,57 @@
+{% comment %}
+  Atomic FI ComplianceScreenings → `compliance_screenings` generic_table row.
+
+  Contract B (`resource_type: "generic_table"`, `generic_table_id` pinned
+  to the compliance-screenings table).
+
+  Source: GET /api/compliance-screenings on Atomic FI (paginated; the
+  fetch pipeline extracts the `data` array via the response_extractor and
+  streams one row per `msg`).
+
+  GH-859 removed the `compliance_screening` resource, and with it the
+  changeset that used to `put_change` the FK columns and call
+  `cast_tokenized_data` on the way past. Both jobs move to declarations:
+  `legal_entity_id` is stamped by the platform from Contract B's MDM
+  resolve (never a column, never written here), and the narrative + name
+  fields are `privacy_requirement: "tokenize"` / `"redact"` on the table,
+  so the raw value goes in and the derived lakes do the masking.
+
+  Two things survive unchanged, because they were always this template's
+  own work:
+
+    * The analytic numerics (`screening_score`, `aml_risk_score`,
+      `aml_velocity_count`) render UNQUOTED so they land as real numbers.
+      The workflow's gray-zone filter compares `screening_score` with
+      `>=` and `<`; a quoted "0.88" would compare as a string and the
+      band would silently stop meaning anything.
+    * `sanctions_matches` is explicitly looped. Liquid's default
+      rendering of a list produces a stringified Elixir list, not JSON —
+      the `{% for %}` emits one object per element so the jsonb column
+      receives a real array.
+{% endcomment %}
+{% assign p = msg %}
+{
+  "compliance_screening_number": "{{ p.compliance_screening_number | default: p.id | json_escape }}",
+  "account_holder_ref": "{{ p.account_holder_id | default: "" | json_escape }}",
+  "scope": "{{ p.scope | default: "account_holder" | json_escape }}",
+  "screening_type": "{{ p.screening_type | default: "sanctions" | json_escape }}",
+  "screening_status": "{{ p.screening_status | default: "pending" | json_escape }}",
+  "screened_entity_type": "{{ p.screened_entity_type | default: "individual" | json_escape }}",
+  "screening_score": {{ p.screening_score | default: 0 }},
+  "match_count": {{ p.match_count | default: 0 }},
+  "sanctions_screening_status": "{{ p.sanctions_screening_status | default: "" | json_escape }}",
+  "screened_entity_name": "{{ p.screened_entity_name | default: "" | json_escape }}",
+  "review_notes": "{{ p.review_notes | default: "" | json_escape }}",
+  "pep_list_name": "{{ p.pep_list_name | default: "" | json_escape }}",
+  "aml_risk_score": {{ p.aml_risk_score | default: 0 }},
+  "aml_velocity_count": {{ p.aml_velocity_count | default: 0 }},
+  "aml_high_risk_country": "{{ p.aml_high_risk_country | default: "" | json_escape }}",
+  "sanctions_matches": [{% for m in p.sanctions_matches %}{
+      "matched_name": "{{ m.matched_name | json_escape }}",
+      "matched_entity_type": "{{ m.matched_entity_type | default: "" | json_escape }}",
+      "match_score": {{ m.match_score | default: 0 }},
+      "source_list": "{{ m.source_list | default: "" | json_escape }}",
+      "source_id": "{{ m.source_id | default: "" | json_escape }}",
+      "false_positive_qualifier": "{{ m.false_positive_qualifier | default: "" | json_escape }}"
+    }{% unless forloop.last %},{% endunless %}{% endfor %}]
+}

package/.agent/cookbook/_fixtures/payments-compliance/_compliance_screenings_legal_entity.liquid

@@ -0,0 +1,30 @@
+{% comment %}
+  Atomic FI ComplianceScreenings → LegalEntity attrs.
+
+  Contract A (`resource_type: "legal_entity"`, `mdm_input_config`
+  `{ type: "null" }`). The account HOLDER a screening was run against is
+  the MDM subject, so this template writes that legal entity directly,
+  keyed on Atomic FI's `account_holder_id`.
+
+  Contract B's MDM input emits the SAME `(uri, account_holder_id)` pair,
+  which is what makes both contracts converge on one legal entity per
+  account holder rather than two.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.screened_entity_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  "role": "direct",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.account_holder_id | json_escape }}",{% endif %}
+  "identifications": [
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | default: "api.atomic.fi" | json_escape }}",
+      "id_number": "{{ p.account_holder_id | json_escape }}"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/payments-compliance/_compliance_screenings_mdm.liquid

@@ -0,0 +1,44 @@
+{% comment %}
+  Atomic FI ComplianceScreenings → MDMInput JSON.
+
+  Used by Contract B's `mdm_input_config` (`resource_type:
+  "generic_table"`). A screening references an account-holder id
+  (`p.account_holder_id`); resolving it routes through the LegalEntity
+  upsert, whose identification dedupe collapses repeat resolves sharing
+  the same `(id_type, id_number, uri)` triple onto the SAME LegalEntity
+  row Contract A wrote. The resolved subject's id is then stamped onto
+  the screening row as `legal_entity_id`.
+
+  GH-859 removed the `owner_type` / `account_holder_*` vocabulary along
+  with the AccountHolder resource: there is no LE+AH parent pair to
+  find-or-create, just the legal entity. The identifier `uri` flows from
+  `data_source.uri` — injected by the DAC as `source_uri`, the same channel
+  Contract A reads — so both contracts converge on one subject.
+
+  NOTE the key names. An MDMInput identifier is `uri` / `type` / `value`. A
+  LegalEntity identification, which is what Contract A writes, is `id_type` /
+  `id_number` / `uri`. They are different shapes for the same idea, and
+  unknown keys are dropped rather than refused — so the wrong one resolves
+  nothing and fails as a bare `mdm_dispatcher_error` naming no field.
+
+  The screened entity's name is carried onto the subject when the export
+  supplies one, which is what lets a reviewer see who was screened
+  without joining back to the screening row.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.screened_entity_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.account_holder_id | json_escape }}",{% endif %}
+  "identifiers": [
+    {
+      "uri": "{{ p.source_uri | default: "api.atomic.fi" | json_escape }}",
+      "type": "digital_identifier",
+      "value": "{{ p.account_holder_id | json_escape }}"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/payments-compliance/_payment_accounts_generic_table.liquid

@@ -0,0 +1,57 @@
+{% comment %}
+  Atomic FI PaymentAccount → `payment_accounts` generic_table row.
+
+  Contract B (`resource_type: "generic_table"`, `generic_table_id` pinned
+  to the payment-accounts table). One JSON field per GT column.
+
+  Source: GET /api/payment-accounts on Atomic FI (paginated; the fetch
+  pipeline extracts the `data` array via the response_extractor and
+  streams one row per `msg`).
+
+  GH-859 removed the `payment_account` resource along with every other
+  per-domain dataset, so the changeset that used to `put_change` the FK
+  columns is gone with it. `legal_entity_id` arrives the way it does for
+  every generic table now: Contract B's `mdm_input_config` resolves the
+  account holder and the platform stamps the subject onto the row. It is
+  NEVER declared as a column and never written here.
+
+  What survives the conversion is the part that was always this
+  template's own work:
+
+    * PCI-DSS-sensitive fields (`account_number`, `iban`, `card_pan`,
+      `wallet_address`) and the free-text narratives are declared
+      `privacy_requirement: "tokenize"` / `"redact"` on the table, so
+      the raw value goes in here and the derived lakes do the masking.
+      Masking is infrastructure, not a second schema to write into.
+    * `destination_country` is derived from `swift_bic` (chars 5-6 per
+      ISO 9362) or `iban` (chars 1-2 per ISO 13616), BIC preferred when
+      both are present, so a downstream agent reads the field instead of
+      re-parsing the identifier.
+    * `enabled_regimes` is joined into one delimited string rather than
+      rendered as a JSON array — a generic-table column is scalar, and a
+      `{{ x }}` on a list would emit a stringified Elixir list anyway.
+{% endcomment %}
+{% assign p = msg %}
+{% if p.swift_bic and p.swift_bic != "" %}
+  {% assign derived_country = p.swift_bic | slice: 4, 2 | upcase %}
+{% elsif p.iban and p.iban != "" %}
+  {% assign derived_country = p.iban | slice: 0, 2 | upcase %}
+{% else %}
+  {% assign derived_country = "" %}
+{% endif %}
+{
+  "payment_account_external_id": "{{ p.payment_account_external_id | default: "" | json_escape }}",
+  "payment_account_number": "{{ p.payment_account_number | default: "" | json_escape }}",
+  "account_holder_ref": "{{ p.account_holder_id | default: "" | json_escape }}",
+  "status": "{{ p.status | default: "pending" | json_escape }}",
+  "account_type": "{{ p.account_type | default: "bank_account" | json_escape }}",
+  "currency": "{{ p.currency | default: "" | json_escape }}",
+  "routing_number": "{{ p.routing_number | default: "" | json_escape }}",
+  "swift_bic": "{{ p.swift_bic | default: "" | json_escape }}",
+  "bank_name": "{{ p.bank_name | default: "" | json_escape }}",
+  "account_number": "{{ p.account_number | default: "" | json_escape }}",
+  "iban": "{{ p.iban | default: "" | json_escape }}",
+  "destination_country": "{{ derived_country | json_escape }}",
+  "purpose_of_payment_detail": "{{ p.purpose_of_payment_detail | default: "" | json_escape }}",
+  "enabled_regimes": "{% for r in p.enabled_regimes %}{{ r | json_escape }}{% unless forloop.last %},{% endunless %}{% endfor %}"
+}

package/.agent/cookbook/_fixtures/payments-compliance/_payment_accounts_legal_entity.liquid

@@ -0,0 +1,36 @@
+{% comment %}
+  Atomic FI PaymentAccount → LegalEntity attrs.
+
+  Contract A (`resource_type: "legal_entity"`, `mdm_input_config`
+  `{ type: "null" }`). The account HOLDER is the MDM subject a payment
+  account belongs to, so this template writes that legal entity
+  directly, keyed on Atomic FI's `account_holder_id`.
+
+  GH-859 removed the per-domain identity chain: there is no
+  `account_holder` resource sitting between the payment account and its
+  legal entity, and no `owner_type` to choose. One LegalEntity schema
+  carries every subject, and a payment account is a generic table row
+  that points at one.
+
+  Contract B's MDM input emits the SAME `(uri, account_holder_id)` pair,
+  which is what makes both contracts converge on one legal entity per
+  account holder rather than two.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.account_holder_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  "role": "direct",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.account_holder_id | json_escape }}",{% endif %}
+  "identifications": [
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | default: "api.atomic.fi" | json_escape }}",
+      "id_number": "{{ p.account_holder_id | json_escape }}"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/payments-compliance/_payment_accounts_mdm.liquid

@@ -0,0 +1,41 @@
+{% comment %}
+  Atomic FI PaymentAccount → MDMInput JSON.
+
+  Used by Contract B's `mdm_input_config` (`resource_type:
+  "generic_table"`). A payment-account row references an account-holder
+  id (`p.account_holder_id`); resolving it routes through the LegalEntity
+  upsert, whose identification dedupe collapses repeat resolves sharing
+  the same `(id_type, id_number, uri)` triple onto the SAME LegalEntity
+  row Contract A wrote. The resolved subject's id is then stamped onto
+  the payment-account row as `legal_entity_id`.
+
+  GH-859 removed the `owner_type` / `account_holder_*` vocabulary along
+  with the AccountHolder resource itself: there is no LegalEntity +
+  AccountHolder pair to find-or-create, just the legal entity. The
+  identifier `uri` flows from `data_source.uri` — injected by the DAC as
+  `source_uri`, the same channel Contract A reads — so both contracts emit
+  an identical pair and converge on one subject.
+
+  NOTE the key names. An MDMInput identifier is `uri` / `type` / `value`. A
+  LegalEntity identification, which is what Contract A writes, is `id_type` /
+  `id_number` / `uri`. They are different shapes for the same idea, and
+  unknown keys are dropped rather than refused — so the wrong one resolves
+  nothing and fails as a bare `mdm_dispatcher_error` naming no field.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.account_holder_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.account_holder_id | json_escape }}",{% endif %}
+  "identifiers": [
+    {
+      "uri": "{{ p.source_uri | default: "api.atomic.fi" | json_escape }}",
+      "type": "digital_identifier",
+      "value": "{{ p.account_holder_id | json_escape }}"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/primary-care-feedback/_cahps_appointments_generic_table.liquid

@@ -0,0 +1,70 @@
+{% comment %}
+  CAHPS Appointments → `appointments` generic_table row.
+
+  Contract B (`resource_type: "generic_table"`, `generic_table_id` pinned
+  to the appointments table). One JSON field per GT column.
+
+  GH-859 removed the `appointment` dataset along with every other
+  per-domain resource, so the FHIR R4 Appointment shape this template
+  used to emit — `participants[]` with `actor_type`, a nested identifier
+  array — has nowhere to go. An appointment is a table you declare, and
+  its columns are flat.
+
+  The load-bearing part survives unchanged: the vendor's
+  `appt_slot_status` string is mapped onto the canonical `status` the
+  workflow filter reads. That mapping is the contract's job, not the
+  workflow's — a filter that had to know about `"3 - checked out"` would
+  be coupled to one vendor's export format.
+
+  `legal_entity_id` is NEVER declared or written here. Contract B's
+  `mdm_input_config` resolves the patient and the platform stamps the
+  subject's id onto the row; the name is reserved, so declaring a column
+  of it 422s this create rather than shadowing the stamp.
+
+  GT columns:
+    * `appointment_id`  — the vendor's id (unique, so a re-ingest updates)
+    * `status`          — canonical: fulfilled / cancelled / arrived /
+                          booked / pending
+    * `appt_start`      — vendor `3/12/2026` + `2:30 PM` composed into one
+                          ISO 8601 local timestamp
+    * `minutes_duration`— integer, so downstream analytics can average it
+    * `description`, `department`, `provider_id`, `provider_name`
+    * `patient_name`, `patient_mobile` — tokenized PII, and the SMS
+      destination the workflow's action templates read
+    * `patient_ref`     — the vendor's patient id, carried so a row can be
+      traced back to the export without joining the subject
+    * `care_gaps`       — jsonb ARRAY of open care gaps. Declared
+      `jsonb` + `is_array: true` + `redact`, which makes it the one
+      column here that exercises all three of those at once.
+
+  NOTE the explicit loop on `care_gaps`. Liquid's `to_json` on a nested
+  array renders Ruby-ish inspect output rather than JSON, so each entry is
+  written field by field. An absent `care_gaps` renders `[]` — a real
+  empty array, not null — which is what the column expects.
+{% endcomment %}
+{% assign a = msg %}
+{% assign raw_status = a.appt_slot_status | default: "" | downcase | strip %}
+{% assign status = "pending" %}
+{% if raw_status == "2 - checked in" %}{% assign status = "arrived" %}
+{% elsif raw_status == "3 - checked out" or raw_status == "4 - charge entered" %}{% assign status = "fulfilled" %}
+{% elsif raw_status == "f - filled" %}{% assign status = "booked" %}
+{% elsif raw_status == "x - cancelled" %}{% assign status = "cancelled" %}
+{% endif %}
+{
+  "appointment_id": "{{ a.appointment_id | default: "" | json_escape }}",
+  "status": "{{ status }}",
+  {% if a.appt_date and a.appt_date != "" %}"appt_start": "{{ a.appt_date | parse_date: "{M}/{D}/{YYYY}" }}T{% if a.appt_start_time and a.appt_start_time != "" %}{{ a.appt_start_time | convert_time: "{h12}:{m} {am}" }}{% else %}00:00:00{% endif %}",{% endif %}
+  {% if a.appt_slot_duration and a.appt_slot_duration != "" %}"minutes_duration": {{ a.appt_slot_duration }},{% endif %}
+  "description": "{{ a.appt_type | default: "" | json_escape }}",
+  "department": "{{ a.svc_department | default: "" | json_escape }}",
+  "provider_id": "{{ a.rndrng_provider_id | default: "" | json_escape }}",
+  "provider_name": "{{ a.rndrng_provider | default: "" | json_escape }}",
+  "patient_name": "{{ a.patient_name | default: "" | json_escape }}",
+  "patient_mobile": "{{ a.patient_mobile_no | default: "" | json_escape }}",
+  "patient_ref": "{{ a.patient_id | default: "" | json_escape }}",
+  "care_gaps": [{% for g in a.care_gaps %}{
+      "code": "{{ g.code | json_escape }}",
+      "description": "{{ g.description | default: "" | json_escape }}",
+      "due_date": "{{ g.due_date | default: "" | json_escape }}"
+    }{% unless forloop.last %},{% endunless %}{% endfor %}]
+}

package/.agent/cookbook/_fixtures/primary-care-feedback/_cahps_appointments_legal_entity.liquid

@@ -0,0 +1,52 @@
+{% comment %}
+  CAHPS Appointments → LegalEntity attrs.
+
+  Contract A (`resource_type: "legal_entity"`, `mdm_input_config`
+  `{ type: "null" }`) — the patient on the CAHPS row IS the MDM subject,
+  so this template writes the LegalEntity directly.
+
+  GH-859 removed the per-domain identity schemas: there is no `patient`
+  resource and no FHIR R4 Patient shape to fill in. One LegalEntity
+  schema carries every subject the platform knows, and it is flat —
+  `first_name` / `last_name` / `date_of_birth` / `phone_numbers` /
+  `identifications`, not `name[].given` / `birth_date` / `telecom[]`.
+
+  ## Identifications
+    * `patient-id` — always present, the practice's own patient id
+    * `enterprise-id` — only when the CAHPS export carries one (a
+      multi-practice enterprise MRN)
+
+  Both use `id_type: "digital_identifier"` with the verifying platform's
+  URI, which the DAC injects from the configured `data_source.uri` as
+  `source_uri`. Contract B's MDM input emits the SAME `(uri, patient_id)`
+  pair, which is what makes both contracts converge on one LegalEntity
+  per patient rather than two.
+
+  Parent-row filtering is handled by the contract's `filter_template`,
+  not here.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.patient_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  "role": "direct",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.patient_name | default: "" | strip | json_escape }}",{% endif %}
+  {% if p.patientdob and p.patientdob != "" %}"date_of_birth": "{{ p.patientdob | parse_date: "{M}/{D}/{YYYY}" }}",{% endif %}
+  {% if p.patient_mobile_no and p.patient_mobile_no != "" %}"phone_numbers": [{ "phone_number": "{{ p.patient_mobile_no | json_escape }}" }],{% endif %}
+  "identifications": [
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | json_escape }}",
+      "id_number": "{{ p.patient_id | default: "" | json_escape }}"
+    }{% if p.enterprise_id and p.enterprise_id != "" %},
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | json_escape }}:enterprise",
+      "id_number": "{{ p.enterprise_id | json_escape }}"
+    }{% endif %}
+  ]
+}

package/.agent/cookbook/_fixtures/primary-care-feedback/_cahps_appointments_mdm.liquid

@@ -0,0 +1,42 @@
+{% comment %}
+  CAHPS Appointments → MDMInput JSON.
+
+  Used by Contract B's `mdm_input_config` (`resource_type:
+  "generic_table"`). The DAC pipeline renders this against the CAHPS row,
+  validates the result as an MDM input, and resolves it — routing the
+  attrs through the LegalEntity upsert, whose identification dedupe
+  collapses repeat resolves sharing the same `(id_type, id_number, uri)`
+  triple onto the SAME LegalEntity row Contract A wrote. The resolved
+  subject's id is then stamped onto the appointment row as
+  `legal_entity_id`.
+
+  The `system` value flows from `data_source.uri`, injected by the DAC as
+  `source_uri` — the same channel Contract A's template reads — so both
+  contracts emit an identical `(uri, patient_id)` pair and converge on
+  one LegalEntity per patient.
+
+  GH-859 removed the per-domain identity vocabularies. There is ONE field
+  set: `first_name` / `last_name` / `date_of_birth` / `phone` / `email` /
+  `identifiers`. `given_name`, `family_name` and `birth_date` are gone —
+  not renamed variants to pick between, and a template still sending them
+  resolves nothing rather than failing loudly.
+{% endcomment %}
+{% assign p = msg %}
+{% assign name_parts = p.patient_name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "individual",
+  {% if first_name != "" and last_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% else %}"last_name": "{{ p.patient_name | default: "" | strip | json_escape }}",{% endif %}
+  {% if p.patientdob and p.patientdob != "" %}"date_of_birth": "{{ p.patientdob | parse_date: "{M}/{D}/{YYYY}" }}",{% endif %}
+  {% if p.patient_mobile_no and p.patient_mobile_no != "" %}"phone": "{{ p.patient_mobile_no | json_escape }}",{% endif %}
+  "identifiers": [
+    {
+      "system": "{{ p.source_uri | json_escape }}",
+      "value": "{{ p.patient_id | default: "" | json_escape }}",
+      "type": "digital_identifier"
+    }
+  ]
+}

package/.agent/cookbook/_fixtures/subscription-saas/_customers_subscription_generic_table.liquid

@@ -0,0 +1,38 @@
+{% comment %}
+  Stripe Customers → `customers` generic_table row.
+
+  Contract B (`resource_type: "generic_table"`, `generic_table_id`
+  pinned to the Stripe Customers table). One JSON field per GT column.
+
+  Contract B also carries an `mdm_input_config` (separate template), so
+  the platform resolves each row's subject and stamps `legal_entity_id`
+  onto the row. `legal_entity_id` is NEVER declared as a column and
+  never written here — the stamp is the platform's, and the name is
+  reserved, so declaring it 422s this create rather than shadowing it.
+
+  GT columns:
+    * `customer_number` — Stripe's customer id (the unique column, so a
+      re-fetch updates the same row instead of inserting a duplicate)
+    * `customer_type`, `status`, `currency` — commercial state, not PII
+    * `name`, `email`, `phone`, `tax_id` — tokenized PII. `tax_id` is
+      the KYC gate the dunning workflow filters on, so a template that
+      drops it makes every row look KYC-incomplete and the workflow
+      filters all of them — green ingest, silently empty outcome.
+    * `delinquent` — boolean; Stripe sends the string "false"/"true",
+      which renders unquoted here and lands as a real boolean
+    * `address_city`, `address_country` — coarse location, not PII
+{% endcomment %}
+{% assign p = msg %}
+{
+  "customer_number": "{{ p.customer_number | json_escape }}",
+  "customer_type": "{{ p.customer_type | default: "individual" | json_escape }}",
+  "status": "{{ p.status | default: "prospect" | json_escape }}",
+  "name": "{{ p.name | default: "" | json_escape }}",
+  "email": "{{ p.email | default: "" | json_escape }}",
+  "phone": "{{ p.phone | default: "" | json_escape }}",
+  "tax_id": "{{ p.tax_id | default: "" | json_escape }}",
+  "currency": "{{ p.currency | default: "" | json_escape }}",
+  "delinquent": {{ p.delinquent | default: "false" }},
+  "address_city": "{{ p.address_city | default: "" | json_escape }}",
+  "address_country": "{{ p.address_country | default: "" | json_escape }}"
+}

package/.agent/cookbook/_fixtures/subscription-saas/_customers_subscription_legal_entity.liquid

@@ -0,0 +1,48 @@
+{% comment %}
+  Stripe Customers → LegalEntity attrs.
+
+  Contract A (`resource_type: "legal_entity"`, `mdm_input_config`
+  `{ type: "null" }`) — this template writes the LegalEntity directly,
+  because the fetched Stripe customer IS the MDM subject.
+
+  ## Branches
+    * `legal_entity_type: "individual"` when Stripe's `customer_type`
+      is `individual` — the display name splits into first/last
+    * `legal_entity_type: "business"` otherwise (`enterprise`, …) — the
+      display name becomes `business_name` and no first/last is written,
+      because a business does not carry them
+
+  ## Identifications
+    * One per row: `id_type: "digital_identifier"`, `uri: <p.source_uri>`
+      (the DAC injects the configured `data_source.uri`),
+      `id_number: <customer_number>`. Contract B's MDM input emits the
+      SAME `(uri, value)` pair, which is what makes both contracts
+      converge on one LegalEntity row per customer instead of two.
+
+  There is ONE LegalEntity schema — GH-859 removed the public/regulated
+  pair, and with it the nested `regulated_customer` block this template
+  used to carry. Masking is infrastructure (the tokenized and redacted
+  lakes), not a second schema to write into.
+{% endcomment %}
+{% assign p = msg %}
+{% assign le_type = "business" %}
+{% if p.customer_type == "individual" %}{% assign le_type = "individual" %}{% endif %}
+{% assign name_parts = p.name | default: "" | split: " " %}
+{% assign first_name = name_parts[0] | default: "" %}
+{% assign last_name_parts = name_parts | slice: 1, 9 %}
+{% assign last_name = last_name_parts | join: " " %}
+{
+  "legal_entity_type": "{{ le_type }}",
+  "role": "direct",
+  {% if le_type == "business" %}"business_name": "{{ p.name | json_escape }}",{% endif %}
+  {% if le_type == "individual" and first_name != "" %}"first_name": "{{ first_name | json_escape }}",{% endif %}
+  {% if le_type == "individual" and last_name != "" %}"last_name": "{{ last_name | json_escape }}",{% endif %}
+  {% if p.phone and p.phone != "" %}"phone_numbers": [{ "phone_number": "{{ p.phone | json_escape }}" }],{% endif %}
+  "identifications": [
+    {
+      "id_type": "digital_identifier",
+      "uri": "{{ p.source_uri | json_escape }}",
+      "id_number": "{{ p.customer_number | json_escape }}"
+    }
+  ]
+}