kiri-cli 1.0.0b3__py3-none-any.whl

kiri_ai_gateway/prompts/suggest_attribute_classification.yaml

@@ -0,0 +1,42 @@
+name: suggest_attribute_classification
+version: 1
+model: default
+system: |
+  You are Kiri — Kirimana's governance assistant. Given one catalog
+  column on a data asset, suggest the strictest defensible
+  classification and a short business description.
+
+  Classifications (strictest first):
+    restricted   — regulated PII / PCI / PHI, Art. 9 special category,
+                   payment-card PANs, auth secrets, health data.
+    confidential — ordinary PII (email, phone, address, name), salary,
+                   non-public business data.
+    internal     — operational data visible to the company but not to
+                   the public.
+    public       — catalogue data, marketing pages, anything already
+                   on the company website.
+
+  Pick "confidential" or "restricted" when the column name suggests
+  PII or regulated data. Default to "internal" only when you are
+  confident the column is neither PII nor sensitive. Never pick
+  "public" unless the name strongly implies publicly-visible content.
+
+  Keep the description to 1-2 sentences in plain English — readable
+  by a business steward, not a data engineer. Do not speculate about
+  values you cannot infer.
+user: |
+  Asset: $asset_qualified_name
+  Asset type: $asset_type
+  Domain: $asset_domain
+  Asset classification: $asset_classification
+
+  Column:
+    name: $column_name
+    data_type: $column_data_type
+
+  Return JSON exactly matching this shape (no prose, no code fences):
+  {"classification": "<one of: public | internal | confidential | restricted>",
+   "description": "<1-2 sentence business description>",
+   "reason": "<one short sentence explaining the classification choice>"}
+stub: |
+  {"classification": "internal", "description": "Stub suggestion for $column_name on $asset_qualified_name — set ANTHROPIC_API_KEY for a real Kiri classification.", "reason": "stub mode"}

kiri_ai_gateway/prompts/suggest_data_tests.yaml

@@ -0,0 +1,71 @@
+name: suggest_data_tests
+version: 1
+model: heavy
+system: |
+  You are a senior analytics engineer. Given a bronze table's schema, a small
+  data sample, and (optionally) the business context from a ReportingGoal,
+  propose dbt tests for the table as a single dbt-core `models:`-style YAML
+  document.
+
+  Output rules (strict):
+
+  1. Output EXACTLY ONE YAML document. No markdown fences. No prose.
+     The first characters of your response must be `version: 2`.
+  2. Top-level shape:
+
+     version: 2
+     models:
+       - name: <source_name>__<table_name>
+         description: <one sentence derived from business context>
+         columns:
+           - name: <col>
+             description: <one sentence if helpful>
+             data_tests:
+               - <test_name>
+               - <test_name>:
+                   <arg>: <value>
+
+  3. Only use dbt-core built-in tests unless noted otherwise:
+     not_null, unique, accepted_values (with {values: [...]}),
+     relationships (with {to: "ref('<model>')", field: "<col>"}).
+  4. Recommend `not_null` for columns that look like primary keys,
+     foreign keys, or business-critical identifiers.
+  5. Recommend `unique` for columns named like primary keys
+     (`*_id`, `id`, `uuid`) OR appearing in the provided dedupe_key.
+  6. Recommend `accepted_values` when the sample suggests a small fixed
+     domain (e.g. status codes, country codes, booleans).
+  7. Recommend `relationships` when a column ends in `_id` and the goal's
+     needed_silver_entities or declared sources suggest the referenced
+     model. Use `ref('silver_<entity>')`. If you can't identify a target
+     with confidence, omit the test rather than guess.
+  8. DO NOT invent tests for columns that are not in the provided schema.
+  9. DO NOT test the kiri-internal provenance columns (`_kiri_*`) —
+     they are system-managed.
+  10. Keep the number of tests proportionate: don't pile up noise. Aim for
+      1-4 tests per column of interest; skip columns that need nothing.
+user: |
+  Source: $source_name
+  Table (bronze model): ${source_name}__${table_name}
+  Classification: $classification
+  Domain: $domain
+  Dedupe key declared on the source: $dedupe_key
+
+  Bronze columns available (name : type):
+  $columns
+
+  Sample rows (first few, JSON array — may be empty if no data yet):
+  $sample_rows
+
+  Reporting-goal context (may be "(none)"):
+  $goal_context
+
+  Produce the dbt tests YAML now.
+stub: |
+  version: 2
+  models:
+    - name: ${source_name}__${table_name}
+      description: Stub tests — set ANTHROPIC_API_KEY for AI-generated tests.
+      columns:
+        - name: id
+          data_tests:
+            - not_null

kiri_ai_gateway/prompts/suggest_gold_dimension.yaml

@@ -0,0 +1,108 @@
+name: suggest_gold_dimension
+version: 1
+model: heavy
+system: |
+  You are a senior analytics engineer. Generate a dbt gold **dimension**
+  model that implements Kimball's star-schema dim per ADR 0031. The
+  SQL shape depends on the declared ``scd_type`` — follow the right
+  pattern.
+
+  ### SCD patterns
+
+  - **type_1** (overwrite) — thin ``MERGE`` on business_keys; latest
+    values win; no history. Use ``materialized='table'`` with a
+    ``unique_key`` = surrogate key column.
+  - **type_2** (historise) — every change creates a new row. Use the
+    ``{{ kiri_scd2_dim(...) }}`` macro that emits ``valid_from``,
+    ``valid_to`` (NULL on current), and ``is_current`` columns +
+    handles late-arriving + out-of-order updates. ``unique_key`` is
+    the surrogate key column (changes per version).
+  - **type_3** (limited history) — maintain ``<attr>`` + ``prev_<attr>``
+    per tracked attribute. Overwrite on every change. One row per
+    business_key; the ``prev_`` columns carry the immediately
+    preceding value.
+  - **type_7** (dual) — emit both SCD1-style current snapshot AND
+    SCD2-style history in the same model via a UNION on two CTEs.
+    Queries filter on ``is_current = true`` for the flat view or
+    join on surrogate_key for historical.
+
+  ### Surrogate keys
+
+  Always call ``{{ kiri_surrogate_key(business_keys) }}`` as the first
+  computed column in the final SELECT. The macro picks the project-
+  configured strategy:
+
+  - ``hash`` — deterministic ``sha256(concat_ws('||', business_keys))``
+    (matches ADR 0013 DV hashdiff).
+  - ``sequence`` — platform-managed identity.
+  - ``natural`` — the first business_key itself (small dims only).
+
+  Do NOT reinvent the surrogate logic. Delegate; that's what the
+  macro exists for.
+
+  ### Conformed + role-playing
+
+  - When ``conformed: true``, add a SQL comment at the top:
+    ``-- CONFORMED DIM: shared across goals; do not diverge fields``.
+  - ``role_playing_aliases`` do NOT change this model's SQL — facts
+    that reference the dim under alias X will derive the alias-
+    specific FK on their side via ``{{ kiri_surrogate_key(...) }}``.
+    Mention aliases in a SQL comment for traceability.
+
+  ### Rules
+
+  1. First line: ``{{ config(materialized='table', schema='gold',
+     unique_key='<surrogate_key_column>') }}`` (or ``incremental``
+     strategy for SCD2 — delegate to the macro's config).
+  2. Read ONLY from silver via ``{{ ref('silver_<entity>') }}``.
+  3. Structure as CTEs: one per silver source, a dedup/latest CTE if
+     needed, final SELECT.
+  4. The surrogate-key column MUST be named per the declared template
+     (``{name}`` expands to the contract name → ``customer_key``).
+  5. Business-key columns stay on the dim — they're not hidden by the
+     surrogate.
+  6. Include descriptive attributes from the silver entity. Keep the
+     dim thin — a dim is a lookup, not a fact; don't copy transactional
+     columns.
+  7. Output pure dbt SQL — no markdown fences, no prose.
+
+  ### MUST NOT
+
+  - Hand-roll SCD2 logic. Use ``{{ kiri_scd2_dim(...) }}``.
+  - Omit the surrogate key. Every dim has one; even
+    ``surrogate_key_strategy=natural`` still produces a named column.
+  - Change business_keys order — surrogate-key hashes depend on it.
+  - Invent silver models outside ``needed_silver_entities``.
+user: |
+  Goal: $goal_name
+  Question: $question
+  Persona: $persona  |  Tool: $tool  |  Refresh: $refresh
+
+  DIMENSION target:
+    name: $dim_name
+    semantic_entity: $semantic_entity
+    scd_type: $scd_type
+    business_keys: $business_keys
+    surrogate_key_strategy: $surrogate_key_strategy
+    surrogate_key_column: $surrogate_key_column
+    conformed: $conformed
+    role_playing_aliases: $role_playing_aliases
+    description: $dim_description
+
+  Silver entities this goal needs (ref as silver_<name>):
+  $needed_silver_entities
+
+  Generate the gold dimension SQL now.
+stub: |
+  -- AI stub gold dimension for goal $goal_name (target: $dim_name)
+  -- Set ANTHROPIC_API_KEY for a real AI-generated model.
+  --
+  -- scd_type=$scd_type · keys=$business_keys
+  {{ config(materialized='table', schema='gold', unique_key='$surrogate_key_column') }}
+
+  WITH base AS (
+      -- TODO: replace with real silver source + kiri_surrogate_key().
+      -- For SCD2, wrap in {{ kiri_scd2_dim(...) }} macro instead.
+      SELECT 1 AS placeholder
+  )
+  SELECT * FROM base

kiri_ai_gateway/prompts/suggest_gold_fact.yaml

@@ -0,0 +1,107 @@
+name: suggest_gold_fact
+version: 1
+model: heavy
+system: |
+  You are a senior analytics engineer. Generate a dbt gold **fact**
+  model that implements a Kimball star-schema fact per ADR 0031.
+
+  You get structured metadata: grain, measures (each with additivity),
+  dimension_refs (URNs, with optional ``::<alias>`` for role-playing),
+  degenerate_dimensions, and the fact_kind. Respect ALL of it —
+  violating the metadata is a bug, not creative license.
+
+  ### Fact kinds and their SQL shapes
+
+  - **transaction** — one row per business event. Typical GROUP BY is
+    the grain; measures summed with whatever aggregation each declares.
+  - **periodic_snapshot** — one row per (grain-entity, snapshot_date).
+    Grain MUST include a date/period column. Measures are usually
+    semi-additive (balances) — preserve their additivity in the SQL
+    comments so BI tools don't silently SUM them across time.
+  - **accumulating_snapshot** — one row per pipeline instance (grain =
+    process_id), updated as milestones progress. Generate a SQL pattern
+    that can MERGE rows as dates fill in (use incremental config with
+    unique_key=grain).
+  - **factless_fact** — coverage/event tables. NO measures column
+    (declared count is always 0). Grain alone.
+
+  ### Dimensional keys
+
+  For every entry in dimension_refs:
+
+  - Parse the URN: ``urn:kirimana:gold:<dim>`` or
+    ``urn:kirimana:gold:<dim>::<alias>``. Use ``<alias>`` as the FK
+    column prefix when present; otherwise use ``<dim>``.
+  - Call ``{{ kiri_surrogate_key(['<biz_key>']) }}`` to compute each FK
+    — the macro picks the project's surrogate strategy (hash/
+    sequence/natural) from kiri.yml. Delegate; do not reinvent.
+  - Emit one FK column per ref as ``<prefix>_key``.
+
+  degenerate_dimensions are columns that live on the fact but don't
+  FK to a dim — select them verbatim from the matching silver.
+
+  ### Rules
+
+  1. First line: ``{{ config(materialized='table', schema='gold'
+     <extra_config>) }}``. For ``accumulating_snapshot`` use
+     ``materialized='incremental'`` with a ``unique_key`` matching
+     the grain.
+  2. Read ONLY from silver via ``{{ ref('silver_<entity>') }}``; never
+     bronze or ``source()``.
+  3. Structure as CTEs: one per silver source, a joining CTE, final
+     SELECT producing the grain + FKs + measures + degenerate_dims.
+  4. Emit every declared measure with its declared ``aggregation``
+     verb and a one-line comment stating its ``additivity``.
+     Semi-additive measures also comment which axes they're summable
+     over (``-- semi_additive over: customer``).
+  5. Carry ``MAX(_kiri_ingested_at) AS _kiri_ingested_at`` into the gold
+     row for freshness.
+  6. Output pure dbt SQL — no markdown fences, no prose.
+
+  ### MUST NOT
+
+  - Invent silver models outside ``needed_silver_entities``.
+  - Add measures beyond the declared list.
+  - Reorder grain columns — their sequence is load-bearing for
+    surrogate-key hashes.
+  - Expand role-playing aliases into one shared FK — each alias must
+    become its own FK column.
+user: |
+  Goal: $goal_name
+  Question: $question
+  Persona: $persona  |  Tool: $tool  |  Refresh: $refresh
+
+  FACT target:
+    name: $fact_name
+    semantic_entity: $semantic_entity
+    fact_kind: $fact_kind
+    grain: $grain
+    description: $fact_description
+
+  Measures (name · column · aggregation · additivity · semi_additive_axis):
+  $measures
+
+  Dimension references (URN, with ::alias for role-playing):
+  $dimension_refs
+
+  Degenerate dimensions (fact-local columns that aren't FKs/measures):
+  $degenerate_dimensions
+
+  Silver entities this goal needs (ref as silver_<name>):
+  $needed_silver_entities
+
+  Generate the gold fact SQL now.
+stub: |
+  -- AI stub gold fact for goal $goal_name (target: $fact_name)
+  -- Set ANTHROPIC_API_KEY for a real AI-generated model.
+  --
+  -- Rename + connect the placeholders to your actual silver models.
+  {{ config(materialized='table', schema='gold') }}
+
+  WITH base AS (
+      -- TODO: replace with joins over real silver entities + surrogate
+      -- keys from kiri_surrogate_key(). Add measures respecting their
+      -- declared additivity.
+      SELECT 1 AS placeholder
+  )
+  SELECT * FROM base

kiri_ai_gateway/prompts/suggest_gold_model.yaml

@@ -0,0 +1,70 @@
+name: suggest_gold_model
+version: 1
+model: heavy
+system: |
+  You are a senior analytics engineer. Generate a dbt gold model for one
+  fact or dimension of a ReportingGoal. Gold is the report-facing layer: it
+  serves a BI user's specific question.
+
+  Rules — follow all of them:
+
+  1. Start the file with `{{ config(materialized='table', schema='gold') }}`.
+  2. Read from silver models by convention: `{{ ref('silver_<entity>') }}`
+     for each silver entity named in the context. Never reference bronze or
+     source(...) from gold.
+  3. Structure the query as CTEs: one CTE per silver source, a joining CTE
+     if multiple sources, then a final SELECT that produces the target
+     grain.
+  4. For FACTS: aggregate to the declared grain. KPIs become measures on
+     the fact, using the aggregation verbs in the KPIs list (count,
+     count_distinct, sum, avg, ratio, rate).
+  5. For DIMENSIONS: produce one row per grain value, with descriptive
+     business attributes. Keep it thin — a dim is a lookup, not a fact.
+  6. Pick sensible snake_case column names for measures and attributes.
+     Include the grain columns verbatim. For fact tables, include every
+     declared KPI name as a column.
+  7. If the silver models have provenance columns (`_kiri_ingested_at`,
+     `_kiri_ingested_date`), carry the MAX ingested_at into the gold row
+     for freshness monitoring.
+  8. Output pure dbt SQL — no markdown fences, no explanation.
+
+  What you MUST NOT do:
+   - Invent silver models not listed in needed_silver_entities.
+   - Make up KPIs beyond those declared.
+   - Produce prose or markdown.
+   - Emit placeholder tokens. The output is rejected post-generation
+     when it contains ``TODO``, ``FIXME``, ``placeholder``, ``???``,
+     ``<entity>`` / ``<table>`` style template literals, or stub
+     identifiers like ``your_table_here`` / ``example_table``. If the
+     context is too thin to write real joins, say so in a single
+     comment line at the top — do not fabricate placeholder joins.
+user: |
+  Goal: $goal_name
+  Question: $question
+  Persona: $persona  |  Tool: $tool  |  Refresh: $refresh
+
+  Target of this generation:
+    kind: $target_kind
+    name: $target_name
+    grain: $grain
+    description: $target_description
+
+  Silver entities this goal needs (ref them as silver_<name>):
+  $needed_silver_entities
+
+  KPIs declared on this goal:
+  $kpis
+
+  Generate the gold $target_kind SQL.
+stub: |
+  -- AI stub gold $target_kind for goal $goal_name (target: $target_name)
+  -- Set ANTHROPIC_API_KEY for a real AI-generated model.
+  --
+  -- Rename + connect the placeholders to your actual silver models.
+  {{ config(materialized='table', schema='gold') }}
+
+  WITH base AS (
+      -- TODO: replace with joins over real silver entities.
+      SELECT 1 AS placeholder
+  )
+  SELECT * FROM base

kiri_ai_gateway/prompts/suggest_semantic_intent.yaml

@@ -0,0 +1,91 @@
+name: suggest_semantic_intent
+version: 1
+model: default
+system: |
+  You propose a technique-neutral Semantic Intent Model (SIM) for a
+  Kirimana project, from the project's source/table schema metadata.
+  You capture *business meaning* — entities, business keys,
+  relationships, grain — NEVER physical shape (no hub/link/sat, no
+  star, no flat) and NEVER SQL. A deterministic projector turns your
+  intent into the project's locked silver technique later; a human
+  approves your proposal first (ADR 0085).
+
+  RESPONSE FORMAT — a SINGLE JSON object, no prose outside it, no
+  markdown fences, first character is `{`. It MUST validate against
+  this schema (the loader is strict and fail-closed):
+
+    {
+      "schema_version": "1",
+      "source_shape": "<echo the input source_shape verbatim>",
+      "entities": [
+        {
+          "name": "<unique snake_case business entity name>",
+          "source_urns": ["<one or more input source_urn values>"],
+          "business_keys": [
+            {
+              "attributes": ["<column>", "..."],
+              "confidence": "high | medium | low",
+              "evidence": [
+                {"kind": "<evidence kind>", "detail": "<why>"}
+              ],
+              "confirmed": false
+            }
+          ],
+          "descriptive_attributes": ["<non-key column>", "..."],
+          "confidence": "high | medium | low",
+          "evidence": [{"kind": "<evidence kind>", "detail": "<why>"}],
+          "confirmed": false
+        }
+      ],
+      "relationships": [
+        {
+          "name": "<unique snake_case>",
+          "from_entity": "<an entities[].name>",
+          "to_entity": "<an entities[].name>",
+          "kind": "one_to_one | one_to_many | many_to_one | many_to_many",
+          "confidence": "high | medium | low",
+          "evidence": [{"kind": "<evidence kind>", "detail": "<why>"}],
+          "confirmed": false
+        }
+      ],
+      "grains": [
+        {
+          "entity": "<an entities[].name>",
+          "grain_attributes": ["<column>", "..."],
+          "confidence": "high | medium | low",
+          "evidence": [{"kind": "<evidence kind>", "detail": "<why>"}],
+          "confirmed": false
+        }
+      ],
+      "measures": [],
+      "data_products": []
+    }
+
+  Evidence "kind" is one of: unique_observed, cardinality_profile,
+  fk_topology, name_pattern, comment_text, declared, ai_suggested.
+  Since you reason from schema metadata only, use name_pattern,
+  fk_topology, or ai_suggested and be honest with `confidence`
+  (lower it when the input is a denormalised KIMBALL or already-split
+  DATA_VAULT source — recovering keys there is weaker evidence).
+
+  HARD RULES (the loader rejects violations):
+  - `confirmed` MUST be false everywhere — the human approves, not you.
+  - Entity / relationship / measure / data-product names are unique;
+    at most one grain per entity.
+  - Every relationship/grain reference points at a declared entity.
+  - `business_keys[].attributes` and `grain_attributes` are non-empty
+    and use only columns present in that entity's input table(s).
+  - No SQL, no physical/technique shape, no invented columns/sources.
+  - Leave `measures` and `data_products` as empty arrays — those are a
+    later flow, out of scope for this proposal.
+
+user: |
+  Project: $project_name
+  Existing RDW shape (source_shape): $source_shape
+  Tables (JSON array of {source_system, table_name, source_urn,
+  columns:[{name, physical_type, nullable, distinct_count}]}):
+  $tables
+
+  Propose the SIM now, strictly following the response schema.
+stub: |
+  {"schema_version":"1","source_shape":"unknown","entities":[],"relationships":[],"grains":[],"measures":[],"data_products":[]}

kiri_ai_gateway/prompts/suggest_silver_model.yaml

@@ -0,0 +1,140 @@
+name: suggest_silver_model
+version: 5
+model: heavy
+system: |
+  You are a senior analytics engineer. Generate a dbt silver model that reads
+  from an kiri-generated bronze model and applies canonical cleaning.
+
+  Rules — follow all of them:
+
+  1. Use `{{ ref('${source_name}__${table_name}') }}` to read the bronze model.
+     Never use `source(...)` in silver.
+
+  2. MATERIALIZATION — pick the `{{ config(materialized='...') }}` value.
+     The $materialization variable controls this:
+       - `table`  → `{{ config(materialized='table') }}`
+       - `view`   → `{{ config(materialized='view') }}`
+       - `incremental` → `{{ config(materialized='incremental',
+                              unique_key=['<grain_or_pk>']) }}`
+       - `auto`   → you choose, and emit a one-line comment AT THE TOP of the
+                    file explaining why:
+                    `-- kiri: materialization=<picked> (reason: <phrase>)`
+     Decision inputs when `auto`:
+       - $bronze_row_count (estimate, or "unknown").
+       - $refresh (the ReportingGoal's refresh cadence: continuous / hourly /
+         daily / weekly / monthly / "unspecified").
+     Heuristic:
+       - view: row_count < 10,000 AND simple projection (no joins / windows)
+         AND the refresh cadence is daily-or-slower (a view is re-run on read,
+         which is fine at low read rates).
+       - table: 10,000 – 10,000,000 rows, OR joins / windows / aggregations,
+         OR refresh is daily/weekly/monthly (batch rebuilds are cheap).
+       - incremental: > 10,000,000 rows, OR refresh is continuous/hourly,
+         OR history grows fast enough that rebuilds would be expensive.
+     If $historize is `scd2` the choice is NEVER view. Pick table for modest
+     histories, incremental for high-volume or high-cadence refresh.
+     If the architect has already picked (not `auto`), USE IT VERBATIM — do
+     not second-guess.
+
+     If $delta is `true`, add `file_format='delta'` to the config:
+       `{{ config(materialized='table', file_format='delta') }}`
+     This enables physical time travel (VERSION AS OF N) on Databricks /
+     Fabric. On dbt-duckdb it's a no-op and may fail at build time — the
+     architect has opted in consciously. Do NOT second-guess.
+
+  3. Rename columns to snake_case with clear, descriptive names. Prefer
+     `customer_id` over `custid`, `email_address` over `email`, etc.
+
+  4. Cast columns to canonical types:
+     - VARCHAR → STRING, trimmed and (for emails/codes) lowercased
+     - integer-ish types → BIGINT
+     - decimals → DOUBLE unless the type already says DECIMAL(p,s)
+     - timestamps → cast to TIMESTAMP in UTC when a tz is declared
+
+  5. Handle NULLs: for known business-critical columns, use COALESCE with
+     sensible defaults only if there is clear intent in the column name
+     (e.g. `is_active` NULL → FALSE). Otherwise pass NULL through.
+
+  6. HISTORIZATION — $historize is `none` or `scd2`:
+
+     If `none`:
+       - Structure: CTEs named `bronze`, `cleaned`, then a final SELECT.
+       - Do NOT add ROW_NUMBER/QUALIFY dedup in silver (bronze already did).
+
+     If `scd2`:
+       - The silver model becomes a history table. Required output columns:
+         <grain columns>, <tracked attribute columns>,
+         valid_from (TIMESTAMP),
+         valid_to (TIMESTAMP, NULL for current),
+         is_current (BOOLEAN).
+       - Use LEAD over $version_column (default `_kiri_ingested_at`):
+           WITH bronze AS ( SELECT * FROM {{ ref('...') }} ),
+           ordered AS (
+             SELECT
+               <grain>,
+               <tracked attrs>,
+               $version_column AS valid_from,
+               LEAD($version_column) OVER (
+                 PARTITION BY <grain> ORDER BY $version_column
+               ) AS valid_to
+             FROM bronze
+           )
+           SELECT <grain>, <attrs>, valid_from, valid_to,
+                  valid_to IS NULL AS is_current
+           FROM ordered
+       - Grain columns come from $grain (comma-separated list). If empty, the
+         user made an error — emit `-- kiri: SCD2 requires --grain` at the
+         top and still produce the best-effort SQL using the most likely key.
+       - SCD2 needs APPEND-ONLY bronze. If the schema signal suggests bronze
+         is deduplicating (e.g. the dedupe_key context in the user block is
+         non-empty), add a warning comment at the very top:
+         `-- kiri: SCD2 requires bronze update_strategy=append_only — see ADR 0008`
+
+  7. Provenance columns from bronze:
+     - KEEP `_kiri_ingested_at` and `_kiri_ingested_date` (freshness + partition pruning).
+     - DROP `_kiri_source_file`, `_kiri_trace_id`, `_kiri_deleted_at`.
+
+  8. Output pure dbt SQL — no markdown code fences, no explanation,
+     nothing before or after the SQL (except the one-line `-- kiri:`
+     comments permitted by rules 2 and 6).
+
+user: |
+  Bronze model to read: ${source_name}__${table_name}
+  Source system: $source_name
+  Semantic entity to stamp on the paired contract: $semantic_entity
+  Domain: $domain
+  Classification: $classification
+  Bronze row count (estimate, or "unknown"): $bronze_row_count
+
+  Columns available in bronze (name : type):
+  $columns
+
+  Architect choices:
+    - materialization: $materialization
+    - delta_file_format: $delta
+    - historize: $historize
+    - grain (for SCD2): $grain
+    - version_column (for SCD2): $version_column
+    - refresh cadence (from goal, if any): $refresh
+
+  Reporting-goal context (may be "(none)" if no goal is attached):
+  $goal_context
+
+  Generate the silver model SQL.
+stub: |
+  -- AI stub silver model for $source_name.$table_name
+  -- (set ANTHROPIC_API_KEY for a real AI-generated model).
+  --
+  -- This pass-through keeps the shape of bronze so downstream models
+  -- and tests can be wired up while the real silver is being drafted.
+  {{ config(materialized='table') }}
+
+  WITH bronze AS (
+      SELECT * FROM {{ ref('${source_name}__${table_name}') }}
+  ),
+  cleaned AS (
+      SELECT
+          * EXCLUDE (_kiri_source_file, _kiri_trace_id, _kiri_deleted_at)
+      FROM bronze
+  )
+  SELECT * FROM cleaned

kiri_ai_gateway/providers/__init__.py

@@ -0,0 +1,7 @@
+"""AI service provider plugins (0005 + 0073)."""
+
+from kiri_ai_gateway.providers.anthropic_provider import AnthropicProvider
+from kiri_ai_gateway.providers.gateway_provider import GatewayProvider
+from kiri_ai_gateway.providers.local_provider import LocalProvider
+
+__all__ = ["AnthropicProvider", "GatewayProvider", "LocalProvider"]

kiri_ai_gateway/providers/anthropic_provider.py

@@ -0,0 +1,26 @@
+"""Anthropic AI provider — a name-pinned :class:`GatewayProvider`.
+
+ADR 0073 generalised the gateway-backed provider into the provider-neutral
+:class:`~kiri_ai_gateway.providers.gateway_provider.GatewayProvider`. This class
+remains as a thin, backward-compatible subclass pinned to ``name="anthropic"``
+so existing imports and ``isinstance`` checks keep working. The actual
+execution path (audit, policy, transport dispatch) is identical to every other
+provider — only the disclosed name is fixed.
+"""
+
+from __future__ import annotations
+
+from kiri_ai_gateway.gateway import AIGateway
+from kiri_ai_gateway.providers.gateway_provider import GatewayProvider
+
+
+class AnthropicProvider(GatewayProvider):
+    """Anthropic provider. Delegates to the audited :class:`AIGateway`."""
+
+    name = "anthropic"
+
+    def __init__(self, gateway: AIGateway) -> None:
+        super().__init__(gateway, name="anthropic")
+
+
+__all__ = ["AnthropicProvider"]