NODEDC_1C/IN/ssistant_runtime_ground_truth_audit.md

ssistant_runtime_ground_truth_audit.md

## Независимый архитектурно-процессный аудит фактического runtime-поведения assistant pipeline

## Цель: не чинить, а сделать подтверждённый рентген текущего механизма

### 1. Контекст

Проект находится в состоянии, где:

* архитектурный baseline уже поднят;
* Stage 4 формально удержан в `P0-only` режиме;
* на Chat20 достигался green по продуктовым метрикам;
* но live-path ранее требовал отдельной дочистки, а в follow-up уже зафиксирована необходимость финального live-rerun и consolidated acceptance note.

Текущая проблема: есть риск, что команда продолжает локально улучшать answer behavior, purity, wording, leakage и отдельные guards, **не имея подтверждённой картины того, как реально работает весь pipeline после пользовательского вопроса**.

Нужен не очередной fix-wave, а **объективный аудит фактического процесса**, основанный на:

* коде,
* конфигурации,
* реальных тестовых прогонах,
* debug/runtime traces,
* подтверждённых артефактах.

---

## 2. Главная цель задания

Нужно **полностью восстановить и доказательно описать реальный end-to-end цикл**:

**пользовательский вопрос → normalizer/router → route → retrieval → snapshot/live access → graph/problem-unit/evidence layers → answer composer → итоговый ответ**

Нужно не пересказывать старые отчёты, а:

* проверить, что реально происходит;
* показать, какие этапы действительно существуют в runtime;
* показать, какие этапы только декларируются;
* показать, где именно строится гипотеза;
* показать, существует ли вообще обязательный этап добычи доказательной базы под вопрос пользователя;
* показать, на каких реальных данных строится ответ.

---

## 3. Жёсткие ограничения задания

### Что делать нельзя

1. Не выполнять в этом задании архитектурный redesign.
2. Не вносить большие изменения в код как часть “исправления”.
3. Не подменять аудит выводами из старых md-отчётов без фактической проверки.
4. Не считать Stage 4 report источником истины — использовать его только как reference map.
5. Не ограничиваться unit-тестами без runtime traces.
6. Не делать “оптимистичный” вывод, если нет подтверждающих артефактов.

### Что делать можно

1. Добавлять временное логирование/трассировку.
2. Добавлять временные probe/debug hooks.
3. Делать controlled test runs.
4. Создавать отчёты, matrices, trace dumps, snapshot inventories, diagrams и служебные md/json файлы в `docs/ARCH`.

---

## 4. Базовый исследовательский вопрос аудита

Нужно ответить на главный вопрос:

### **Что именно реально делает система после пользовательского вопроса, и на каком основании она формирует вывод?**

Подвопросы, на которые аудит обязан дать подтверждённые ответы:

1. Какие этапы реально проходят всегда, а какие — опциональны?
2. Есть ли отдельный обязательный шаг:

   * формулировки claim,
   * адресного похода за доказательствами,
   * проверки обязательных звеньев цепочки,
   * сборки verdict?
3. Или система сейчас в основном работает как:

   * hypothesis-first,
   * signal-first,
   * snapshot-first,
   * partial live probe,
   * answer synthesis?
4. Какие именно данные реально используются:

   * какие snapshot файлы,
   * какого они размера,
   * какого типа данные в них лежат,
   * какая глубина и полнота этих данных,
   * хватает ли их для восстановления цепочек?
5. Что реально делает MCP/live:

   * какие вызовы идут,
   * когда идут,
   * с какими аргументами,
   * что возвращают,
   * являются ли они доказательной базой или только дополнительным слабым сигналом?
6. Где и как рождаются:

   * route,
   * semantic profile,
   * graph traversal,
   * domain purity,
   * problem units,
   * evidence,
   * confidence,
   * limitations?
7. На каком шаге система впервые делает интерпретацию?
8. До или после сбора фактов?
9. Есть ли в runtime механизм, который запрещает ответу звучать уверенно при неполной доказательной базе?
10. Что в pipeline реально является фундаментом ответа:

* факт,
* сигнал,
* эвристика,
* graph hint,
* snapshot artifact,
* live lookup,
* LLM interpretation?

---

## 5. Что именно нужно проверить в коде и рантайме

### A. Runtime process map

Нужно построить фактическую карту pipeline:

* входной user message;
* normalizer;
* decomposition/fragments/requirements;
* route selection;
* retrieval backend(s);
* snapshot access;
* live MCP access;
* graph logic;
* domain guardrails;
* problem-unit assembly;
* evidence packaging;
* answer composer;
* debug/export behavior.

Для каждого шага указать:

* модуль/файл/функцию;
* вход;
* выход;
* обязательность шага;
* где принимается решение;
* deterministic это или LLM-mediated;
* есть ли logging/trace.

### B. Snapshot reality audit

Нужно провести отдельный аудит snapshot-слоя:

1. Какие snapshot-источники реально участвуют в Stage 4.
2. Где они лежат.
3. Какие размеры файлов.
4. Какие сущности/поля/таблицы/срезы содержат.
5. На какие вопросы они вообще способны отвечать.
6. Какие вопросы они принципиально не могут закрыть без live access.
7. Есть ли разрыв между “в документах написано heavy/deep snapshots” и фактической полнотой snapshot-data. 

### C. Live MCP reality audit

Нужно проверить:

1. Какие MCP/live методы реально вызываются на контрольных вопросах.
2. На каком шаге pipeline это происходит.
3. Какие аргументы реально передаются.
4. Идут ли вызовы на:

   * адресный сбор доказательств,
   * восстановление цепочки,
   * сверку договора/объекта расчётов,
   * closure/tax/book/register verification,
     или live используется только как ограниченный дополнительный сигнал.
5. Есть ли ситуации, где:

   * `matched_rows = 0`,
   * account scope не применён,
   * live не подтвердил claim,
   * но ответ всё равно строится как содержательный grounded answer.
     Это уже наблюдалось в traces и должно быть отдельно проверено.

### D. Evidence contract audit

Нужно проверить, существует ли в системе реальный слой:

* claim verification,
* evidence admissibility,
* proof verdict.

Нужно установить:

1. Есть ли отдельный этап “сначала собрали факты, потом интерпретировали”.
2. Или фактически происходит наоборот:

   * сначала формируется hypothesis/problem unit,
   * потом под неё подбираются supporting signals.
3. Какие типы evidence реально существуют:

   * hard evidence,
   * weak mapping,
   * graph hint,
   * problem signal,
   * partial support,
   * inadmissible noise.
4. Есть ли gate, который вырезает нерелевантное evidence.
5. Если такого gate нет — это нужно зафиксировать как structural gap.

### E. Answer truthfulness audit

Нужно проверить, что именно уходит наружу:

* гипотеза,
* доказанный факт,
* partial coverage,
* explain mode,
* limitation-first answer,
* pseudo-grounded answer.

Нужно установить:

1. Умеет ли система различать:

   * “доказано”,
   * “опровергнуто”,
   * “недостаточно данных”.
2. Или наружу в основном уходит “похоже / есть признаки / часть цепочки подтверждена”.
3. Где answer composer теряет честность или, наоборот, слишком рано интерпретирует слабый сигнал как почти доказанный вывод.

---

## 6. Обязательный контрольный набор для аудита

Нужно прогнать минимум ядро из вопросов по company snapshot July 2020, потому что именно на нём уже формулировались P0-требования. В первую очередь использовать 8 сильных core-вопросов: расчёты 60–62, НДС, month-close, РБП, limitation honesty.

Минимально обязательны к прогону:

1. Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
2. Поступление 276 873,60 — корректно ли зачёлся аванс 15 июля.
3. Платежи 40 860 и 20 000 по договору № 1-ПМ/2020 — это аванс или закрытие дебиторки.
4. Услуги связи + НДС 233,33 + счёт-фактура — полная ли НДС-цепочка.
5. Есть ли покупки июля с неполным НДС-контуром.
6. Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
7. Списание РБП — не живёт ли часть РБП дольше ожидаемого.
8. После полного month-end — что реально проблема, а что нормальный остаток.

---

## 7. Формат выполнения аудита

### Этап 1. Static architecture pass

Без изменений логики:

* прочитать relevant code paths;
* построить map модулей;
* составить runtime call graph;
* определить места принятия решений.

### Этап 2. Instrumentation pass

Добавить временное диагностическое логирование, если его не хватает, чтобы фиксировать:

* какой route выбран;
* какие sources выбраны;
* какой snapshot использован;
* какие live MCP calls ушли;
* какие аргументы ушли;
* что вернулось;
* какие evidence items попали в answer;
* на каком шаге появился primary interpretation;
* какой confidence/limitation режим ушёл наружу.

### Этап 3. Controlled runtime pass

Прогнать контрольный набор вопросов с включённым audit logging.

### Этап 4. Comparative pass

Для каждого вопроса восстановить таблицу:

* что спросил пользователь;
* какие anchors извлеклись;
* какой route selected;
* какие snapshot datasets реально использовались;
* какие live calls реально были;
* какие факты реально подтверждены;
* что осталось недоказанным;
* где возникла гипотеза;
* из чего собрался финальный ответ.

### Этап 5. Structural gap analysis

Выделить:

* отсутствующие обязательные шаги;
* смешанные режимы;
* места ранней интерпретации;
* фиктивную или слабую доказательную базу;
* расхождение между декларируемой архитектурой и фактическим runtime.

---

## 8. Главные вопросы, на которые аудит обязан ответить в финальном отчёте

1. Система сейчас **proof-first** или **hypothesis-first**?
2. Есть ли у неё реальный слой **claim verification**?
3. Что является фактическим фундаментом ответа:

   * snapshot,
   * live lookup,
   * graph signals,
   * problem units,
   * эвристики,
   * LLM synthesis?
4. Достаточен ли текущий snapshot-слой для company-specific July 2020 reasoning?
5. Какие классы вопросов нельзя надёжно решать без обязательного live evidence acquisition?
6. Есть ли в runtime этап адресного похода по цепочке:

   * документ,
   * договор,
   * объект расчётов,
   * проводка,
   * регистр,
   * книга,
   * closure?
7. Если такого этапа нет, где именно он должен быть встроен концептуально.
8. Что сейчас реально делает MCP:

   * verification,
   * lookup,
   * enrichment,
   * noise injection,
   * partial support?
9. Какие части Stage 4 реально полезны, а какие маскируют отсутствие фундамента.
10. Что является минимальным обязательным новым слоем, без которого дальнейшие corrective waves теряют смысл.

---

## 9. Что нужно создать в `docs/ARCH`

Создать новый комплект артефактов.

### Основной отчёт

`docs/ARCH/7 - assistant_runtime_ground_truth_audit_2026-03-28.md`

В нём должны быть разделы:

1. Executive summary
2. Scope and constraints
3. Verified runtime architecture
4. Snapshot reality
5. MCP/live reality
6. Evidence acquisition reality
7. Answer synthesis reality
8. Control question audit
9. Structural gaps
10. Minimum required architectural correction
11. What not to do next

### Приложения

1. `docs/ARCH/7A - runtime_call_graph.md`

   * по шагам и модулям

2. `docs/ARCH/7B - snapshot_inventory_and_coverage.md`

   * список snapshot-источников, размеров, сущностей, покрываемых question classes

3. `docs/ARCH/7C - live_mcp_call_inventory.md`

   * какие live вызовы реально ушли на контрольных прогонах

4. `docs/ARCH/7D - control_question_trace_matrix.md`

   * по каждому вопросу: route, sources, evidence, claim status, answer type

5. `docs/ARCH/7E - structural_gap_register.md`

   * список критичных gap’ов с severity:

     * blocker
     * high
     * medium

6. `docs/ARCH/7F - instrumentation_notes.md`

   * что было добавлено/включено ради аудита

7. `docs/ARCH/audit_artifacts/`

   * raw json traces,
   * exported debug payloads,
   * sample dialog logs,
   * live call dumps,
   * optional diagrams

---

## 10. Требования к доказательности отчёта

Финальный отчёт **не может** состоять из общих слов.
Каждое важное утверждение должно быть подтверждено хотя бы одним из:

* ссылкой на конкретный кодовый путь;
* runtime trace;
* debug payload;
* live MCP call dump;
* snapshot inspection artifact;
* reproduced control question log.

Если что-то не удалось проверить — это нужно явно маркировать:

* `verified`
* `partially verified`
* `not verified`
* `inferred`

---

## 11. Специальный акцент аудита

Отдельно нужно проверить и честно описать:

### A. Существует ли сейчас отдельный обязательный шаг “добычи доказательной базы”

Не abstract retrieval, а именно:

* по claim пользователя;
* с обязательными anchors;
* с адресной проверкой звеньев цепочки.

### B. Не подменяется ли доказательство problem units / graph hints / snapshot signals

Это критический вопрос.

### C. Не является ли текущая система фактически:

**snapshot-driven hypothesis engine with partial live enrichment**
вместо:
**evidence-first accounting verification assistant**

---

## 12. Финальная форма вывода

В конце основного отчёта обязательно дать **жёсткий вердикт** в одной из форм:

* `VERIFIED_AS_EVIDENCE_FIRST`
* `VERIFIED_AS_HYPOTHESIS_FIRST`
* `MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`

И отдельно:

* что именно уже годно;
* что именно фундаментально отсутствует;
* какой минимальный архитектурный слой нужен дальше;
* почему дальнейшие локальные фиксы без этого слоя либо полезны, либо уже неокупаемы.

---

## 13. Что не должно быть результатом

Результатом этого задания **не должен** стать новый fix pack.
Результатом должен стать:

* честный рентген,
* подтверждённая карта runtime,
* список gaps,
* и ясный ответ, **что у нас вообще реально работает после вопроса пользователя**.

---