SILVER
/
NODEDC_1C
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_1C/docs/accounting-assistant/accounting-assistant/4 ЭТАП - ПРОВЕМУТОЧНЫЕ ЭТАП...

16 KiB
Raw Blame History

Да. Тут лучше не распиливать на десять мелких задач. Оптимальный формат — одна ТЗ на corrective pack Stage 4, но внутри неё сделать 4 короткие подволны с отдельным acceptance на каждую. Это не ломает вашу текущую рамку, потому что Stage 4 у вас уже жёстко зафиксирован как P0-only по трём доменам, без новых доменов, без graph/schema expansion, без Stage 5/6 как core path и без больших транспортных рефакторингов. При этом сам отчёт уже показывает, что после зелёного Chat20 у вас live-path всё ещё дочищался отдельными micro-fix проходами, а в follow-up прямо требуется финальный live-rerun и consolidated acceptance note.

Ниже даю ТЗ в форме, которую можно почти как есть отправлять в Codex.

ТЗ для Codex: Stage 4 Corrective Pack — Grounding / Polarity / Evidence / Mechanism

1. Контекст

Текущий Stage 4 формально удерживается в P0-only контуре по трём доменам:

  • settlements_60_62
  • vat_document_register_book
  • month_close_costs_20_44

В рамках corrective work запрещено:

  • добавлять новые домены;
  • расширять graph/schema;
  • тащить внутрь core-path Stage 5 investigation;
  • строить новый live verification layer как архитектурный слой;
  • делать большие refactor transport/routing.

2. Цель corrective pack

Нужно не расширять архитектуру, а добить качество Stage 4 на live-path для company-specific вопросов по июльскому снапшоту 2020 так, чтобы ассистент:

  • держал правильный temporal anchor;
  • не путал supplier/customer polarity;
  • не тащил нерелевантные live/snapshot evidence в ответ;
  • отвечал mechanism-first, а не checklist-ом из нескольких гипотез;
  • проходил контрольные P0-вопросы не только на Chat20, но и на живом trace/debug прогоне.

3. Зафиксированные дефекты, которые надо исправить

На текущем прогоне по supplier settlement вопросу зафиксированы такие сбои:

  1. Temporal anchor error Вопрос про оплату 6 июля в июльском снапшоте 2020 был нормализован в time_scope = 2023-07-06.

  2. Business scope / company grounding слабый business_scope остался generic_accounting, хотя вопрос company-specific и привязан к конкретному снапшоту.

  3. Domain polarity drift Кейс по поставщику / счёту 60 уходит в смесь supplier/customer логики, а problem units оказываются в customer_settlement и stale_receivable, что бухгалтерски неверно для supplier payable closure. При этом semantic profile одновременно содержит и suppliers, и customers, а graph traversal допускает bank_settlement и customer_settlement вместе.

  4. Evidence contamination / inadmissible evidence live_mcp.matched_rows = 0, но в evidence всё равно попадают live-элементы; среди них есть записи с проводками 68.02 / 19.04, то есть VAT-контур, плюс даты 2025/2026/2030, что недопустимо для ответа по июльскому снапшоту 2020. Для части evidence уже помечено weak_source_mapping, но они всё равно используются как опора.

  5. Mechanism-first answer contract не дожат Вопросы в контрольном наборе специально проверяют, способен ли ассистент различать механизм разрыва: не тот договор, не тот объект расчётов, неполный closure, неполный VAT-edge, stale RBP и т.д. Сейчас ответ часто скатывается в общий partial-coverage checklist вместо выбора наиболее вероятного механизма и объяснения, почему именно он.

4. Объём работ

Сделать одну corrective wave, но внутри неё 4 подволны.

Подволна A — Temporal Anchor Hardening

Задача

Запретить неверную интерпретацию даты/периода для company snapshot вопросов.

Что сделать

  1. В normalizer/router добавить company_snapshot_temporal_lock.

  2. Если вопрос явно относится к июльскому снапшоту 2020:

    • не допускать авто-подстановку текущего/дефолтного года;
    • не допускать relative reinterpretation;
    • переводить время в fixed window 2020-07-01 .. 2020-07-31, если вопрос не требует более узкого дня;
    • если в вопросе явно указан день июля, привязывать к 2020-07-DD.

  3. Добавить hard-fail guard:

    • если extracted time_scope выходит за рамки company snapshot, answer не должен собираться как grounded.

  4. В debug/export явно показывать:

    • raw time anchor;
    • resolved time anchor;
    • source of resolution (explicit_from_question, snapshot_context_lock, etc.).

Acceptance

  • Ни один вопрос из июльского контрольного набора не должен уходить в 2023/2025/2026/2030.
  • В debug payload temporal resolution должна быть прозрачной и объяснимой.
  • Если temporal anchor неразрешим, ответ обязан честно это признать, а не строить псевдо-grounded answer.

Подволна B — Domain Polarity Lock

Задача

Убрать путаницу между supplier/customer, payable/receivable, 60/62 и month-close/VAT соседними контурами.

Что сделать

  1. Ввести domain_polarity_guard до retrieval ranking и до problem-unit assembly.

  2. Минимальные правила:

    • supplier + account 60 + obligation not closed => только supplier/payable semantics.
    • buyer/customer + 62 + аванс/дебиторка => только customer/receivable semantics.
    • VAT domain не может подмешиваться в settlement answer без явного VAT-вопроса.
    • month-close domain не может подменять settlement domain по общим lifecycle сигналам.

  3. Запретить mixed semantic_profile вида:

    • suppliers + customers одновременно для одного single-focus question, если вопрос не cross-entity by design.

  4. Для problem units ввести polarity-aware mapping:

    • supplier cases: unresolved_supplier_settlement_cluster, supplier_document_conflict, supplier_partial_closure
    • customer cases: unresolved_customer_settlement_cluster, customer_advance_offset_conflict Названия можно оставить внутренними, но логика должна быть раздельной.

  5. Если polarity не определена достаточно уверенно, ответ должен переходить в ограниченный режим с явным указанием, что именно не удалось различить.

Acceptance

  • Вопросы про счёт 60 и поставщика не должны производить customer_settlement, stale_receivable, receivable_closed.
  • Вопросы про 62/авансы покупателя не должны превращаться в supplier payable cases.
  • Domain drift между settlement / VAT / month-close должен быть снят не только по Chat20, но и по debug/live traces.

Подволна C — Evidence Admissibility Gate

Задача

Запретить попадание в grounding нерелевантного evidence даже если retrieval что-то “нашёл”.

Что сделать

  1. Ввести evidence_admissibility_gate перед answer composer.

  2. Evidence допускается в grounded answer только если одновременно выполнено:

    • дата попадает в допустимое временное окно вопроса;
    • домен совпадает с активным domain card;
    • account scope совместим с вопросом;
    • source mapping не weak/ambiguous, либо такой evidence помечается только как limitation, но не как доказательство;
    • если live probe дал matched_rows = 0, live evidence не усиливает answer.

  3. Запретить cross-domain contamination:

    • VAT postings не попадают в settlement evidence;
    • settlement traces не попадают в VAT proof без явной cross-branch задачи;
    • month-close traces не усиливают settlement answer.

  4. Развести уровни evidence:

    • hard_evidence
    • supporting_signal
    • inadmissible_noise

  5. В debug payload показывать:

    • сколько evidence прошло gate;
    • сколько отрезано и почему (wrong_period, wrong_domain, wrong_account_scope, weak_source_mapping, zero_live_match).

Acceptance

  • При matched_rows = 0 live probe не должен добавлять ложную уверенность.
  • VAT проводки и future-dated live rows не должны попадать в settlement-grounded answer.
  • grounded answer без admissible evidence должен автоматически деградировать в честный limited answer.

Подволна D — Mechanism-Specific Answer Contract

Задача

Заставить ассистента не просто перечислять проверки, а различать механизм разрыва и объяснять его.

Что сделать

  1. Для P0-доменов ввести mechanism_discriminator перед финальным answer composer.

  2. Для settlements_60_62 минимум различать:

    • wrong_contract_binding
    • wrong_settlement_object
    • closure_document_not_confirmed
    • partial_settlement_tail
    • chronology_break

  3. Для VAT минимум различать:

    • missing_invoice_link
    • missing_tax_entry
    • missing_purchase_book_entry
    • partial_vat_chain

  4. Для month_close минимум различать:

    • close_completed_but_tail_remains
    • stale_rbp
    • invalid_close_transition
    • normal_residual_not_a_bug

  5. Финальный answer contract сделать таким:

    • Основной вывод: один наиболее вероятный механизм.
    • Почему именно он: 2–4 коротких grounding facts.
    • Что не доказано: отдельный limitation block.
    • Что проверить первым: 1–2 next checks, а не длинный checklist.

  6. Если discriminator не может выбрать один механизм честно:

    • разрешено показать top-2 mechanism candidates,
    • но с ранжированием и явным объяснением, почему первый выше второго.

Acceptance

  • Ответ на symptom-first вопросы должен содержать не набор равноправных гипотез, а основной mechanism candidate.
  • False confidence по VAT и month-close не допускается.
  • Ranking/truthful limitation из контрольного набора должны быть сохранены.

5. Eval / Regression

Обязательный контрольный набор

Минимум прогонять:

  1. supplier settlement case по оплате 55 200 / незакрытый хвост;
  2. buyer advance offset case 276 873,60 / 62.02;
  3. VAT case по услугам связи + счёт-фактура 233,33;
  4. month-close case по закрытию косвенных расходов;
  5. RBP case;
  6. limitation honesty case после полного month-end.

Предпочтительно прогонять все 8 core-вопросов из вашего ядра.

Новые метрики

Добавить в harness:

  • temporal_anchor_correctness_rate
  • domain_polarity_correctness_rate
  • evidence_admissibility_rate
  • mechanism_discrimination_rate
  • limited_answer_honesty_rate

Минимальный проходной порог

Для corrective acceptance:

  • 100% по temporal_anchor на контрольном наборе;
  • 100% по domain polarity на core P0 вопросах;
  • 0 inadmissible evidence в grounded answers;
  • не менее 0.9 по mechanism discrimination;
  • 0 false-grounded answers при weak evidence / zero live match.

6. Артефакты, которые нужно вернуть после реализации

  1. run_summary.json

  2. before_after_metrics.json

  3. case_matrix.md по контрольным вопросам

  4. чат.txt / dialog export по минимум 3 вопросам, лучше по 6–8

  5. debug_payloads/ с примерами:

    • supplier 60 case
    • VAT case
    • month-close case

  6. короткий acceptance_note.md:

    • что исправлено;
    • что осталось ограничением;
    • прошёл ли final live rerun.

Это согласуется с вашим текущим operational follow-up по Stage 4: нужен единый финальный live-rerun и короткая consolidated acceptance фиксация.

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

  • Не добавлять новые домены.
  • Не расширять онтологию/graph ради этого фикса.
  • Не тащить Stage 5 investigation state как обязательный core-path.
  • Не делать большой рефактор маршрутизации.
  • Не пытаться “лечить” всё общим ростом generic retrieval.

Задача corrective pack — не расширение платформы, а жёсткое добивание качества Stage 4 в уже зафиксированной P0-рамке.

8. Ожидаемый итог

После corrective pack система должна:

  • корректно держать июль 2020;
  • не путать supplier/customer и 60/62;
  • не использовать нерелевантные live/VAT/future traces как доказательство;
  • выдавать mechanism-first answer с честными ограничениями;
  • проходить контрольные company-specific P0 вопросы не только на корпусе, но и на живом trace/debug прогоне.

Если хочешь, следующим сообщением я могу сразу дать ещё сверхкороткую версию этой ТЗ на 15–20 строк, прямо в формате “вставить в Codex без лишнего контекста”.