# Stage 4 - Family Card v1 — VAT chain (runtime-aligned)

**document_status:** `ACTIVE`  
**family_name:** `НДС-цепочка — полнота прохождения от документа до налогового отражения`  
**family_id:** `VAT_CHAIN_COMPLETENESS_V1`  
**stage_scope:** `Stage 4 (P0-only)`  
**current_family_status:** `PARTIALLY_WORKING / NON-BLOCKER`  
**primary_gap:** `residual admissibility/materialization quality`  
**latest_pack:** `2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt`  
**next_pack_focus:** `targeted live narrowing + reject cleanup for VAT proof-path`  
**family_source_of_truth_questions:** `VAT-Q1 (13 июля поступление, 15 июля реализация — полная ли НДС-цепочка); VAT-Q2 (есть ли выпадение между документом, проводкой, НДС-регистром и книгой); VAT-Q3 (по July 2020 VAT path grounded-positive или остаются weak-mapping шумы)`  
**family_latest_live_replay:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\1_live_replay.txt`  
**family_latest_acceptance_run:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json`

## 1) Что фиксирует этот документ

Карточка разделяет два слоя:

1. `Runtime V1 (as-is)` — только то, что подтверждено текущим кодом и run-артефактами.
2. `Target V2 (planned)` — что нужно дожать следующими family-pack, но пока не является hard gate текущей приемки.

Это соответствует Stage 4 family-based execution в рамках `P0-only` без перехода в Stage 5 и без архитектурного redesign.

## 2) Runtime V1 (фактический контракт на 2026-03-29)

### 2.1 Claim contract (as-is)

- **primary claim_type:** `prove_vat_chain_completeness`
- **additional claim_types:** пока не выделялись как first-class в runtime
- **границы claim:**
- не расширяет домены за рамки VAT family;
- не включает общий налоговый аудит;
- не включает Stage 5 investigation как core path.

### 2.2 Required anchors (runtime-enforced, as-is)

Для `prove_vat_chain_completeness` в текущем runtime обязательны:

- `period`
- `document_types`
- `vat_signal`
- `chain_signal`

Факт: эти anchors соответствуют текущему `requiredByClaim` в runtime.

### 2.3 Claim checks and live recipe (runtime-enforced, as-is)

Для VAT claim runtime требует закрытия проверок:

1. `source_document_found`
2. `invoice_found`
3. `tax_register_entry_found`
4. `book_entry_found`
5. `chain_linkage_status`

Текущий live acquisition path для VAT в runtime:

- в отличие от RBP/FA, нет выделенного VAT-specific набора обязательных live call id;
- используется `hybrid_store_plus_live` + generic live overlay probe;
- positive VAT-case может быть закрыт за счет admissible evidence и targeted checks.

### 2.4 Route behavior (as-is)

Факт по latest run:

- VAT case (`L1`) отрабатывает в `factual_with_explanation`;
- claim: `prove_vat_chain_completeness`;
- mode: `grounded_positive`;
- scope: `company_specific_accounting`;
- temporal outcome: `passed`.

### 2.5 Evidence/admissibility behavior (as-is)

Факт по VAT case (`L1`) в latest run:

- `admissible_evidence_count = 12`
- `grounding_mode = grounded_positive`
- основные reject-хвосты: `wrong_account_scope`, `weak_source_mapping`

Факт по aggregate reject breakdown (run-level):

- `weak_source_mapping` и `wrong_account_scope` остаются ключевым residual шумом.

### 2.6 Runtime acceptance snapshot (по latest pack)

- family status: `PARTIALLY_WORKING / NON-BLOCKER`
- по `L1` VAT-кейсу есть `grounded_positive`
- общий статус run: `WAVE19_2_ACCEPTED`
- важная оговорка: в run зафиксирован `normalizer_mode = useMock=true`

### 2.7 known_runtime_limits (as-is)

- `normalizer_mock_mode_in_latest_acceptance`: latest acceptance run выполнялся в режиме `useMock=true`.
- `no_explicit_vat_live_call_contract`: для VAT пока нет отдельного жесткого live-call контракта как у RBP/FA.
- `admissibility_noise_remains`: сохраняются residual rejects по `weak_source_mapping` и `wrong_account_scope`.

## 3) Target V2 (planned, не критерий текущей приемки)

### 3.1 Planned claim extension

- `prove_vat_register_book_consistency`
- `prove_document_to_tax_reflection_closure`
- `prove_missing_vat_link_risk`

### 3.2 Planned anchor extension

- `invoice_anchor`
- `register_entry_anchor`
- `book_entry_anchor`
- `vat_amount_anchor`
- `goods_or_item_linkage_anchor`

### 3.3 Planned family metrics

- `vat_grounded_positive_rate`
- `vat_admissibility_noise_rate`
- `vat_book_register_linkage_rate`
- `vat_false_grounded_answer_rate`
- `vat_live_targeting_precision_rate`

## 4) Required entities and relations (business contract)

### 4.1 Минимально необходимые сущности для proof closure

1. Документ поступления/реализации.
2. Счет-фактура.
3. Проводка/движение.
4. Запись в НДС-регистре.
5. Запись в книге покупок/продаж.
6. Связь по товарной позиции/номенклатуре/документной цепочке.
7. Контрагент/договорный контур при необходимости.

### 4.2 Критические relation links

1. `receipt_or_sale_document -> posting`
2. `document -> invoice`
3. `invoice -> vat_register_entry`
4. `vat_register_entry -> purchase_or_sales_book_entry`
5. `goods_or_item_context -> chain_completeness_verdict`

## 5) Snapshot/Live coverage verdict (as-is)

- practical mode для VAT family: `snapshot_plus_live_required`
- positive path уже подтвержден на части кейсов
- family не является текущим главным blocker
- next focus: `live narrowing + reject cleanup`, без domain expansion

## 6) Answer/proof modes contract

### `grounded_positive`

Допускается, если одновременно:

- `admissible_evidence_count > 0`
- подтверждены звенья `document -> invoice -> register -> book`
- вывод не основан только на общем domain narrative
- `false_grounded_answer_rate = 0`

Короткий пример:

- `По July 2020 цепочка документ -> проводка -> НДС-регистр -> книга подтверждена; явного выпадения по этой связке не найдено.`

### `limited_or_insufficient_evidence`

Обязателен, если:

- отсутствует одно из ключевых звеньев цепочки;
- evidence есть, но mapping слабый;
- `register/book` linkage не закрыт.

Короткий пример:

- `Документный и проводочный контур частично подтверждены, но связь до НДС-регистра или книги не восстановлена; вывод ограничен.`

### Запрещенные паттерны

- `НДС отражен корректно` без документно-регистровой связки;
- уверенный verdict при `admissible = 0`;
- подмена chain-proof общим domain narrative.

Короткий антипример:

- `НДС-цепочка в порядке` (нельзя без подтверждения register/book closure).

## 7) Gap register (VAT family)

| gap_id | category | severity | current_state | note |
| --- | --- | --- | --- | --- |
| VAT-G1 | `admissibility_residual_noise` | medium | open | остаточный шум по `weak_source_mapping` / `wrong_account_scope` |
| VAT-G2 | `live_targeting_breadth` | medium | open | live targeting для VAT еще можно сузить до более proof-specific слоя |
| VAT-G3 | `materialization_cleanup` | medium | open | positive path есть, но часть proof-path требует дочистки |
| VAT-G4 | `false_grounded_risk_control` | low | controlled | family должна удерживать `false_grounded = 0` |

## 8) Code-path inventory (где живет контракт)

- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
- VAT claim type;
- required anchors;
- required checks для VAT chain.

- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
- route/live plan behavior (в т.ч. generic live overlay для non-FA/RBP);
- VAT semantic profile and relation patterns.

- `llm_normalizer/backend/src/services/assistantService.ts`
- routing and eligibility handoff;
- answer-mode and debug export integration.

- run artifacts:
- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt`

## 9) Regression set and acceptance policy

Обязательный минимум для VAT family:

1. базовый вопрос по поступлению 13 июля и реализации 15 июля;
2. вариация на выпадение между документом, проводкой и налоговым отражением;
3. вариация на книгу покупок/продаж;
4. follow-up по той же цепочке;
5. соседний VAT sanity-check.

Политика:

- после каждого VAT family pack обязателен новый run folder;
- acceptance фиксируется на уровне family;
- `false_grounded` должен оставаться нулевым.

## 10) Project decision line for this family

VAT family уже переведена в family-based execution контур Stage 4 и рассматривается как `non-blocker`, где нужен cleanup-дожим, а не отдельный большой redesign-пакет.