# Stage 4 - Family Card v1 — RBP tail / write-off overstay (runtime-aligned)

**document_status:** `ACTIVE`  
**family_name:** `РБП — хвост / списание / overstay`  
**family_id:** `RBP_TAIL_WRITEOFF_OVERSTAY_V1`  
**stage_scope:** `Stage 4 (P0-only)`  
**current_family_status:** `ACCEPTED_WITH_LIMITATIONS`  
**primary_gap:** `source coverage`  
**latest_pack:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix`  
**next_pack_focus:** `source coverage recovery + route tightening for full claim closure`  
**family_source_of_truth_questions:** `RBP-Q1 (Списание РБП за Июль 2020, включая 5 000); RBP-Q2 (хвост РБП к концу июля без суммы); RBP-Q3 (полнота закрытия июльского списания)`  
**family_latest_live_replay:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/1.txt (локальный replay; внешний live-канал требует отдельной приемки)`  
**family_latest_acceptance_run:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/run_summary.json`

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

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

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

Это нужно, чтобы не смешивать факт и план и не закрывать family “по красивому тексту”.

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

### 2.1 Claim contract (as-is)

- **primary claim_type:** `prove_rbp_tail_state`
- **additional claim_types:** пока не first-class в runtime (учитываются как план V2)
- **границы claim:**
- не включает Stage 5 investigation как core path;
- не расширяет домены за пределы Stage 4 P0;
- не делает full redesign proof engine.

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

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

- `period`
- `rbp_signal`
- `writeoff_signal`

Технические reason codes на этом шаге:

- `claim_missing_required_anchors`
- `claim_anchor_resolution_low`

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

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

1. `find_rbp_writeoff_documents_in_period`
2. `find_rbp_object_movements_account_97`
3. `find_month_close_entries_linked_to_rbp`
4. `compute_end_period_residual_by_rbp_object`

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

- подтверждение документа списания;
- привязка к объекту(ам) РБП;
- движение/связанные записи;
- residual state на границе периода.

### 2.4 Route behavior (as-is)

Для `prove_rbp_tail_state` runtime:

- форсирует live-capable маршрут (`hybrid_store_plus_live` / `live_mcp_drilldown`);
- поднимает `insufficient_specificity` в live path вместо `no_route`;
- экспортирует `rbp_live_route_audit` в debug payload.

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

Подтверждено в текущем пакете:

- убрана инъекция raw live rows при `matched_rows = 0`;
- добавлена стабилизированная live metadata для source mapping;
- claim-bound targeted checks для RBP расширены до object/document/movement/residual.

Наблюдаемые baseline reject reasons (до фикса пакета):

- `zero_live_match`
- `weak_source_mapping`
- `wrong_account_scope`

### 2.6 Runtime acceptance snapshot (по артефактам latest pack)

- `RBP_SOURCE_COVERAGE_FIXED = NOT_FIXED`
- `RBP_LIVE_ROUTE_FIXED = FIXED`
- `RBP_EVIDENCE_MATERIALIZATION_FIXED = FIXED`
- общий статус: `RBP_PACK_ACCEPTED_WITH_LIMITATIONS`

### 2.7 known_runtime_limits (as-is)

- `source coverage incomplete`: для части object-level proof звеньев данные в runtime source set еще неполные.
- `business scope inconsistency possible`: в части live traces возможна несогласованность `generic_accounting` vs `company_specific_accounting`.
- `anchor noise in edge cases`: в отдельных кейсах могут появляться нерелевантные account hints, влияющие на route profile.

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

### 3.1 Planned claim extension

Дополнительные claim types (план):

- `prove_rbp_writeoff_completeness`
- `prove_rbp_lifecycle_overstay`
- `prove_rbp_period_end_residual_state`

### 3.2 Planned anchor extension

Расширенный target-набор anchors (план):

- период (primary + period-end)
- суммы/диапазоны
- объект РБП
- документ/тип документа
- движения/остаток на конец периода
- lifecycle markers для overstay

### 3.3 Planned family metrics

Плановые family-метрики (в stable harness):

- `rbp_required_entity_coverage_rate`
- `rbp_live_route_execution_rate`
- `rbp_admissible_evidence_nonzero_rate`
- `rbp_source_to_proof_completion_rate`
- `rbp_partial_coverage_default_rate`
- `rbp_false_grounded_answer_rate`

До формализации в harness эти метрики считаются target-моделью, а не текущим hard gate.

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

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

1. Документ `Списание РБП` за целевой период.
2. Объект(ы) РБП.
3. Движения/регистровые записи по списанию.
4. Residual state на конец периода.
5. Связь со стадией month-close при необходимости.

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

1. `RBP object -> writeoff document`
2. `writeoff document -> movement/register record`
3. `movement/register record -> period-end residual`
4. `expected lifecycle -> actual lifecycle result`
5. `residual state -> overstay/no-overstay verdict`

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

- `snapshot-only` для RBP сейчас **недостаточен** для устойчивого object-level proof closure.
- Family требует `snapshot_plus_live_required`.
- Главный незакрытый узел — source coverage в production live данных.

## 6) Answer/proof modes contract

### `grounded_positive`

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

- `admissible_evidence_count > 0`
- закрыта цепочка object/document/movement/residual
- вывод опирается на конкретные source refs
- `false_grounded_answer_rate = 0`

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

- `Подтвержден документ "Списание РБП" за июль 2020, найден связанный объект РБП и остаток на конец периода = 0; признаков overstay по этому объекту не выявлено.`

### `limited_or_insufficient_evidence`

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

- не найден ключевой link (document/object/residual)
- admissible evidence недостаточно
- нет права имитировать доказанность

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

- `Документ списания найден, но связь с объектом РБП и подтвержденный остаток на конец периода не восстановлены; вывод ограничен до partial coverage без утверждения об overstay.`

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

- общий lifecycle narrative без указания missing link
- уверенный вывод при `admissible = 0`
- смешивание snapshot-гипотез с live-доказанностью без маркировки

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

- `Есть признаки проблемы по РБП, вероятно хвост остался` (нельзя без document/object/residual подтверждения).

## 7) Gap register (RBP family)

| gap_id | category | severity | current_state | note |
| --- | --- | --- | --- | --- |
| RBP-G1 | `missing_source_data` / `source_coverage` | blocker | open | ключевая причина `ACCEPTED_WITH_LIMITATIONS` |
| RBP-G2 | `business_scope_resolution_consistency` | high | open | в отдельных live traces встречается несогласованность generic/company-specific слоев |
| RBP-G3 | `anchor_quality` | medium | open | в отдельных кейсах попадают нерелевантные account hints, что ухудшает route profile |

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

- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
- claim type resolution;
- required anchors для `prove_rbp_tail_state`;
- anchor resolution rate и claim reason codes.

- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
- claim-bound live plan для RBP;
- обязательные live call ids и account scope overrides;
- source profile `claim_bound_rbp_live_path`.

- `llm_normalizer/backend/src/services/assistantService.ts`
- RBP live route enforcement;
- no-route recovery;
- `rbp_live_route_audit` export.

- run artifacts:
- `llm_normalizer/docs/runs/2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix`

## 9) Regression set and acceptance policy

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

1. Базовый RBP вопрос: `Списание РБП за Июль 2020`, включая сумму `5 000`.
2. Вариация без суммы (проверка period + overstay signal).
3. Вариация на полноту закрытия.
4. Follow-up по тому же документу/объекту.
5. Соседний month-close sanity case.

Политика:

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

## 10) Project decision line for this family

RBP уже перешел в family-based execution контур Stage 4, но остается в статусе `accepted_with_limitations` до восстановления source coverage в живом канале.