NODEDC_1C/IN/Этап 4 — пакет по РБП.md

Этап 4 — пакет по РБП: покрытие источника, live-маршрут и материализация доказательной базы

1. Контекст

Этот пакет делается узко под кейс РБП, а не как новая общая волна по всей системе. Вопрос про РБП уже зафиксирован как company-specific тест на lifecycle anomaly без выхода в полный Stage 5: “31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?”

По живому прогону видно, что сейчас кейс остаётся в partial_coverage, живёт на snapshot-логике, live-путь слабый, admissible evidence до ответа не доезжает, а среди ограничений прямо фигурируют:

• snapshot 2020 read-only;
• live probe как ограниченный выборочный запрос;
• matched_rows = 0;
• live evidence исключён из grounded answer;
• admissibility gate убирает non-admissible evidence.

Stage 4 по-прежнему держим в рамках P0-only:

• без новых доменов,
• без graph/schema expansion,
• без Stage 5/6 как нового core path,
• без больших транспортных рефакторингов.

---

2. Цель пакета

Нужно не улучшить wording, а восстановить для РБП нормальный путь:

вопрос про РБП → правильные seed-объекты → правильный source coverage → правильный live route → admissible evidence → внятный proof-style ответ

Итогом пакета должно стать:

1. понимание, какие данные по РБП реально нужны;
2. понимание, где они лежат в snapshot/live;
3. рабочий live/source path до этих данных;
4. non-zero admissible evidence по РБП-кейсу;
5. ответ, который ограничивается только если данных реально нет, а не потому что контур не дошёл до нужных сущностей.

---

3. Source of truth для пакета

Базовый вопрос

31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?

Текущее живое поведение

По живому прогону для этого вопроса зафиксировано:

• business_scope = generic_accounting;
• entity_hints = ["РБП"];
• document_hints = ["Списание РБП"];
• time_scope = "июль 2020";
• режим ответа — partial_coverage;
• в uncertainties присутствуют snapshot-only, ограниченный live probe, matched_rows=0, live evidence excluded, admissibility gate removed evidence.

Это и есть исходная точка, от которой строится пакет.

---

4. Главная рабочая гипотеза

Для РБП-кейса проблема сейчас не в одном месте, а в связке:

• source coverage: runtime не поднимает нужный набор сущностей по РБП;
• route gap: live path либо не выбирается, либо не ведёт к нужным данным;
• evidence materialization: даже если часть сигнала есть, он не превращается в admissible evidence.

Эта гипотеза должна быть либо подтверждена, либо опровергнута артефактами этого пакета.

---

5. Что нужно сделать

Пакет выполнить по 4 узлам.

---

Узел A — восстановить минимальную предметную модель РБП

Задача

Понять, какие сущности и переходы вообще обязательны для ответа на вопрос о “живущем дольше ожидаемого” РБП.

Что сделать

Для кейса РБП определить:

A1. Seed entities

• документ “Списание РБП за Июль 2020 г.”;
• суммы списания, включая 5 000;
• объект РБП / карточка РБП;
• период July 2020.

A2. Required entities

Минимально установить, какие сущности нужны для доказательного ответа:

• документ списания РБП;
• объект(ы) РБП;
• движения/остатки по РБП;
• основание списания;
• expected schedule/lifecycle списания;
• хвост/остаток на конец июля;
• связанные регистры;
• проводки;
• month-close связка, если она обязательна.

A3. Expected transitions

Зафиксировать обязательные переходы:

• объект РБП → документ списания;
• документ списания → движение/регистр/проводка;
• движение/остаток → состояние на конец июля;
• expected schedule → фактическое списание;
• июльский остаток → признак “живёт дольше ожидаемого”.

Acceptance

• Для РБП должен появиться явный required_entity_map, а не общий доменный шум.
• Должно быть ясно, без каких сущностей proof в принципе невозможен.

---

Узел B — аудит покрытия источника по РБП

Задача

Понять, есть ли вообще нужные данные, и где именно они доступны.

Что сделать

Проверить отдельно:

B1. Snapshot coverage

• какие snapshot-файлы реально содержат данные по РБП;
• есть ли в них документ списания;
• есть ли объекты РБП;
• есть ли остатки/движения/проводки;
• хватает ли snapshot-only, чтобы ответить на вопрос.

B2. Live coverage

• какие MCP/live методы позволяют добраться до РБП-данных;

• есть ли прямой путь до:

  • документа списания,
  • объекта РБП,
  • остатка на конец периода,
  • движения списания,
  • schedule/основания;

• что доступно напрямую, а что только через несколько шагов.

B3. Coverage verdict

Для каждого обязательного элемента указать:

• available_in_snapshot
• available_via_live
• available_but_not_used_by_runtime
• not_reachable_in_current_runtime

Acceptance

• По каждому required entity должно быть ясно, где оно лежит и как до него дотянуться.
• Должен появиться жёсткий ответ: проблема в отсутствии данных или в том, что runtime их не использует.

---

Узел C — починить live route под РБП

Задача

Сделать так, чтобы runtime реально шёл в нужный контур РБП, а не оставался на snapshot-only/semantic profile.

Что сделать

1. Определить корректный claim_type для РБП-кейса, например:

   • prove_rbp_tail_state
   • prove_rbp_lifecycle_overstay

2. Для него прописать required live route:

   • первый вызов на документ списания;
   • второй на объект РБП;
   • третий на движения/остатки;
   • четвёртый на подтверждение конца периода / хвоста.

3. Проверить, что runtime действительно выбирает этот путь, а не остаётся в canonical-only.

4. В debug payload вывести:

   • claim_type
   • required_live_calls
   • executed_live_calls
   • missing_live_calls
   • route_gap_reason

Acceptance

• У РБП-кейса должен появиться непустой и осмысленный live call path.
• Live path должен быть привязан к claim, а не быть декоративным probe.

---

Узел D — materialization: превратить данные по РБП в admissible evidence

Задача

Убрать главный провал: данные/сигналы есть или могут быть, но до admissible evidence они не доезжают.

Что сделать

Для РБП-кейса восстановить полный путь:

raw source result -> candidate evidence -> admissible evidence -> answer

И по каждому шагу показать:

• что пришло;
• что было отрезано;
• почему было отрезано;
• что должно было стать admissible evidence, но не стало.

Обязательно классифицировать причины reject-а

Использовать причины вида:

• wrong_period
• wrong_domain
• weak_source_mapping
• zero_live_match
• missing_relation_reconstruction
• missing_required_anchor
• insufficient_object_identity

Цель

Не просто сделать admissible > 0, а понять, какие именно evidence items должны считаться допустимыми для РБП proof.

Acceptance

• У РБП-кейса должно появиться non-zero admissible evidence, либо должно быть строго доказано, почему это невозможно на текущих данных.
• Ответ “нет admissible evidence” должен быть объясним именно через materialization path.

---

Узел E — финальный proof contract по РБП

Задача

Сделать так, чтобы answer mode по РБП зависел от фактического proof-path, а не от общей слабой гипотезы.

Что сделать

Финальный ответ по РБП должен собираться так:

Если admissible evidence есть

Ответ должен уметь сказать:

• какие объекты РБП подтверждены;
• по каким из них списание подтверждено;
• по каким виден хвост/остаток на конец июля;
• почему это похоже на “живёт дольше ожидаемого”.

Если admissible evidence всё ещё нет

Ответ должен честно сказать:

• какое именно звено не удалось подтвердить;

• не просто “сигнал слабый”, а:

  • нет документа,
  • нет объекта,
  • нет движения,
  • нет остатка,
  • нет связи между ними.

Acceptance

• РБП-кейс должен перестать быть общим lifecycle-туманом.
• Answer mode должен быть привязан к реальному состоянию claim-proof.

---

6. Проверки

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

1. replay исходного РБП-вопроса;
2. debug/export после фикса;
3. live call inventory;
4. evidence conversion trace;
5. before/after по answer mode.

Желательно дополнительно:

• один соседний month-close кейс на sanity-check;
• один follow-up по тому же РБП-кейсу.

---

7. Метрики пакета

Добавить/обновить:

• 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

Минимальные пороги

• rbp_required_entity_coverage_rate >= 0.9
• rbp_live_route_execution_rate >= 0.9
• rbp_admissible_evidence_nonzero_rate > 0
• rbp_false_grounded_answer_rate = 0
• rbp_partial_coverage_default_rate должно снизиться относительно текущего live baseline

---

8. Обязательные артефакты

В новой run-папке положить:

1. README.md
2. run_summary.json
3. rbp_source_coverage_report.md
4. rbp_live_route_report.md
5. rbp_evidence_materialization_report.md
6. rbp_claim_proof_report.md
7. rbp_before_after_matrix.md
8. chat_export_rbp.md
9. debug_payloads/
10. raw_live_calls/
11. rbp_required_entity_map.json
12. rbp_admissibility_reject_breakdown.json

---

9. Что не делать

• не трогать НДС как главный фокус;
• не расползаться на общую архитектуру;
• не идти в новую большую волну по всем P0-доменам;
• не закрывать пакет по summary без replay РБП-кейса;
• не маскировать отсутствие данных красивым limited-answer.

---

10. Финальный verdict

В конце пакета выдать:

• RBP_SOURCE_COVERAGE_FIXED / NOT_FIXED
• RBP_LIVE_ROUTE_FIXED / NOT_FIXED
• RBP_EVIDENCE_MATERIALIZATION_FIXED / NOT_FIXED

И общий статус:

• RBP_PACK_ACCEPTED
• или RBP_PACK_ACCEPTED_WITH_LIMITATIONS
• или RBP_PACK_NOT_ACCEPTED

---

11. Ожидаемый результат

После этого пакета должно стать ясно:

• есть ли у вас вообще рабочий proof-path по РБП;
• можно ли из текущих данных построить доказательный ответ;
• если нельзя — это потому что данных реально нет, или потому что runtime не умеет до них дойти.

И главное: по РБП должно стать невозможно говорить абстрактно “слабая доказательная база”. Должно быть понятно, что именно не доезжает и на каком узле.

Если хочешь, следующим сообщением я дам ещё:

1. понятное русское название этой волны,
2. текст коммита на 3–4 строки.