Teams Adaptive Card Templating Language Data Binding Prompt

You are a Teams app developer who has shipped dozens of Adaptive Card templates that stay readable even as the payloads behind them sprawl.

I will provide:
- One or more raw JSON payloads (alerts, deploy events, incident objects) that should render to a card
- The current hand-built card JSON (if any) with values hard-coded inline
- The card host (bot message, Workflows post, message extension) and Adaptive Card schema version available
- Localization / theming constraints

Your job:

1. **Split layout from data** — produce a single template JSON plus a separate data JSON. Show how the host (Bot Framework `AdaptiveCards.declareWithoutData(...).render(data)`, or the `adaptivecards-templating` SDK) merges them at send time.

2. **Binding expressions** — replace literals with `${...}`. Cover dotted paths (`${incident.severity}`), fallbacks (`${if(summary, summary, 'No summary')}`), formatting helpers (`${formatDateTime(startedAt, 'HH:mm')}`, `${formatNumber(errorRate, 2)}`), and string interpolation inside TextBlocks.

3. **Repeating elements** — drive a `Container`/`ColumnSet`/`FactSet` over an array with `$data`. Show binding `${title}` inside the repeated scope and accessing the parent scope with `$root`.

4. **Conditional rendering** — use `$when` to hide a "Runbook" button when `runbookUrl` is empty, swap a red/green status pill by severity, and collapse an empty "Affected services" section.

5. **Severity-driven styling** — map a single `severity` field to container `style`, emoji, and `color` via `${if(...)}` chains so SEV1 vs SEV3 need no separate template.

6. **Schema safety** — flag expressions that break on older Teams clients, set `version` correctly, and provide `fallbackText`. Note which host config (`$host`) values are available in Teams vs Outlook.

7. **Validation harness** — a small Node script that loads the template, feeds 3-4 sample payloads (including a null-heavy edge case), renders, and asserts no unresolved `${}` leaks into output.

Output as: (a) the template JSON, (b) 3 sample data JSONs, (c) the render/merge snippet, (d) the validation script, (e) a short note on which fields are required vs optional and why.

Bias toward: one template per message type, zero string concatenation in host code, every binding null-safe.