SILVER
/
NODEDC_1C
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_1C/IN/Stage 4 - Family Card v1 — ...

10 KiB
Raw Blame History

Stage 4 - Family Card v1 — VAT chain (runtime-aligned)

document_status: ACTIVE
family_name: НДС-цепочка — полнота прохождения от документа до налогового отражения
family_id: VAT_CHAIN_COMPLETENESS_V1
stage_scope: Stage 4 (P0-only)
current_family_status: PARTIALLY_WORKING / NON-BLOCKER
primary_gap: residual admissibility/materialization quality
latest_pack: 2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt
next_pack_focus: targeted live narrowing + reject cleanup for VAT proof-path
family_source_of_truth_questions: VAT-Q1 (13 июля поступление, 15 июля реализация — полная ли НДС-цепочка); VAT-Q2 (есть ли выпадение между документом, проводкой, НДС-регистром и книгой); VAT-Q3 (по July 2020 VAT path grounded-positive или остаются weak-mapping шумы)
family_latest_live_replay: X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\1_live_replay.txt
family_latest_acceptance_run: X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json

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

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

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

Это соответствует Stage 4 family-based execution в рамках P0-only без перехода в Stage 5 и без архитектурного redesign.

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

2.1 Claim contract (as-is)

  • primary claim_type: prove_vat_chain_completeness
  • additional claim_types: пока не выделялись как first-class в runtime
  • границы claim:
  • не расширяет домены за рамки VAT family;
  • не включает общий налоговый аудит;
  • не включает Stage 5 investigation как core path.

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

Для prove_vat_chain_completeness в текущем runtime обязательны:

  • period
  • document_types
  • vat_signal
  • chain_signal

Факт: эти anchors соответствуют текущему requiredByClaim в runtime.

2.3 Claim checks and live recipe (runtime-enforced, as-is)

Для VAT claim runtime требует закрытия проверок:

  1. source_document_found
  2. invoice_found
  3. tax_register_entry_found
  4. book_entry_found
  5. chain_linkage_status

Текущий live acquisition path для VAT в runtime:

  • в отличие от RBP/FA, нет выделенного VAT-specific набора обязательных live call id;
  • используется hybrid_store_plus_live + generic live overlay probe;
  • positive VAT-case может быть закрыт за счет admissible evidence и targeted checks.

2.4 Route behavior (as-is)

Факт по latest run:

  • VAT case (L1) отрабатывает в factual_with_explanation;
  • claim: prove_vat_chain_completeness;
  • mode: grounded_positive;
  • scope: company_specific_accounting;
  • temporal outcome: passed.

2.5 Evidence/admissibility behavior (as-is)

Факт по VAT case (L1) в latest run:

  • admissible_evidence_count = 12
  • grounding_mode = grounded_positive
  • основные reject-хвосты: wrong_account_scope, weak_source_mapping

Факт по aggregate reject breakdown (run-level):

  • weak_source_mapping и wrong_account_scope остаются ключевым residual шумом.

2.6 Runtime acceptance snapshot (по latest pack)

  • family status: PARTIALLY_WORKING / NON-BLOCKER
  • по L1 VAT-кейсу есть grounded_positive
  • общий статус run: WAVE19_2_ACCEPTED
  • важная оговорка: в run зафиксирован normalizer_mode = useMock=true

2.7 known_runtime_limits (as-is)

  • normalizer_mock_mode_in_latest_acceptance: latest acceptance run выполнялся в режиме useMock=true.
  • no_explicit_vat_live_call_contract: для VAT пока нет отдельного жесткого live-call контракта как у RBP/FA.
  • admissibility_noise_remains: сохраняются residual rejects по weak_source_mapping и wrong_account_scope.

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

3.1 Planned claim extension

  • prove_vat_register_book_consistency
  • prove_document_to_tax_reflection_closure
  • prove_missing_vat_link_risk

3.2 Planned anchor extension

  • invoice_anchor
  • register_entry_anchor
  • book_entry_anchor
  • vat_amount_anchor
  • goods_or_item_linkage_anchor

3.3 Planned family metrics

  • vat_grounded_positive_rate
  • vat_admissibility_noise_rate
  • vat_book_register_linkage_rate
  • vat_false_grounded_answer_rate
  • vat_live_targeting_precision_rate

4) Required entities and relations (business contract)

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

  1. Документ поступления/реализации.
  2. Счет-фактура.
  3. Проводка/движение.
  4. Запись в НДС-регистре.
  5. Запись в книге покупок/продаж.
  6. Связь по товарной позиции/номенклатуре/документной цепочке.
  7. Контрагент/договорный контур при необходимости.

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

  1. receipt_or_sale_document -> posting
  2. document -> invoice
  3. invoice -> vat_register_entry
  4. vat_register_entry -> purchase_or_sales_book_entry
  5. goods_or_item_context -> chain_completeness_verdict

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

  • practical mode для VAT family: snapshot_plus_live_required
  • positive path уже подтвержден на части кейсов
  • family не является текущим главным blocker
  • next focus: live narrowing + reject cleanup, без domain expansion

6) Answer/proof modes contract

grounded_positive

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

  • admissible_evidence_count > 0
  • подтверждены звенья document -> invoice -> register -> book
  • вывод не основан только на общем domain narrative
  • false_grounded_answer_rate = 0

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

  • По July 2020 цепочка документ -> проводка -> НДС-регистр -> книга подтверждена; явного выпадения по этой связке не найдено.

limited_or_insufficient_evidence

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

  • отсутствует одно из ключевых звеньев цепочки;
  • evidence есть, но mapping слабый;
  • register/book linkage не закрыт.

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

  • Документный и проводочный контур частично подтверждены, но связь до НДС-регистра или книги не восстановлена; вывод ограничен.

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

  • НДС отражен корректно без документно-регистровой связки;
  • уверенный verdict при admissible = 0;
  • подмена chain-proof общим domain narrative.

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

  • НДС-цепочка в порядке (нельзя без подтверждения register/book closure).

7) Gap register (VAT family)

gap_id category severity current_state note
VAT-G1 admissibility_residual_noise medium open остаточный шум по weak_source_mapping / wrong_account_scope
VAT-G2 live_targeting_breadth medium open live targeting для VAT еще можно сузить до более proof-specific слоя
VAT-G3 materialization_cleanup medium open positive path есть, но часть proof-path требует дочистки
VAT-G4 false_grounded_risk_control low controlled family должна удерживать false_grounded = 0

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

  • llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts

  • VAT claim type;

  • required anchors;

  • required checks для VAT chain.

  • llm_normalizer/backend/src/services/assistantDataLayer.ts

  • route/live plan behavior (в т.ч. generic live overlay для non-FA/RBP);

  • VAT semantic profile and relation patterns.

  • llm_normalizer/backend/src/services/assistantService.ts

  • routing and eligibility handoff;

  • answer-mode and debug export integration.

  • run artifacts:

  • X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt

9) Regression set and acceptance policy

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

  1. базовый вопрос по поступлению 13 июля и реализации 15 июля;
  2. вариация на выпадение между документом, проводкой и налоговым отражением;
  3. вариация на книгу покупок/продаж;
  4. follow-up по той же цепочке;
  5. соседний VAT sanity-check.

Политика:

  • после каждого VAT family pack обязателен новый run folder;
  • acceptance фиксируется на уровне family;
  • false_grounded должен оставаться нулевым.

10) Project decision line for this family

VAT family уже переведена в family-based execution контур Stage 4 и рассматривается как non-blocker, где нужен cleanup-дожим, а не отдельный большой redesign-пакет.