NODEDC_1C/IN/Этап 4 — corrective pack по family isolation.md

Этап 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 с сопоставимыми метриками и артефактами.