# Stage 4 - Family Card v1 — FA amortization coverage (runtime-aligned)

**document_status:** `ACTIVE`  
**family_name:** `Амортизация ОС — полнота охвата / риск пропуска объекта`  
**family_id:** `FA_AMORTIZATION_COVERAGE_V1`  
**stage_scope:** `Stage 4 (P0-only)`  
**current_family_status:** `PROOF_PATH_RAISED_LIVE_ACCEPTANCE_PENDING`  
**primary_gap:** `live object-level relation clarity + production live acceptance`  
**latest_pack:** `2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure`  
**next_pack_focus:** `live replay acceptance + relation/anchor consistency in production channel`  
**family_source_of_truth_questions:** `FA-Q1 (31 июля: 2 471,52 / 2 465,28 / 849,83 — полное ли начисление); FA-Q2 (expected vs actual set по объектам ОС за июль); FA-Q3 (есть ли missing object candidates в июльском начислении)`  
**family_latest_live_replay:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt\fa_live_raw.json (текущий live attempt: http_status=400, невалидная приемка)`  
**family_latest_acceptance_run:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json`

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

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

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

Это защищает от ложного закрытия family по mock-результату без live-приемки.

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

### 2.1 Claim contract (as-is)

- **primary claim_type:** `prove_fixed_asset_amortization_coverage`
- **additional claim_types:** пока не выделялись как отдельные first-class claim types
- **границы claim:**
- не расширяет домены за рамки Stage 4 P0;
- не вводит новый proof engine;
- не использует Stage 5 investigation как core path.

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

Для `prove_fixed_asset_amortization_coverage` в рантайме обязательны:

- `period`
- `fixed_asset_signal`
- `amortization_signal`
- `amount_or_document`
- `account_scope_or_document_type`

Факт по latest acceptance run:

- `required_anchors_count = 5`
- `missing_anchor_classes_count = 0`
- `claim_anchor_coverage_ratio = 1`

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

Обязательные live вызовы:

1. `find_amortization_documents_in_period`
2. `find_fixed_asset_movements_accounts_01_02`
3. `find_fixed_asset_cards_expected_for_period`
4. `match_expected_vs_actual_fa_coverage`

Ожидаемый результат recipe:

- документ(ы) начисления амортизации;
- candidate/actual набор объектов ОС;
- expected set для периода;
- сравнение expected vs actual и кандидаты пропуска.

### 2.4 Route behavior (as-is)

Для FA-claim runtime:

- форсирует claim-bound live-capable route;
- может переопределять `store_feature_risk` в live/hybrid path;
- экспортирует `fa_live_route_audit` в debug payload.

Факт по latest acceptance run:

- `live_route_execution_rate = 1`
- `required_live_calls = 4`
- `missing_live_calls = 0`
- `route_adjustments_applied = 1`

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

Факт по latest acceptance run:

- `admissible_evidence_count = 16`
- `rejected_evidence_count = 32`
- reject breakdown: `wrong_account_scope = 16`, `weak_source_mapping = 16`

Факт по targeted evidence:

- `targeted_evidence_hit_rate = 1`
- `expected_fa_set_count = 2`
- `actual_fa_set_count = 2`
- `missing_fa_candidates_count = 0`
- `uncertain_fa_candidates_count = 28`

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

- `FA_EXPECTED_SET_FIXED = FIXED`
- `FA_RELATION_MAPPING_FIXED = FIXED`
- `FA_CLAIM_ANCHOR_CLOSURE_FIXED = FIXED`
- `FA_PROOF_CLOSURE_FIXED = FIXED`
- общий статус: `FA_PACK_ACCEPTED`
- важная оговорка: режим пакета `mock` (controlled replay)

### 2.7 known_runtime_limits (as-is)

- `live acceptance pending`: актуальный live attempt завершился `http_status=400`, не может быть источником приемки.
- `relation clarity incomplete`: несмотря на coverage=1 в mock, в relation map много `coverage_status=uncertain` и слабых object-level link.
- `admissibility noise remains`: значимый reject-шум (`wrong_account_scope`, `weak_source_mapping`) сохраняется и требует дожима для production live.

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

### 3.1 Planned claim extension

- Развести подтипы FA-claim по режимам:
- `prove_fixed_asset_amortization_completeness`
- `prove_fixed_asset_missing_object_risk`
- `prove_fixed_asset_expected_actual_consistency`

### 3.2 Planned anchor extension

- Явный `expected_fa_set` как first-class anchor.
- Явный `actual_fa_set_from_amortization` как first-class anchor.
- Явный `missing_fa_candidates` с object identity и link quality.

### 3.3 Planned family metrics

- `fa_expected_set_reconstruction_rate`
- `fa_relation_mapping_coverage_rate`
- `fa_claim_anchor_coverage_rate`
- `fa_actual_vs_expected_comparison_rate`
- `fa_proof_closure_rate`
- `fa_false_grounded_answer_rate`
- `fa_live_acceptance_pass_rate`

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

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

1. Документ(ы) начисления амортизации за июль.
2. Объекты ОС, которые должны участвовать в начислении.
3. Движения/проводки по контуру амортизации (в т.ч. счета 01/02).
4. Expected set объектов ОС на период.
5. Actual set объектов, реально попавших в начисление.
6. Missing/uncertain candidates для object-level verdict.

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

1. `fa_object -> amortization_document`
2. `amortization_document -> movement/posting`
3. `fa_object -> expected_period_coverage`
4. `expected_set -> actual_set`
5. `missing_or_uncertain_object -> coverage_risk_verdict`

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

- По FA family практический режим: `snapshot_plus_live_required`.
- В controlled replay proof-path поднят до `grounded_positive`.
- Production live приемка пока не закрыта.

## 6) Answer/proof modes contract

### `grounded_positive`

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

- `admissible_evidence_count > 0`
- реконструированы `expected_fa_set` и `actual_fa_set`
- сделано сравнение expected vs actual
- вывод имеет object-level опору, не только сумму
- `false_grounded_answer_rate = 0`

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

- `За июль подтверждены ожидаемый и фактический наборы ОС; пропусков по зафиксированным объектам не выявлено, риск неполноты начисления низкий.`

### `limited_or_insufficient_evidence`

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

- не реконструирован expected set или actual set
- object-level links недостаточны
- есть только косвенная/шумная опора

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

- `Суммы начисления зафиксированы, но object-level соответствие expected vs actual не восстановлено; вывод ограничен и не подтверждает полноту начисления.`

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

- вывод о полноте начисления только по суммам без object-level связи
- уверенный verdict при `admissible = 0`
- общий lifecycle-текст без указания missing object/link

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

- `Амортизация начислена корректно, пропусков нет` (нельзя без expected/actual object-level proof).

## 7) Gap register (FA family)

| gap_id | category | severity | current_state | note |
| --- | --- | --- | --- | --- |
| FA-G1 | `live_acceptance_not_confirmed` | blocker | open | текущий live attempt дал `http_status=400`, приемка фактически mock-only |
| FA-G2 | `wrong_entity_mapping` / `relation_clarity` | high | open | в relation map много `coverage_status=uncertain` и слабых direct links |
| FA-G3 | `admissibility_reject_not_due_to_data` | medium | open | reject-шум по `wrong_account_scope` и `weak_source_mapping` |
| FA-G4 | `answer_layer_underuses_available_evidence` | medium | partial | в части трасс answer-mode может звучать ограничительно при сильной eligibility |

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

- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
- FA claim resolution;
- required anchors;
- targeted checks;
- expected/actual/missing/uncertain FA coverage structures.

- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
- claim-bound FA live plan;
- live call profile `claim_bound_fa_live_path`;
- relation markers (`asset_card_to_depreciation`, `document_to_posting`).

- `llm_normalizer/backend/src/services/assistantService.ts`
- FA live route enforcement;
- route override audit (`fa_live_route_audit`);
- handoff в eligibility/answer layer.

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

## 9) Regression set and acceptance policy

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

1. Базовый вопрос по трем суммам `2 471,52 / 2 465,28 / 849,83`.
2. Вариация без сумм, но с запросом полноты expected vs actual.
3. Вариация на missing-object risk.
4. Follow-up по конкретному объекту ОС (если объект выделен).

Политика:

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

## 10) Project decision line for this family

FA family поднята до proof-ready уровня в controlled replay, но остается в статусе `live acceptance pending` до подтверждения object-level closure на реальном live канале.