# Domain Card Template V1

Дата: `YYYY-MM-DD`  
Домен: `<domain_name>`  
Статус: `draft | active | shadow | deprecated`  
Владелец: `<owner/team>`

## 1. Scope

Кратко: какую бизнес-задачу закрывает домен и что сознательно не входит в scope.

In-scope intents:

1. `<intent_1>`
2. `<intent_2>`

Out-of-scope:

1. `<intent_or_case_not_supported>`

## 2. Intent Contract

Для каждого intent фиксируем контракт.

### 2.1 `<intent_1>`

- `query_shape`: `FACTUAL_LIST | FACTUAL_SUMMARY`
- `required_filters`: `[<filter_a>, <filter_b>]`
- `optional_filters`: `[<filter_c>]`
- `resolver_signals`: ключевые фразы/паттерны распознавания
- `ambiguity_rules`: как разрешаем коллизии (дата vs счет vs номер договора)
- `fallback_policy`: только внутри intent, без смены домена

### 2.2 `<intent_2>`

- `query_shape`: `FACTUAL_LIST | FACTUAL_SUMMARY`
- `required_filters`: `[...]`
- `optional_filters`: `[...]`
- `resolver_signals`: `...`
- `ambiguity_rules`: `...`
- `fallback_policy`: `...`

## 3. Recipe Mapping

Связка `intent -> recipe_id` должна совпадать с runtime catalog (`addressRecipeCatalog.ts`).

| intent | recipe_id | mcp_method | expected_statuses |
| --- | --- | --- | --- |
| `<intent_1>` | `<address_*_v1>` | `<method>` | `matched_non_empty, no_raw_rows, materialized_but_not_anchor_matched` |
| `<intent_2>` | `<address_*_v1>` | `<method>` | `...` |

## 4. Anchor and Resolver Rules

- `anchor_type`: `counterparty | contract | account | date_range | ...`
- `anchor_resolution_order`: metadata-first порядок
- `min_confidence`: порог для factual-ответа
- `unresolved_behavior`: что отдаем при неполной резолюции

## 5. Limited Reasons (taxonomy)

Разрешенные категории для этого домена:

1. `<limited_reason_category_1>`
2. `<limited_reason_category_2>`

Запрещено:

- смешивать произвольные free-form причины;
- выдавать factual при unresolved required filter.

## 6. Test Coverage

Unit:

1. resolver intent positives
2. resolver negatives (непересечение с соседними intent)
3. filter extraction required/optional
4. ambiguity resolution tests

Integration:

1. recipe selection
2. execution status mapping
3. debug payload completeness

Live acceptance:

1. canonical questions
2. noisy/slang questions
3. follow-up chains

## 7. Gate Criteria

Domain gate:

- `strict_pass(route)=100%`
- `false_factual_rate=0`
- `execution_error_rate=0`

Global gate:

- baseline stress не ниже текущего эталона
- baseline follow-up не ниже текущего эталона

## 8. Rollout Plan

1. `shadow`: логируем и сравниваем без влияния на prod-ответ.
2. `soft-enable`: ограниченное включение (feature flag/percentage).
3. `prod`: полное включение после green global gate.

## 9. Artifacts

Обязательные артефакты:

1. `domain_<name>_card_v1.md`
2. `question_sets/domain_<name>_acceptance_<date>.json`
3. `runs/<run_id>/run_summary.json`
4. `runs/<run_id>/full_live_results.json`
5. `runs/<run_id>/failures_only.json`
6. `runs/<run_id>/README.md`

## 10. Change Log

- `YYYY-MM-DD` — `<what changed>`