# Этап 4 — corrective pack по family isolation, claim routing и чистой приемке

## 1. Контекст

Stage 4 уже работает в `family-based execution`:

- единица анализа: `family`;
- единица реализации: `family pack`;
- единица приемки: `family acceptance`.

По трем новым прогонам подтверждено: основная проблема в runtime не текстовая, а маршрутизационная:

- leakage между family/lane;
- неправильный `claim_type` на корректных вопросах;
- рассинхрон между route/domain/claim в разных слоях runtime;
- смешанные acceptance-файлы, где трудно объективно мерить качество lane/family.

## 2. Архитектурная рамка corrective pack

Чтобы пакет был совместим с текущим проектом, фиксируем:

1. `core families` Stage 4:  
   `VAT chain`, `RBP tail`, `FA amortization`.
2. `control lanes` (regression/sanity, не first-class family):  
   `settlements_60_62`, `month_close_indirect_costs`.
3. Пакет не добавляет новые домены и не меняет Stage 4 модель.
4. Пакет не строит новый proof engine и не уводит в Stage 5.

## 3. Цель corrective pack

Привести execution к состоянию, где:

1. вопрос из одного family/lane не уходит в чужой `claim/domain path`;
2. routing в live и follow-up не расходится между runtime-слоями;
3. acceptance выполняется по чистым family/lane файлам;
4. `false_grounded_answer_rate = 0`;
5. `wrong_family_route_rate = 0` на контрольном наборе этого pack.

## 4. Подволны

### Подволна 1 — Family isolation matrix

#### Задача

Снять матрицу соответствия вопроса и целевого family/lane, и явно показать точки leakage.

#### Что сделать

Построить матрицу по контрольным вопросам из трех файлов:

- `расчеты банк 60 62.txt`
- `ндс книга покупок и продаж.txt`
- `рбп затраты аморт.txt`

Для каждого вопроса зафиксировать:

- `raw_question`
- `expected_lane_type` (`core_family` | `control_lane`)
- `expected_family_or_lane`
- `expected_domain`
- `expected_claim_type`
- `actual_domain`
- `actual_claim_type`
- `actual_query_subject`
- `actual_source_profile`
- `actual_business_scope`
- `mismatch_type`

Минимальные lane:

1. `settlements_60_62` (control lane)
2. `VAT chain` (core family)
3. `RBP tail` (core family)
4. `FA amortization` (core family)
5. `month_close_indirect_costs` (control/sanity lane)

#### Acceptance

Есть явная матрица:

- что относится к core family, а что к control lane;
- где и почему происходит leakage.

### Подволна 2 — Claim routing + domain purity alignment

#### Задача

Устранить переходы:

- settlement -> VAT claim;
- settlement -> FA claim;
- VAT -> settlement guard path;
- month-close -> случайный FA/RBP claim без основания.

#### Что сделать

##### A. Синхронизировать domain inference между слоями

Унифицировать доменную классификацию для:

- `assistantService` domain hint;
- `investigationState` explicit domain hint;
- follow-up cross-scope checks.

Цель: один и тот же вопрос не должен получать разные домены в разных слоях runtime.

##### B. Ужесточить claim inference для settlement/VAT/FA

1. Settlement/advance/closure не должны резолвиться в:

- `prove_vat_chain_completeness`;
- `prove_fixed_asset_amortization_coverage`.

2. Убрать ложный FA-триггер на числовых артефактах:

- числа из дат/сумм не должны поднимать FA claim;
- `62.02` не должен теряться как `amount_token` в settlement flow.

3. FA claim допускается только при явном FA-сигнале:

- лексический FA-сигнал;
- или валидные account/object anchors после account extraction cleanup.

##### C. Привязать `query_subject` к resolved family/lane

`query_subject` должен строиться от resolved route/domain/claim, а не от сырого mixed-domain списка.

Практический эффект:

- VAT не должен уходить в `supplier_tail_analysis`;
- settlement не должен маскироваться под VAT/FA path.

##### D. Сохранить рабочий RBP path

Не ломать поднятый RBP контракт:

- `claim_type = prove_rbp_tail_state`;
- обязательный live recipe;
- non-zero admissible evidence path.

##### E. Для FA использовать route-lock/parity контроль

FA в этом паке контролируется через:

- `claim-route lock`;
- `mock/live parity` по целевым FA вопросам;

а не через прямую метрику domain-card purity 1:1.

#### Acceptance

На контрольном наборе pack:

- `wrong_family_route_rate = 0`;
- `wrong_claim_type_rate = 0`;
- `domain_purity_guard_lane_match_rate = 1.0` для lanes с domain-card (`settlements`, `VAT`, `month_close`);
- `fa_route_lock_correctness_rate >= 0.95`;
- `supplier_customer_polarity` не остается unresolved на core settlement cases.

### Подволна 3 — Чистая структура acceptance-прогонов

#### Задача

Убрать смешанные acceptance-файлы.

#### Что сделать

Собрать отдельные прогоны:

1. `chat_export_settlements.txt` (control lane)
2. `chat_export_vat.txt` (core family)
3. `chat_export_rbp.txt` (core family)
4. `chat_export_fa.txt` (core family)
5. `chat_export_month_close_sanity.txt` (control lane)

Правило:

- один файл = один family/lane;
- mixed files не используются как family acceptance.

#### Acceptance

Все acceptance-артефакты lane-clean и сопоставимы между волнами.

### Подволна 4 — Final live rerun по изолированным lanes

#### Задача

Пересобрать финальный live rerun после исправления isolation/routing.

#### Обязательный набор кейсов

`settlements_60_62` (control lane):

1. supplier settlement (`55 200`)
2. buyer advance (`62.02`)
3. closure case без суммы
4. follow-up по тому же договору/документу

`VAT chain`:

1. услуги связи (`1 166,67 + НДС 233,33`)
2. счет-фактура / книга покупок
3. выпадение между документом и книгой
4. follow-up по той же VAT-цепочке

`RBP tail`:

1. `Списание РБП за Июль 2020` (`5 000`)
2. вариант без суммы
3. полнота закрытия
4. follow-up по объекту/документу

`FA amortization`:

1. `2 471,52 / 2 465,28 / 849,83`
2. expected vs actual set
3. missing object risk
4. follow-up по объекту ОС

`month_close_indirect_costs` (control lane):

1. базовый вопрос по косвенным расходам
2. зависший хвост
3. limitation-honesty после полного month-end

#### Acceptance

Новый live rerun показывает:

- route/claim isolation без cross-family leakage;
- корректную lane-классификацию;
- честный limited mode только по фактической нехватке данных.

## 5. Метрики corrective pack

### Добавить/вывести

- `wrong_family_route_rate`
- `wrong_claim_type_rate`
- `domain_purity_guard_lane_match_rate`
- `fa_route_lock_correctness_rate`
- `family_isolation_correctness_rate`
- `live_recipe_binding_rate`
- `false_grounded_answer_rate`
- `mechanism_discrimination_rate`
- `limited_answer_honesty_rate`

### Минимальные пороги (для контрольного набора этого pack)

- `wrong_family_route_rate = 0`
- `wrong_claim_type_rate = 0`
- `domain_purity_guard_lane_match_rate = 1.0` (для lanes с domain-card)
- `fa_route_lock_correctness_rate >= 0.95`
- `false_grounded_answer_rate = 0`
- `mechanism_discrimination_rate >= 0.90`
- `limited_answer_honesty_rate >= 0.95`

## 6. Что создать

### В `docs/ARCH`

1. `10 - family_isolation_and_claim_routing_corrective_pack_2026-03-29.md`
2. `10A - family_isolation_matrix.md`
3. `10B - wrong_claim_route_register.md`
4. `10C - clean_family_run_structure.md`
5. `10D - family_acceptance_policy_update.md`
6. `10E - cross_layer_domain_inference_parity.md`

### В `llm_normalizer/docs/runs/<new_run_pack>`

1. `run_summary.json`
2. `before_after_metrics.json`
3. `family_case_matrix.md`
4. `acceptance_note.md`
5. `chat_export_settlements.txt`
6. `chat_export_vat.txt`
7. `chat_export_rbp.txt`
8. `chat_export_fa.txt`
9. `chat_export_month_close_sanity.txt`
10. `debug_payloads/`
11. `routing_parity_diff.md`

## 7. Что нельзя делать

- не добавлять новые домены;
- не менять Stage 4 family-based model;
- не строить новый proof engine;
- не смешивать acceptance разных family/lane в одном файле;
- не закрывать acceptance по одному удачному ответу;
- не лечить leakage общим ростом generic retrieval.

## 8. Финальный verdict

Выдать:

- `FAMILY_ISOLATION_FIXED / NOT_FIXED`
- `CLAIM_ROUTING_FIXED / NOT_FIXED`
- `CLEAN_FAMILY_ACCEPTANCE_READY / NOT_READY`

Общий статус:

- `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED`
- или `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED_WITH_LIMITATIONS`
- или `STAGE4_FAMILY_ISOLATION_PACK_NOT_ACCEPTED`

## 9. Ожидаемый итог

После этого пакета:

- settlement-вопросы не уходят в VAT/FA claim;
- VAT-вопросы не ведутся через settlement-path;
- mixed-file приемка не используется;
- прогресс измеряется по чистым family/lane с сопоставимыми метриками и артефактами.