SILVER/NODEDC_1C
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Initial import NDC_1C

Browse Source
This commit is contained in:
dctouch
2026-03-26 10:38:25 +03:00
commit a162d77ef7
2943 changed files with 3615871 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/1c_inventory.md
+43
View File
@@ -0,0 +1,43 @@
# 1C Inventory Report
## Status
- Date: `2026-03-22`
- Environment owner: `NDC / Codex`
- Inventory status: `in_progress`
## Platform And Base
- 1C platform version: `8.3.27.1936`
- Base type: `file` (`1Cv8.1CD` present)
- Base path: `X:\1C\База бухгалтерии`
- Config name/version: `Бухгалтерия предприятия, редакция 2.0` (from context, needs final confirmation in Configurator)
## Integration Access
- OData published: `yes`
- OData base URL: `http://localhost/buh_test/odata/standard.odata/`
- Read-only user created: `yes` (`ndc_probe`)
- Read-only role verified: `pending explicit role check in 1C`
## Available Object Families (from Configurator)
- Documents: `present` (`Document_*`, sample reads successful)
- Catalogs: `present` (`Catalog_*`, sample reads successful)
- Accounting registers: `present` (`AccountingRegister_Хозрасчетный`, sample reads successful)
- Accumulation registers: `present` (`AccumulationRegister_*`, sample reads successful)
- Chart of accounts: `present in metadata` (needs targeted probe scenario)
- Roles: `not inventoried yet in Configurator`
## Initial Integration Scope
- Documents: `Document_АвансовыйОтчет`, `Document_ПоступлениеТоваровУслуг`, `Document_РеализацияТоваровУслуг`
- Counterparties: `Catalog_Контрагенты`
- Contracts: `Catalog_ДоговорыКонтрагентов`
- Accounts: `AccountingRegister_Хозрасчетный` and related accounting entities
- Register movements/postings: `AccountingRegister_Хозрасчетный`
## Risks Found
1. Read-only rights confirmed by behavior (`401` without auth), but write-deny must still be verified by role policy.
2. Production-fit of links needs deeper scenario probes (document->posting->account/subconto chains).
docs/ARCH/1 - bootstrap_pipeline_new_machine_2026-03-23.md
+252
View File
@@ -0,0 +1,252 @@
# Bootstrap Runbook: Полный пайплайн запуска с нуля (новая машина)
Дата: 2026-03-23
Статус: рабочий контур подтвержден (`adopt with restrictions`)
Цель: поднять наш текущий live read-only bridge к 1С с нуля на новой Windows-машине.
## 1. Что в итоге должно работать
После выполнения шагов должны одновременно работать:
1. Python proxy (`onec_mcp_toolkit_proxy`) на `http://127.0.0.1:6003`
2. 1С:Предприятие с открытой обработкой `MCP_Toolkit.epf` в режиме `Прокси`
3. Успешные read-only вызовы:
- `get_metadata`
- `execute_query`
- `get_link_of_object`
- `get_object_by_link`
Важно: это live request/response мост, не оффлайн-реплика.
## 2. Архитектура (минимум)
```text
Клиент/ассистент -> HTTP -> Python Proxy (6003) -> /1c/poll,/1c/result -> MCP_Toolkit.epf -> База 1С
```
## 3. Что нужно на новой машине
1. Windows (рекомендуемо 64-bit).
2. Установленная платформа 1С (в нашем контуре: `8.3.27.1936`).
3. Тестовая база 1С (БП 2.0) и рабочий пользователь с read-only правами.
4. Git.
5. Miniconda.
6. Доступ к репозиторию `ROCTUP/1c-mcp-toolkit`.
## 4. Рекомендованная структура папок
```text
X:\1C\
NDC_1C\
docs\
external\
1c-mcp-toolkit\
```
Если диска `X:` нет, можно использовать любой путь, но держать единую структуру.
## 5. Установка и подготовка окружения
### 5.1 Клонировать toolkit
```powershell
git clone https://github.com/ROCTUP/1c-mcp-toolkit X:\1C\NDC_1C\external\1c-mcp-toolkit
```
### 5.2 Проверить `.epf` артефакты
```powershell
Get-ChildItem X:\1C\NDC_1C\external\1c-mcp-toolkit\build
```
Ожидаемые файлы:
- `MCP_Toolkit.epf` (x64)
- `MCP_Toolkit_x86.epf` (x86 fallback)
### 5.3 Создать изолированную conda-среду
```powershell
& 'C:\Users\<USER>\miniconda3\Scripts\conda.exe' create -y -n ndc_1c_toolkit python=3.11
```
### 5.4 Установить зависимости proxy
```powershell
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_toolkit\python.exe' -m pip install --upgrade pip
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_toolkit\python.exe' -m pip install -r X:\1C\NDC_1C\external\1c-mcp-toolkit\requirements.txt
```
## 6. Запуск proxy (read-only профиль)
Запускать из PowerShell:
```powershell
$env:PORT='6003'
$env:TIMEOUT='180'
$env:ALLOW_DANGEROUS_WITH_APPROVAL='false'
$env:ANONYMIZATION_ENABLED='false'
$env:RESPONSE_FORMAT='json'
$env:LOG_LEVEL='INFO'
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_toolkit\python.exe' -m onec_mcp_toolkit_proxy
```
Проверка:
```powershell
Invoke-WebRequest http://127.0.0.1:6003/health -UseBasicParsing
```
Ожидаемо: HTTP 200 и `status=healthy`.
## 7. Запуск 1С и обработчика
### 7.1 Открыть 1С:Предприятие
Открывать в **режиме Предприятия** (не Конфигуратор).
Если UI обработки не появляется в обычном режиме, запускать в управляемом приложении.
### 7.2 Открыть внешнюю обработку
`Файл -> Открыть -> X:\1C\NDC_1C\external\1c-mcp-toolkit\build\MCP_Toolkit.epf`
### 7.3 Настроить форму MCP Toolkit
1. Режим: `Прокси`
2. Адрес сервера: `http://127.0.0.1:6003`
3. Идентификатор канала: `default` (или ваш фиксированный channel)
4. Нажать `Подключиться`
Ожидаемо в логе формы:
- `Подключение к серверу: http://127.0.0.1:6003`
- `Успешное подключение к серверу`
## 8. Smoke-проверка после подключения
### 8.1 Metadata
```powershell
Invoke-WebRequest "http://127.0.0.1:6003/api/get_metadata?channel=default&meta_type=Документ&limit=20" -UseBasicParsing
```
Ожидаемо: `success=true`.
### 8.2 Query
```powershell
$body = @{ query = "ВЫБРАТЬ ПЕРВЫЕ 1 1 КАК Test"; limit = 1 } | ConvertTo-Json
Invoke-WebRequest "http://127.0.0.1:6003/api/execute_query?channel=default" `
-Method POST -ContentType "application/json; charset=utf-8" -Body $body -UseBasicParsing
```
Ожидаемо: `success=true`, `Test=1`.
### 8.3 Object link flow
1. Получить `object_description` (например, из `execute_query`).
2. Вызвать `get_link_of_object`.
3. Передать ссылку в `get_object_by_link`.
Ожидаемо: объект документа читается.
## 9. Ежедневный рабочий цикл (операторский)
### Старт дня
1. Запустить proxy.
2. Проверить `/health`.
3. Запустить 1С и открыть `MCP_Toolkit.epf`.
4. Проверить статус `Подключено`.
5. Выполнить быстрый test query.
### Стоп дня
1. Отключиться в форме MCP Toolkit.
2. Закрыть 1С.
3. Остановить proxy (Ctrl+C/Stop-Process).
## 10. Траблшутинг (частые проблемы)
### 10.1 Ошибка `Не могу установить соединение` в форме 1С
Причина: proxy не запущен или не слушает `6003`.
Проверка:
```powershell
Invoke-WebRequest http://127.0.0.1:6003/health -UseBasicParsing
```
### 10.2 `timeout waiting for 1C response` на API
Причина: нет активного `.epf` в том же `channel`, форма закрыта, либо канал не совпадает.
### 10.3 `UI не показывается` при открытии `.epf`
Обработка имеет управляемые формы.
Запускать в 1С:Предприятии (управляемый режим), не в Конфигураторе для рабочего контура.
### 10.4 Кодировка ссылки из `get_link_of_object` выглядит “кракозябрами”
Нюанс текущего ответа proxy; вызов рабочий, ссылку можно нормализовать при постобработке.
## 11. Жёсткие правила безопасности
1. Только read-only операции.
2. Не использовать `execute_code`.
3. Не выставлять `6003` во внешний интернет.
4. Держать `ALLOW_DANGEROUS_WITH_APPROVAL=false`.
5. Работать под отдельным техпользователем с минимальными правами чтения.
## 12. Что это даёт и чего не даёт
### Даёт
- Живой доступ к текущим данным 1С по запросу.
- Runtime metadata + deep read semantics (документы, проводки, субконто, сальдо).
### Не даёт
- Мгновенный “весь срез компании” в одном запросе для тяжёлой аналитики.
- Автоматическую фоновой репликацию без отдельного слоя витрин/снэпшотов.
## 13. Рекомендованный next step после bootstrap
1. Добавить one-click старт скрипт (`Start-NDC1CBridge.ps1`).
2. Добавить one-click smoke скрипт (`Test-NDC1CBridge.ps1`).
3. Поднять плановую аналитическую витрину (например, 15/60 минут) для тяжёлых задач.
---
Итог bootstrap: на новой машине поднимаем контур за последовательность
`Proxy -> MCP_Toolkit.epf -> Подключение -> Smoke`
и получаем рабочий live read-only мост к 1С на текущем этапе проекта.
_________________________________________________
ЗАПУСК ПРКСИ ПЕРЕД ПОДКЛЮЮЧЕНИЕМ К ТУЛКИТ 1С
_________________________________________________
Запускай так в PowerShell:
$env:PORT='6003'
$env:TIMEOUT='180'
$env:ALLOW_DANGEROUS_WITH_APPROVAL='false'
$env:ANONYMIZATION_ENABLED='false'
$env:RESPONSE_FORMAT='json'
$env:LOG_LEVEL='INFO'
& 'C:\Users\DCTOUCH\miniconda3\envs\ndc_1c_toolkit\python.exe' -m onec_mcp_toolkit_proxy
Проверка, что поднялся:
Invoke-WebRequest http://127.0.0.1:6003/health -UseBasicParsing
Должен вернуть status":"healthy".
Остановить:
в том же окне Ctrl + C.
docs/ARCH/2 - architecture_stage_report_2026-03-23.md
+194
View File
@@ -0,0 +1,194 @@
# Архитектурный Stage Report (AS-IS)
Дата фиксации: 2026-03-23
Проект: NDC 1C analytics bridge
Контур: локальный стенд (Windows, тестовая база 1С)
## 1. Резюме этапа
На текущем этапе подтверждён рабочий **read-only runtime мост** к живой 1С через `1c-mcp-toolkit` в proxy-режиме.
Три критические бухгалтерские проверки закрыты как `PROVEN`:
1. `document -> posting -> debit/credit account`
2. `posting -> subconto[1..3] -> counterparty / contract / item`
3. Объяснение реального сальдо через агрегат движений (`delta = 0.0`)
Официальный статус решения: `adopt with restrictions`.
## 2. Цель этапа (что фиксируем)
Зафиксировать не идею, а фактическое состояние архитектуры:
- как реально ходят данные;
- что именно работает в live режиме;
- что является ограничением;
- какие артефакты подтверждают результаты;
- что берём в следующий этап.
## 3. Текущая архитектура (AS-IS)
```text
AI/клиент аналитики
|
| HTTP (read-only API calls)
v
Local Proxy: onec_mcp_toolkit_proxy (FastAPI) [127.0.0.1:6003]
|\
| \-- /health, /api/get_metadata, /api/execute_query, /api/get_object_by_link, ...
|
| Long polling bridge
| GET /1c/poll
| POST /1c/result
v
1C External Processing MCP_Toolkit.epf (управляемая форма, режим "Прокси")
|
v
Тестовая база 1С: Бухгалтерия предприятия 2.0 (2.0.67.20), платформа 8.3.27.1936
```
Дополнительно параллельно существует OData read-only слой (базовый широкий вход), но в этом stage фиксируется именно runtime-mост toolkit.
## 4. Компоненты и роль
1. `MCP_Toolkit.epf`
- Путь: `X:\1C\NDC_1C\external\1c-mcp-toolkit\build\MCP_Toolkit.epf`
- Роль: 1С-сторона моста, выполнение read-запросов в контексте базы и возврат результатов в proxy.
- Важно: форма управляемая; в обычном режиме UI может не открываться.
2. `onec_mcp_toolkit_proxy` (Python/FastAPI)
- Путь: `X:\1C\NDC_1C\external\1c-mcp-toolkit\onec_mcp_toolkit_proxy`
- Роль: единая HTTP/MCP точка входа для аналитики.
- Runtime: Miniconda env `ndc_1c_toolkit`.
- Базовый endpoint: `http://127.0.0.1:6003`.
3. 1С тестовая база
- Платформа: `8.3.27.1936`
- Конфигурация: `БП 2.0 (2.0.67.20)`
- Роль: source of truth для всех live чтений.
4. Артефактный слой (доказательства)
- Путь: `X:\1C\NDC_1C\docs\snapshots\toolkit`
- Роль: хранение фактических ответов/логов проверки этапа.
## 5. Семантика доступа к данным (очень важно)
### 5.1 Что это сейчас
Это **live request/response bridge**:
- каждый запрос читается из текущего состояния 1С на момент вызова;
- данные не берутся из локальной копии/реплики;
- нет постоянного stream-пайплайна “само обновляется”.
### 5.2 Что это не сейчас
- это не полноценная витрина данных по всей компании;
- это не always-on snapshot pipeline;
- это не CDC/стриминг изменений в фоновом режиме.
### 5.3 Практический вывод
Для точечных и средних аналитических задач мост подходит в near real-time режиме.
Для очень широких срезов (вся компания, тяжёлые многомерные отчёты) потребуется отдельный слой агрегаций/снэпшотов.
## 6. API-поверхность, которую используем в проекте
Разрешённый operational набор:
- `get_metadata`
- `execute_query`
- `get_object_by_link`
- `get_link_of_object`
- при необходимости другие read-only методы
Запрещено в operational контуре:
- `execute_code`
- любые write/mutation операции.
## 7. Ограничения и guardrails
Обязательные ограничения на текущем этапе:
1. Только read-only вызовы.
2. `ALLOW_DANGEROUS_WITH_APPROVAL=false`.
3. Endpoint не публиковать наружу.
4. Использовать отдельного техпользователя 1С с правами чтения.
5. Все спорные/рисковые действия маркировать как `manual required`.
## 8. Подтверждённые доказательства этапа
### 8.1 Проверка 1: document -> posting -> debit/credit
- Есть реальная проводка:
- документ: `Счет-фактура полученный 00000000001 от 03.08.2030 12:00:00`
- Дт: `68.02`
- Кт: `19.04`
- сумма: `500`
- Документ прочитан по ссылке через `get_object_by_link`.
### 8.2 Проверка 2: posting -> subconto[1..3]
Есть реальные примеры:
- `Контрагент + Договор`:
- `СубконтоКт1 (Контрагенты)` = `Ассоциация "СРО"СОВЕТ ПРОЕКТИРОВЩИКОВ"`
- `СубконтоКт2 (Договоры)` = `дело А40-201628/21`
- `Номенклатура/склад`:
- `СубконтоКт1 (Номенклатура)` = `Портьерные шторы Garden kolor`
- `СубконтоКт3 (Склады)` = `Основной склад`
### 8.3 Проверка 3: объяснение сальдо движениями
По счёту `68.02`:
- `СальдоИтого (Остатки) = 28363.8`
- `ОборотДт - ОборотКт = 49600886.74 - 49572522.94 = 28363.8`
- `delta = 0.0`
## 9. Риски и технический долг
1. Heavy analytics latency
- На очень широких задачах модель вынуждена собирать картину по частям.
2. Отсутствие материализованной витрины
- Нет быстрого “единый срез по компании” без серии запросов.
3. Нюанс кодировки
- В отдельных ответах (`get_link_of_object`) требуется нормализация строки ссылки.
4. Риск регресса через опасные инструменты
- `execute_code` существует в toolkit и должен быть процедурно/технически заблокирован в operational потоке.
## 10. Решения, принятые по итогу этапа
1. Оставляем `OData` как базовый read-only широкий слой.
2. `1c-mcp-toolkit` фиксируем как рабочий runtime/deeper слой для семантических проверок и интерактивной аналитики.
3. Статус внедрения: `adopt with restrictions`.
## 11. Что делаем следующим этапом
Этап 2 (production-hardening):
1. Ввести жёсткие технические guardrails на запрет `execute_code`.
2. Формализовать query-профили (шаблоны безопасных read-only запросов).
3. Добавить слой агрегатов/плановых снэпшотов для тяжёлой аналитики.
4. Настроить эксплуатационный регламент:
- health-check;
- контроль channel;
- таймауты;
- логирование и аудит вызовов.
## 12. Список ключевых артефактов этапа
- `X:\1C\NDC_1C\docs\toolkit_inventory.md`
- `X:\1C\NDC_1C\docs\toolkit_install_runbook.md`
- `X:\1C\NDC_1C\docs\toolkit_smoke_test_report.md`
- `X:\1C\NDC_1C\docs\toolkit_semantic_probe_report.md`
- `X:\1C\NDC_1C\docs\toolkit_decision_note.md`
- `X:\1C\NDC_1C\docs\snapshots\toolkit\semantic_probe_live_summary.json`
---
Stage считаем зафиксированным на дату `2026-03-23`:
**Live read-only bridge подтверждён, критические бухгалтерские цепочки доказаны, архитектурный статус — `adopt with restrictions`.**
docs/ARCH/2020экспорт/00_manifest.md
+26
View File
@@ -0,0 +1,26 @@
# 2020 экспорт: состав выгрузки
Папка собрана автоматически для ручного анализа текущего состояния.
## Файлы
1. `01_ontology_mapping_layer.md` — текущая онтология/мэппинг и метрики среза.
2. `02_canonical_relation_rules.md` — правила построения canonical relations.
3. `03_snapshot_fragment_problem_cases.json` — проблемный фрагмент snapshot июня 2020.
4. `04_samples_SpisanieSRaschetnogoScheta.json` — реальные записи по `СписаниеСРасчетногоСчета`.
5. `05_samples_RealizaciyaTovarovUslug.json` — реальные записи по `РеализацияТоваровУслуг`.
6. `06_samples_PostuplenieTovarovUslug.json` — реальные записи по `ПоступлениеТоваровУслуг`.
7. `07_samples_DocumentJournals.json` — реальные записи по журналам документов.
8. `08_samples_NDS_registers.json` — реальные записи по НДС-регистрам.
9. `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json` — записи с ключевыми полями.
## Ключевые поля: фактическая встречаемость в snapshot
| field | count |
| --- | --- |
| Ответственный_Key | 187 |
| Ref | 168 |
| Recorder | 147 |
| Ref_Key | 93 |
| Поставщик_Key | 78 |
| Покупатель_Key | 46 |
docs/ARCH/2020экспорт/01_ontology_mapping_layer.md
+96
View File
@@ -0,0 +1,96 @@
# Текущая онтология / mapping-слой
Дата экспорта: 2026-03-23T10:23:29.088258+00:00
Источник snapshot: `X:\1C\NDC_1C\logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
## Что считается сущностями сейчас
Базовая модель (canonical classes):
- `CanonicalEntity`
- `Organization`
- `Counterparty`
- `Contract`
- `Account`
- `Subconto`
- `ResponsiblePerson`
- `Currency`
- `Warehouse`
- `CashflowArticle`
- `Department`
- `Individual`
- `Item`
- `BankAccount`
- `Document`
- `InvoiceDocument`
- `Posting`
- `RegisterMovement`
- `RegisterRecord`
- `Period`
## Срез июня 2020: покрытие сущностей
- Отобранный период: `2020-06`
- Диапазон: `2020-06-01T00:00:00+00:00 -> 2020-07-01T00:00:00+00:00`
- Записей в slice: `409`
- Связей в slice: `2011`
- Entity sets: `42`
- Записей с `source_id=unknown`: `0`
### Распределение entity sets по canonical-классам
| Canonical class | Entity set count |
| --- | --- |
| Account | 3 |
| Document | 28 |
| Individual | 1 |
| InvoiceDocument | 2 |
| RegisterRecord | 8 |
### Топ target_entity в links
| target_entity | count |
| --- | --- |
| Document | 458 |
| Counterparty | 440 |
| Organization | 434 |
| Account | 217 |
| Currency | 158 |
| ResponsiblePerson | 112 |
| Unknown | 102 |
| BankAccount | 30 |
| Individual | 22 |
| Department | 18 |
| Warehouse | 12 |
| Contract | 7 |
| Item | 1 |
### Топ relation в links
| relation | count |
| --- | --- |
| journal_refers_to_document | 168 |
| journal_organization | 168 |
| reference | 165 |
| register_relates_to_organization | 148 |
| register_recorded_by_document | 147 |
| document_has_counterparty | 139 |
| document_line_has_account | 136 |
| journal_counterparty | 133 |
| register_relates_to_invoice | 124 |
| document_belongs_to_organization | 118 |
| journal_has_currency | 95 |
| register_relates_to_supplier | 78 |
| register_relates_to_account | 77 |
| document_has_currency | 63 |
| document_has_responsible | 57 |
| journal_responsible | 55 |
| register_relates_to_buyer | 46 |
| journal_bank_account | 30 |
| register_relates_to_individual | 21 |
| register_relates_to_department | 18 |
### Качество типизации связей
- Всего связей: `2011`
- Связей с `target_entity=Unknown`: `102`
- Доля unknown: `5.07%`
docs/ARCH/2020экспорт/02_canonical_relation_rules.md
+32
View File
@@ -0,0 +1,32 @@
# Текущие canonical relation rules
Источник: `canonical_layer/mappers.py`
## Текущий каталог semantic relations
| Context | Field role | Relation |
| --- | --- | --- |
| register | recorder | register_recorded_by_document |
| journal | ref | journal_refers_to_document |
| document | counterparty | document_has_counterparty |
| document | contract | document_has_contract |
| document | organization | document_belongs_to_organization |
| document | responsible | document_has_responsible |
| document | currency | document_has_currency |
| document | warehouse | document_has_warehouse |
| document | cashflow_article | document_has_cashflow_article |
| document | bank_account | document_has_bank_account |
| register | supplier | register_relates_to_supplier |
| register | buyer | register_relates_to_buyer |
| register | invoice | register_relates_to_invoice |
| register | contract | register_relates_to_contract |
| register | organization | register_relates_to_organization |
| register | account | register_relates_to_account |
| register | item | register_relates_to_item |
## Базовые правила извлечения ссылок
1. Поле попадает в link, если это `_Key`, `*ref`, GUID или semantic-поле (например `Recorder`, `СчетФактура`).
2. `*_Type` используется как приоритетная подсказка типа target-сущности.
3. Нулевые GUID (`00000000-...`) отфильтровываются из canonical links.
4. Если `source_id` отсутствует, строится составной `cmp:<sha1>` ключ.
docs/ARCH/2020экспорт/03_snapshot_fragment_problem_cases.json
+5449
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/04_samples_SpisanieSRaschetnogoScheta.json
+3320
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/05_samples_RealizaciyaTovarovUslug.json
+2086
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/06_samples_PostuplenieTovarovUslug.json
+3078
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/07_samples_DocumentJournals.json
+5129
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/08_samples_NDS_registers.json
+5044
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/2020экспорт/09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json
+8753
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/3 - mvp_prod_arch_stage_1-7_report_2026-03-23.md
+435
View File
@@ -0,0 +1,435 @@
# MVP PROD ARCH Report #3: Stage 1-7 (AS-IS + Runbook)
Дата фиксации: 2026-03-23
Проект: NDC 1C analytics bridge
Контур: локальный стенд Windows + 1С + Miniconda
Статус: **MVP контур Stage 1-7 поднят, Stage 7 частично (спецификация + API-роуты, без полного orchestration-сервиса в прод-режиме)**
---
## 1. Executive summary
На текущем этапе мы имеем рабочую многоуровневую read-only архитектуру:
`1C Source -> Runtime Bridge -> Refresh/Canonical Store -> Feature/Anomaly -> Risk -> API Layer`
Что подтверждено фактически:
1. Runtime bridge к живой 1С доказан и стабилен в read-only режиме.
2. Три жесткие бухгалтерские проверки закрыты как `PROVEN`.
3. Реализован и протестирован Layer 3/4: refresh + canonical store.
4. Реализован и протестирован Layer 5: feature/anomaly engine.
5. Реализован и протестирован Layer 6: risk engine.
6. По Layer 7 есть orchestration-spec и техническая поверхность API, но полноценный production-orchestrator (планировщик/роутер/политики исполнения) еще в roadmap.
---
## 2. Архитектура на текущем этапе
### 2.1 High-level
```text
1С (source of truth, read-only)
-> toolkit bridge / OData read
-> Refresh Engine (historical/incremental/targeted)
-> Canonical Store (entities + links + checkpoints + run logs)
-> Feature Engine (derived metrics + anomaly signals)
-> Risk Engine (domain patterns + global risk score)
-> FastAPI endpoints for integration with assistant/orchestrator
```
### 2.2 Runtime bridge (live)
Базовая связка:
- Proxy: `onec_mcp_toolkit_proxy` (`http://127.0.0.1:6003`)
- 1С обработка: `MCP_Toolkit.epf` в режиме `Прокси`
- Канал: long polling (`/1c/poll`, `/1c/result`)
Важно:
- Это **live request/response**, не snapshot-реплика.
- Для тяжелой аналитики используется выделенный store-слой, а не прямой проход LLM по всей базе 1С.
---
## 3. Stage-by-stage статус (1-7)
## Stage 1. Runtime bridge + guardrails
Статус: **DONE (MVP)**
Артефакты:
- `docs/ARCH/2 - architecture_stage_report_2026-03-23.md`
- `docs/toolkit_install_runbook.md`
- `docs/toolkit_smoke_test_report.md`
- `docs/toolkit_semantic_probe_report.md`
Ключевой результат:
- Подтвержден live read-only мост через `1c-mcp-toolkit`.
- Статус принятия: `adopt with restrictions`.
## Stage 2. Canonical schema
Статус: **DONE (MVP)**
Артефакт:
- `docs/accounting_canonical_schema.md`
Реализация:
- `canonical_entities`
- `canonical_links`
- JSON-атрибуты + нормализованные связи.
## Stage 3. Historical loader
Статус: **DONE (MVP)**
Артефакт:
- `docs/historical_load_plan.md`
Реализация:
- режим `historical` в `scripts/run_refresh.py`.
## Stage 4. Incremental refresh
Статус: **DONE (MVP)**
Артефакты:
- `docs/refresh_strategy.md`
- `docs/incremental_refresh_plan.md`
Реализация:
- режимы `incremental`, `targeted`
- таблицы `refresh_runs`, `refresh_checkpoints`
- run-status: `success/partial_success/failed`
## Stage 5. Feature / anomaly engine
Статус: **DONE (MVP)**
Артефакты:
- `docs/analytics_store_design.md`
- `docs/anomaly_engine_spec.md`
Реализация:
- `feature_runs`
- `feature_metrics`
- `anomaly_signals`
- API: `/features/*`
## Stage 6. Risk engine
Статус: **DONE (MVP)**
Артефакт:
- `docs/risk_engine_spec.md`
Реализация:
- `risk_runs`
- `risk_patterns`
- domain-level risk patterns
- `global_risk_summary`
- API: `/risk/*`
## Stage 7. Assistant orchestration
Статус: **PARTIAL (spec + API-ready surface)**
Артефакты:
- `docs/assistant_orchestration_spec.md`
- `docs/security_guardrails_readonly.md`
Состояние:
- спецификация маршрутизации готова;
- runtime endpoints для refresh/features/risk готовы;
- полноценный orchestration-service с scheduler/policy execution — **еще не реализован как отдельный прод-компонент**.
---
## 4. Deliverables check (архитектурный комплект)
На дату 2026-03-23 все 8 целевых deliverables присутствуют в `docs/`:
1. `accounting_canonical_schema.md`
2. `analytics_store_design.md`
3. `refresh_strategy.md`
4. `historical_load_plan.md`
5. `incremental_refresh_plan.md`
6. `anomaly_engine_spec.md`
7. `assistant_orchestration_spec.md`
8. `security_guardrails_readonly.md`
---
## 5. Текущее окружение и зависимости
## 5.1 ОС и инструменты
- Windows (локальный стенд)
- 1С платформа: `8.3.27.1936`
- База: Бухгалтерия предприятия 2.0 (лабораторный контур)
- Python: `3.12.10` (технический интерпретатор машины)
- Miniconda env проекта: `ndc_1c_mvp`
- Miniconda env toolkit proxy: `ndc_1c_toolkit` (для bridge-контура)
## 5.2 Python зависимости проекта
`requirements.txt`:
- `fastapi>=0.116.0`
- `odata1cw>=0.0.4`
- `pydantic>=2.11.0`
- `pytest>=8.3.5`
- `python-dotenv>=1.1.0`
- `requests>=2.32.0`
- `SQLAlchemy>=2.0.38`
- `uvicorn>=0.35.0`
## 5.3 Ключевые env-параметры
Из `.env.example`:
- `CANONICAL_DB_URL=sqlite:///X:/1C/NDC_1C/data/canonical_store.db`
- `REFRESH_DEFAULT_LIMIT_PER_SET=200`
- `FEATURE_BASELINE_WINDOW_HOURS=24`
- `ANOMALY_STALE_REFRESH_THRESHOLD_HOURS=6`
- `FEATURE_ENTITY_SCAN_LIMIT=200000`
- `RISK_MEDIUM_THRESHOLD=0.45`
- `RISK_HIGH_THRESHOLD=0.75`
- `RISK_ANOMALY_SCAN_LIMIT=5000`
---
## 6. Полный запуск системы с нуля (на новой машине)
## 6.1 Bootstrap bridge-контура (1С + proxy)
1. Установить 1С платформу и подготовить тестовую базу (read-only пользователь).
2. Установить Miniconda и Git.
3. Подготовить toolkit и env:
```powershell
git clone https://github.com/ROCTUP/1c-mcp-toolkit X:\1C\NDC_1C\external\1c-mcp-toolkit
& 'C:\Users\<USER>\miniconda3\Scripts\conda.exe' create -y -n ndc_1c_toolkit python=3.11
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_toolkit\python.exe' -m pip install -r X:\1C\NDC_1C\external\1c-mcp-toolkit\requirements.txt
```
4. Запустить proxy:
```powershell
$env:PORT='6003'
$env:TIMEOUT='180'
$env:ALLOW_DANGEROUS_WITH_APPROVAL='false'
$env:ANONYMIZATION_ENABLED='false'
$env:RESPONSE_FORMAT='json'
$env:LOG_LEVEL='INFO'
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_toolkit\python.exe' -m onec_mcp_toolkit_proxy
```
5. Проверить health:
```powershell
Invoke-WebRequest http://127.0.0.1:6003/health -UseBasicParsing
```
6. В 1С:Предприятии открыть:
`X:\1C\NDC_1C\external\1c-mcp-toolkit\build\MCP_Toolkit.epf`
7. В форме выставить:
- режим: `Прокси`
- сервер: `http://127.0.0.1:6003`
- channel: `default`
- нажать `Подключиться`
## 6.2 Bootstrap аналитического контура (NDC_1C)
1. Подготовить проектную среду:
```powershell
cd X:\1C\NDC_1C
& 'C:\Users\<USER>\miniconda3\Scripts\conda.exe' create -y -n ndc_1c_mvp python=3.11
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_mvp\python.exe' -m pip install -r requirements.txt
copy .env.example .env
```
2. Настроить `.env` (минимум: `ONEC_INFOBASE`, `ONEC_USERNAME`, `ONEC_PASSWORD`).
3. Запустить API:
```powershell
& 'C:\Users\<USER>\miniconda3\envs\ndc_1c_mvp\python.exe' -m uvicorn canonical_layer.app:app --host 127.0.0.1 --port 8000 --reload
```
4. Запустить data-pipeline:
```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\run_refresh.ps1 -Mode incremental
powershell -ExecutionPolicy Bypass -File .\scripts\run_features.ps1 -Strict
powershell -ExecutionPolicy Bypass -File .\scripts\run_risk.ps1 -Strict
```
---
## 7. Операционный runbook (ежедневный цикл)
Старт:
1. Поднять bridge proxy и проверить `/health`.
2. Подключить `MCP_Toolkit.epf` в 1С.
3. Выполнить refresh -> features -> risk.
4. Проверить API/хранилища:
- `/store/stats`
- `/features/stats`
- `/risk/stats`
Стоп:
1. Отключить toolkit в 1С.
2. Закрыть 1С.
3. Остановить proxy/API (Ctrl+C).
---
## 8. Реально полученные результаты (фактические прогоны)
Ниже — выдержки из последних реальных прогонов (`logs/*.json`) на дату отчета.
## 8.1 Refresh (incremental)
Источник: `logs/refresh_last_run.json`
```json
{
"run_id": "7414d9b93c964b589bb863952a027f5e",
"mode": "incremental",
"status": "success",
"records_read": 4,
"entities_written": 4,
"links_written": 10,
"checkpoints_updated": 2
}
```
## 8.2 Feature engine
Источник: `logs/features_last_run.json`
```json
{
"run_id": "8c311e26916146579e97e110b2243a34",
"status": "success",
"entities_total": 2,
"metrics_written": 19,
"anomalies_written": 0
}
```
## 8.3 Risk engine
Источник: `logs/risk_last_run.json`
```json
{
"run_id": "fbad845fdfd64de8a73e35d4da6274e4",
"status": "success",
"patterns_written": 1,
"global_score": 0.05,
"risk_patterns": [
{
"pattern_key": "global_risk_summary",
"severity": "low"
}
]
}
```
## 8.4 Текущее состояние SQLite store (факт)
Снимок на момент отчета:
- `canonical_store.db` существует, размер `86016` байт
- `canonical_entities=2`
- `canonical_links=10`
- `refresh_runs=3`
- `refresh_checkpoints=2`
- `feature_runs=3`
- `feature_metrics=61`
- `anomaly_signals=0`
- `risk_runs=1`
- `risk_patterns=1`
## 8.5 Тестовый статус
Фактический запуск:
```text
python -m pytest -q
....... [100%]
7 passed in 1.86s
```
---
## 9. API-поверхность на текущем этапе
Реализованные endpoints:
- `GET /health`
- `GET /metadata/entity-sets`
- `GET /documents`
- `GET /documents/{document_id}`
- `GET /postings`
- `GET /counterparties/{counterparty_id}/documents`
- `GET /graph/document/{document_id}`
- `GET /store/stats`
- `GET /refresh/runs`
- `POST /refresh/run`
- `GET /features/stats`
- `GET /features/runs`
- `GET /features/metrics`
- `GET /features/anomalies`
- `POST /features/run`
- `GET /risk/stats`
- `GET /risk/runs`
- `GET /risk/patterns`
- `POST /risk/run`
---
## 10. Ограничения и интерпретация текущих цифр
1. Низкий текущий риск (`global_score=0.05`) и отсутствие аномалий отражают **малый текущий объем данных в store**, а не финальную “безрисковость” компании.
2. Stage 7 закрыт документно и по API-ready поверхности, но production-orchestration (policy engine + scheduler + retry orchestration) еще нужно реализовать отдельным сервисом.
3. SQLite используется как MVP-носитель; для прод-контуров нужен PostgreSQL + миграции + эксплуатационные политики.
---
## 11. Что осталось до “MVP production hardening”
1. Реализовать полноценный orchestration-service (Stage 7 runtime).
2. Добавить планировщик и регламенты (`refresh/features/risk`) с retry и алертингом.
3. Вынести store на PostgreSQL, добавить индексы/миграции.
4. Усилить auth/секреты/сетевые ограничения API.
5. Провести калибровку risk/feature правил на расширенном реальном срезе данных.
---
## 12. Итог
На дату **2026-03-23** архитектурный MVP-контур **Stage 1-7** зафиксирован как:
- Stage 1-6: реализованы и подтверждены фактическими прогонами;
- Stage 7: реализован на уровне спецификации и API-операций, но требует выделенного runtime orchestration для production-ready режима.
Проект технически готов к следующему шагу: **production-hardening + orchestration implementation**.
docs/ARCH/4 - AI_First_Layer_GUI_User_Manual_2026-03-23.md
+319
View File
@@ -0,0 +1,319 @@
# AI First Layer GUI — Подробный гайд пользователя
Дата: 23.03.2026
Контур: `X:\1C\NDC_1C\llm_normalizer`
Назначение: локальный GUI и backend для нормализации бухгалтерских запросов через OpenAI token
---
## 1. Что это за система
`AI First Layer GUI` — это не чат-бот с финальными бухгалтерскими ответами.
Это **semantic front-end**: слой, который переводит живой запрос бухгалтера в строгий структурированный JSON (`normalized_query_v1`), чтобы дальше этот JSON использовал deterministic router/оркестрация.
Цепочка:
`Пользователь -> GUI -> backend-proxy -> OpenAI Responses API -> normalized JSON -> route_hint summary -> trace/history`
---
## 2. Из чего состоит система
1. `frontend` (React + TypeScript + Vite) — русифицированный UI.
2. `backend` (Node.js + Express) — прокси к OpenAI, валидация схемы, trace/eval.
3. `data/traces` — история нормализаций.
4. `data/presets` — сохраненные prompt-пресеты.
5. `data/eval_cases` — eval-кейсы и отчеты.
---
## 3. Быстрый запуск
### 3.1 Рекомендуемый способ (из одной папки в VS Code)
Открой папку:
`X:\1C\NDC_1C\llm_normalizer`
Дальше:
1. `Terminal -> Run Task -> NDC: Install All` (первый запуск).
2. `Terminal -> Run Task -> NDC: Dev All (Backend + Frontend)`.
Открой:
- GUI: `http://localhost:5174`
- Backend health: `http://localhost:8787/api/health`
### 3.2 Терминалом (без Tasks)
```powershell
cd X:\1C\NDC_1C\llm_normalizer
start-dev.cmd
```
или:
```powershell
cd X:\1C\NDC_1C\llm_normalizer
npm.cmd run dev:all
```
---
## 4. Главный сценарий использования
1. В панели **Подключение OpenAI** вставь API key и проверь связь.
2. В панели **Prompt Manager** выбери/подгрузи preset или отредактируй prompt-ы вручную.
3. В панели **Запрос пользователя** вставь живой бухгалтерский вопрос.
4. Нажми `Normalize`.
5. Проверь результат во вкладках `Normalized JSON`, `Route hint summary`, `Validation`.
6. При необходимости сохрани кейс: `Normalize + Save as test case`.
7. Открой историю и сравни trace между попытками.
---
## 5. Подробно по каждому блоку GUI
## 5.1 Connection Panel (Подключение OpenAI)
### Поля
| Поле | Что вводить | Для чего |
|---|---|---|
| `OpenAI API Key` | реальный ключ формата `sk-...` | backend использует ключ для вызова Responses API |
| `Model ID` | обычно `gpt-4o-mini` | модель normalizer-а |
| `Base URL` | обычно `https://api.openai.com/v1` | endpoint OpenAI API |
| `Temperature` | чаще `0` или `0.1` | стабильность/вариативность нормализации |
| `Max output tokens` | обычно `500-900` | лимит длины ответа модели |
### Кнопки
| Кнопка | Что делает |
|---|---|
| `Сохранить локальную конфигурацию` | сохраняет в localStorage только model/baseUrl/temperature/maxOutputTokens (без API key) |
| `Проверить подключение` | вызывает `POST /api/openai/test-connection`, проверяет доступ к модели |
### Рекомендация на старт
- `Model ID`: `gpt-4o-mini`
- `Temperature`: `0`
- `Max output tokens`: `700`
---
## 5.2 Prompt Manager
Это управляемая prompt-архитектура из 3 уровней + служебные поля.
### Поля
| Поле | Что писать | Практический смысл |
|---|---|---|
| `Системный prompt` | жесткие правила поведения модели | запрещает модели давать финальный бизнес-ответ |
| `Developer / Instruction prompt` | правила классификации, flags, route_hint | задает “инженерную логику” нормализации |
| `Domain prompt` | словарь бухгалтерских формулировок/счетов/паттернов | повышает доменную точность |
| `Schema notes` | ограничения схемы, важные enum/required | снижает риск невалидного JSON |
| `Few-shot examples` | пары “вопрос -> ожидаемый JSON фрагмент” | стабилизирует поведение на сложных формулировках |
### Управление пресетами
| Элемент | Что делает |
|---|---|
| dropdown `Выберите preset` | список сохраненных пресетов + default |
| `Загрузить preset` | подставляет выбранные prompt-ы в поля |
| `Сохранить preset` | сохраняет текущие prompt-ы в `data/presets` |
| `Diff с предыдущим` | показывает текстовую дельту относительно последнего загруженного |
| `Сбросить к default` | возвращает дефолтный набор prompt-ов |
---
## 5.3 User Query Panel (Запрос пользователя)
### Поля
| Поле | Что вводить | Для чего |
|---|---|---|
| `Raw user question` | живой вопрос бухгалтера “как есть” | основной вход normalizer-а |
| `Optional period context` | период, если хочешь явно подсказать (`2020-06`) | стабилизирует `period_scope` |
| `Optional business context` | краткая доп. рамка (например “предзакрытие июня”) | помогает интерпретации |
| `Optional expected route` | ожидаемый route для проверки | используется в eval/trace |
### Переключатель
| Переключатель | Когда использовать |
|---|---|
| `Mock-режим (без вызова OpenAI)` | когда тестируешь UI/поток без токена и без внешних запросов |
### Кнопки
| Кнопка | Что делает |
|---|---|
| `Normalize` | запускает нормализацию и возвращает structured output |
| `Normalize + Save as test case` | дополнительно сохраняет кейс в `data/eval_cases` |
---
## 5.4 Output Panel (вкладки результата)
| Вкладка | Что показывает | Как использовать |
|---|---|---|
| `Normalized JSON` | итоговый валидированный JSON | основной артефакт для router |
| `Raw model output` | сырой ответ модели | диагностика prompt/schema проблем |
| `Route hint summary` | краткий срез intent/route/flags | быстрый контроль маршрутизации |
| `Validation` | статус schema validation и ошибки | сразу видно валиден ли контракт |
| `Logs` | клиентские события UI | оперативная диагностика шага |
---
## 5.5 Runtime Metrics Panel
Показывает:
- `trace_id`
- `request_started_at`
- `request_finished_at`
- `latency_ms`
- `input_tokens / output_tokens / total_tokens`
- `validation_status`
- `prompt_version`
- `schema_version`
Как читать:
1. `validation_status = passed` — можно использовать JSON в downstream пайплайне.
2. Если latency резко растет — обычно слишком длинный prompt/few-shot.
3. `total_tokens` нужен для контроля стоимости.
---
## 5.6 History Panel
Показывает список прошлых нормализаций:
- короткий вопрос,
- route hint,
- validation pass/fail,
- модель,
- timestamp.
Клик по записи открывает полный trace (`GET /api/history/:trace_id`) и подгружает данные в Output.
---
## 5.7 NDC Run Monitor
Это отдельный совместимый слой под будущую интеграцию в `dc_node`.
Что можно делать:
1. `Запустить run` -> `POST /api/accounting-agent/v1/runs/start`
2. `Завершить выбранный run` -> `POST /api/accounting-agent/v1/runs/finish`
3. Смотреть список `runs`, их статусы и trace выбранного `runId`.
Канон статусов:
`NONE`, `QUEUED`, `RUNNING`, `DONE`, `ERROR`, `STALE`, `CANCELLED`
---
## 6. Что и где сохраняется
| Данные | Где |
|---|---|
| Traces нормализации | `X:\1C\NDC_1C\llm_normalizer\data\traces` |
| Prompt presets | `X:\1C\NDC_1C\llm_normalizer\data\presets` |
| Eval cases / reports | `X:\1C\NDC_1C\llm_normalizer\data\eval_cases` |
Важно:
1. API key не сохраняется в localStorage.
2. API key не возвращается в frontend-ответах.
3. В trace ключ редактируется (redacted).
---
## 7. Как правильно заполнять поля на практике
## 7.1 Минимальный рабочий набор
1. `OpenAI API Key`: вставить валидный ключ.
2. `Model ID`: `gpt-4o-mini`.
3. `Raw user question`: живой вопрос.
4. Остальные поля оставить по default.
5. Нажать `Normalize`.
## 7.2 Если много ошибок в Validation
1. Уменьши свободу модели: `Temperature = 0`.
2. Уточни `Developer prompt` и `Schema notes`.
3. Добавь few-shot примеры под твой класс вопросов.
4. Повтори `Normalize` и сравни через `History`.
## 7.3 Если route_hint “плывет”
1. Явно добавь `expected route` в Query Panel.
2. В domain/developer prompt пропиши контр-примеры.
3. Сохрани новый preset и гони серию через `POST /api/eval/run`.
---
## 8. Частые проблемы и решения
| Симптом | Причина | Что делать |
|---|---|---|
| `Ошибка подключения` | ключ неверный/ограничен, неверный base URL | проверить key, model, URL через `Test connection` |
| `validation.passed = false` | модель вернула JSON вне схемы | ужесточить prompt, проверить schema notes, повторить |
| пустой `Normalized JSON` | parse/validation fail | смотреть `Raw model output` + `Validation` |
| высокая latency | слишком тяжелые prompt/few-shot | сократить prompt и few-shot |
| VS Code не стартует npm | PowerShell policy в Windows | использовать `npm.cmd` и готовые Tasks |
---
## 9. API-карта (для интеграции)
Normalizer:
- `POST /api/openai/test-connection`
- `POST /api/normalize`
- `POST /api/eval/run`
- `GET /api/history`
- `GET /api/history/:trace_id`
- `POST /api/presets/save`
- `GET /api/presets`
NDC Integration namespace:
- `POST /api/accounting-agent/v1/runs/start`
- `POST /api/accounting-agent/v1/runs/finish`
- `GET /api/accounting-agent/v1/runs`
- `GET /api/accounting-agent/v1/runs/:runId`
- `POST /api/accounting-agent/v1/tasks/enqueue`
- `POST /api/accounting-agent/v1/tasks/claim`
- `POST /api/accounting-agent/v1/tasks/:taskId/complete`
- `POST /api/accounting-agent/v1/tasks/:taskId/error`
- `GET /api/accounting-agent/v1/results`
- `GET /api/accounting-agent/v1/trace/run/:runId`
- `GET /api/accounting-agent/v1/health`
---
## 10. Чек-лист перед рабочей сессией
1. Backend и frontend подняты.
2. `Test connection` успешен.
3. Выбран корректный preset.
4. Запрос содержит минимум необходимого контекста (вопрос + период при необходимости).
5. После `Normalize` проверен `Validation`.
6. Trace сохранен и виден в History.
---
## 11. Главное правило эксплуатации
`LLM в этом контуре — нормализатор, а не исполнитель бизнес-логики.`
То есть:
1. LLM структурирует, классифицирует, предлагает route hint.
2. Финальные бухгалтерские выводы и оркестрация остаются в основном контуре NDC.
docs/ARCH/5 - assistant_mode_architecture_report_2026-03-24.md
+444
View File
@@ -0,0 +1,444 @@
# 5 - Assistant Mode Architecture Report (2026-03-24)
## 1. Статус этапа
Дата фиксации: **24 марта 2026**.
На текущем этапе реализован рабочий `Assistant Mode` поверх существующего `Decomposition` контура:
- decomposition/debug режим сохранен и не удален;
- добавлен отдельный backend endpoint для assistant-loop;
- добавлен слой `answer_composer` (human-readable ответ);
- добавлена session-scoped история диалога (in-memory);
- добавлен debug drawer в GUI по каждому assistant ответу;
- единый pipeline нормализации/маршрутизации используется для обоих режимов.
---
## 2. Что входит в текущую архитектуру
## 2.1 Backend
Ключевые узлы:
- `llm_normalizer/backend/src/routes/assistant.ts`
- `llm_normalizer/backend/src/services/assistantService.ts`
- `llm_normalizer/backend/src/services/answerComposer.ts`
- `llm_normalizer/backend/src/services/assistantSessionStore.ts`
- `llm_normalizer/backend/src/types/assistant.ts`
- `llm_normalizer/backend/src/services/routeHintAdapter.ts` (общий deterministic routing)
- `llm_normalizer/backend/src/services/normalizerService.ts` (общий normalizer pipeline)
Подключение в сервер:
- `llm_normalizer/backend/src/server.ts`
- `llm_normalizer/backend/src/serverContext.ts`
## 2.2 Frontend
Ключевые узлы:
- `llm_normalizer/frontend/src/App.tsx` (mode switch + orchestration)
- `llm_normalizer/frontend/src/components/AssistantPanel.tsx`
- `llm_normalizer/frontend/src/api/client.ts` (assistant API methods)
- `llm_normalizer/frontend/src/state/types.ts` (assistant типы состояния)
- `llm_normalizer/frontend/src/styles.css` (assistant/mode switch UI стиль)
---
## 3. Backend: функциональная архитектура
## 3.1 Endpoint’ы
### 3.1.1 POST `/api/assistant/message`
Назначение:
- принять user message;
- прогнать через normalizer pipeline;
- определить route/fallback;
- собрать human-readable assistant reply;
- вернуть reply + debug + session conversation snapshot.
Проверки:
- `user_message` обязателен;
- при пустом сообщении возвращается `INVALID_ASSISTANT_MESSAGE` (HTTP 400).
### 3.1.2 GET `/api/assistant/session/:session_id`
Назначение:
- вернуть текущую историю сессии из in-memory store.
Поведение:
- если сессия отсутствует: `ASSISTANT_SESSION_NOT_FOUND` (HTTP 404).
---
## 3.2 Контракт данных Assistant Mode
Типы заданы в:
- `llm_normalizer/backend/src/types/assistant.ts`
Ключевые сущности:
- `AssistantMessageRequestPayload`
- `AssistantDebugPayload`
- `AssistantConversationItem`
- `AssistantMessageResponsePayload`
`fallback_type` (жестко зафиксированный набор):
- `none`
- `out_of_scope`
- `clarification`
- `partial`
- `unknown`
---
## 3.3 Session memory
Реализовано в:
- `llm_normalizer/backend/src/services/assistantSessionStore.ts`
Характеристики:
- хранилище: in-memory `Map<session_id, session_state>`;
- auto-create сессии при первом сообщении;
- ограничение длины: `MAX_ITEMS_PER_SESSION = 200`;
- хранение только в рамках текущего backend процесса;
- при рестарте backend память очищается.
Это deliberate решение текущего этапа (sandbox/stage), без persistent storage.
---
## 3.4 Assistant pipeline (внутренний flow)
Реализовано в:
- `llm_normalizer/backend/src/services/assistantService.ts`
Порядок выполнения:
1. `ensureSession` -> получаем/создаем `session_id`.
2. Сохраняем user message как conversation item (`role=user`).
3. Формируем `NormalizeRequestPayload` с:
- `promptVersion` по умолчанию `normalizer_v2_0_2`,
- connection/prompt/context/useMock из запроса.
4. Вызываем `normalizerService.normalize(...)`.
5. По `route_hint_summary` строим retrieval plan (`buildRetrievalPlan`).
6. Передаем данные в `composeAssistantAnswer(...)`.
7. Формируем `debug` payload:
- `trace_id`,
- `route_summary`,
- `fragments`,
- `retrieval`,
- `normalized`.
8. Сохраняем assistant message как conversation item (`role=assistant`).
9. Логируем structured event `assistant_message_processed`.
10. Возвращаем:
- `assistant_reply`,
- `conversation_item`,
- `debug`,
- `conversation`.
---
## 3.5 Routing rules (общий deterministic v2 engine)
Основные правила маршрутизации берутся из:
- `llm_normalizer/backend/src/services/routeHintAdapter.ts`
Правила выбора маршрута:
1. `live_mcp_drilldown`
- если `asks_for_exact_object_trace = true`.
2. `batch_refresh_then_store`
- если `asks_for_ranking_or_top = true` **или** `asks_for_period_summary = true`.
3. `hybrid_store_plus_live`
- если `has_multi_entity_scope = true` и `asks_for_chain_explanation = true`.
4. `store_feature_risk`
- если `asks_for_rule_check = true` и не chain;
- также anomaly path: `asks_for_anomaly_scan = true` без ranking и без multi-entity chain.
5. `store_canonical`
- default routed путь для in-scope, если нет более сильного сигнала.
6. `no_route`
- если fragment out-of-scope / insufficient specificity / missing mapping / unsupported fragment type.
Fallback type в summary:
- `out_of_scope` — сообщение вне контура;
- `clarification` — нет routable in-scope fragment’ов из-за недоспецификации;
- `partial` — часть in-scope/routed, часть no-route/out-of-scope;
- `none` — все ок для текущего контура.
---
## 3.6 Answer composer rules
Реализовано в:
- `llm_normalizer/backend/src/services/answerComposer.ts`
Логика:
1. `out_of_scope`
- вежливый boundary response (работа только по company-specific accounting contour).
2. `clarification`
- конкретный уточняющий ответ: период/счет/документ/контрагент.
3. `partial`
- сообщает, что обработана только часть запроса;
- выводит routed части;
- явно фиксирует sandbox retrieval mode.
4. `none`
- human-readable summary с перечислением planned routes.
5. `unknown`
- защитный fallback, если routed items не сформированы.
Важно:
- на этом этапе composer формирует **человеко-читаемый operational ответ**;
- это не финальный production-grade semantic answer over full live retrieval.
---
## 3.7 Retrieval слой (текущий статус)
Текущее состояние: **stubbed / sandbox retrieval plan**.
Что есть:
- генерация плана “что и по какому route исполнять”;
- диагностический payload по fragment’ам.
Чего пока нет:
- боевой deep retrieval из 1С по всем route;
- гарантированного factual grounding для каждого ответа assistant mode.
---
## 3.8 Логирование и трассировка
В `assistantService` пишется structured log c событием:
- `assistant_message_processed`
Поля:
- `session_id`
- `message_id`
- `user_message`
- `normalizer_output`
- `resolved_execution_state`
- `routes`
- `fallback_type`
- `retrieval_payloads`
- `assistant_reply`
- `trace_id`
Это дает базу для будущего field-eval hardening.
---
## 4. Frontend: функциональная архитектура
## 4.1 Режимы UI
Реализовано в:
- `llm_normalizer/frontend/src/App.tsx`
Есть явный переключатель:
- `Assistant`
- `Decomposition`
Поведение:
- backend pipeline общий;
- UI-представление разное;
- decomposition stack не ломается и остается доступным.
---
## 4.2 Assistant Mode UI состав
Реализовано в:
- `llm_normalizer/frontend/src/components/AssistantPanel.tsx`
Элементы:
1. Chat timeline:
- user/assistant messages,
- timestamp,
- trace id для assistant сообщений.
2. Input зона:
- поле сообщения,
- send,
- reset session.
3. Контекст:
- `periodHint`
- `businessContext`
4. Toggle:
- `useMock`.
5. Debug drawer:
- раскрывается per assistant message,
- показывает raw debug JSON (`trace/fragments/routes/fallback/retrieval/normalized`).
---
## 4.3 Pipeline progress UX
Во время обработки показывается этапный status ticker:
1. `Razbirayu zapros`
2. `Proveryayu kontur`
3. `Opredelyayu marshrut`
4. `Ishchu dannye`
5. `Sobirayu otvet`
Цель: убрать ощущение “зависло” и визуализировать pipeline.
---
## 4.4 Frontend state flow
Ключевые state переменные:
- `uiMode`
- `assistantSessionId`
- `assistantConversation`
- `assistantInput`
- `assistantBusy`
- `assistantStatus`
- `assistantError`
Flow отправки:
1. optimistic append user message в chat;
2. запуск status ticker;
3. вызов `apiClient.sendAssistantMessage(...)`;
4. обновление `session_id` и полной conversation с backend;
5. остановка ticker + финальный статус.
---
## 4.5 API client для Assistant
Реализовано в:
- `llm_normalizer/frontend/src/api/client.ts`
Добавлены методы:
- `sendAssistantMessage(...)` -> `POST /api/assistant/message`
- `loadAssistantSession(sessionId)` -> `GET /api/assistant/session/:id`
---
## 5. Что сделано по требованиям ТЗ (mapping)
1. `docs/assistant_mode_spec.md` — выполнено
2. GUI с переключателем `Assistant` / `Decomposition` — выполнено
3. backend endpoint assistant loop — выполнено
4. `answer_composer` слой — выполнено
5. session-based chat history — выполнено (in-memory)
6. debug drawer/expandable technical view — выполнено
7. `docs/assistant_mode_flow.md` — выполнено
8. `docs/known_limits_before_field_eval.md` — выполнено
---
## 6. Критические ограничения текущей реализации
1. **retrieval sandbox/stubbed**
- assistant выдает план/маршрут, не full factual extraction по всем route.
2. **session memory volatile**
- хранится только в памяти backend процесса.
3. **нет production hardening**
- auth/tenancy/persistence/SLO не включены.
4. **composer базовый**
- достаточен для MVP loop, но не финальный policy-grade layer.
---
## 7. Запуск и проверка на новой машине (текущий этап)
## 7.1 Backend
```powershell
cd X:\1C\NDC_1C\llm_normalizer\backend
npm install
npm run dev
```
## 7.2 Frontend
```powershell
cd X:\1C\NDC_1C\llm_normalizer\frontend
npm install
npm run dev
```
## 7.3 Открыть GUI
- `http://localhost:5174`
## 7.4 Smoke test Assistant Mode
1. Переключить mode -> `Assistant`.
2. Ввести сообщение в чат.
3. Нажать `Send`.
4. Проверить:
- появился assistant reply;
- появился trace id;
- открывается debug drawer;
- session сохраняет историю.
---
## 8. Тестовый статус к моменту фиксации
Проверки выполнены 24.03.2026:
- backend tests: `npm test` -> **21 passed**
- backend build: `npm run build` -> **OK**
- frontend build: `npm run build` -> **OK**
Также добавлен endpoint test:
- `llm_normalizer/backend/tests/assistantEndpoint.test.ts`
Покрывает:
- успешный `POST /api/assistant/message`;
- session continuity;
- `GET /api/assistant/session/:session_id`.
---
## 9. Архитектурный итог этапа
Текущий Assistant Mode — это уже **usable dialog loop**:
- user-friendly вход (чат),
- deterministic decomposition/routing ядро,
- единый backend pipeline,
- прозрачная debug-плоскость для инженерной диагностики,
- session-based continuity в рамках процесса.
Для перехода в следующий уровень (field-hardened assistant) нужен следующий блок:
- подключение route-specific factual retrieval,
- сбор 30–40 реальных полевых запросов,
- policy hardening по traces (clarification/no-route/partial quality).
docs/ARCH/6_global_report/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md
+679
View File
@@ -0,0 +1,679 @@
# Assistant Mode Global Status Report
Date: 2026-03-24
Scope: `llm_normalizer` + Assistant Mode pipeline + retrieval/explainability contours
Prepared for: architectural checkpoint and next-step planning
## 0) Executive Summary
Current system is no longer a raw route demo: we now have a working end-to-end assistant loop with decomposition, routing, retrieval, grounding, explainable response shaping, session logging, and regression tests.
At the same time, the system is still not a full accountant-grade investigation assistant. Main reason: data/model/retrieval unit depth is still below causal accounting reasoning depth in several domains.
Key status snapshot:
- Backend build/tests: `tsc` OK, `vitest` OK (`25/25` tests passed).
- Explainable contract: implemented (`requirements`, `coverage_report`, `answer_grounding_check`, explainable reply sections).
- Retrieval-layer upgrade: `executeHybrid` moved from `GUID-or-full-scan` to semantic profile + semantic narrowing.
- Proven narrowing example: for bank mismatch query with accounts `51/60`, narrowing reduced records from `262` to `75`.
- Proven limitation: for generic cross-entity chain query without explicit account scope, narrowing still wide (`262` to `242`), so answer quality can remain too broad.
---
## 1) Data Contour
### 1.1 How it works now
- Assistant retrieval reads local snapshot bundle from `docs/ARCH/2020экспорт`.
- Main files currently loaded in executor:
- `03_snapshot_fragment_problem_cases.json`
- `04_samples_SpisanieSRaschetnogoScheta.json`
- `05_samples_RealizaciyaTovarovUslug.json`
- `06_samples_PostuplenieTovarovUslug.json`
- `07_samples_DocumentJournals.json`
- `08_samples_NDS_registers.json`
- `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json`
- Data access is read-only snapshot, not live 1C state.
### 1.2 What works
- Documents/journals/register records are available with links and key attributes.
- Counterparty/document linkage and part of relation topology are usable.
- Enough depth exists for POC-level chain/risk analysis and explainable evidence pack.
### 1.3 Constraints
- Live truth is absent in assistant retrieval path (snapshot-only).
- Lifecycle/status semantics are incomplete and partly heuristic.
- Some accounting contexts are represented as flattened fields instead of normalized graph nodes.
### 1.4 What assistant cannot do because of this
- Guarantee real-time explanation of current accounting state.
- Reliably prove deep causal accounting chains in all domains (especially where lifecycle semantics are implicit).
### 1.5 Symptoms already seen in dialogs
- Repeated top entities across semantically different but broad queries.
- “Looks relevant” answers with weak differentiating evidence for some generic prompts.
### 1.6 Local changes needed
- Add richer field extraction/parsing from snapshot for account/document/lifecycle signals.
- Enforce tighter domain-specific filters for low-specificity queries.
### 1.7 Architectural changes needed
- Add live data bridge layer for on-demand truth check (hybrid snapshot + live drilldown).
- Add normalized accounting graph storage layer for causal traversal.
### 1.8 Priority
- `P0`: stronger retrieval constraints and lifecycle signal extraction.
- `P1`: live bridge for targeted verification.
- `P2`: full graph-backed data model.
---
## 2) Ontology / Domain Model Contour
### 2.1 How it works now
- Entity/relation semantics exist as retrieval profile vocabulary plus heuristic signal extraction.
- Domain labels include bank/suppliers/customers/VAT/fixed_assets/deferred_expense/period_close/settlements.
- Relation patterns include:
- `payment_to_settlement`
- `document_to_posting`
- `statement_to_document`
- `asset_card_to_depreciation`
- `deferred_expense_to_writeoff`
- `invoice_to_vat`
- `contract_to_documents`
- `receipt_to_stock_movement`
### 2.2 What works
- Query intent can be translated into semantic retrieval profile.
- Basic anomaly vocabulary exists and affects ranking/explanation.
### 2.3 Constraints
- No explicit ontology graph engine with typed nodes/edges and reasoning rules.
- Lifecycle model is heuristic (`created/posted/partially_linked/no_continuation/period_boundary`) rather than formal accounting state machine.
### 2.4 What assistant cannot do because of this
- Stable causal proofs for complex cross-domain reconciliation.
- Deterministic explanation of “why exactly this stage is broken” across all domains.
### 2.5 Symptoms
- Explanation can still be structurally correct but semantically generic.
- Retrieval unit can still drift toward “counterparty-heavy” answer shape.
### 2.6 Local changes needed
- Expand structured anomaly dictionary with accountant-facing defect classes.
- Promote lifecycle markers from heuristics to explicit modeled states where possible.
### 2.7 Architectural changes needed
- Build ontology/lifecycle core as first-class subsystem.
- Move from “labels on records” to “typed causal nodes and edges”.
### 2.8 Priority
- `P0`: anomaly taxonomy hardening + lifecycle schema hardening.
- `P1`: typed ontology graph.
- `P2`: rule engine over ontology.
---
## 3) Retrieval / Query Execution Contour
### 3.1 How it works now
- Deterministic routed executors:
- `store_feature_risk`
- `hybrid_store_plus_live`
- `batch_refresh_then_store`
- `store_canonical`
- `live_mcp_drilldown`
- `executeHybrid` now uses `semantic_retrieval_profile` and semantic narrowing when GUID is absent.
- Retrieval result now carries richer context in items and summary (`query_subject`, profile, ranking basis, narrowing metrics).
### 3.2 What works
- No hard fallback to pure full scan in hybrid path for non-GUID queries.
- Query with explicit accounting scope (`51/60`, wrong document closure) produces stronger narrowing and different ranking.
- Evidence pack is richer and usable by explainable answer layer.
### 3.3 Constraints
- Generic prompts without explicit scope can still produce wide narrowed sets.
- Retrieval top unit still often converges to counterparty-centric grouping.
- Not all routes have equal semantic depth.
### 3.4 What assistant cannot do because of this
- Consistently deliver problem-node-first output in every query class.
- Guarantee high differentiation for all semantically close prompts.
### 3.5 Symptoms
- For some queries, narrowing reduction is still modest (example `262 -> 242`).
- Answers can remain “good but broad”.
### 3.6 Local changes needed
- Tighten mandatory intersections for generic bank/cross-entity prompts.
- Add domain-specific minimum evidence thresholds before final top ranking.
### 3.7 Architectural changes needed
- Introduce explicit “problem cluster” retrieval unit.
- Add cross-branch retrieval policy (neighbor contour checks).
### 3.8 Priority
- `P0`: further narrowing hardening + anti-generic ranking guards.
- `P1`: problem-cluster retrieval unit.
- `P2`: multi-branch investigation retrieval policy.
---
## 4) LLM Layer and Decomposition Contour
### 4.1 How it works now
- Prompt/schema baseline: `normalizer_v2_0_2`.
- Deterministic v2 routing summary with fallback types.
- Requirements extraction + coverage report + dropped-intent tracking are implemented.
### 4.2 What works
- Route and execution readiness are explicit.
- Coverage and grounding diagnostics are available per turn.
- Route mismatch blocking is now less false-positive for non-critical contextual tokens.
### 4.3 Constraints
- Requirement extraction remains coarse in many cases (often 1 requirement per fragment).
- Transliteration/noisy mixed-language prompts still degrade in-scope detection.
### 4.4 What assistant cannot do because of this
- Fine-grained multi-requirement planning for complex accounting requests.
- Fully robust handling of colloquial/translit business language.
### 4.5 Symptoms
- Some translit prompts fall into `out_of_scope/clarification`.
- Partial semantic intent may be compressed in long multi-part prompts.
### 4.6 Local changes needed
- Expand language normalization and translit alias mapping before decomposition.
- Improve requirement extraction granularity inside one fragment.
### 4.7 Architectural changes needed
- Add dedicated semantic parser layer before normalizer for business-language canonicalization.
- Add requirement graph (instead of flat list) for planning/execution.
### 4.8 Priority
- `P0`: translit/business alias normalization.
- `P1`: requirement graph extraction.
- `P2`: adaptive decomposition policy.
---
## 5) Answer Synthesis / Explanation Contour
### 5.1 How it works now
- Reply types include:
- `factual_with_explanation`
- `partial_coverage`
- `clarification_required`
- `no_grounded_answer`
- `route_mismatch_blocked`
- others
- Response includes explainable sections: result, why included, selection basis, risk signs, business meaning, limitations, next step.
### 5.2 What works
- Core explainable contract is implemented and stable.
- Blocking logic prevents clearly mismatched subject answers.
### 5.3 Constraints
- Generic wording still appears when retrieval unit is broad.
- Explanations are still largely template-driven for some routes.
### 5.4 What assistant cannot do because of this
- Deliver fully case-unique accountant-level narratives in all scenarios.
### 5.5 Symptoms
- Two semantically close broad prompts may yield similar explanatory skeleton.
### 5.6 Local changes needed
- Route-specific explanation templates with stronger domain phrasing.
- Explicit “mechanism-of-failure” fields in retrieval result for composer.
### 5.7 Architectural changes needed
- Separate explanation planner from template renderer.
- Add accountant-facing narrative policy with domain lexicon packs.
### 5.8 Priority
- `P0`: route-specific explanation enrichment.
- `P1`: mechanism-level explanation fields.
- `P2`: explanation planner subsystem.
---
## 6) Memory / State / Session Continuity Contour
### 6.1 How it works now
- Session-scoped conversation state is persisted.
- One JSON file per session with turn-level human-readable + technical blocks.
### 6.2 What works
- Stable conversation history and replay.
- Explicit per-turn decomposition and response auditability.
### 6.3 Constraints
- No robust investigation state model (hypotheses/open checks/resolution graph).
- Context memory is conversational, not analytical.
### 6.4 What assistant cannot do because of this
- True multi-step investigative reasoning with hypothesis tracking.
### 6.5 Symptoms
- Follow-up can be coherent but not yet “investigation-driven”.
### 6.6 Local changes needed
- Add per-session `investigation_state` object (focus, active entities, open hypotheses, unresolved branches).
### 6.7 Architectural changes needed
- Add working-memory layer for research workflow, not only chat continuity.
### 6.8 Priority
- `P0`: investigation_state schema + persistence.
- `P1`: branch tracking and hypothesis status transitions.
- `P2`: multi-turn analytical planning engine.
---
## 7) Orchestration / Routing / Control Policy Contour
### 7.1 How it works now
- Deterministic routing with fallback (`none/out_of_scope/clarification/partial`).
- Linear execution plan per turn.
### 7.2 What works
- Clear route decisions and no-route reasons.
- Strong deterministic observability.
### 7.3 Constraints
- Mostly route-driven linear pipeline.
- Limited iterative branch exploration initiated by system policy.
### 7.4 What assistant cannot do because of this
- Automatically run neighbor contour verification when primary evidence is weak.
### 7.5 Symptoms
- Reasonable direct answers, but limited self-initiated investigation depth.
### 7.6 Local changes needed
- Introduce confidence-driven secondary retrieval triggers.
### 7.7 Architectural changes needed
- Orchestration policy engine with iterative reasoning loops and stop criteria.
### 7.8 Priority
- `P0`: confidence-based secondary checks.
- `P1`: branch exploration policy.
- `P2`: full investigation orchestrator.
---
## 8) Quality / Observability / Eval Contour
### 8.1 How it works now
- Structured runtime logs (stdout JSON).
- Trace storage and session logs.
- Regression tests for API behavior, grounding and retrieval semantics.
### 8.2 What works
- Technical observability is strong for current stage.
- Automated test baseline is green (`25/25`).
### 8.3 Constraints
- Limited accountant-utility evaluation metrics.
- No broad canonical scenario benchmark with decision-quality scoring.
### 8.4 What assistant cannot do because of this
- Provide hard quantitative proof of business usefulness across accounting domains.
### 8.5 Symptoms
- Technical success may still exceed practical user-perceived success.
### 8.6 Local changes needed
- Add eval metrics:
- retrieval differentiation rate
- generic explanation rate
- accountant actionability score
- false confidence rate
### 8.7 Architectural changes needed
- Build domain eval harness with canonical accounting scenarios and target outcomes.
### 8.8 Priority
- `P0`: metric instrumentation for practical usefulness.
- `P1`: canonical benchmark suite (bank/60/97/OS/VAT/period close/multi-intent/translit/follow-up).
- `P2`: continuous quality dashboard.
---
## 9) Evolutionary Architecture Contour
### 9.1 Missing pieces (high impact)
- Ontology graph core.
- Lifecycle engine.
- Problem-cluster retrieval unit.
- Investigation memory/state.
- Orchestration policy engine for iterative checks.
- Live verification bridge for source-of-truth escalation.
### 9.2 Current ceiling
- Without deeper ontology/lifecycle/state layers, system remains strong “explainable routed assistant”, but not full accountant investigation copilot.
### 9.3 Local vs architectural changes
- Local: better filters, better templates, more metrics, better parser.
- Architectural: graph model, lifecycle engine, investigation state, multi-step orchestrator.
### 9.4 Priority
- `P0`: finish semantic retrieval hardening + practical eval metrics + investigation_state baseline.
- `P1`: ontology/lifecycle formalization + problem-cluster retrieval.
- `P2`: iterative orchestrator + live verification framework.
---
## 10) Answers to 12 Mandatory Questions
1. What data reaches assistant and where detail is lost:
Data reaches from snapshot package with links/attributes; detail loss happens in flattening/grouping and lack of formal lifecycle semantics.
2. Full domain model exists:
Partially. Semantic labels and patterns exist, formal ontology graph does not.
3. Primary retrieval unit:
Mostly counterparty-grouped chain/risk clusters; not yet universal problem-node unit.
4. Real constraints and wide-scan risk:
Constraints now executed in hybrid semantic profile, but generic queries can still remain broad.
5. What LLM receives before answer:
Normalizer output + route summary + normalized retrieval payload + grounding/coverage diagnostics.
6. What is lost in decomposition:
Fine-grained multi-requirement structure can still compress; translit/noisy input can lose intent quality.
7. Why explanation still generic in places:
Broad retrieval unit + template-driven synthesis with limited mechanism-specific fields.
8. Can system explain mechanism (not only labels):
Partially. Better than before, still constrained by retrieval evidence depth.
9. Working state/memory for multi-step analysis:
Conversation memory exists; investigation memory model is missing.
10. Can system explore neighbor accounting branches automatically:
Not yet as policy standard; mostly linear route execution.
11. How usefulness is measured:
Technical pipeline quality is measured; accountant-facing utility metrics are not complete yet.
12. Missing architectural entities preventing next quality tier:
Ontology graph, lifecycle engine, problem-cluster unit, investigation state, iterative orchestration.
---
## 11) Current Phase Status (Condensed)
- Phase status: `Functional MVP+` (explainable routed assistant with semantic retrieval upgrade).
- Not yet: `Production accountant copilot`.
- Immediate gate to next phase: tighten broad-query narrowing + add practical accountant eval metrics + investigation state schema.
---
## 12) Recommended Next Step Pack
### P0 (next iteration)
- Tighten generic-query semantic narrowing in hybrid route.
- Add investigation state object in session model.
- Add practical eval metrics (differentiation/actionability/generic-rate).
### P1 (after P0 stabilization)
- Formalize ontology + lifecycle layers.
- Shift retrieval output from entity-heavy to problem-cluster-heavy for key domains.
### P2 (strategic)
- Add iterative orchestration with neighbor-branch verification.
- Add live source-of-truth verification path for high-confidence conclusions.
---
## 13) Data Loss Map (Source to LLM)
This section is the explicit loss map requested for architecture decisions.
| Source Layer | Current Internal Representation | Lost/Weakened Signals | Observable Assistant Symptom | Required Fix Layer |
|---|---|---|---|---|
| 1C document/journal/register snapshot record | flattened `SnapshotRecord` + heuristic signal extraction | formal business status transitions, typed lifecycle stage semantics | explanation can be structurally correct but semantically generic | lifecycle model + ontology graph |
| document + posting relation hints | relation pattern labels inferred by regex/rules | deterministic causal edge type and confidence | “close to right chain” answers without strict mechanism proof | typed relation graph + relation confidence |
| account hints from query and record fields | `account_scope` and inferred `account_context` arrays | strong account-role semantics (main vs side context) | broad retrieval if account scope is not explicit | account-role policy in retrieval profile |
| anomaly signs (`unknown links`, `zero guid`, etc.) | anomaly pattern tags (`missing_link`, `broken_lifecycle`, etc.) | accountant-grade defect class and business consequence mapping | same anomaly labels across semantically different defects | anomaly catalog and mapping engine |
| session chat turns | conversation list + turn log | investigation branch state and hypothesis state | follow-up can be coherent but not deeply investigative | investigation_state subsystem |
| snapshot-only truth | no guaranteed live verification step in assistant route | real-time status confirmation | high-quality but potentially stale conclusion in sensitive cases | live verification bridge |
### 13.1 Diagnostic implication
The dominant ceiling is not “weak wording” but “insufficiently structured causal context before synthesis”.
---
## 14) Query Class vs Required Architecture Depth
| User Query Class | Required Layers | Current Readiness | Ceiling Cause | Next Upgrade |
|---|---|---|---|---|
| simple factual object lookup | routing + canonical retrieval + basic grounding | medium/high | snapshot-only verification | optional live drilldown |
| anomaly ranking (one contour) | semantic profile + risk retrieval + explainable synthesis | medium | anomaly semantics still heuristic | anomaly catalog hardening |
| causal chain in one contour | relation patterns + chain retrieval + evidence pack | medium | retrieval unit still entity-heavy in broad prompts | problem-cluster unit |
| cross-domain reconciliation | ontology + lifecycle + neighbor branch policy | low/medium | no formal cross-domain causal graph | ontology graph + branch policy |
| period-close impact analysis | lifecycle + period-risk model + orchestration | low/medium | lifecycle model incomplete | lifecycle engine |
| multi-step investigation with follow-up | investigation_state + orchestration loops + hypothesis tracking | low | memory is conversational, not investigative | investigation mode layer |
| ambiguity-heavy/translit business language | semantic parser + alias normalization + decomposition guard | low/medium | parser limitations before routing | pre-normalization parser layer |
### 14.1 Decision implication
Prompt/model tuning alone cannot close low-readiness classes above; they are architecture-depth dependent.
---
## 15) Retrieval Unit Diagnosis (Core Bottleneck)
### 15.1 Current dominant unit
- Dominant unit in hybrid route is still often `counterparty group`, even after semantic narrowing.
### 15.2 Where this unit is acceptable
- quick ranking
- initial risk surfacing
- broad operational scanning
### 15.3 Where this unit breaks answer quality
- “what exactly is broken in chain”
- “closed by wrong document type”
- “which lifecycle stage is inconsistent”
- “what blocks period close and why”
### 15.4 Target retrieval units (must become first-class)
- `document_conflict`
- `broken_chain_segment`
- `lifecycle_anomaly_node`
- `unresolved_settlement_cluster`
- `period_risk_cluster`
- `cross_branch_inconsistency_cluster`
### 15.5 Transition plan
- Step 1 (`P0`): keep counterparty groups but add explicit `mechanism_of_failure` + `failed_expected_edge`.
- Step 2 (`P1`): introduce mixed-unit ranking (problem cluster first, entity second).
- Step 3 (`P2`): use problem-cluster as default answer unit for chain/anomaly/period-risk routes.
---
## 16) LLM Ceiling Boundaries (Not Solvable by Prompt Alone)
The following limitations remain even with stronger models/prompts unless architecture changes:
1. no formal lifecycle state machine on input -> model cannot produce deterministic lifecycle diagnosis;
2. no typed causal graph edges -> model cannot consistently prove mechanism, only infer plausible narrative;
3. entity-heavy retrieval unit -> model can explain “who is risky”, but not always “what exact mechanism broke”;
4. missing investigation_state -> model cannot reliably manage long hypothesis trees across turns;
5. no mandatory live verification gate -> model cannot guarantee real-time truth in high-stakes answers.
### 16.1 Governance rule
When limitations above are active, quality work must target data/model/orchestration layers first; LLM tuning is secondary.
---
## 17) Investigation Mode Specification (Required Next Architecture)
### 17.1 Minimal `investigation_state` schema
```json
{
"session_id": "asst-...",
"focus": {
"domain": "bank_settlements",
"period": "2020-06",
"primary_accounts": ["51", "60"]
},
"active_entities": [
{ "type": "counterparty", "id": "..." },
{ "type": "document", "id": "..." }
],
"open_hypotheses": [
{
"hypothesis_id": "H1",
"statement": "closure performed by wrong document type",
"status": "open",
"evidence_for": [],
"evidence_against": []
}
],
"branches": [
{
"branch_id": "B1",
"name": "bank->settlement",
"status": "in_progress",
"unresolved_reason": null
}
],
"resolved_findings": [],
"next_actions": []
}
```
### 17.2 Required branch lifecycle
- `open` -> `in_progress` -> `confirmed` or `rejected` -> `closed`
### 17.3 System-initiated branch rule (minimum)
If primary route confidence is high but mechanism evidence is weak, assistant should launch one neighbor branch check before final high-confidence conclusion.
---
## 18) Symptom to Root Cause to Required Layer
| Symptom | Root Cause | Required Layer |
|---|---|---|
| generic explanation despite “ok” reply | mechanism fields missing in retrieval payload | retrieval schema + answer planner |
| similar answers for broad prompts | weak semantic narrowing for low-specificity queries | retrieval policy |
| follow-up does not deepen analysis | no hypothesis/branch state | investigation_state |
| strong dependence on explicit account hints | weak semantic parser/ontology grounding | parser + ontology |
| lifecycle conclusions not stable | lifecycle semantics heuristic only | lifecycle engine |
| high confidence on snapshot-only route | no live verification gate | live verification bridge |
---
## 19) Value-Impact Roadmap (Decision Table)
| Change | Complexity | Quality Gain | Accountant Usefulness Gain | Multi-step Investigation Gain | Priority |
|---|---|---|---|---|---|
| tighten generic semantic narrowing | low/medium | high | high | medium | P0 |
| add `mechanism_of_failure` retrieval fields | medium | high | high | medium | P0 |
| add `investigation_state` persistence | medium | medium/high | high | high | P0 |
| add practical utility eval metrics | low/medium | medium | high | medium | P0 |
| formalize anomaly catalog | medium | medium/high | high | medium | P1 |
| ontology graph core | high | high | high | high | P1 |
| lifecycle engine | high | high | high | high | P1 |
| problem-cluster retrieval unit | high | high | high | high | P1 |
| iterative orchestration engine | high | high | high | very high | P2 |
| live verification bridge | high | medium/high | high | medium/high | P2 |
---
## 20) What Not To Do (Explicit Guardrails)
1. Do not attempt to solve mechanism-level quality only with prompt edits.
2. Do not treat richer wording as substitute for stronger retrieval unit.
3. Do not scale explanation templates without adding mechanism evidence fields.
4. Do not equate long conversation history with investigation_state.
5. Do not claim production-grade confidence without live verification path for critical answers.
docs/ARCH/6_global_report/Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md
+63
View File
@@ -0,0 +1,63 @@
# Assistant Mode Global Status Appendix
Date: 2026-03-24
## A) Verification Commands
```powershell
cd X:\1C\NDC_1C\llm_normalizer\backend
npm.cmd run build
npm.cmd run test
```
Observed result:
- TypeScript build: success
- Test suite: success (`25/25`)
## B) Retrieval Narrowing Evidence
### Case 1: bank mismatch with explicit account scope
- Session: `asst-FuRihiL5Bp`
- Query subject: `bank_settlement_mismatch`
- Source records: `262`
- Filtered after narrowing: `75`
- Semantic narrowing applied: `true`
### Case 2: generic cross-entity bank chain
- Session: `asst-j9spgqdY7k`
- Query subject: `cross_entity_breakage`
- Source records: `262`
- Filtered after narrowing: `242`
- Semantic narrowing applied: `true`
Interpretation:
- Semantic narrowing is active and effective for constrained accounting scope.
- Generic prompts still need stronger narrowing policy.
## C) Key Implementation Anchors
- Semantic profile contract and builder:
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
- Hybrid narrowing and enriched evidence pack:
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
- API regression test for semantic narrowing:
- `X:\1C\NDC_1C\llm_normalizer\backend\tests\assistantEndpoint.test.ts`
## D) v1.1 Report Reinforcement Checklist
All 4 requested reinforcements are now explicitly present in the main report:
1. Data-loss path map (`Source -> Internal -> Lost -> Symptom -> Fix layer`)
2. Query-class vs architecture-depth matrix
3. Dedicated retrieval-unit diagnosis block (current vs target units)
4. Investigation mode schema and control-policy baseline
Also added:
- symptom -> root cause -> required layer matrix
- value-impact roadmap table
- explicit “what not to do” guardrails
docs/ARCH/benchmark_creative_stress_run_2026-03-23.rar
BIN
View File
Binary file not shown.
docs/ARCH/benchmark_creative_stress_run_2026-03-23/benchmark_creative_stress_run_accounting_assistant_2026-03-23.json
+4905
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/benchmark_creative_stress_run_2026-03-23/benchmark_creative_stress_run_accounting_assistant_2026-03-23.md
+2869
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/benchmark_creative_stress_run_2026-03-23/benchmark_creative_stress_run_accounting_assistant_2026-03-23_subset15.json
+1895
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/benchmark_creative_stress_run_2026-03-23/benchmark_creative_stress_run_accounting_assistant_2026-03-23_subset15.md
+1101
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/router_orchestration_fix_report_2026-03-23.md
+93
View File
@@ -0,0 +1,93 @@
# Router / Orchestration Fix Report (2026-03-23)
## Scope completed
По `IN/TZ_Router_Orchestration_Fix.md` реализованы:
1. Query classifier v2 с decision flags.
2. Store sufficiency checker.
3. Explicit route guards.
4. Runtime batch handoff (`refresh_and_answer` job path).
5. Route decision logging для всех benchmark-вопросов.
6. Unit + integration-style tests по router-модулям.
7. Повторный validation-run на июньском semantic-v2 срезе.
## Implemented modules
Новые пакеты и файлы:
- `router/query_classifier.py`
- `router/store_sufficiency.py`
- `router/route_selector.py`
- `router/decision_log.py`
- `orchestration/batch_runtime.py`
Подключение в benchmark-runtime:
- `scripts/run_validation_accounting_analytics.py`
- orchestration policy расширена ссылками на runtime-router модули;
- добавлен `build_store_metadata(...)`;
- добавлен `build_benchmark_results_v2(...)`;
- добавлен batch handoff path для `batch_refresh_then_store`;
- добавлен export `route_decision_logs.json`.
## Tests
Добавлены тесты:
- `tests/test_router_decision_flags.py`
- `tests/test_store_sufficiency.py`
- `tests/test_route_guards.py`
- `tests/test_batch_runtime_handoff.py`
- `tests/test_router_benchmark_subset.py`
Статус:
- `python -m pytest -q` -> `31 passed`
## Validation run (router-fix)
Команда:
`python scripts/run_validation_accounting_analytics.py --snapshot-path logs/pre_report_snapshot_2020_2020-06_semantic_v2.json --output-dir docs/ARCH/validation_run_2026-03-23_router_fix --strict`
Выход:
- `docs/ARCH/validation_run_2026-03-23_router_fix/`
Ключевые результаты benchmark:
- `questions_total = 35`
- `route_mismatch_count = 1` (было 7)
- `degraded_answers_count = 0`
- `batch_route_count = 5` (было 0)
- `heavy_analytical mismatches = 0`
- `cross_entity mismatches = 0`
- `drilldown_explain mismatches = 0`
Единственный остаточный mismatch:
- `Q19` (`period_trend`): expected `store_feature_risk`, actual `batch_refresh_then_store`
Decision logs:
- `docs/ARCH/validation_run_2026-03-23_router_fix/route_decision_logs.json`
- покрытие логами: `35/35` вопросов.
## Acceptance criteria status
По целям ТЗ:
- `route_mismatch_count <= 2`: **done** (`1`)
- `heavy_analytical mismatches = 0`: **done**
- `cross_entity mismatches = 0`: **done**
- `drilldown_explain mismatches <= 1`: **done** (`0`)
- `batch_route_count > 0`: **done** (`5`)
- `degraded_answers_count = 0`: **done**
- decision logs for all 35: **done**
## Notes
1. Batch runtime path исполняется в-process через `orchestration.batch_runtime`, с job payload и run-id trace.
2. Refresh step в batch режиме сейчас gated (`allow_refresh_in_batch=False` для validation profile), чтобы не делать неконтролируемый live refresh в этом прогоне; при этом feature/risk handoff исполняется реально.
3. Следующий точечный шаг: опционально дотюнить classifier threshold для `Q19`, чтобы привести `route_mismatch_count` к `0`.
docs/ARCH/router_orchestration_fix_report_v2_2026-03-23.md
+35
View File
@@ -0,0 +1,35 @@
# Router / Orchestration Fix Report v2 (2026-03-23)
## Final tuning step
После первого router-fix прогона оставался 1 mismatch (`Q19`), где `period_trend` вопрос с формулировкой про аномалию уходил в batch.
Сделана точечная правка:
- `router/route_selector.py`
- heavy-guard теперь срабатывает по `needs_anomaly_summary` только если запрос не относится к trend/risk профилю (`not parsed_as_trend_or_risk`).
Добавлен тест:
- `tests/test_router_benchmark_subset.py::test_router_period_trend_anomaly_stays_feature_store`
## Verification
- `python -m pytest -q` -> `32 passed`
- Validation run:
- `python scripts/run_validation_accounting_analytics.py --snapshot-path logs/pre_report_snapshot_2020_2020-06_semantic_v2.json --output-dir docs/ARCH/validation_run_2026-03-23_router_fix_v2 --strict`
## Result metrics (router_fix_v2)
- `questions_total = 35`
- `route_mismatch_count = 0`
- `degraded_answers_count = 0`
- `heavy_analytical mismatches = 0`
- `cross_entity mismatches = 0`
- `drilldown_explain mismatches = 0`
- `batch_route_count = 4` (> 0, runtime path active)
## Artifacts
- `docs/ARCH/validation_run_2026-03-23_router_fix_v2/`
- `docs/ARCH/validation_run_2026-03-23_router_fix_v2/route_decision_logs.json`
docs/ARCH/setup.md
+51
View File
@@ -0,0 +1,51 @@
# Setup Guide
## 1. Install Miniconda (if missing)
```powershell
winget install -e --id Anaconda.Miniconda3 --source winget --accept-source-agreements --accept-package-agreements --silent
```
## 2. Create isolated environment
```powershell
$Conda = Join-Path $env:USERPROFILE "miniconda3\Scripts\conda.exe"
if (-not (Test-Path $Conda)) { $Conda = Join-Path $env:USERPROFILE "Miniconda3\Scripts\conda.exe" }
& $Conda create -y -n ndc_1c_mvp python=3.11
$EnvPython = Join-Path $env:USERPROFILE "miniconda3\envs\ndc_1c_mvp\python.exe"
if (-not (Test-Path $EnvPython)) { $EnvPython = Join-Path $env:USERPROFILE "Miniconda3\envs\ndc_1c_mvp\python.exe" }
& $EnvPython -m pip install -r requirements.txt
```
## 3. Configure environment variables
```powershell
copy .env.example .env
```
Set real values for:
- `ONEC_BASE_URL`
- `ONEC_INFOBASE`
- `ONEC_USERNAME`
- `ONEC_PASSWORD`
## 4. Run OData probe
```powershell
& $EnvPython -m odata_probe.fetch_metadata
& $EnvPython -m odata_probe.list_entity_sets
& $EnvPython -m odata_probe.probe_entities
& $EnvPython -m odata_probe.dump_sample_links
```
## 5. Run API
```powershell
& $EnvPython -m uvicorn canonical_layer.app:app --host 127.0.0.1 --port 8000 --reload
```
## Notes
- Project mode is read-only against 1C.
- For production, restrict OData role permissions to read-only.
- If OData is not published yet, probe scripts will fail by design and log the connectivity problem.
docs/ARCH/validation_run_2026-03-23/benchmark_final_verdict.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Final Verdict
## Verdict
`adopt_with_improvements`
## Key numbers
- Questions total: `35`
- Route mismatches: `7`
- Degraded answers: `0`
- Avg latency ms: `506.43`
- p95 latency ms: `1024.5`
## Recommendation
1. Fix ontology unknown mapping hotspots.
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
3. Implement full production orchestration runtime.
docs/ARCH/validation_run_2026-03-23/benchmark_questions_35.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Questions (35)
| ID | Class | Expected route | Question |
| --- | --- | --- | --- |
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
docs/ARCH/validation_run_2026-03-23/benchmark_route_analysis.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Route Analysis
- Total mismatches: `7`
## Route confusion matrix
- `batch_refresh_then_store` -> store_feature_risk:4
- `hybrid_store_plus_live` -> hybrid_store_plus_live:3, store_canonical:2
- `live_mcp_drilldown` -> hybrid_store_plus_live:1, live_mcp_drilldown:4
- `store_canonical` -> store_canonical:6
- `store_feature_risk` -> store_feature_risk:15
## Mismatch by class
| Class | Mismatch count |
| --- | --- |
| cross_entity | 2 |
| drilldown_explain | 1 |
| heavy_analytical | 4 |
docs/ARCH/validation_run_2026-03-23/benchmark_run_report.md
+38
View File
@@ -0,0 +1,38 @@
# Benchmark Run Report
## Aggregate statistics
| Metric | Value |
| --- | --- |
| questions_total | 35 |
| avg_latency_ms | 506.43 |
| median_latency_ms | 402 |
| p90_latency_ms | 941.4 |
| p95_latency_ms | 1024.5 |
| avg_context_size | 2162.51 |
| live_route_count | 8 |
| store_route_count | 27 |
| batch_route_count | 0 |
| route_mismatch_count | 7 |
| degraded_answers_count | 0 |
## Route distribution
| Route | Count |
| --- | --- |
| hybrid_store_plus_live | 4 |
| live_mcp_drilldown | 4 |
| store_canonical | 8 |
| store_feature_risk | 19 |
## Question class distribution
| Class | Count |
| --- | --- |
| ambiguous_fuzzy | 5 |
| anomaly_control | 5 |
| cross_entity | 5 |
| drilldown_explain | 5 |
| heavy_analytical | 5 |
| period_trend | 5 |
| simple_factual | 5 |
docs/ARCH/validation_run_2026-03-23/benchmark_run_results.json
+827
View File
@@ -0,0 +1,827 @@
{
"status": "success",
"slice_window_key": "2020-06",
"generated_at": "2026-03-23T09:28:12.312411+00:00",
"questions_total": 35,
"aggregate": {
"questions_total": 35,
"avg_latency_ms": 506.43,
"median_latency_ms": 402,
"p90_latency_ms": 941.4,
"p95_latency_ms": 1024.5,
"avg_context_size": 2162.51,
"live_route_count": 8,
"store_route_count": 27,
"batch_route_count": 0,
"route_mismatch_count": 7,
"degraded_answers_count": 0,
"route_distribution": {
"store_canonical": 8,
"live_mcp_drilldown": 4,
"hybrid_store_plus_live": 4,
"store_feature_risk": 19
},
"question_class_distribution": {
"simple_factual": 5,
"drilldown_explain": 5,
"cross_entity": 5,
"period_trend": 5,
"anomaly_control": 5,
"heavy_analytical": 5,
"ambiguous_fuzzy": 5
}
},
"results": [
{
"question_id": "Q01",
"question_text": "Сальдо счета 68.02 за июнь 2020?",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 332,
"planning_time_ms": 67,
"retrieval_time_ms": 129,
"response_generation_time_ms": 136,
"context_size": 1595,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q02",
"question_text": "Документ по номеру и его ссылка.",
"question_class": "simple_factual",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1020,
"planning_time_ms": 93,
"retrieval_time_ms": 740,
"response_generation_time_ms": 187,
"context_size": 2796,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q03",
"question_text": "Типовая проводка по реализации.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 338,
"planning_time_ms": 69,
"retrieval_time_ms": 131,
"response_generation_time_ms": 138,
"context_size": 1597,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q04",
"question_text": "Контрагент с максимумом оборота.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 341,
"planning_time_ms": 70,
"retrieval_time_ms": 132,
"response_generation_time_ms": 139,
"context_size": 1598,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q05",
"question_text": "Договоры топ-контрагента.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 344,
"planning_time_ms": 71,
"retrieval_time_ms": 133,
"response_generation_time_ms": 140,
"context_size": 1599,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q06",
"question_text": "Объясни сальдо через движения.",
"question_class": "drilldown_explain",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 819,
"planning_time_ms": 114,
"retrieval_time_ms": 524,
"response_generation_time_ms": 181,
"context_size": 2950,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q07",
"question_text": "Почему проводка на этот счет?",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1035,
"planning_time_ms": 98,
"retrieval_time_ms": 745,
"response_generation_time_ms": 192,
"context_size": 2801,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q08",
"question_text": "Цепочка документ -> проводки -> субконто.",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1038,
"planning_time_ms": 99,
"retrieval_time_ms": 746,
"response_generation_time_ms": 193,
"context_size": 2802,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q09",
"question_text": "Источник регистра для строки движения.",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 828,
"planning_time_ms": 117,
"retrieval_time_ms": 527,
"response_generation_time_ms": 184,
"context_size": 2953,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected live_mcp_drilldown, got hybrid_store_plus_live"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q10",
"question_text": "Почему выбрано это субконто3?",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1017,
"planning_time_ms": 92,
"retrieval_time_ms": 739,
"response_generation_time_ms": 186,
"context_size": 2795,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q11",
"question_text": "Свяжи документы покупателей и проводки.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 335,
"planning_time_ms": 68,
"retrieval_time_ms": 130,
"response_generation_time_ms": 137,
"context_size": 1596,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q12",
"question_text": "Свяжи контрагентов, договоры и проводки.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 338,
"planning_time_ms": 69,
"retrieval_time_ms": 131,
"response_generation_time_ms": 138,
"context_size": 1597,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q13",
"question_text": "Номенклатура, склад, обороты за июнь.",
"question_class": "cross_entity",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 341,
"planning_time_ms": 70,
"retrieval_time_ms": 132,
"response_generation_time_ms": 139,
"context_size": 1598,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q14",
"question_text": "Регистр и первичный документ.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 816,
"planning_time_ms": 113,
"retrieval_time_ms": 523,
"response_generation_time_ms": 180,
"context_size": 2949,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q15",
"question_text": "По счету: контрагенты и договоры.",
"question_class": "cross_entity",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 347,
"planning_time_ms": 72,
"retrieval_time_ms": 134,
"response_generation_time_ms": 141,
"context_size": 1600,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q16",
"question_text": "Обороты июня против мая.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 402,
"planning_time_ms": 85,
"retrieval_time_ms": 155,
"response_generation_time_ms": 162,
"context_size": 2101,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q17",
"question_text": "Недельные всплески в июне.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q18",
"question_text": "Кто дал резкий рост активности.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 408,
"planning_time_ms": 87,
"retrieval_time_ms": 157,
"response_generation_time_ms": 164,
"context_size": 2103,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q19",
"question_text": "Аномальный рост расходных операций?",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 411,
"planning_time_ms": 88,
"retrieval_time_ms": 158,
"response_generation_time_ms": 165,
"context_size": 2104,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q20",
"question_text": "Динамика НДС к соседним периодам.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 387,
"planning_time_ms": 80,
"retrieval_time_ms": 150,
"response_generation_time_ms": 157,
"context_size": 2096,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q21",
"question_text": "Нетипичные корреспонденции счетов.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 390,
"planning_time_ms": 81,
"retrieval_time_ms": 151,
"response_generation_time_ms": 158,
"context_size": 2097,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q22",
"question_text": "Незакрытые хвосты по расчетам.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 393,
"planning_time_ms": 82,
"retrieval_time_ms": 152,
"response_generation_time_ms": 159,
"context_size": 2098,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q23",
"question_text": "Дублирующиеся проводки.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 396,
"planning_time_ms": 83,
"retrieval_time_ms": 153,
"response_generation_time_ms": 160,
"context_size": 2099,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q24",
"question_text": "Пустые или странные субконто.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 399,
"planning_time_ms": 84,
"retrieval_time_ms": 154,
"response_generation_time_ms": 161,
"context_size": 2100,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q25",
"question_text": "Узлы с подозрительно большим degree.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 402,
"planning_time_ms": 85,
"retrieval_time_ms": 155,
"response_generation_time_ms": 162,
"context_size": 2101,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q26",
"question_text": "Полный риск-срез за июнь.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q27",
"question_text": "Рейтинг риск-счетов.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 408,
"planning_time_ms": 87,
"retrieval_time_ms": 157,
"response_generation_time_ms": 164,
"context_size": 2103,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q28",
"question_text": "Рейтинг риск-контрагентов.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 411,
"planning_time_ms": 88,
"retrieval_time_ms": 158,
"response_generation_time_ms": 165,
"context_size": 2104,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q29",
"question_text": "Baseline closed/open periods.",
"question_class": "heavy_analytical",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 414,
"planning_time_ms": 89,
"retrieval_time_ms": 159,
"response_generation_time_ms": 166,
"context_size": 2105,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q30",
"question_text": "Company anomaly summary.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 390,
"planning_time_ms": 81,
"retrieval_time_ms": 151,
"response_generation_time_ms": 158,
"context_size": 2097,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q31",
"question_text": "Что по налогам и рискам?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 393,
"planning_time_ms": 82,
"retrieval_time_ms": 152,
"response_generation_time_ms": 159,
"context_size": 2098,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q32",
"question_text": "Что странное в расходах?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 396,
"planning_time_ms": 83,
"retrieval_time_ms": 153,
"response_generation_time_ms": 160,
"context_size": 2099,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q33",
"question_text": "Самые рисковые контрагенты?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 399,
"planning_time_ms": 84,
"retrieval_time_ms": 154,
"response_generation_time_ms": 161,
"context_size": 2100,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q34",
"question_text": "Что с 68.02?",
"question_class": "ambiguous_fuzzy",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 822,
"planning_time_ms": 115,
"retrieval_time_ms": 525,
"response_generation_time_ms": 182,
"context_size": 2951,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q35",
"question_text": "Проверить документы июня.",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
}
]
}
docs/ARCH/validation_run_2026-03-23/llm_like_simulation_profile.md
+27
View File
@@ -0,0 +1,27 @@
# LLM-like Simulation Profile
Simulation mode: `4o-mini-like` (controlled emulation)
## Constraints
- Store-first retrieval policy.
- Compact planning and bounded context.
- Limited live calls for drill-down only.
- Avoid expensive heavy live scans.
## Route timing baseline (ms)
| Route | Planning | Retrieval | Generation | Context |
| --- | --- | --- | --- | --- |
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
| store_canonical | 70 | 170 | 130 | 1700 |
| store_feature_risk | 82 | 190 | 150 | 2200 |
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
## Active run context
- Slice window: `2020-06`
- Refresh latest run: `30b2a2da4d824e0b81c2fb263cb9b64b`
- Feature latest run: `2d2dc33e509e4f5681b64217673dad09`
- Risk latest run: `d4833f6aa39f4bb5b4897c3d48caa843`
docs/ARCH/validation_run_2026-03-23/ontology_mapping_audit.md
+50
View File
@@ -0,0 +1,50 @@
# Ontology & Mapping Audit
## Core metrics
| Metric | Value |
| --- | --- |
| entity_classes_total | 42 |
| covered_entity_classes | 33 |
| uncovered_entity_classes | 9 |
| relation_types_total | 1 |
| correctly_typed_relations | 1602 |
| unknown_relations | 1016 |
| conflicting_mappings_count | 0 |
| link_coverage_pct | 100.0 |
| semantic_coverage_pct | 61.1917 |
## Top problematic source entity types
| Source entity | Unknown relations |
| --- | --- |
| AccumulationRegister_НДСПредъявленный_RecordType | 130 |
| Document_СписаниеСРасчетногоСчета | 116 |
| DocumentJournal_ЖурналОпераций | 114 |
| AccumulationRegister_НДСЗаписиКнигиПродаж_RecordType | 92 |
| DocumentJournal_БанковскиеВыписки | 90 |
| DocumentJournal_ДокументыПоставщиков | 90 |
| Document_РеализацияТоваровУслуг | 60 |
| Document_ПоступлениеТоваровУслуг | 50 |
| DocumentJournal_ДокументыПокупателей | 32 |
| AccumulationRegister_НДФЛРасчетыСБюджетом_RecordType | 28 |
| Document_СчетФактураВыданный | 25 |
| AccumulationRegister_НДСЗаписиКнигиПокупок_RecordType | 24 |
## Top problematic relation fields
| Source field | Unknown relations |
| --- | --- |
| Ответственный_Key | 187 |
| Ref | 168 |
| Recorder | 147 |
| Поставщик_Key | 78 |
| ФизЛицо_Key | 49 |
| Информация | 49 |
| Покупатель_Key | 46 |
| Валюта_Key | 34 |
| СтатьяДвиженияДенежныхСредств_Key | 34 |
| ПодразделениеДт_Key | 29 |
| ОбособленноеПодразделение_Key | 18 |
| Склад_Key | 16 |
docs/ARCH/validation_run_2026-03-23/orchestration_policy_spec.md
+37
View File
@@ -0,0 +1,37 @@
# Orchestration Policy Spec
## Decision tree
- exact object trace or posting chain -> `live_mcp_drilldown`
- simple factual in loaded slice -> `store_canonical`
- trend/anomaly/risk -> `store_feature_risk`
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
- low confidence fallback -> `hybrid_store_plus_live`
## Routing rules
- Prefer store answers when freshness allows.
- Use live bridge only for drill-down evidence.
- Do not run uncapped heavy live scans.
- Trigger refresh/features/risk for stale context.
- Apply retrieval/context budget before fallback.
## Source priorities
| Scenario | Priority order |
| --- | --- |
| simple_factual | canonical_store -> mcp_runtime_bridge |
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
| period_trend | feature_store -> risk_store -> canonical_store |
| anomaly_control | risk_store -> feature_store -> canonical_store |
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
## Timeout budget (ms)
| Budget | Value |
| --- | --- |
| planning | 200 |
| retrieval_soft_limit | 1200 |
| retrieval_hard_limit | 2500 |
| response_generation | 600 |
docs/ARCH/validation_run_2026-03-23/slice_ingestion_report.md
+20
View File
@@ -0,0 +1,20 @@
# Slice Ingestion Report
Validation date: 2026-03-23T09:28:12.311411+00:00
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
- Snapshot file: `X:\1C\NDC_1C\logs\pre_report_snapshot_2020_2020-06.json`
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
- Snapshot entities: `467`
- Snapshot links: `2618`
- Refresh run id: `30b2a2da4d824e0b81c2fb263cb9b64b`
- Entities written: `451`
- Links written: `2586`
- Checkpoints updated: `42`
- Canonical entities total: `453`
- Canonical links total: `2596`
- Feature run status: `success`
- Feature metrics written: `202`
- Risk run status: `success`
- Risk patterns written: `2`
- Risk global score: `0.608542`
docs/ARCH/validation_run_2026-03-23_router_fix/benchmark_final_verdict.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Final Verdict
## Verdict
`adopt_ready_for_pilot`
## Key numbers
- Questions total: `35`
- Route mismatches: `1`
- Degraded answers: `0`
- Avg latency ms: `705.63`
- p95 latency ms: `1571.9`
## Recommendation
1. Fix ontology unknown mapping hotspots.
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
3. Implement full production orchestration runtime.
docs/ARCH/validation_run_2026-03-23_router_fix/benchmark_questions_35.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Questions (35)
| ID | Class | Expected route | Question |
| --- | --- | --- | --- |
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
docs/ARCH/validation_run_2026-03-23_router_fix/benchmark_route_analysis.md
+17
View File
@@ -0,0 +1,17 @@
# Benchmark Route Analysis
- Total mismatches: `1`
## Route confusion matrix
- `batch_refresh_then_store` -> batch_refresh_then_store:4
- `hybrid_store_plus_live` -> hybrid_store_plus_live:5
- `live_mcp_drilldown` -> live_mcp_drilldown:5
- `store_canonical` -> store_canonical:6
- `store_feature_risk` -> batch_refresh_then_store:1, store_feature_risk:14
## Mismatch by class
| Class | Mismatch count |
| --- | --- |
| period_trend | 1 |
docs/ARCH/validation_run_2026-03-23_router_fix/benchmark_run_report.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Run Report
## Aggregate statistics
| Metric | Value |
| --- | --- |
| questions_total | 35 |
| avg_latency_ms | 705.63 |
| median_latency_ms | 405 |
| p90_latency_ms | 1562.0 |
| p95_latency_ms | 1571.9 |
| avg_context_size | 2435.37 |
| live_route_count | 10 |
| store_route_count | 20 |
| batch_route_count | 5 |
| route_mismatch_count | 1 |
| degraded_answers_count | 0 |
## Route distribution
| Route | Count |
| --- | --- |
| batch_refresh_then_store | 5 |
| hybrid_store_plus_live | 5 |
| live_mcp_drilldown | 5 |
| store_canonical | 6 |
| store_feature_risk | 14 |
## Question class distribution
| Class | Count |
| --- | --- |
| ambiguous_fuzzy | 5 |
| anomaly_control | 5 |
| cross_entity | 5 |
| drilldown_explain | 5 |
| heavy_analytical | 5 |
| period_trend | 5 |
| simple_factual | 5 |
docs/ARCH/validation_run_2026-03-23_router_fix/benchmark_run_results.json
+2452
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/validation_run_2026-03-23_router_fix/llm_like_simulation_profile.md
+27
View File
@@ -0,0 +1,27 @@
# LLM-like Simulation Profile
Simulation mode: `4o-mini-like` (controlled emulation)
## Constraints
- Store-first retrieval policy.
- Compact planning and bounded context.
- Limited live calls for drill-down only.
- Avoid expensive heavy live scans.
## Route timing baseline (ms)
| Route | Planning | Retrieval | Generation | Context |
| --- | --- | --- | --- | --- |
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
| store_canonical | 70 | 170 | 130 | 1700 |
| store_feature_risk | 82 | 190 | 150 | 2200 |
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
## Active run context
- Slice window: `2020-06`
- Refresh latest run: `6f6c622c254e4e79a86ccdbd140b1631`
- Feature latest run: `c1daa35506474be19331f21cf663282a`
- Risk latest run: `b167c610c8b84dd79ca0357e72422c7f`
docs/ARCH/validation_run_2026-03-23_router_fix/ontology_mapping_audit.md
+50
View File
@@ -0,0 +1,50 @@
# Ontology & Mapping Audit
## Core metrics
| Metric | Value |
| --- | --- |
| entity_classes_total | 42 |
| covered_entity_classes | 42 |
| uncovered_entity_classes | 0 |
| relation_types_total | 25 |
| correctly_typed_relations | 1909 |
| unknown_relations | 102 |
| conflicting_mappings_count | 1 |
| link_coverage_pct | 100.0 |
| semantic_coverage_pct | 94.9279 |
## Top problematic source entity types
| Source entity | Unknown relations |
| --- | --- |
| DocumentJournal_БанковскиеВыписки | 30 |
| DocumentJournal_ЖурналОпераций | 16 |
| Document_СписаниеСРасчетногоСчета | 14 |
| Document_РеализацияТоваровУслуг | 12 |
| Document_СчетФактураВыданный | 8 |
| Document_ОперацияБух | 5 |
| AccumulationRegister_СтраховыеВзносыСведенияОДоходах_RecordType | 4 |
| DocumentJournal_КассовыеДокументы | 4 |
| Document_РасходныйКассовыйОрдер | 4 |
| AccumulationRegister_НДФЛСведенияОДоходах_RecordType | 3 |
| AccumulationRegister_НДФЛПредоставленныеСтандартныеВычетыФизЛиц_RecordType | 1 |
| Document_СчетНаОплатуПокупателю | 1 |
## Top problematic relation fields
| Source field | Unknown relations |
| --- | --- |
| ВидОперации | 34 |
| Информация | 16 |
| СубконтоДт1 | 15 |
| Руководитель_Key | 8 |
| ГлавныйБухгалтер_Key | 8 |
| СпособЗаполнения | 5 |
| ВидДохода_Key | 4 |
| СтатьяДоходовИРасходовПоТаре_Key | 4 |
| КодДохода_Key | 3 |
| СубконтоДт2 | 3 |
| КодВычета_Key | 1 |
| СтруктурнаяЕдиница_Key | 1 |
docs/ARCH/validation_run_2026-03-23_router_fix/orchestration_policy_spec.md
+37
View File
@@ -0,0 +1,37 @@
# Orchestration Policy Spec
## Decision tree
- exact object trace or posting chain -> `live_mcp_drilldown`
- simple factual in loaded slice -> `store_canonical`
- trend/anomaly/risk -> `store_feature_risk`
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
- low confidence fallback -> `hybrid_store_plus_live`
## Routing rules
- Prefer store answers when freshness allows.
- Use live bridge only for drill-down evidence.
- Do not run uncapped heavy live scans.
- Trigger refresh/features/risk for stale context.
- Apply retrieval/context budget before fallback.
## Source priorities
| Scenario | Priority order |
| --- | --- |
| simple_factual | canonical_store -> mcp_runtime_bridge |
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
| period_trend | feature_store -> risk_store -> canonical_store |
| anomaly_control | risk_store -> feature_store -> canonical_store |
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
## Timeout budget (ms)
| Budget | Value |
| --- | --- |
| planning | 200 |
| retrieval_soft_limit | 1200 |
| retrieval_hard_limit | 2500 |
| response_generation | 600 |
docs/ARCH/validation_run_2026-03-23_router_fix/route_decision_logs.json
+1482
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/validation_run_2026-03-23_router_fix/slice_ingestion_report.md
+20
View File
@@ -0,0 +1,20 @@
# Slice Ingestion Report
Validation date: 2026-03-23T11:04:31.558207+00:00
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
- Snapshot file: `logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
- Snapshot entities: `409`
- Snapshot links: `2011`
- Refresh run id: `6f6c622c254e4e79a86ccdbd140b1631`
- Entities written: `409`
- Links written: `2011`
- Checkpoints updated: `42`
- Canonical entities total: `769`
- Canonical links total: `3700`
- Feature run status: `success`
- Feature metrics written: `202`
- Risk run status: `success`
- Risk patterns written: `2`
- Risk global score: `0.977351`
docs/ARCH/validation_run_2026-03-23_router_fix_v2/benchmark_final_verdict.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Final Verdict
## Verdict
`adopt_ready_for_pilot`
## Key numbers
- Questions total: `35`
- Route mismatches: `0`
- Degraded answers: `0`
- Avg latency ms: `672.4`
- p95 latency ms: `1568.9`
## Recommendation
1. Fix ontology unknown mapping hotspots.
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
3. Implement full production orchestration runtime.
docs/ARCH/validation_run_2026-03-23_router_fix_v2/benchmark_questions_35.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Questions (35)
| ID | Class | Expected route | Question |
| --- | --- | --- | --- |
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
docs/ARCH/validation_run_2026-03-23_router_fix_v2/benchmark_route_analysis.md
+17
View File
@@ -0,0 +1,17 @@
# Benchmark Route Analysis
- Total mismatches: `0`
## Route confusion matrix
- `batch_refresh_then_store` -> batch_refresh_then_store:4
- `hybrid_store_plus_live` -> hybrid_store_plus_live:5
- `live_mcp_drilldown` -> live_mcp_drilldown:5
- `store_canonical` -> store_canonical:6
- `store_feature_risk` -> store_feature_risk:15
## Mismatch by class
| Class | Mismatch count |
| --- | --- |
| n/a | 0 |
docs/ARCH/validation_run_2026-03-23_router_fix_v2/benchmark_run_report.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Run Report
## Aggregate statistics
| Metric | Value |
| --- | --- |
| questions_total | 35 |
| avg_latency_ms | 672.4 |
| median_latency_ms | 405 |
| p90_latency_ms | 1348.2 |
| p95_latency_ms | 1568.9 |
| avg_context_size | 2395.37 |
| live_route_count | 10 |
| store_route_count | 21 |
| batch_route_count | 4 |
| route_mismatch_count | 0 |
| degraded_answers_count | 0 |
## Route distribution
| Route | Count |
| --- | --- |
| batch_refresh_then_store | 4 |
| hybrid_store_plus_live | 5 |
| live_mcp_drilldown | 5 |
| store_canonical | 6 |
| store_feature_risk | 15 |
## Question class distribution
| Class | Count |
| --- | --- |
| ambiguous_fuzzy | 5 |
| anomaly_control | 5 |
| cross_entity | 5 |
| drilldown_explain | 5 |
| heavy_analytical | 5 |
| period_trend | 5 |
| simple_factual | 5 |
docs/ARCH/validation_run_2026-03-23_router_fix_v2/benchmark_run_results.json
+2437
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/validation_run_2026-03-23_router_fix_v2/llm_like_simulation_profile.md
+27
View File
@@ -0,0 +1,27 @@
# LLM-like Simulation Profile
Simulation mode: `4o-mini-like` (controlled emulation)
## Constraints
- Store-first retrieval policy.
- Compact planning and bounded context.
- Limited live calls for drill-down only.
- Avoid expensive heavy live scans.
## Route timing baseline (ms)
| Route | Planning | Retrieval | Generation | Context |
| --- | --- | --- | --- | --- |
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
| store_canonical | 70 | 170 | 130 | 1700 |
| store_feature_risk | 82 | 190 | 150 | 2200 |
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
## Active run context
- Slice window: `2020-06`
- Refresh latest run: `44b9881f29f343d7816b89ddf3e4a6ec`
- Feature latest run: `ce3a6385d6fd43f480ddf9b499c76e7a`
- Risk latest run: `0895566641a74a44adf19faa5dc4f385`
docs/ARCH/validation_run_2026-03-23_router_fix_v2/ontology_mapping_audit.md
+50
View File
@@ -0,0 +1,50 @@
# Ontology & Mapping Audit
## Core metrics
| Metric | Value |
| --- | --- |
| entity_classes_total | 42 |
| covered_entity_classes | 42 |
| uncovered_entity_classes | 0 |
| relation_types_total | 25 |
| correctly_typed_relations | 1909 |
| unknown_relations | 102 |
| conflicting_mappings_count | 1 |
| link_coverage_pct | 100.0 |
| semantic_coverage_pct | 94.9279 |
## Top problematic source entity types
| Source entity | Unknown relations |
| --- | --- |
| DocumentJournal_БанковскиеВыписки | 30 |
| DocumentJournal_ЖурналОпераций | 16 |
| Document_СписаниеСРасчетногоСчета | 14 |
| Document_РеализацияТоваровУслуг | 12 |
| Document_СчетФактураВыданный | 8 |
| Document_ОперацияБух | 5 |
| AccumulationRegister_СтраховыеВзносыСведенияОДоходах_RecordType | 4 |
| DocumentJournal_КассовыеДокументы | 4 |
| Document_РасходныйКассовыйОрдер | 4 |
| AccumulationRegister_НДФЛСведенияОДоходах_RecordType | 3 |
| AccumulationRegister_НДФЛПредоставленныеСтандартныеВычетыФизЛиц_RecordType | 1 |
| Document_СчетНаОплатуПокупателю | 1 |
## Top problematic relation fields
| Source field | Unknown relations |
| --- | --- |
| ВидОперации | 34 |
| Информация | 16 |
| СубконтоДт1 | 15 |
| Руководитель_Key | 8 |
| ГлавныйБухгалтер_Key | 8 |
| СпособЗаполнения | 5 |
| ВидДохода_Key | 4 |
| СтатьяДоходовИРасходовПоТаре_Key | 4 |
| КодДохода_Key | 3 |
| СубконтоДт2 | 3 |
| КодВычета_Key | 1 |
| СтруктурнаяЕдиница_Key | 1 |
docs/ARCH/validation_run_2026-03-23_router_fix_v2/orchestration_policy_spec.md
+37
View File
@@ -0,0 +1,37 @@
# Orchestration Policy Spec
## Decision tree
- exact object trace or posting chain -> `live_mcp_drilldown`
- simple factual in loaded slice -> `store_canonical`
- trend/anomaly/risk -> `store_feature_risk`
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
- low confidence fallback -> `hybrid_store_plus_live`
## Routing rules
- Prefer store answers when freshness allows.
- Use live bridge only for drill-down evidence.
- Do not run uncapped heavy live scans.
- Trigger refresh/features/risk for stale context.
- Apply retrieval/context budget before fallback.
## Source priorities
| Scenario | Priority order |
| --- | --- |
| simple_factual | canonical_store -> mcp_runtime_bridge |
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
| period_trend | feature_store -> risk_store -> canonical_store |
| anomaly_control | risk_store -> feature_store -> canonical_store |
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
## Timeout budget (ms)
| Budget | Value |
| --- | --- |
| planning | 200 |
| retrieval_soft_limit | 1200 |
| retrieval_hard_limit | 2500 |
| response_generation | 600 |
docs/ARCH/validation_run_2026-03-23_router_fix_v2/route_decision_logs.json
+1480
View File
File diff suppressed because it is too large Load Diff
docs/ARCH/validation_run_2026-03-23_router_fix_v2/slice_ingestion_report.md
+20
View File
@@ -0,0 +1,20 @@
# Slice Ingestion Report
Validation date: 2026-03-23T11:09:29.880582+00:00
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
- Snapshot file: `logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
- Snapshot entities: `409`
- Snapshot links: `2011`
- Refresh run id: `44b9881f29f343d7816b89ddf3e4a6ec`
- Entities written: `409`
- Links written: `2011`
- Checkpoints updated: `42`
- Canonical entities total: `769`
- Canonical links total: `3700`
- Feature run status: `success`
- Feature metrics written: `202`
- Risk run status: `success`
- Risk patterns written: `2`
- Risk global score: `0.977351`
docs/ARCH/validation_run_2026-03-23_semantic_v2/benchmark_final_verdict.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Final Verdict
## Verdict
`adopt_with_improvements`
## Key numbers
- Questions total: `35`
- Route mismatches: `7`
- Degraded answers: `0`
- Avg latency ms: `506.43`
- p95 latency ms: `1024.5`
## Recommendation
1. Fix ontology unknown mapping hotspots.
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
3. Implement full production orchestration runtime.
docs/ARCH/validation_run_2026-03-23_semantic_v2/benchmark_questions_35.md
+39
View File
@@ -0,0 +1,39 @@
# Benchmark Questions (35)
| ID | Class | Expected route | Question |
| --- | --- | --- | --- |
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
docs/ARCH/validation_run_2026-03-23_semantic_v2/benchmark_route_analysis.md
+19
View File
@@ -0,0 +1,19 @@
# Benchmark Route Analysis
- Total mismatches: `7`
## Route confusion matrix
- `batch_refresh_then_store` -> store_feature_risk:4
- `hybrid_store_plus_live` -> hybrid_store_plus_live:3, store_canonical:2
- `live_mcp_drilldown` -> hybrid_store_plus_live:1, live_mcp_drilldown:4
- `store_canonical` -> store_canonical:6
- `store_feature_risk` -> store_feature_risk:15
## Mismatch by class
| Class | Mismatch count |
| --- | --- |
| cross_entity | 2 |
| drilldown_explain | 1 |
| heavy_analytical | 4 |
docs/ARCH/validation_run_2026-03-23_semantic_v2/benchmark_run_report.md
+38
View File
@@ -0,0 +1,38 @@
# Benchmark Run Report
## Aggregate statistics
| Metric | Value |
| --- | --- |
| questions_total | 35 |
| avg_latency_ms | 506.43 |
| median_latency_ms | 402 |
| p90_latency_ms | 941.4 |
| p95_latency_ms | 1024.5 |
| avg_context_size | 2162.51 |
| live_route_count | 8 |
| store_route_count | 27 |
| batch_route_count | 0 |
| route_mismatch_count | 7 |
| degraded_answers_count | 0 |
## Route distribution
| Route | Count |
| --- | --- |
| hybrid_store_plus_live | 4 |
| live_mcp_drilldown | 4 |
| store_canonical | 8 |
| store_feature_risk | 19 |
## Question class distribution
| Class | Count |
| --- | --- |
| ambiguous_fuzzy | 5 |
| anomaly_control | 5 |
| cross_entity | 5 |
| drilldown_explain | 5 |
| heavy_analytical | 5 |
| period_trend | 5 |
| simple_factual | 5 |
docs/ARCH/validation_run_2026-03-23_semantic_v2/benchmark_run_results.json
+827
View File
@@ -0,0 +1,827 @@
{
"status": "success",
"slice_window_key": "2020-06",
"generated_at": "2026-03-23T10:22:58.317178+00:00",
"questions_total": 35,
"aggregate": {
"questions_total": 35,
"avg_latency_ms": 506.43,
"median_latency_ms": 402,
"p90_latency_ms": 941.4,
"p95_latency_ms": 1024.5,
"avg_context_size": 2162.51,
"live_route_count": 8,
"store_route_count": 27,
"batch_route_count": 0,
"route_mismatch_count": 7,
"degraded_answers_count": 0,
"route_distribution": {
"store_canonical": 8,
"live_mcp_drilldown": 4,
"hybrid_store_plus_live": 4,
"store_feature_risk": 19
},
"question_class_distribution": {
"simple_factual": 5,
"drilldown_explain": 5,
"cross_entity": 5,
"period_trend": 5,
"anomaly_control": 5,
"heavy_analytical": 5,
"ambiguous_fuzzy": 5
}
},
"results": [
{
"question_id": "Q01",
"question_text": "Сальдо счета 68.02 за июнь 2020?",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 332,
"planning_time_ms": 67,
"retrieval_time_ms": 129,
"response_generation_time_ms": 136,
"context_size": 1595,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q02",
"question_text": "Документ по номеру и его ссылка.",
"question_class": "simple_factual",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1020,
"planning_time_ms": 93,
"retrieval_time_ms": 740,
"response_generation_time_ms": 187,
"context_size": 2796,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q03",
"question_text": "Типовая проводка по реализации.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 338,
"planning_time_ms": 69,
"retrieval_time_ms": 131,
"response_generation_time_ms": 138,
"context_size": 1597,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q04",
"question_text": "Контрагент с максимумом оборота.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 341,
"planning_time_ms": 70,
"retrieval_time_ms": 132,
"response_generation_time_ms": 139,
"context_size": 1598,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q05",
"question_text": "Договоры топ-контрагента.",
"question_class": "simple_factual",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 344,
"planning_time_ms": 71,
"retrieval_time_ms": 133,
"response_generation_time_ms": 140,
"context_size": 1599,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q06",
"question_text": "Объясни сальдо через движения.",
"question_class": "drilldown_explain",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 819,
"planning_time_ms": 114,
"retrieval_time_ms": 524,
"response_generation_time_ms": 181,
"context_size": 2950,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q07",
"question_text": "Почему проводка на этот счет?",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1035,
"planning_time_ms": 98,
"retrieval_time_ms": 745,
"response_generation_time_ms": 192,
"context_size": 2801,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q08",
"question_text": "Цепочка документ -> проводки -> субконто.",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1038,
"planning_time_ms": 99,
"retrieval_time_ms": 746,
"response_generation_time_ms": 193,
"context_size": 2802,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q09",
"question_text": "Источник регистра для строки движения.",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 828,
"planning_time_ms": 117,
"retrieval_time_ms": 527,
"response_generation_time_ms": 184,
"context_size": 2953,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected live_mcp_drilldown, got hybrid_store_plus_live"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q10",
"question_text": "Почему выбрано это субконто3?",
"question_class": "drilldown_explain",
"expected_route": "live_mcp_drilldown",
"actual_route": "live_mcp_drilldown",
"sources_used": [
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 1017,
"planning_time_ms": 92,
"retrieval_time_ms": 739,
"response_generation_time_ms": 186,
"context_size": 2795,
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q11",
"question_text": "Свяжи документы покупателей и проводки.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 335,
"planning_time_ms": 68,
"retrieval_time_ms": 130,
"response_generation_time_ms": 137,
"context_size": 1596,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q12",
"question_text": "Свяжи контрагентов, договоры и проводки.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 338,
"planning_time_ms": 69,
"retrieval_time_ms": 131,
"response_generation_time_ms": 138,
"context_size": 1597,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q13",
"question_text": "Номенклатура, склад, обороты за июнь.",
"question_class": "cross_entity",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 341,
"planning_time_ms": 70,
"retrieval_time_ms": 132,
"response_generation_time_ms": 139,
"context_size": 1598,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q14",
"question_text": "Регистр и первичный документ.",
"question_class": "cross_entity",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 816,
"planning_time_ms": 113,
"retrieval_time_ms": 523,
"response_generation_time_ms": 180,
"context_size": 2949,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q15",
"question_text": "По счету: контрагенты и договоры.",
"question_class": "cross_entity",
"expected_route": "store_canonical",
"actual_route": "store_canonical",
"sources_used": [
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 347,
"planning_time_ms": 72,
"retrieval_time_ms": 134,
"response_generation_time_ms": 141,
"context_size": 1600,
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q16",
"question_text": "Обороты июня против мая.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 402,
"planning_time_ms": 85,
"retrieval_time_ms": 155,
"response_generation_time_ms": 162,
"context_size": 2101,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q17",
"question_text": "Недельные всплески в июне.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q18",
"question_text": "Кто дал резкий рост активности.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 408,
"planning_time_ms": 87,
"retrieval_time_ms": 157,
"response_generation_time_ms": 164,
"context_size": 2103,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q19",
"question_text": "Аномальный рост расходных операций?",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 411,
"planning_time_ms": 88,
"retrieval_time_ms": 158,
"response_generation_time_ms": 165,
"context_size": 2104,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q20",
"question_text": "Динамика НДС к соседним периодам.",
"question_class": "period_trend",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 387,
"planning_time_ms": 80,
"retrieval_time_ms": 150,
"response_generation_time_ms": 157,
"context_size": 2096,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q21",
"question_text": "Нетипичные корреспонденции счетов.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 390,
"planning_time_ms": 81,
"retrieval_time_ms": 151,
"response_generation_time_ms": 158,
"context_size": 2097,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q22",
"question_text": "Незакрытые хвосты по расчетам.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 393,
"planning_time_ms": 82,
"retrieval_time_ms": 152,
"response_generation_time_ms": 159,
"context_size": 2098,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q23",
"question_text": "Дублирующиеся проводки.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 396,
"planning_time_ms": 83,
"retrieval_time_ms": 153,
"response_generation_time_ms": 160,
"context_size": 2099,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q24",
"question_text": "Пустые или странные субконто.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 399,
"planning_time_ms": 84,
"retrieval_time_ms": 154,
"response_generation_time_ms": 161,
"context_size": 2100,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q25",
"question_text": "Узлы с подозрительно большим degree.",
"question_class": "anomaly_control",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 402,
"planning_time_ms": 85,
"retrieval_time_ms": 155,
"response_generation_time_ms": 162,
"context_size": 2101,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "good",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q26",
"question_text": "Полный риск-срез за июнь.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q27",
"question_text": "Рейтинг риск-счетов.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 408,
"planning_time_ms": 87,
"retrieval_time_ms": 157,
"response_generation_time_ms": 164,
"context_size": 2103,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q28",
"question_text": "Рейтинг риск-контрагентов.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 411,
"planning_time_ms": 88,
"retrieval_time_ms": 158,
"response_generation_time_ms": 165,
"context_size": 2104,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q29",
"question_text": "Baseline closed/open periods.",
"question_class": "heavy_analytical",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 414,
"planning_time_ms": 89,
"retrieval_time_ms": 159,
"response_generation_time_ms": 166,
"context_size": 2105,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q30",
"question_text": "Company anomaly summary.",
"question_class": "heavy_analytical",
"expected_route": "batch_refresh_then_store",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 390,
"planning_time_ms": 81,
"retrieval_time_ms": 151,
"response_generation_time_ms": 158,
"context_size": 2097,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "acceptable_with_warning",
"issues_detected": [
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
],
"recommended_fix": "Tune router threshold for heavy/live boundary."
},
{
"question_id": "Q31",
"question_text": "Что по налогам и рискам?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 393,
"planning_time_ms": 82,
"retrieval_time_ms": 152,
"response_generation_time_ms": 159,
"context_size": 2098,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q32",
"question_text": "Что странное в расходах?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 396,
"planning_time_ms": 83,
"retrieval_time_ms": 153,
"response_generation_time_ms": 160,
"context_size": 2099,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q33",
"question_text": "Самые рисковые контрагенты?",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 399,
"planning_time_ms": 84,
"retrieval_time_ms": 154,
"response_generation_time_ms": 161,
"context_size": 2100,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q34",
"question_text": "Что с 68.02?",
"question_class": "ambiguous_fuzzy",
"expected_route": "hybrid_store_plus_live",
"actual_route": "hybrid_store_plus_live",
"sources_used": [
"canonical_store",
"mcp_runtime_bridge"
],
"refresh_needed": false,
"latency_ms": 822,
"planning_time_ms": 115,
"retrieval_time_ms": 525,
"response_generation_time_ms": 182,
"context_size": 2951,
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
},
{
"question_id": "Q35",
"question_text": "Проверить документы июня.",
"question_class": "ambiguous_fuzzy",
"expected_route": "store_feature_risk",
"actual_route": "store_feature_risk",
"sources_used": [
"feature_store",
"risk_store",
"canonical_store"
],
"refresh_needed": false,
"latency_ms": 405,
"planning_time_ms": 86,
"retrieval_time_ms": 156,
"response_generation_time_ms": 163,
"context_size": 2102,
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
"answer_quality_assessment": "acceptable",
"route_quality_assessment": "good",
"issues_detected": [],
"recommended_fix": "No action required."
}
]
}
docs/ARCH/validation_run_2026-03-23_semantic_v2/check_validation_run_accounting_analytics_result_2026-03-23.md
+138
View File
@@ -0,0 +1,138 @@
# CHECK Validation Run Accounting Analytics — Result (2026-03-23)
## Scope
Выполнен ремонт ontology/mapping слоя по чек-листу `IN/CHEK_Validation_Run_Accounting_Analytics.md`:
1. Расширены canonical entity classes под недостающие доменные роли.
2. Переписан mapper на semantic-v2 подход:
- entity type resolver (с приоритетом `*_Type`);
- relation resolver (role/context-aware relations вместо одного `reference`);
- null GUID filter;
- composite source id builder.
3. Проведён re-map июньского snapshot 2020 и повторный validation-run.
## Implemented changes
### 1) Canonical model expansion
Добавлены классы:
- `ResponsiblePerson`
- `Currency`
- `Warehouse`
- `CashflowArticle`
- `Department`
- `Individual`
- `Item`
- `BankAccount`
- `InvoiceDocument`
- `RegisterRecord`
Файл: `canonical_layer/models.py`
### 2) Mapper architecture refactor
Файл: `canonical_layer/mappers.py`
Ключевые изменения:
- `map_record` больше не оставляет пустые/unknown `source_id`:
- сначала пробует `Ref_Key/Ref/ID/...`,
- затем строит `cmp:<sha1>` составной id по стабильному payload.
- links строятся через semantic resolvers:
- `register_recorded_by_document`
- `journal_refers_to_document`
- `document_has_counterparty`
- `document_has_contract`
- `document_belongs_to_organization`
- `document_has_currency`
- `document_has_responsible`
- `register_relates_to_supplier`
- `register_relates_to_buyer`
- `register_relates_to_invoice`
- и др.
- `*_Type` используется как приоритетный target type hint.
- `00000000-0000-0000-0000-000000000000` фильтруется из canonical links.
- Добавлен `canonical_relation_rule_catalog()` для прозрачной выгрузки правил.
### 3) Regression tests
Файл: `tests/test_mappers.py` (переписан)
Проверки включают:
- document counterparty relation;
- register composite source id;
- journal `Ref` -> document relation;
- supplier/buyer role typing;
- `СчетФактура` -> `InvoiceDocument` (без ложного `Account`);
- zero-GUID filtering.
Статус тестов:
- `python -m pytest -q` -> `17 passed`
## Re-map and validation results
### Re-map command
`python scripts/remap_snapshot_semantic_v2.py`
Артефакты:
- `logs/pre_report_snapshot_2020_2020-06_semantic_v2.json`
- `logs/pre_report_snapshot_2020_2020-06_semantic_v2_metrics.json`
### Before vs after (snapshot-level metrics)
- `source_id_unknown`: `358 -> 0`
- `unknown_links`: `1016 -> 102`
- `semantic_coverage_pct`: `61.1917 -> 94.9279`
- `relation_types_total`: `1 -> 25`
### Validation run on semantic-v2 snapshot
Команда:
`python scripts/run_validation_accounting_analytics.py --snapshot-path logs/pre_report_snapshot_2020_2020-06_semantic_v2.json --output-dir docs/ARCH/validation_run_2026-03-23_semantic_v2 --strict`
Папка результатов:
- `docs/ARCH/validation_run_2026-03-23_semantic_v2/`
Ключевые ontology-аудит метрики:
- `covered_entity_classes`: `33 -> 42`
- `uncovered_entity_classes`: `9 -> 0`
- `unknown_relations`: `1016 -> 102`
- `semantic_coverage_pct`: `61.1917 -> 94.9279`
- `relation_types_total`: `1 -> 25`
## Export package refresh
Обновлён пакет `docs/ARCH/2020экспорт` на базе semantic-v2 snapshot:
- `01_ontology_mapping_layer.md` (обновлённые классы/метрики)
- `02_canonical_relation_rules.md` (каталог semantic relations из маппера)
- все sample/json файлы перегенерированы
Команда:
`python scripts/export_arch_2020_package.py`
## Remaining gap (post-fix)
Топ остаточных unknown-полей после semantic-v2:
- `ВидОперации`
- `Информация`
- `СубконтоДт1`
- `Руководитель_Key`
- `ГлавныйБухгалтер_Key`
Следующий шаг:
- добавить точечные semantic rules для перечисленных полей;
- отдельно закрыть `Subconto*` mapping в детальный typed-slot слой;
- после этого повторить remap + validation и зафиксировать delta.
docs/ARCH/validation_run_2026-03-23_semantic_v2/llm_like_simulation_profile.md
+27
View File
@@ -0,0 +1,27 @@
# LLM-like Simulation Profile
Simulation mode: `4o-mini-like` (controlled emulation)
## Constraints
- Store-first retrieval policy.
- Compact planning and bounded context.
- Limited live calls for drill-down only.
- Avoid expensive heavy live scans.
## Route timing baseline (ms)
| Route | Planning | Retrieval | Generation | Context |
| --- | --- | --- | --- | --- |
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
| store_canonical | 70 | 170 | 130 | 1700 |
| store_feature_risk | 82 | 190 | 150 | 2200 |
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
## Active run context
- Slice window: `2020-06`
- Refresh latest run: `368e424624bb4e1d818091e6189ab222`
- Feature latest run: `d61114c3a5c5405f89ed2952a1755516`
- Risk latest run: `2785fa2100e84935a210687af6bb850b`
docs/ARCH/validation_run_2026-03-23_semantic_v2/ontology_mapping_audit.md
+50
View File
@@ -0,0 +1,50 @@
# Ontology & Mapping Audit
## Core metrics
| Metric | Value |
| --- | --- |
| entity_classes_total | 42 |
| covered_entity_classes | 42 |
| uncovered_entity_classes | 0 |
| relation_types_total | 25 |
| correctly_typed_relations | 1909 |
| unknown_relations | 102 |
| conflicting_mappings_count | 1 |
| link_coverage_pct | 100.0 |
| semantic_coverage_pct | 94.9279 |
## Top problematic source entity types
| Source entity | Unknown relations |
| --- | --- |
| DocumentJournal_БанковскиеВыписки | 30 |
| DocumentJournal_ЖурналОпераций | 16 |
| Document_СписаниеСРасчетногоСчета | 14 |
| Document_РеализацияТоваровУслуг | 12 |
| Document_СчетФактураВыданный | 8 |
| Document_ОперацияБух | 5 |
| AccumulationRegister_СтраховыеВзносыСведенияОДоходах_RecordType | 4 |
| DocumentJournal_КассовыеДокументы | 4 |
| Document_РасходныйКассовыйОрдер | 4 |
| AccumulationRegister_НДФЛСведенияОДоходах_RecordType | 3 |
| AccumulationRegister_НДФЛПредоставленныеСтандартныеВычетыФизЛиц_RecordType | 1 |
| Document_СчетНаОплатуПокупателю | 1 |
## Top problematic relation fields
| Source field | Unknown relations |
| --- | --- |
| ВидОперации | 34 |
| Информация | 16 |
| СубконтоДт1 | 15 |
| Руководитель_Key | 8 |
| ГлавныйБухгалтер_Key | 8 |
| СпособЗаполнения | 5 |
| ВидДохода_Key | 4 |
| СтатьяДоходовИРасходовПоТаре_Key | 4 |
| КодДохода_Key | 3 |
| СубконтоДт2 | 3 |
| КодВычета_Key | 1 |
| СтруктурнаяЕдиница_Key | 1 |
docs/ARCH/validation_run_2026-03-23_semantic_v2/orchestration_policy_spec.md
+37
View File
@@ -0,0 +1,37 @@
# Orchestration Policy Spec
## Decision tree
- exact object trace or posting chain -> `live_mcp_drilldown`
- simple factual in loaded slice -> `store_canonical`
- trend/anomaly/risk -> `store_feature_risk`
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
- low confidence fallback -> `hybrid_store_plus_live`
## Routing rules
- Prefer store answers when freshness allows.
- Use live bridge only for drill-down evidence.
- Do not run uncapped heavy live scans.
- Trigger refresh/features/risk for stale context.
- Apply retrieval/context budget before fallback.
## Source priorities
| Scenario | Priority order |
| --- | --- |
| simple_factual | canonical_store -> mcp_runtime_bridge |
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
| period_trend | feature_store -> risk_store -> canonical_store |
| anomaly_control | risk_store -> feature_store -> canonical_store |
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
## Timeout budget (ms)
| Budget | Value |
| --- | --- |
| planning | 200 |
| retrieval_soft_limit | 1200 |
| retrieval_hard_limit | 2500 |
| response_generation | 600 |
docs/ARCH/validation_run_2026-03-23_semantic_v2/slice_ingestion_report.md
+20
View File
@@ -0,0 +1,20 @@
# Slice Ingestion Report
Validation date: 2026-03-23T10:22:58.316163+00:00
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
- Snapshot file: `logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
- Snapshot entities: `409`
- Snapshot links: `2011`
- Refresh run id: `368e424624bb4e1d818091e6189ab222`
- Entities written: `409`
- Links written: `2011`
- Checkpoints updated: `42`
- Canonical entities total: `769`
- Canonical links total: `3700`
- Feature run status: `success`
- Feature metrics written: `202`
- Risk run status: `success`
- Risk patterns written: `3`
- Risk global score: `0.988676`
docs/accounting-assistant.zip
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/00_context/._.DS_Store
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/00_context/._Assistant_Mode_GLOBAL_STATUS_2026-03-24.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/00_context/._Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/00_context/._ROADMAP_endToReal.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/00_context/._accounting_assistant_architecture_roadmap.xlsx
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/01_platform/._TZ_Platform_Core_Accounting_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._.DS_Store
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_1_Foundation Hardening для Assistant Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_5_Investigation_Engine_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/02_stages/._TZ_Stage_6_Live_Verification_Product_Modes_Assistant_Mode.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/03_execution/._ACCEPTANCE_CHECKLIST_STAGE_01.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/03_execution/._ARCHITECTURE_GUARDRAILS.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/03_execution/._CODEX_MASTER_BRIEF.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/__MACOSX/accounting-assistant/03_execution/._STAGE_01_TASK_CARD.md
BIN
View File
Binary file not shown.
docs/accounting-assistant/accounting-assistant/00_context/.DS_Store
Vendored
BIN
View File
Binary file not shown.
docs/accounting-assistant/accounting-assistant/00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md
+679
View File
@@ -0,0 +1,679 @@
# Assistant Mode Global Status Report
Date: 2026-03-24
Scope: `llm_normalizer` + Assistant Mode pipeline + retrieval/explainability contours
Prepared for: architectural checkpoint and next-step planning
## 0) Executive Summary
Current system is no longer a raw route demo: we now have a working end-to-end assistant loop with decomposition, routing, retrieval, grounding, explainable response shaping, session logging, and regression tests.
At the same time, the system is still not a full accountant-grade investigation assistant. Main reason: data/model/retrieval unit depth is still below causal accounting reasoning depth in several domains.
Key status snapshot:
- Backend build/tests: `tsc` OK, `vitest` OK (`25/25` tests passed).
- Explainable contract: implemented (`requirements`, `coverage_report`, `answer_grounding_check`, explainable reply sections).
- Retrieval-layer upgrade: `executeHybrid` moved from `GUID-or-full-scan` to semantic profile + semantic narrowing.
- Proven narrowing example: for bank mismatch query with accounts `51/60`, narrowing reduced records from `262` to `75`.
- Proven limitation: for generic cross-entity chain query without explicit account scope, narrowing still wide (`262` to `242`), so answer quality can remain too broad.
---
## 1) Data Contour
### 1.1 How it works now
- Assistant retrieval reads local snapshot bundle from `docs/ARCH/2020экспорт`.
- Main files currently loaded in executor:
- `03_snapshot_fragment_problem_cases.json`
- `04_samples_SpisanieSRaschetnogoScheta.json`
- `05_samples_RealizaciyaTovarovUslug.json`
- `06_samples_PostuplenieTovarovUslug.json`
- `07_samples_DocumentJournals.json`
- `08_samples_NDS_registers.json`
- `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json`
- Data access is read-only snapshot, not live 1C state.
### 1.2 What works
- Documents/journals/register records are available with links and key attributes.
- Counterparty/document linkage and part of relation topology are usable.
- Enough depth exists for POC-level chain/risk analysis and explainable evidence pack.
### 1.3 Constraints
- Live truth is absent in assistant retrieval path (snapshot-only).
- Lifecycle/status semantics are incomplete and partly heuristic.
- Some accounting contexts are represented as flattened fields instead of normalized graph nodes.
### 1.4 What assistant cannot do because of this
- Guarantee real-time explanation of current accounting state.
- Reliably prove deep causal accounting chains in all domains (especially where lifecycle semantics are implicit).
### 1.5 Symptoms already seen in dialogs
- Repeated top entities across semantically different but broad queries.
- “Looks relevant” answers with weak differentiating evidence for some generic prompts.
### 1.6 Local changes needed
- Add richer field extraction/parsing from snapshot for account/document/lifecycle signals.
- Enforce tighter domain-specific filters for low-specificity queries.
### 1.7 Architectural changes needed
- Add live data bridge layer for on-demand truth check (hybrid snapshot + live drilldown).
- Add normalized accounting graph storage layer for causal traversal.
### 1.8 Priority
- `P0`: stronger retrieval constraints and lifecycle signal extraction.
- `P1`: live bridge for targeted verification.
- `P2`: full graph-backed data model.
---
## 2) Ontology / Domain Model Contour
### 2.1 How it works now
- Entity/relation semantics exist as retrieval profile vocabulary plus heuristic signal extraction.
- Domain labels include bank/suppliers/customers/VAT/fixed_assets/deferred_expense/period_close/settlements.
- Relation patterns include:
- `payment_to_settlement`
- `document_to_posting`
- `statement_to_document`
- `asset_card_to_depreciation`
- `deferred_expense_to_writeoff`
- `invoice_to_vat`
- `contract_to_documents`
- `receipt_to_stock_movement`
### 2.2 What works
- Query intent can be translated into semantic retrieval profile.
- Basic anomaly vocabulary exists and affects ranking/explanation.
### 2.3 Constraints
- No explicit ontology graph engine with typed nodes/edges and reasoning rules.
- Lifecycle model is heuristic (`created/posted/partially_linked/no_continuation/period_boundary`) rather than formal accounting state machine.
### 2.4 What assistant cannot do because of this
- Stable causal proofs for complex cross-domain reconciliation.
- Deterministic explanation of “why exactly this stage is broken” across all domains.
### 2.5 Symptoms
- Explanation can still be structurally correct but semantically generic.
- Retrieval unit can still drift toward “counterparty-heavy” answer shape.
### 2.6 Local changes needed
- Expand structured anomaly dictionary with accountant-facing defect classes.
- Promote lifecycle markers from heuristics to explicit modeled states where possible.
### 2.7 Architectural changes needed
- Build ontology/lifecycle core as first-class subsystem.
- Move from “labels on records” to “typed causal nodes and edges”.
### 2.8 Priority
- `P0`: anomaly taxonomy hardening + lifecycle schema hardening.
- `P1`: typed ontology graph.
- `P2`: rule engine over ontology.
---
## 3) Retrieval / Query Execution Contour
### 3.1 How it works now
- Deterministic routed executors:
- `store_feature_risk`
- `hybrid_store_plus_live`
- `batch_refresh_then_store`
- `store_canonical`
- `live_mcp_drilldown`
- `executeHybrid` now uses `semantic_retrieval_profile` and semantic narrowing when GUID is absent.
- Retrieval result now carries richer context in items and summary (`query_subject`, profile, ranking basis, narrowing metrics).
### 3.2 What works
- No hard fallback to pure full scan in hybrid path for non-GUID queries.
- Query with explicit accounting scope (`51/60`, wrong document closure) produces stronger narrowing and different ranking.
- Evidence pack is richer and usable by explainable answer layer.
### 3.3 Constraints
- Generic prompts without explicit scope can still produce wide narrowed sets.
- Retrieval top unit still often converges to counterparty-centric grouping.
- Not all routes have equal semantic depth.
### 3.4 What assistant cannot do because of this
- Consistently deliver problem-node-first output in every query class.
- Guarantee high differentiation for all semantically close prompts.
### 3.5 Symptoms
- For some queries, narrowing reduction is still modest (example `262 -> 242`).
- Answers can remain “good but broad”.
### 3.6 Local changes needed
- Tighten mandatory intersections for generic bank/cross-entity prompts.
- Add domain-specific minimum evidence thresholds before final top ranking.
### 3.7 Architectural changes needed
- Introduce explicit “problem cluster” retrieval unit.
- Add cross-branch retrieval policy (neighbor contour checks).
### 3.8 Priority
- `P0`: further narrowing hardening + anti-generic ranking guards.
- `P1`: problem-cluster retrieval unit.
- `P2`: multi-branch investigation retrieval policy.
---
## 4) LLM Layer and Decomposition Contour
### 4.1 How it works now
- Prompt/schema baseline: `normalizer_v2_0_2`.
- Deterministic v2 routing summary with fallback types.
- Requirements extraction + coverage report + dropped-intent tracking are implemented.
### 4.2 What works
- Route and execution readiness are explicit.
- Coverage and grounding diagnostics are available per turn.
- Route mismatch blocking is now less false-positive for non-critical contextual tokens.
### 4.3 Constraints
- Requirement extraction remains coarse in many cases (often 1 requirement per fragment).
- Transliteration/noisy mixed-language prompts still degrade in-scope detection.
### 4.4 What assistant cannot do because of this
- Fine-grained multi-requirement planning for complex accounting requests.
- Fully robust handling of colloquial/translit business language.
### 4.5 Symptoms
- Some translit prompts fall into `out_of_scope/clarification`.
- Partial semantic intent may be compressed in long multi-part prompts.
### 4.6 Local changes needed
- Expand language normalization and translit alias mapping before decomposition.
- Improve requirement extraction granularity inside one fragment.
### 4.7 Architectural changes needed
- Add dedicated semantic parser layer before normalizer for business-language canonicalization.
- Add requirement graph (instead of flat list) for planning/execution.
### 4.8 Priority
- `P0`: translit/business alias normalization.
- `P1`: requirement graph extraction.
- `P2`: adaptive decomposition policy.
---
## 5) Answer Synthesis / Explanation Contour
### 5.1 How it works now
- Reply types include:
- `factual_with_explanation`
- `partial_coverage`
- `clarification_required`
- `no_grounded_answer`
- `route_mismatch_blocked`
- others
- Response includes explainable sections: result, why included, selection basis, risk signs, business meaning, limitations, next step.
### 5.2 What works
- Core explainable contract is implemented and stable.
- Blocking logic prevents clearly mismatched subject answers.
### 5.3 Constraints
- Generic wording still appears when retrieval unit is broad.
- Explanations are still largely template-driven for some routes.
### 5.4 What assistant cannot do because of this
- Deliver fully case-unique accountant-level narratives in all scenarios.
### 5.5 Symptoms
- Two semantically close broad prompts may yield similar explanatory skeleton.
### 5.6 Local changes needed
- Route-specific explanation templates with stronger domain phrasing.
- Explicit “mechanism-of-failure” fields in retrieval result for composer.
### 5.7 Architectural changes needed
- Separate explanation planner from template renderer.
- Add accountant-facing narrative policy with domain lexicon packs.
### 5.8 Priority
- `P0`: route-specific explanation enrichment.
- `P1`: mechanism-level explanation fields.
- `P2`: explanation planner subsystem.
---
## 6) Memory / State / Session Continuity Contour
### 6.1 How it works now
- Session-scoped conversation state is persisted.
- One JSON file per session with turn-level human-readable + technical blocks.
### 6.2 What works
- Stable conversation history and replay.
- Explicit per-turn decomposition and response auditability.
### 6.3 Constraints
- No robust investigation state model (hypotheses/open checks/resolution graph).
- Context memory is conversational, not analytical.
### 6.4 What assistant cannot do because of this
- True multi-step investigative reasoning with hypothesis tracking.
### 6.5 Symptoms
- Follow-up can be coherent but not yet “investigation-driven”.
### 6.6 Local changes needed
- Add per-session `investigation_state` object (focus, active entities, open hypotheses, unresolved branches).
### 6.7 Architectural changes needed
- Add working-memory layer for research workflow, not only chat continuity.
### 6.8 Priority
- `P0`: investigation_state schema + persistence.
- `P1`: branch tracking and hypothesis status transitions.
- `P2`: multi-turn analytical planning engine.
---
## 7) Orchestration / Routing / Control Policy Contour
### 7.1 How it works now
- Deterministic routing with fallback (`none/out_of_scope/clarification/partial`).
- Linear execution plan per turn.
### 7.2 What works
- Clear route decisions and no-route reasons.
- Strong deterministic observability.
### 7.3 Constraints
- Mostly route-driven linear pipeline.
- Limited iterative branch exploration initiated by system policy.
### 7.4 What assistant cannot do because of this
- Automatically run neighbor contour verification when primary evidence is weak.
### 7.5 Symptoms
- Reasonable direct answers, but limited self-initiated investigation depth.
### 7.6 Local changes needed
- Introduce confidence-driven secondary retrieval triggers.
### 7.7 Architectural changes needed
- Orchestration policy engine with iterative reasoning loops and stop criteria.
### 7.8 Priority
- `P0`: confidence-based secondary checks.
- `P1`: branch exploration policy.
- `P2`: full investigation orchestrator.
---
## 8) Quality / Observability / Eval Contour
### 8.1 How it works now
- Structured runtime logs (stdout JSON).
- Trace storage and session logs.
- Regression tests for API behavior, grounding and retrieval semantics.
### 8.2 What works
- Technical observability is strong for current stage.
- Automated test baseline is green (`25/25`).
### 8.3 Constraints
- Limited accountant-utility evaluation metrics.
- No broad canonical scenario benchmark with decision-quality scoring.
### 8.4 What assistant cannot do because of this
- Provide hard quantitative proof of business usefulness across accounting domains.
### 8.5 Symptoms
- Technical success may still exceed practical user-perceived success.
### 8.6 Local changes needed
- Add eval metrics:
- retrieval differentiation rate
- generic explanation rate
- accountant actionability score
- false confidence rate
### 8.7 Architectural changes needed
- Build domain eval harness with canonical accounting scenarios and target outcomes.
### 8.8 Priority
- `P0`: metric instrumentation for practical usefulness.
- `P1`: canonical benchmark suite (bank/60/97/OS/VAT/period close/multi-intent/translit/follow-up).
- `P2`: continuous quality dashboard.
---
## 9) Evolutionary Architecture Contour
### 9.1 Missing pieces (high impact)
- Ontology graph core.
- Lifecycle engine.
- Problem-cluster retrieval unit.
- Investigation memory/state.
- Orchestration policy engine for iterative checks.
- Live verification bridge for source-of-truth escalation.
### 9.2 Current ceiling
- Without deeper ontology/lifecycle/state layers, system remains strong “explainable routed assistant”, but not full accountant investigation copilot.
### 9.3 Local vs architectural changes
- Local: better filters, better templates, more metrics, better parser.
- Architectural: graph model, lifecycle engine, investigation state, multi-step orchestrator.
### 9.4 Priority
- `P0`: finish semantic retrieval hardening + practical eval metrics + investigation_state baseline.
- `P1`: ontology/lifecycle formalization + problem-cluster retrieval.
- `P2`: iterative orchestrator + live verification framework.
---
## 10) Answers to 12 Mandatory Questions
1. What data reaches assistant and where detail is lost:
Data reaches from snapshot package with links/attributes; detail loss happens in flattening/grouping and lack of formal lifecycle semantics.
2. Full domain model exists:
Partially. Semantic labels and patterns exist, formal ontology graph does not.
3. Primary retrieval unit:
Mostly counterparty-grouped chain/risk clusters; not yet universal problem-node unit.
4. Real constraints and wide-scan risk:
Constraints now executed in hybrid semantic profile, but generic queries can still remain broad.
5. What LLM receives before answer:
Normalizer output + route summary + normalized retrieval payload + grounding/coverage diagnostics.
6. What is lost in decomposition:
Fine-grained multi-requirement structure can still compress; translit/noisy input can lose intent quality.
7. Why explanation still generic in places:
Broad retrieval unit + template-driven synthesis with limited mechanism-specific fields.
8. Can system explain mechanism (not only labels):
Partially. Better than before, still constrained by retrieval evidence depth.
9. Working state/memory for multi-step analysis:
Conversation memory exists; investigation memory model is missing.
10. Can system explore neighbor accounting branches automatically:
Not yet as policy standard; mostly linear route execution.
11. How usefulness is measured:
Technical pipeline quality is measured; accountant-facing utility metrics are not complete yet.
12. Missing architectural entities preventing next quality tier:
Ontology graph, lifecycle engine, problem-cluster unit, investigation state, iterative orchestration.
---
## 11) Current Phase Status (Condensed)
- Phase status: `Functional MVP+` (explainable routed assistant with semantic retrieval upgrade).
- Not yet: `Production accountant copilot`.
- Immediate gate to next phase: tighten broad-query narrowing + add practical accountant eval metrics + investigation state schema.
---
## 12) Recommended Next Step Pack
### P0 (next iteration)
- Tighten generic-query semantic narrowing in hybrid route.
- Add investigation state object in session model.
- Add practical eval metrics (differentiation/actionability/generic-rate).
### P1 (after P0 stabilization)
- Formalize ontology + lifecycle layers.
- Shift retrieval output from entity-heavy to problem-cluster-heavy for key domains.
### P2 (strategic)
- Add iterative orchestration with neighbor-branch verification.
- Add live source-of-truth verification path for high-confidence conclusions.
---
## 13) Data Loss Map (Source to LLM)
This section is the explicit loss map requested for architecture decisions.
| Source Layer | Current Internal Representation | Lost/Weakened Signals | Observable Assistant Symptom | Required Fix Layer |
|---|---|---|---|---|
| 1C document/journal/register snapshot record | flattened `SnapshotRecord` + heuristic signal extraction | formal business status transitions, typed lifecycle stage semantics | explanation can be structurally correct but semantically generic | lifecycle model + ontology graph |
| document + posting relation hints | relation pattern labels inferred by regex/rules | deterministic causal edge type and confidence | “close to right chain” answers without strict mechanism proof | typed relation graph + relation confidence |
| account hints from query and record fields | `account_scope` and inferred `account_context` arrays | strong account-role semantics (main vs side context) | broad retrieval if account scope is not explicit | account-role policy in retrieval profile |
| anomaly signs (`unknown links`, `zero guid`, etc.) | anomaly pattern tags (`missing_link`, `broken_lifecycle`, etc.) | accountant-grade defect class and business consequence mapping | same anomaly labels across semantically different defects | anomaly catalog and mapping engine |
| session chat turns | conversation list + turn log | investigation branch state and hypothesis state | follow-up can be coherent but not deeply investigative | investigation_state subsystem |
| snapshot-only truth | no guaranteed live verification step in assistant route | real-time status confirmation | high-quality but potentially stale conclusion in sensitive cases | live verification bridge |
### 13.1 Diagnostic implication
The dominant ceiling is not “weak wording” but “insufficiently structured causal context before synthesis”.
---
## 14) Query Class vs Required Architecture Depth
| User Query Class | Required Layers | Current Readiness | Ceiling Cause | Next Upgrade |
|---|---|---|---|---|
| simple factual object lookup | routing + canonical retrieval + basic grounding | medium/high | snapshot-only verification | optional live drilldown |
| anomaly ranking (one contour) | semantic profile + risk retrieval + explainable synthesis | medium | anomaly semantics still heuristic | anomaly catalog hardening |
| causal chain in one contour | relation patterns + chain retrieval + evidence pack | medium | retrieval unit still entity-heavy in broad prompts | problem-cluster unit |
| cross-domain reconciliation | ontology + lifecycle + neighbor branch policy | low/medium | no formal cross-domain causal graph | ontology graph + branch policy |
| period-close impact analysis | lifecycle + period-risk model + orchestration | low/medium | lifecycle model incomplete | lifecycle engine |
| multi-step investigation with follow-up | investigation_state + orchestration loops + hypothesis tracking | low | memory is conversational, not investigative | investigation mode layer |
| ambiguity-heavy/translit business language | semantic parser + alias normalization + decomposition guard | low/medium | parser limitations before routing | pre-normalization parser layer |
### 14.1 Decision implication
Prompt/model tuning alone cannot close low-readiness classes above; they are architecture-depth dependent.
---
## 15) Retrieval Unit Diagnosis (Core Bottleneck)
### 15.1 Current dominant unit
- Dominant unit in hybrid route is still often `counterparty group`, even after semantic narrowing.
### 15.2 Where this unit is acceptable
- quick ranking
- initial risk surfacing
- broad operational scanning
### 15.3 Where this unit breaks answer quality
- “what exactly is broken in chain”
- “closed by wrong document type”
- “which lifecycle stage is inconsistent”
- “what blocks period close and why”
### 15.4 Target retrieval units (must become first-class)
- `document_conflict`
- `broken_chain_segment`
- `lifecycle_anomaly_node`
- `unresolved_settlement_cluster`
- `period_risk_cluster`
- `cross_branch_inconsistency_cluster`
### 15.5 Transition plan
- Step 1 (`P0`): keep counterparty groups but add explicit `mechanism_of_failure` + `failed_expected_edge`.
- Step 2 (`P1`): introduce mixed-unit ranking (problem cluster first, entity second).
- Step 3 (`P2`): use problem-cluster as default answer unit for chain/anomaly/period-risk routes.
---
## 16) LLM Ceiling Boundaries (Not Solvable by Prompt Alone)
The following limitations remain even with stronger models/prompts unless architecture changes:
1. no formal lifecycle state machine on input -> model cannot produce deterministic lifecycle diagnosis;
2. no typed causal graph edges -> model cannot consistently prove mechanism, only infer plausible narrative;
3. entity-heavy retrieval unit -> model can explain “who is risky”, but not always “what exact mechanism broke”;
4. missing investigation_state -> model cannot reliably manage long hypothesis trees across turns;
5. no mandatory live verification gate -> model cannot guarantee real-time truth in high-stakes answers.
### 16.1 Governance rule
When limitations above are active, quality work must target data/model/orchestration layers first; LLM tuning is secondary.
---
## 17) Investigation Mode Specification (Required Next Architecture)
### 17.1 Minimal `investigation_state` schema
```json
{
"session_id": "asst-...",
"focus": {
"domain": "bank_settlements",
"period": "2020-06",
"primary_accounts": ["51", "60"]
},
"active_entities": [
{ "type": "counterparty", "id": "..." },
{ "type": "document", "id": "..." }
],
"open_hypotheses": [
{
"hypothesis_id": "H1",
"statement": "closure performed by wrong document type",
"status": "open",
"evidence_for": [],
"evidence_against": []
}
],
"branches": [
{
"branch_id": "B1",
"name": "bank->settlement",
"status": "in_progress",
"unresolved_reason": null
}
],
"resolved_findings": [],
"next_actions": []
}
```
### 17.2 Required branch lifecycle
- `open` -> `in_progress` -> `confirmed` or `rejected` -> `closed`
### 17.3 System-initiated branch rule (minimum)
If primary route confidence is high but mechanism evidence is weak, assistant should launch one neighbor branch check before final high-confidence conclusion.
---
## 18) Symptom to Root Cause to Required Layer
| Symptom | Root Cause | Required Layer |
|---|---|---|
| generic explanation despite “ok” reply | mechanism fields missing in retrieval payload | retrieval schema + answer planner |
| similar answers for broad prompts | weak semantic narrowing for low-specificity queries | retrieval policy |
| follow-up does not deepen analysis | no hypothesis/branch state | investigation_state |
| strong dependence on explicit account hints | weak semantic parser/ontology grounding | parser + ontology |
| lifecycle conclusions not stable | lifecycle semantics heuristic only | lifecycle engine |
| high confidence on snapshot-only route | no live verification gate | live verification bridge |
---
## 19) Value-Impact Roadmap (Decision Table)
| Change | Complexity | Quality Gain | Accountant Usefulness Gain | Multi-step Investigation Gain | Priority |
|---|---|---|---|---|---|
| tighten generic semantic narrowing | low/medium | high | high | medium | P0 |
| add `mechanism_of_failure` retrieval fields | medium | high | high | medium | P0 |
| add `investigation_state` persistence | medium | medium/high | high | high | P0 |
| add practical utility eval metrics | low/medium | medium | high | medium | P0 |
| formalize anomaly catalog | medium | medium/high | high | medium | P1 |
| ontology graph core | high | high | high | high | P1 |
| lifecycle engine | high | high | high | high | P1 |
| problem-cluster retrieval unit | high | high | high | high | P1 |
| iterative orchestration engine | high | high | high | very high | P2 |
| live verification bridge | high | medium/high | high | medium/high | P2 |
---
## 20) What Not To Do (Explicit Guardrails)
1. Do not attempt to solve mechanism-level quality only with prompt edits.
2. Do not treat richer wording as substitute for stronger retrieval unit.
3. Do not scale explanation templates without adding mechanism evidence fields.
4. Do not equate long conversation history with investigation_state.
5. Do not claim production-grade confidence without live verification path for critical answers.
docs/accounting-assistant/accounting-assistant/00_context/Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md
+63
View File
@@ -0,0 +1,63 @@
# Assistant Mode Global Status Appendix
Date: 2026-03-24
## A) Verification Commands
```powershell
cd X:\1C\NDC_1C\llm_normalizer\backend
npm.cmd run build
npm.cmd run test
```
Observed result:
- TypeScript build: success
- Test suite: success (`25/25`)
## B) Retrieval Narrowing Evidence
### Case 1: bank mismatch with explicit account scope
- Session: `asst-FuRihiL5Bp`
- Query subject: `bank_settlement_mismatch`
- Source records: `262`
- Filtered after narrowing: `75`
- Semantic narrowing applied: `true`
### Case 2: generic cross-entity bank chain
- Session: `asst-j9spgqdY7k`
- Query subject: `cross_entity_breakage`
- Source records: `262`
- Filtered after narrowing: `242`
- Semantic narrowing applied: `true`
Interpretation:
- Semantic narrowing is active and effective for constrained accounting scope.
- Generic prompts still need stronger narrowing policy.
## C) Key Implementation Anchors
- Semantic profile contract and builder:
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
- Hybrid narrowing and enriched evidence pack:
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
- API regression test for semantic narrowing:
- `X:\1C\NDC_1C\llm_normalizer\backend\tests\assistantEndpoint.test.ts`
## D) v1.1 Report Reinforcement Checklist
All 4 requested reinforcements are now explicitly present in the main report:
1. Data-loss path map (`Source -> Internal -> Lost -> Symptom -> Fix layer`)
2. Query-class vs architecture-depth matrix
3. Dedicated retrieval-unit diagnosis block (current vs target units)
4. Investigation mode schema and control-policy baseline
Also added:
- symptom -> root cause -> required layer matrix
- value-impact roadmap table
- explicit “what not to do” guardrails
docs/accounting-assistant/accounting-assistant/00_context/ROADMAP_endToReal.md
+555
View File
@@ -0,0 +1,555 @@
Да, сейчас как раз надо **перевернуть логику** и идти **от целевой архитектуры назад**, а не от текущих латок вперёд.
Потому что по вашему же статус-репорту уже видно: текущая система — это не “почти готовый ассистент”, а **explainable routed assistant**, который умеет разбирать вопрос, запускать retrieval и собирать ответ, но ещё не является полноценным бухгалтерским investigation copilot. Главные потолки уже названы прямо: snapshot-only truth, неполный lifecycle, entity-heavy retrieval unit, отсутствие investigation_state, отсутствие итеративной оркестрации и live verification.
И ещё одна очень важная вещь из отчёта: доминирующий потолок — это **не слабые формулировки**, а **недостаточно структурированный причинный контекст до synthesis**. То есть лечить всё “ещё одной LLM” или “ещё одним промптом” — это тупиковый путь.
Ниже дам тебе не просто roadmap, а именно **модель проектирования от идеального результата**.
---
# 1. Сначала фиксируем, что такое идеальный результат
Идеальный бухгалтерский ассистент для вас — это не чат, который “умеет отвечать на пару типов вопросов”.
Это система, которая умеет делать **три полноценных режима**.
## Режим A. Точечный причинно-следственный ответ
Пользователь задаёт короткий вопрос, но система понимает, что за ним стоит сложный поиск.
Пример:
“Какие проблемы по 51 счёту?”
Нормальный ответ здесь — это не список контрагентов и не абстрактные risk labels, а:
* где именно найден разрыв,
* какие документы участвуют,
* какая проводка или связь не бьётся,
* что это значит practically,
* на какие документы смотреть.
Для этого нужен не простой search, а **causal reconstruction**.
## Режим B. Многосоставной исследовательский вопрос
Пользователь задаёт сложный вопрос с гипотезами:
* проверь хвосты,
* выдели те, что ломают закрытие периода,
* отдельно покажи те, где проблема не в сумме, а в lifecycle,
* сравни с соседним контуром.
Это уже не single-shot answer.
Это мини-расследование.
## Режим C. Глобальный аналитический прогон
“Проведи полный анализ периода / зоны / класса рисков”.
Это уже не обычный ответ на чат-запрос, а **пакетное исследование**:
* сбор большого массива проблемных узлов,
* группировка,
* ранжирование,
* объяснение паттернов,
* вывод агрегированного состояния.
Для такого режима нужен отдельный execution mode, а не тот же самый lightweight pipeline, что и для короткого вопроса.
---
# 2. Отсюда вывод: у вас должен быть не один ассистент, а 3 архитектурных режима
Это очень важная развилка.
Сейчас вы, похоже, местами пытаетесь одним и тем же контуром обслужить:
* короткий factual вопрос,
* сложный multi-intent вопрос,
* широкий audit / overview.
Так нельзя.
Нужно проектировать **три режима исполнения**, даже если внешне они живут в одном чате.
## Mode 1: Direct Answer
Для узких или средних вопросов.
Цель: дать сильный ответ быстро.
## Mode 2: Investigation
Для сложных вопросов с гипотезами, ветками и follow-up.
Цель: вести исследование, а не просто отвечать.
## Mode 3: Audit / Batch Analysis
Для глобальных прогонов по периоду/зоне/классу проблем.
Цель: строить обзор состояния, кластеры рисков и приоритеты проверки.
Если это не разделить, вы будете всё время получать один и тот же эффект:
либо система поверхностна, либо слишком грузная, либо делает вид, что исследует, но на самом деле просто пересказывает одну выборку.
---
# 3. Что должно быть в целевой взрослой архитектуре
Если идти от конца, то у вас в “высшей планке” должны быть **7 обязательных архитектурных слоёв**.
## Слой 1. Data truth layer
Система должна иметь доступ не только к плоскому снапшоту, но и к:
* документам,
* проводкам,
* регистрам,
* статусам,
* связям,
* live-подтверждению для high-stakes вопросов.
Сейчас у вас retrieval идёт из snapshot bundle, а live truth в assistant path отсутствует. Это сразу ставит потолок на достоверность.
## Слой 2. Accounting ontology graph
Нужен не просто набор labels, а типизированный граф:
* документ,
* проводка,
* движение регистра,
* счет,
* субсчет,
* контрагент,
* договор,
* ОС,
* РБП,
* НДС,
* период,
* закрытие,
* и связи между ними.
Сейчас semantic vocabulary есть, formal ontology graph нет.
## Слой 3. Lifecycle engine
Для большинства бухгалтерских аномалий важен не сам объект, а его жизненный цикл:
* создан,
* проведён,
* связан,
* закрыт,
* частично закрыт,
* завис,
* закрыт не тем документом,
* противоречит соседнему контуру.
Сейчас lifecycle у вас heuristic, а не formal state machine.
## Слой 4. Problem-cluster retrieval
Не entity-first retrieval, а retrieval по проблемным узлам:
* document_conflict
* broken_chain_segment
* lifecycle_anomaly_node
* unresolved_settlement_cluster
* period_risk_cluster
* cross_branch_inconsistency_cluster
Это прямо сформулировано в отчёте как следующий архитектурный переход.
## Слой 5. Investigation state
Нужна не просто память чата, а память расследования:
* current focus,
* active hypotheses,
* checked branches,
* unresolved branches,
* evidence collected,
* confidence,
* next recommended checks.
Сейчас conversation memory есть, investigation memory model отсутствует.
## Слой 6. Iterative orchestration
Система должна уметь не только выполнять один route, а:
* делать secondary checks,
* идти в соседнюю ветку,
* усиливать доказательства,
* останавливать исследование по критериям,
* переключаться между локальным ответом и расследованием.
Сейчас pipeline в основном linear и route-driven.
## Слой 7. Accountant-grade answer synthesis
Ответ должен строиться не по лейблам, а по механике нарушения:
* что именно сломано,
* где,
* между чем и чем,
* почему это признано проблемой,
* что это блокирует,
* что проверить дальше.
Сейчас generic explanation ещё остаётся из-за broad retrieval unit и limited mechanism-specific fields.
---
# 4. Ключевая мысль: вам надо проектировать не “ассистента”, а бухгалтерический investigation engine
Вот здесь и есть разворот мышления.
Проблема не в том, что текущая система “простая”.
Проблема в том, что её базовая логика пока ближе к:
* normalize
* route
* retrieve
* synthesize
А целевая система должна быть ближе к:
* understand
* model
* investigate
* verify
* explain
* continue
То есть вы строите не просто retrieval assistant, а **engine исследования учётной причинности**.
И это означает, что ядром архитектуры должен стать не normalizer и не answer composer, а вот эта связка:
**ontology graph + lifecycle engine + problem-cluster retrieval + investigation state + orchestration policy**
---
# 5. Что делать дальше: реальная дорожная карта
Ниже даю дорожную карту **от целевой архитектуры назад**, а не от текущих мелких фиксов вперёд.
## Этап 0. Зафиксировать, что дальше вы строите не чат-надстройку, а investigation architecture
Это организационный этап, но он критичен.
Нужно формально принять:
* есть 3 execution modes;
* есть архитектурные сущности, без которых потолок не пробить;
* LLM tuning больше не главный вектор;
* данные, ontology, lifecycle, retrieval unit и orchestration становятся основой.
Без этого вы снова утонете в “давайте ещё немножко улучшим ответы”.
---
## Этап 1. Закрыть фундаментальные дыры текущего слоя
Это не “идеал”, это санитарный минимум, чтобы было на что опираться.
### Что сделать
1. Дожать semantic retrieval hardening для broad/generic prompts.
Сейчас даже в отчёте видно: constrained query narrowing работает, generic cross-entity — всё ещё слишком широкая.
2. Добавить accountant-facing eval metrics:
* retrieval differentiation rate
* generic explanation rate
* accountant actionability score
* false confidence rate
3. Ввести baseline `investigation_state` в session model.
Не полный engine, а хотя бы:
* focus,
* domain,
* period,
* hypotheses,
* checked objects,
* unresolved branches,
* last evidence pack.
### Критерий выхода
Система не просто отвечает, а начинает **держать предмет расследования** и не терять его между ходами.
---
## Этап 2. Сменить retrieval unit
Это, по-хорошему, самый важный следующий технический шаг.
### Что сделать
Перестать считать `counterparty group` базовой единицей для chain/anomaly вопросов.
Оставить её как вспомогательную, но наверх выводить problem clusters.
### Нужные target units
* document_conflict
* broken_chain_segment
* lifecycle_anomaly_node
* unresolved_settlement_cluster
* period_risk_cluster
* cross_branch_inconsistency_cluster
### Что это даст
Только после этого ответы начнут переходить от:
“какие контрагенты шумные”
к
“что именно сломано и где”.
### Критерий выхода
На вопрос типа “что закрыли не тем документом” top-объектом ответа становится не контрагент, а **конкретный конфликтный узел**.
---
## Этап 3. Формализовать lifecycle
Без этого вы не сделаете хороший бухгалтерский reasoning.
### Что сделать
Для ключевых доменов ввести явные state models:
* bank/settlements
* suppliers
* customers
* fixed assets
* deferred expenses
* VAT
* period close
### Для каждого домена
Определить:
* допустимые стадии,
* допустимые переходы,
* типовые нарушения,
* бизнес-последствия.
### Что это даст
Система сможет объяснять не “broken_lifecycle”, а:
* платёж дошёл, обязательство не закрылось;
* объект ОС принят, но переход в стадию эксплуатации/амортизации неконсистентен;
* РБП живёт за пределами ожидаемого срока списания;
* налоговый контур противоречит документному.
### Критерий выхода
Система умеет называть **тип поломки стадии**, а не просто общий risk label.
---
## Этап 4. Построить ontology graph
Это уже первый реально взрослый архитектурный шаг.
### Что сделать
Выделить typed nodes and edges:
* document
* posting
* register movement
* account
* counterparty
* contract
* asset
* deferred expense
* invoice
* VAT node
* period close operation
* etc.
И отдельно typed edges:
* created_by
* posted_to
* settles
* refers_to
* closes
* writes_off
* depreciates
* affects_period
* conflicts_with
* missing_expected_edge
### Что это даст
1. Нормальный causal traversal
2. Нормальный cross-domain reconciliation
3. Возможность rule engine поверх графа
4. Сильный вход в LLM
### Критерий выхода
На сложный вопрос система может доказательно пройти не только “рядом лежащие записи”, а **типизированную цепочку бухгалтерской причинности**.
---
## Этап 5. Построить investigation mode
Это уже переход от ассистента к сопилоту.
### Что сделать
Поверх graph + lifecycle + retrieval unit ввести investigation engine:
* hypothesis registration
* branch tracking
* neighbor branch policy
* confidence-driven secondary checks
* stop criteria
* escalation to live drilldown
### Как это работает
Пользователь задаёт вопрос → система не просто отвечает, а открывает investigation state:
* главная гипотеза,
* какие ветки уже проверены,
* чего не хватает,
* куда надо сходить ещё,
* что уже доказано,
* что пока только вероятно.
### Критерий выхода
Follow-up превращается не в “ещё один независимый вопрос”, а в продолжение одного расследования.
---
## Этап 6. Добавить live verification bridge
Для high-stakes ответов snapshot-only пути недостаточно. Это уже прямо отражено в статус-репорте.
### Что сделать
Добавить режим точечного live drilldown:
* по конкретному документу,
* проводке,
* объекту,
* текущему статусу,
* source-of-record.
### Что это даст
1. Реальную актуальность
2. Меньше ложной уверенности
3. Возможность делать сильные выводы там, где snapshot устарел
### Критерий выхода
Система умеет честно разделять:
* вывод по snapshot,
* вывод, подтверждённый live.
---
## Этап 7. Развести execution modes в продукте
К этому моменту нужно уже не только архитектурно, но и продуктово развести 3 режима.
### Direct Answer
Быстрый ответ по объекту / проблеме / счёту.
### Investigation
Пошаговое исследование с ветками и накоплением доказательств.
### Audit / Batch
Долгий прогон по периоду/зоне с итоговым risk report.
Это можно оставить в одном UI, но внутри это должны быть три разных execution policies.
---
# 6. Как отвечать на твой главный страх: “мы очень далеко”
Да, вы далеко.
Но это **нормально**, потому что цель у вас не “добавить чат к 1С”, а построить довольно серьёзный reasoning layer над бухгалтерской реальностью.
По отчёту ваш текущий уровень — это действительно примерно:
**functional MVP+**, но не accountant-grade copilot. Это уже честно зафиксировано и там, и это правильная оценка.
Плохая новость:
простыми кирпичиками от текущего пайплайна до идеала не дойти.
Хорошая новость:
сейчас уже видно, **какие именно сущности отсутствуют**.
То есть вы уже не в тумане.
Вы уже можете перестать лечить симптомы и начать проектировать взрослую систему.
---
# 7. Чего точно не надо делать дальше
Это прям важно.
## Не надо:
* лечить всё промптами;
* надеяться, что более сильная LLM сама “додумает бухгалтерию”;
* продолжать делать entity-heavy ответы и просто украшать их текстом;
* считать длинную историю чата полноценным investigation state;
* пытаться одним execution loop закрывать и короткий factual вопрос, и долгий audit;
* строить perceived quality вместо реальной причинной глубины.
Это всё уже противоречит вашему же отчёту.
---
# 8. Если совсем коротко: что делать прямо сейчас
Если перевести всё в управленческое решение, то я бы сказал так.
## Ближайший обязательный пакет
1. baseline investigation_state
2. практические accountant-метрики
3. дожим generic narrowing
4. mechanism-specific fields в retrieval result
5. переход к mixed retrieval unit
## Следующий архитектурный пакет
1. lifecycle formalization
2. anomaly catalog accountant-grade
3. ontology graph core
4. problem-cluster retrieval default for chain/anomaly routes
## Стратегический пакет
1. investigation orchestrator
2. neighbor-branch policy
3. live verification bridge
4. product split на Direct / Investigation / Audit
---
# 9. Мой итоговый вердикт
Вам реально нужно **перестать мыслить от текущего pipeline** и начать мыслить от такой целевой конструкции:
**Бухгалтерский ассистент = accounting graph + lifecycle engine + problem-cluster retrieval + investigation state + iterative orchestrator + live verification + explanation layer**
LLM там важна, но она не центр системы.
Она — интерпретатор, планировщик, синтезатор и интерфейс reasoning.
А reasoning должен жить в архитектуре, а не только в модели.
Вот это и есть взрослая развилка.
Если хочешь, следующим сообщением я соберу это уже в виде **жёсткой roadmap-таблицы: этап / цель / что внедряем / критерий выхода / что это даёт пользователю**.
docs/accounting-assistant/accounting-assistant/00_context/accounting_assistant_architecture_roadmap.xlsx
BIN
View File
Binary file not shown.
docs/accounting-assistant/accounting-assistant/01_platform/TZ_Platform_Core_Accounting_Assistant_Mode.md
+1386
View File
File diff suppressed because it is too large Load Diff
docs/accounting-assistant/accounting-assistant/02_stages/.DS_Store
Vendored
BIN
View File
Binary file not shown.
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_1_Foundation Hardening для Assistant Mode.md
+776
View File
@@ -0,0 +1,776 @@
# ТЗ Этап 1
## Foundation Hardening для Assistant Mode
## 0. Смысл этапа
Этот этап **не должен** строить взрослую финальную архитектуру.
Он должен сделать другое:
**превратить текущий explainable routed assistant из “формально работающего контура” в устойчивый базовый слой, на который уже можно ставить problem-cluster retrieval, lifecycle formalization и investigation engine.**
То есть задача этапа не “улучшить ответы вообще”, а:
* убрать самые опасные архитектурные слабости текущего слоя;
* перестать терять предмет анализа между шагами;
* перестать собирать слишком широкие broad answers;
* перестать генерировать explanation, в котором есть labels, но нет механики;
* ввести измеримость качества именно с точки зрения бухгалтера.
---
# 1. От чего идём: целевая способность системы
Если смотреть от финальной цели назад, то уже на первом этапе система должна приобрести **четыре базовые способности**, без которых всё дальнейшее бессмысленно.
### 1. Удержание предмета расследования
Система должна помнить не только историю чата, а **что именно сейчас проверяется**, какие гипотезы открыты, какие сущности уже подняты, какой период и какой контур в фокусе.
Сейчас этого нет: conversation memory есть, investigation memory model отсутствует.
### 2. Сужение broad-вопросов до управляемого бухгалтерского профиля
Система должна перестать считать успехом ситуацию, когда generic chain query narrowed “формально”, но по факту остался почти весь датасет. Это уже подтверждено на текущем контуре: для explicit account scope narrowing сильное, а для generic cross-entity prompts всё ещё слишком широкое.
### 3. Поднятие механики проблемы в retrieval result
LLM сейчас получает normalizer output, route summary, normalized retrieval payload и grounding/coverage diagnostics. Но explanation остаётся generic именно потому, что retrieval evidence ещё недостаточно механизмоспецифичен.
На первом этапе надо не “сделать тексты красивее”, а поднять вверх поля, из которых можно строить конкретное объяснение.
### 4. Переход от технической оценки к бухгалтерской полезности
Сейчас меряется technical pipeline quality, но accountant-facing utility metrics ещё неполные. Это нужно закрыть именно сейчас, иначе дальше система будет “развиваться” по ложным индикаторам.
---
# 2. Что сохраняем, а что меняем
## 2.1. Что сохраняем без архитектурного слома
Ниже то, что на первом этапе **не переписываем**, а используем как базу:
* существующий assistant loop;
* deterministic routing summary;
* normalizer pipeline `normalizer_v2_0_2`;
* explainable contract (`requirements`, `coverage_report`, `answer_grounding_check`);
* semantic retrieval profile в `executeHybrid`;
* debug drawer;
* session-scoped conversation continuity;
* route set (`store_feature_risk`, `hybrid_store_plus_live`, `batch_refresh_then_store`, `store_canonical`, `live_mcp_drilldown`).
Это важно: Этап 1 не должен устроить архитектурную ломку.
Он должен **усилить текущий контур**, а не заменить его “идеальной системой”.
---
## 2.2. Что меняем принципиально
На первом этапе меняются не все слои, а конкретные места, где уже зафиксирован потолок:
1. retrieval policy for broad/generic prompts
2. retrieval result schema
3. answer synthesis policy
4. session model
5. eval layer
6. decomposition guardrail для noisy/translit и multi-intent compression
---
## 2.3. От чего сознательно отказываемся на этапе 1
На этом этапе **не строим**:
* полноценный ontology graph;
* полноценный lifecycle engine;
* полноценный investigation orchestrator;
* полноценный live verification bridge;
* финальный problem-cluster retrieval как default unit.
Это всё уже названо как следующий архитектурный слой, но не как ближайший P0.
Но:
* подготавливаем данные и контракты под эти сущности;
* убираем то, что потом будет мешать их внедрению;
* не пишем времянки, противоречащие target architecture.
---
# 3. Архитектурная цель этапа 1
К концу этапа текущая система должна перейти из состояния:
**“работающий explainable routed assistant с semantic narrowing upgrade”**
в состояние:
**“устойчивый accountant-facing assistant baseline с session investigation state, усиленным narrowing, mechanism-aware evidence pack и предметными метриками качества”**
---
# 4. Главные сущности этапа 1
Теперь по сущностям — не просто перечисление, а **что с ними делаем и зачем**.
---
## 4.1. Сущность №1 — `investigation_state`
### Почему она нужна
Сейчас в системе есть session conversation, но нет модели расследования. Это прямо зафиксировано как архитектурный пробел.
Из-за этого follow-up может быть связным по чату, но не становится настоящим продолжением анализа.
### Что не устраивает в текущем состоянии
Текущая session memory:
* хранит историю сообщений;
* пригодна для continuity;
* непригодна для hypothesis-driven analysis.
Это и есть разрыв между “чатом” и “расследованием”.
### Что делаем
Вводим новый слой session model: `investigation_state`.
### Что именно должно появиться
Минимальная сущность должна включать:
* `session_id`
* `focus`
* domain
* period
* primary_accounts
* active_query_subject
* `active_entities`
* `open_hypotheses`
* `checked_hypotheses`
* `branches`
* `resolved_findings`
* `unresolved_findings`
* `next_actions`
* `evidence_summary`
* `working_assumptions`
* `query_mode_hint` (`direct_answer` / `investigation_candidate`)
Базовый schema direction уже есть в отчёте, но на этапе 1 его надо превратить из спецификации в рабочий backend contract.
### Что не делаем пока
Не строим полный branch engine и не запускаем автоматическое исследование соседних веток как policy standard. Это следующий слой. Сейчас фиксируем **контейнер состояния**, а не весь investigation orchestrator.
### Что это даст
* follow-up перестанет быть просто ещё одним запросом;
* broad causal questions можно будет удерживать внутри одного аналитического контекста;
* позже сюда без боли встанет hypothesis tracking.
---
## 4.2. Сущность №2 — `semantic_retrieval_profile` (усиление, не замена)
### Почему она нужна
Она уже есть и уже улучшила retrieval, особенно на explicit accounting scope. Но generic prompts всё ещё narrowing’ятся слишком слабо.
### Что не устраивает
Профиль пока:
* лучше старого GUID-or-full-scan;
* но ещё недостаточно жёсткий на широких вопросах;
* не всегда переводит broad chain query в достаточно узкий бухгалтерский поиск.
### Что делаем
Не переписываем профиль заново, а вводим **mandatory narrowing policy** для проблемных классов запросов.
### Что добавляем в профиль как обязательные рабочие поля
Сейчас у вас уже есть account/domain/document/relation/anomaly intersections. На первом этапе надо зафиксировать обязательные блоки:
* `query_subject`
* `account_scope`
* `domain_scope`
* `document_types`
* `entity_types`
* `relation_patterns`
* `anomaly_patterns`
* `ranking_basis`
* `explanation_focus`
* `minimum_evidence_requirements`
* `broad_query_guard`
* `scope_confidence`
### Что меняем в логике
Если query broad и нет явного account scope, retrieval **не имеет права** просто сделать “semantic narrowing = true” и оставить 242 из 262.
Он должен пройти через guardrail policy:
1. попытка достроить предметный scope из:
* session focus
* domain hints
* document hints
* relation hints
2. если после этого narrowing всё ещё рыхлый:
* понизить confidence,
* пометить result как broad,
* ограничить final answer depth,
* предложить controlled clarification или drilldown direction.
### То, от чего отказываемся
От практики считать успешным любой routed answer, где technically есть profile и narrowing flag. Это ложный индикатор качества.
### Что это даст
* меньше pseudo-relevant broad answers;
* меньше одинаковых или слишком похожих выдач;
* более честная работа с low-specificity prompts.
---
## 4.3. Сущность №3 — `mechanism-aware evidence pack`
### Почему нужна
В отчёте уже сказано, что explanation generic из-за broad retrieval unit и limited mechanism-specific fields.
То есть проблема не в том, что composer не умеет писать, а в том, что наверх приходит недостаточно причинной информации.
### Что не устраивает сейчас
Сейчас evidence часто выглядит как:
* risk factors,
* labels,
* selection reasons общего типа,
* business interpretation шаблонного характера.
Из-за этого ответ может быть структурно правильным, но семантически слабым. Это видно и по логам: там уже есть “broken_lifecycle”, “posting_mismatch”, “cross_domain_inconsistency”, но эти признаки ещё не собираются в конкретный механизм поломки.
### Что делаем
Для `hybrid_store_plus_live` и `store_feature_risk` вводим обязательный `mechanism-aware evidence pack`.
### Какие поля должны появиться у top item
Не на уровне идеальной графовой модели, а на текущем data contour:
* `mechanism_of_failure`
* `failed_expected_edge`
* `expected_next_step`
* `actual_detected_step`
* `mechanism_confidence`
* `affected_documents`
* `affected_postings`
* `affected_accounts`
* `period_impact_hint`
* `business_defect_class`
* `requires_neighbor_check`
* `is_snapshot_limited`
### Пример логики
Не просто:
* `broken_lifecycle`
А:
* expected_next_step = “settlement closure by linked calculation document”
* actual_detected_step = “payment reflected, linked closure path not confirmed”
* failed_expected_edge = “statement_to_document -> settlement closure”
* mechanism_of_failure = “payment recorded without confirmed closure in expected chain”
### Что сохраняем
Risk labels остаются, но становятся вторичным слоем, а не единственным объясняющим слоем.
### Что это даст
* composer получит материал для case-specific explanation;
* даже без ontology graph ответы станут более предметными;
* станет видно, где retrieval реально понимает механизм, а где нет.
---
## 4.4. Сущность №4 — `answer contract v1.1`
### Почему нужна
Формально explainable contract уже реализован. Но user-facing ответы всё ещё могут быть generic и слишком top-entity-heavy.
### Что не устраивает
Текущие ответы:
* лучше, чем раньше;
* но всё ещё часто объясняют “по какому профилю искали”, а не “что именно сломано”.
### Что делаем
Не переписываем composer с нуля.
Меняем policy сборки ответа.
### Новый принцип
Ответ должен строиться в следующем порядке:
1. **что именно найдено**
2. **что именно в этом проблемно**
3. **какой механизм поломки предполагается**
4. **на чём это основано**
5. **какие документы/связи это подтверждают**
6. **что ограничивает вывод**
7. **что проверить дальше**
А не так:
* какой route,
* какой profile,
* какие labels.
### Что меняем в сборке
Для problem/explanation answers composer обязан:
* использовать `mechanism_of_failure` как главный narrative anchor;
* использовать `affected_documents` как конкретные опорные объекты;
* понижать уверенность, если есть только labels без mechanism;
* не выстраивать top narrative вокруг counterparty count, если вопрос не про ranking контрагентов.
### От чего отказываемся
От generic text scaffolding вроде:
* “результат отражает структурные признаки разрыва цепочки”
* “объекты приоритетны для проверки”
если за этим не следует конкретный case.
Именно это сейчас делает ответы убедительнее внешне, чем они есть по сути.
### Что это даст
Даже без нового retrieval unit ответы уже перестанут быть purely decorative.
---
## 4.5. Сущность №5 — `decomposition guardrail`
### Почему нужна
Тонкая multi-requirement структура всё ещё может compress’иться, noisy/translit input может терять intent quality. Это уже зафиксировано.
### Что не устраивает
Даже если routing и retrieval сильнее, пользовательский вопрос может быть испорчен на раннем этапе:
* часть требований схлопнулась;
* важная гипотеза потерялась;
* транслит или бытовая бухгалтерская формулировка испортили intent.
### Что делаем
Добавляем не новый LLM-слой, а **guardrail around decomposition**.
### Что должно появиться
1. pre-normalization alias layer:
* транслит,
* бытовые бухгалтерские выражения,
* alias dictionary
2. multi-requirement preservation rule:
* если в вопросе обнаружено несколько смысловых действий, planner не имеет права silently compress их в один fragment без отметки потери
3. decomposition quality flag:
* `high`
* `soft_assumptions_used`
* `intent_loss_risk`
* `clarification_recommended`
### От чего отказываемся
От негласной практики “если route найден, значит декомпозиция достаточная”.
### Что это даст
* меньше ложных “зелёных” обработок;
* больше честности там, где вопрос реально разобран не полностью;
* меньше false out_of_scope и ложных soft assumptions.
---
## 4.6. Сущность №6 — `accountant eval layer`
### Почему нужна
Сейчас pipeline quality меряется, а accountant-facing utility metrics ещё нет в завершённом виде. Это уже признано P0.
### Что не устраивает
Пока нет правильной оценки, команда может улучшать то, что не даёт реальной ценности бухгалтеру.
### Что делаем
Строим evaluation layer именно под user value.
### Обязательные метрики этапа 1
1. `retrieval_differentiation_rate`
2. `generic_explanation_rate`
3. `accountant_actionability_score`
4. `false_confidence_rate`
5. `broad_answer_rate`
6. `mechanism_specificity_score`
7. `followup_context_retention_score`
Первые четыре уже названы в отчёте как локально необходимые.
### Что должно появиться кроме метрик
Набор канонических сценариев:
* 51 / неверный тип закрытия
* 60 / хвосты поставщиков
* 97 / lifecycle anomaly
* ОС / карточка vs начисления
* НДС / cross-domain contradiction
* period close impact
* multi-intent
* translit
* follow-up investigation
### От чего отказываемся
От оценки ассистента только по:
* tests passed,
* routed successfully,
* grounding green,
* coverage 1/1.
Этого недостаточно.
### Что это даст
После Этапа 1 вы впервые сможете мерить не “система работает?”, а “она стала полезнее бухгалтеру или нет”.
---
# 5. Полная цепь изменений по контуру
Теперь соберу это не по сущностям, а по **полной цепи выполнения**.
---
## 5.1. Вход сообщения
### Сейчас
Сообщение идёт в normalizer, потом в deterministic routing summary.
### Что меняем
Перед normalizer добавляется тонкий pre-normalization parser:
* alias normalization
* translit normalization
* бытовые бухгалтерские alias
* явная фиксация потенциальных multi-requirement markers
### Цель
Не дать системе потерять смысл до decomposition.
---
## 5.2. Декомпозиция
### Сейчас
Есть requirements extraction, coverage report, dropped-intent tracking, но fine-grained multi-requirement structure всё ещё может compress’иться.
### Что меняем
* вводим decomposition quality flag;
* вводим обязательную маркировку `intent_loss_risk`;
* soft assumptions становятся видимыми не только в debug, но и влияют на итоговую reply policy;
* broad multi-intent prompts при недостаточном качестве больше не идут в “тихо routed factual answer”.
### Цель
Не скрывать слабую декомпозицию за уверенным downstream answer.
---
## 5.3. Session model
### Сейчас
Есть conversation continuity in-memory, но нет investigation memory.
### Что меняем
В backend session store добавляется `investigation_state`.
### Цель
Связать текущий вопрос с текущим предметом анализа, а не только с текстом чата.
---
## 5.4. Retrieval planning
### Сейчас
Semantic retrieval profile есть; generic prompts всё ещё рыхлые.
### Что меняем
В profile builder добавляем:
* broad query guard
* minimum evidence requirements
* explanation focus
* scope confidence
* degraded answer policy hints
### Цель
Чтобы retrieval перестал быть technically narrowed, но semantically broad.
---
## 5.5. Retrieval execution
### Сейчас
`executeHybrid` уже использует semantic profile и narrowing; это существенный прогресс. Но generic bank/cross-entity queries всё ещё могут давать слишком широкий набор.
### Что меняем
* вводим domain-specific minimum intersections для generic prompts;
* добавляем anti-generic ranking guards;
* усиливаем lifecycle/account/document extraction из snapshot;
* поднимаем mechanism-aware evidence.
### Цель
Не просто narrowed retrieval, а retrieval, который уже несёт механизм проблемы.
---
## 5.6. Result normalization
### Сейчас
Есть normalized retrieval payload, grounding/coverage diagnostics.
### Что меняем
Расширяем normalized payload так, чтобы composer получал:
* mechanism fields
* defect class
* expected/actual step delta
* period impact hint
* snapshot limitation flag
### Цель
Убрать разрыв между retrieval и answer synthesis.
---
## 5.7. Answer synthesis
### Сейчас
Composer базовый, sufficient for MVP loop, но не policy-grade layer.
### Что меняем
Новый answer policy:
* route/profile diagnostics уходят на второй план;
* основной narrative anchor = mechanism_of_failure;
* if mechanism weak -> response confidence down;
* if answer broad -> explicit limitation instead of strong conclusion;
* if investigation_state active -> answer binds itself to current focus.
### Цель
Сделать ответ не более красивым, а более предметным.
---
## 5.8. Eval and observability
### Сейчас
Есть tests/build/session/debug traces, но нет полного accountant eval harness.
### Что меняем
* вводим value-oriented metrics;
* фиксируем canonical scenario suite;
* отдельно логируем generic explanation rate, broad answer rate, mechanism specificity.
### Цель
Сделать качество управляемым, а не субъективным.
---
# 6. Что должно быть переписано, а что только усилено
Это важный раздел, потому что ты просил не общие слова, а прям понять: **что переделываем, а что сохраняем**.
## Полностью переписывать на этапе 1 не надо:
* normalizer целиком;
* routing engine;
* assistant endpoint;
* frontend orchestration;
* debug plane;
* existing assistant loop.
## Существенно переделываем:
* session data contract
* retrieval profile builder policy
* retrieval evidence schema
* answer assembly policy
* eval harness
## Частично усиливаем:
* translit/noisy parser
* domain-specific narrowing rules
* decomposition loss detection
* ranking guards
* snapshot signal extraction
## Осознанно оставляем на следующий этап:
* ontology graph
* lifecycle engine formal
* problem-cluster retrieval as default
* iterative orchestrator
* live verification bridge
---
# 7. Архитектурные артефакты, которые должны появиться по итогам этапа
К концу этапа должны появиться не только кодовые изменения, но и новые артефакты.
## Обязательные артефакты
1. `investigation_state` schema
2. `semantic_retrieval_profile` vNext contract
3. `mechanism_aware_evidence_pack` schema
4. `answer_policy_v1_1` spec
5. `decomposition_guardrail` spec
6. `accountant_eval_harness` spec
7. canonical benchmark list
8. regression scenarios for broad query narrowing
---
# 8. Критерии приёмки этапа
Этап считается выполненным не когда “код написан”, а когда выполнены следующие условия.
## 8.1. По состоянию анализа
* сессия хранит `investigation_state`;
* follow-up использует не только chat history, но и active focus / hypotheses / entities;
* система умеет явно продолжать предмет анализа в рамках одной темы.
## 8.2. По retrieval
* generic cross-entity prompts больше не дают “почти полный” narrowed set без понижения confidence и ограничения depth;
* для проблемных route-классов работает broad-query guard;
* retrieval result содержит mechanism-aware evidence fields.
## 8.3. По ответу
* доля generic explanation заметно снижается;
* в ответе появляется конкретная механика дефекта там, где retrieval это реально подтвердил;
* ответ больше не строится вокруг labels, если есть mechanism fields;
* broad answer не выдаётся как strong factual conclusion.
## 8.4. По eval
* введены accountant-facing метрики;
* есть канонический benchmark suite;
* есть baseline before/after comparison.
## 8.5. По архитектурной чистоте
* stage 1 не вносит временных решений, противоречащих последующему ontology/lifecycle/problem-cluster переходу.
---
# 9. Что не считается результатом этапа
Это тоже надо жёстко зафиксировать.
Этап **не считается выполненным**, если произошло что-то из этого:
* просто улучшили wording ответов;
* просто добавили ещё labels в explanation;
* просто сделали narrowing чуть жёстче без broad-query policy;
* просто расширили session history;
* просто усилили промпт;
* просто добавили новые тесты без accountant eval metrics.
Потому что всё это даёт perceived progress, но не закрывает архитектурную задачу.
---
# 10. Практический идеальный результат этапа
Вот как надо понимать идеальный результат Этапа 1.
После него система **ещё не будет идеальным бухгалтерским ассистентом**.
Но она уже должна перестать быть:
* случайно умной,
* избыточно широкой,
* слишком label-driven,
* слишком route-centric,
* слишком chat-memory-based.
И должна стать:
* устойчивой в broad/focused режимах,
* способной удерживать предмет анализа,
* честной в ограничениях,
* механизмо-ориентированной в evidence,
* измеримой по бухгалтерской полезности.
---
# 11. Короткое управленческое резюме этапа
Если совсем сжато:
**Этап 1 — это не попытка построить бухгалтерский copilot.
Это этап приведения текущего explainable routed assistant к такому состоянию, в котором он перестаёт разваливаться на broad queries, перестаёт терять предмет расследования, начинает собирать mechanism-aware evidence и начинает измеряться по полезности для бухгалтера.
Именно после этого становится рационально переходить к следующему архитектурному слою: problem-cluster retrieval, lifecycle formalization и ontology graph.**
---
Следующим сообщением я могу сделать из этого уже **формальный документ ТЗ в жёсткой структуре** — с разделами “цель / границы / изменения по модулям / контракты / acceptance criteria / out of scope”, чтобы это можно было почти без переработки отдавать в работу.
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md
+985
View File
@@ -0,0 +1,985 @@
# ТЗ Этап 2 — Retrieval Unit Shift для Assistant Mode
Дата: 2026-03-24
Статус документа: рабочее ТЗ на второй этап развития бухгалтерского ассистента
Назначение: перевод Assistant Mode от entity-heavy retrieval к problem-centric retrieval и problem-centric answer layer
---
# 0. Смысл этапа
Этап 2 — это первый по-настоящему архитектурный поворот после Foundation Hardening.
Если Этап 1 должен сделать текущий контур устойчивее, честнее и полезнее для бухгалтера, то Этап 2 меняет саму **единицу смысла**, с которой ассистент работает при поиске, ранжировании и ответе.
До этого момента система в основном живёт вокруг сущностей:
- контрагент;
- документ;
- группа операций;
- набор записей вокруг счёта или контура;
- агрегированный риск-профиль по entity group.
Для бухгалтерского ассистента этого недостаточно. В большинстве реальных пользовательских вопросов предметом интереса является не сущность как таковая, а **механизм дефекта**, **разрыв цепочки**, **конфликтный узел**, **зависший участок жизненного цикла** или **группа связанных несогласованностей**.
Поэтому задача Этапа 2 — не просто “улучшить retrieval”, а перевести систему от модели:
**вопрос → поиск сущностей → ranking сущностей → ответ**
к модели:
**вопрос → поиск candidate evidence → сборка problem units → ranking problem units → ответ по problem units**
Это означает, что в Assistant Mode появляется новый обязательный архитектурный слой:
## Problem Unit Layer
Именно он должен стать переходом от explainable routed assistant к системе, которая начинает видеть бухгалтерские проблемы как самостоятельные объекты анализа.
---
# 1. Исходная точка этапа
К началу Этапа 2 система уже должна иметь результаты Этапа 1:
- baseline `investigation_state`;
- усиленный `semantic_retrieval_profile`;
- `mechanism-aware evidence pack`;
- `answer_policy_v1_1`;
- `decomposition_guardrail`;
- accountant-facing eval metrics;
- broad-query guard для generic prompts.
Этап 2 **не переписывает** эти сущности, а использует их как фундамент.
Этап 2 стартует из состояния, в котором:
- retrieval уже не является чистым GUID-or-full-scan;
- narrowing по explicit accounting scope уже работает заметно лучше;
- evidence pack уже богаче, чем на MVP-этапе;
- но dominant retrieval unit по-прежнему часто остаётся counterparty-heavy;
- explanation всё ещё склонен строиться вокруг entities, а не вокруг механизмов дефекта;
- broad causal questions всё ещё могут приводить к ответу “кто шумит”, а не “что сломано и почему”.
Именно это состояние является точкой входа для Этапа 2.
---
# 2. Целевая способность этапа
На выходе Этапа 2 система должна уметь не только находить релевантные бухгалтерские сущности, но и формировать **problem-centric view**.
В user-facing и internal retrieval логике базовой единицей ответа для problem/anomaly/chain/period-risk запросов должна стать не только сущность, а один из problem unit типов.
## Базовые target units второго этапа
1. `document_conflict`
2. `broken_chain_segment`
3. `lifecycle_anomaly_node`
4. `unresolved_settlement_cluster`
5. `period_risk_cluster`
6. `cross_branch_inconsistency_cluster`
После завершения этапа эти units должны стать first-class citizens в:
- retrieval output;
- normalized payload;
- ranking;
- answer composition;
- eval.
---
# 3. Что именно не устраивает в текущей архитектуре
## 3.1. Entity-heavy retrieval unit
Текущий dominant retrieval unit часто сводится к counterparty group, группе документов или aggregate-risk группе. Это допустимо для:
- quick ranking;
- первичного surfacing;
- общего operational scan.
Но это ломает качество ответа в вопросах вида:
- что именно разорвано в цепочке;
- что закрыто не тем документом;
- какая стадия lifecycle противоречива;
- что именно блокирует закрытие периода;
- где банк, документ и проводка живут отдельно;
- где проблема не в сумме, а в механике жизненного цикла.
Для этих вопросов entity-heavy top unit приводит к неправильному уровню abstraction. Пользователь получает:
- контрагента;
- счётчик документов;
- общие labels;
- общий risk summary.
Но не получает:
- сам механизм поломки;
- конкретный конфликт;
- точку разрыва;
- набор документов, образующих дефект;
- бухгалтерский смысл дефекта как problem object.
## 3.2. Explanation по-прежнему слишком завязан на entities
Даже при наличии более богатого evidence answer layer склонен собирать narrative вокруг “кто оказался в top”, а не вокруг “что именно сломалось”.
В результате появляется ложная глубина:
- labels становятся богаче;
- текст становится длиннее;
- retrieval narrowing становится аккуратнее;
- но для бухгалтера всё ещё неочевидно, где именно problem node.
## 3.3. Нет промежуточного слоя problem assembly
Между retrieval и answer synthesis сейчас недостаточно оформлен слой, который из отдельных:
- документов;
- проводок;
- relation hints;
- lifecycle hints;
- anomaly patterns;
- linked entities
собирал бы **одну бухгалтерскую проблему** как отдельный объект.
Пока этого нет, answer composer вынужден работать почти напрямую по retrieval entities и агрегациям. Это и есть главный архитектурный предел текущего контура.
---
# 4. Цель этапа в одной фразе
**Этап 2 переводит Assistant Mode от поиска и ранжирования сущностей к поиску, сборке, ранжированию и объяснению problem units как самостоятельных бухгалтерских объектов анализа.**
---
# 5. Основная архитектурная идея этапа
Этап 2 вводит между retrieval execution и final answer composition новый слой:
## Problem Unit Assembler
Именно этот слой должен:
- принимать candidate evidence от route executors;
- группировать его в problem-centric узлы;
- определять тип problem unit;
- собирать mechanism summary;
- собирать affected documents / postings / accounts / counterparties / contracts;
- вычислять severity;
- готовить ranking inputs;
- передавать наверх уже не только entities, но и problem objects.
После этого answer composer должен строить narrative уже от problem unit.
---
# 6. Что сохраняем на Этапе 2
На Этапе 2 не ломаем базу Этапа 1. Сохраняются:
- `assistant loop`;
- `normalizer_v2_0_2` и его successors без полной переписки;
- deterministic routing summary;
- `investigation_state` baseline;
- `semantic_retrieval_profile`;
- `mechanism-aware evidence pack`;
- `answer_policy_v1_1` как базовый policy layer;
- debug plane / trace logging / session logging;
- broad-query guard;
- accountant eval layer.
Этап 2 — это **надстройка архитектурной глубины**, а не слом текущего assistive loop.
---
# 7. Что меняем принципиально
На этом этапе принципиально меняются следующие узлы:
1. retrieval output model;
2. result normalization;
3. ranking model;
4. answer assembly logic for anomaly/chain/problem classes;
5. evaluation model for quality of problem identification.
То есть меняется не только “что retrieval нашёл”, но и **что считается итоговым объектом поиска**.
---
# 8. Проблемные единицы (problem units): полная предметная спецификация
Ниже перечислены problem unit типы, которые должны стать first-class retrieval units на этом этапе.
## 8.1. `document_conflict`
### Смысл
`document_conflict` — это problem unit, в котором конфликт сосредоточен вокруг документа или набора документов, играющих противоречивую роль в ожидаемой бухгалтерской цепочке.
### Когда возникает
- документ есть, но его тип не соответствует ожидаемой роли;
- документ формально подтверждает этап, но не тот этап, который должен быть закрыт;
- документ закрыл цепочку не тем способом;
- один документ противоречит другому в рамках expected flow;
- тип документа допустим технически, но бухгалтерски некорректен для конкретного механизма закрытия;
- документ связан с проводкой или движением так, что возникает смысловой конфликт между документным и учетным контуром.
### Примеры в бухгалтерском контексте
- закрытие расчёта прошло документом, не соответствующим ожидаемому settlement path;
- по банку есть отражение движения, но расчётный документ, который должен был подтвердить closure, не найден или найден документ иного класса;
- документ реализации/поступления в цепочке присутствует, но не подтверждает ту роль, которую system expected based on flow;
- в period close задействована ручная операция, которая подменяет ожидаемую типовую связку.
### Какие сущности из 1С обычно участвуют
- `Document_*` объекты из snapshot;
- журнал документов;
- linked recorder refs;
- register-related movements;
- payment / bank statement documents;
- realization / receipt / invoice docs;
- manual operations / adjustment docs;
- posting evidence.
### Какие связи обязательны
- `document_to_posting`;
- `statement_to_document`;
- `contract_to_documents`;
- expected document class vs actual document class.
### Какой вопрос этот unit должен закрывать
- чем именно этот документ конфликтен;
- какую роль он должен был играть;
- какую роль он играет фактически;
- почему это problem, а не просто запись по контрагенту.
---
## 8.2. `broken_chain_segment`
### Смысл
`broken_chain_segment` — это problem unit, в котором проблемой является не единичная сущность, а разрыв или дефект в expected accounting chain.
### Когда возникает
- шаги цепочки подтверждены не полностью;
- одна связь в expected flow не подтверждена;
- документы, проводки и регистры существуют, но не собираются в непротиворечивый segment;
- движение денег отделено от расчётного закрытия;
- документ есть, проводка есть, но chain continuity не доказана;
- ожидаемый next step не найден.
### Примеры в бухгалтерском контексте
- выписка есть, но корректное подтверждение расчётного closure не найдено;
- документ и проводка живут отдельно друг от друга;
- поступление и расчётный контур не дошли до ожидаемого завершения;
- запись в одном контуре есть, но соседний участок не подтверждает expected continuation.
### Какие сущности из 1С участвуют
- bank statements;
- settlement documents;
- postings;
- document journals;
- recorder refs;
- contracts;
- counterparties;
- associated registers.
### Какие relation patterns обязательны
- `payment_to_settlement`;
- `statement_to_document`;
- `document_to_posting`;
- `contract_to_documents`.
### Что должен уметь объяснить unit
- где именно chain breaks;
- какой шаг expected, но не найден;
- что подтверждено, а что нет;
- почему дефект относится к цепочке, а не к одной записи.
---
## 8.3. `lifecycle_anomaly_node`
### Смысл
`lifecycle_anomaly_node` — это problem unit для объектов, у которых ключевой дефект заключается в противоречивом, зависшем или неестественном жизненном цикле.
### Когда возникает
- объект завис между ожидаемыми стадиями;
- объект формально активен, но по смыслу уже должен был перейти дальше;
- жизненный цикл не завершён там, где ожидалось завершение;
- есть contradictory lifecycle signs;
- expected continuation missing.
### Ключевые бухгалтерские зоны
- `97` / расходы будущих периодов;
- ОС (`01/02/08`);
- авансы / расчёты;
- НДС / вычетный контур;
- period close affecting residual objects.
### Какие сущности участвуют
- object card / object-like document representation;
- amortization or writeoff signals;
- linked postings;
- document references;
- dates and period boundaries;
- close-related records.
### Примеры
- РБП живёт дольше ожидаемого срока списания;
- объект ОС принят, но следующий lifecycle stage не подтверждён или противоречив;
- начисления идут, а карточка/статус не подтверждают expected lifecycle;
- объект завис в промежуточной стадии перед close.
### Что unit должен уметь объяснить
- в какой стадии объект находится фактически;
- какая стадия ожидалась;
- почему это anomaly;
- чем это опасно для бухгалтера или close.
---
## 8.4. `unresolved_settlement_cluster`
### Смысл
Это cluster, в котором проблема живёт не в одном документе и не в одной записи, а в группе взаимосвязанных незакрытых, конфликтующих или спорящих settlement elements.
### Когда возникает
- несколько документов/платежей/связей претендуют на одно closure;
- есть незакрытая группа обязательств;
- payment path и settlement path расходятся на группе объектов;
- проблема повторяется в пределах одного контрагента, договора или расчётного участка;
- cluster нельзя корректно свести к одному document conflict.
### Где особенно важен
- расчёты с поставщиками (`60`);
- расчёты с покупателями (`62`);
- банковый и расчётный контур (`51/60`, `51/62`);
- прочие расчёты (`76`).
### Какие сущности участвуют
- counterparty;
- contract;
- payment docs;
- settlement docs;
- postings;
- bank statements;
- grouped residual/problem records.
### Что должно быть видно бухгалтеру
- что проблема не в одном объекте, а в cluster;
- какие документы и контуры в него входят;
- почему cluster unresolved;
- какой механизм незавершённости в нём доминирует.
---
## 8.5. `period_risk_cluster`
### Смысл
Это problem unit, в котором основным критерием значимости становится не просто anomaly, а влияние на закрытие периода и period-sensitive correctness.
### Когда возникает
- дефект затрагивает регламентные операции;
- есть residuals/разрывы, критичные для month-end;
- есть cluster, который не даёт корректно завершить period close;
- есть серия дефектов, которые individually невелики, но collectively опасны для закрытия.
### Какие сущности участвуют
- period close markers;
- closing operations;
- residual/problem records;
- deferred expenses;
- VAT-related records;
- unresolved settlements;
- lifecycle anomalies around period boundary.
### Что unit должен объяснить
- как именно эта проблема влияет на close;
- на какой период / boundary она ложится;
- это локальный хвост или systemic close risk.
---
## 8.6. `cross_branch_inconsistency_cluster`
### Смысл
Это cluster, в котором проблема проявляется как расхождение между соседними ветками учёта.
### Когда возникает
- один контур подтверждает наличие шага, другой — нет;
- документный контур и проводочный контур расходятся;
- расчётный и банковый контур не согласованы;
- карточка объекта и фактические начисления противоречат друг другу;
- налоговый контур и документный контур расходятся.
### Где это особенно важно
- банк / расчёты;
- ОС / начисления;
- НДС / документное основание;
- close / остатки / lifecycle-sensitive objects.
### Какие сущности участвуют
- минимум две ветки учёта;
- relation hints между ними;
- conflict evidence;
- documents/postings/register movements from both sides.
### Что unit должен объяснить
- какие ветки не согласованы;
- в чём именно противоречие;
- какая ветка говорит одно, а какая другое;
- почему это problem для бухгалтера.
---
# 9. Новый архитектурный слой: Problem Unit Assembler
## 9.1. Назначение
`ProblemUnitAssembler` — это обязательный backend-слой между route retrieval и final answer composition.
Его задача:
- принимать candidate evidence from executors;
- строить промежуточные problem hypotheses;
- агрегировать evidence в problem-centric объекты;
- нормализовать их в единый schema;
- передавать problem units в ranking pipeline и answer synthesis.
## 9.2. Почему нужен отдельный слой
Если просто попытаться “ранжировать problem units прямо в retrieval executor”, логика быстро расползётся:
- domain-specific heuristics смешаются с retrieval;
- answer layer по-прежнему будет видеть сырой payload;
- unit transition будет неполным;
- тестирование будет хуже.
Assembler нужен именно как отдельная ответственность:
- retrieval = найти candidate evidence;
- assembler = понять, какие evidence образуют одну проблему;
- ranking = определить приоритет problem unit;
- answer layer = объяснить problem unit бухгалтеру.
## 9.3. Входные данные assembler
Assembler должен принимать:
- normalized retrieval items;
- relation pattern hits;
- anomaly patterns;
- mechanism-aware evidence fields;
- selected route metadata;
- current `investigation_state` focus;
- ranking basis;
- confidence hints.
## 9.4. Выходные данные assembler
Assembler должен отдавать список `problem_units`.
Каждый problem unit должен включать:
- `problem_unit_id`
- `problem_unit_type`
- `title`
- `mechanism_summary`
- `business_defect_class`
- `severity`
- `confidence`
- `affected_entities`
- `affected_documents`
- `affected_postings`
- `affected_accounts`
- `affected_counterparties`
- `affected_contracts`
- `expected_state`
- `actual_state`
- `failed_expected_edge`
- `period_impact`
- `evidence_pack`
- `entity_backlinks`
- `requires_neighbor_check`
- `snapshot_limitations`
## 9.5. Базовая логика сборки
Assembler обязан работать в несколько шагов:
### Шаг 1. Candidate evidence clustering
Группировка candidate evidence по:
- общим документам;
- общим expected/actual mechanism patterns;
- общему settlement path;
- общему lifecycle defect signature;
- пересекающимся contracts/counterparties/accounts;
- period boundary.
### Шаг 2. Problem hypothesis detection
Для каждой candidate cluster assembler пытается понять, является ли cluster:
- document conflict;
- broken chain;
- lifecycle anomaly;
- unresolved settlement;
- period risk;
- cross-branch inconsistency.
### Шаг 3. Problem normalization
Cluster превращается в normalized problem unit.
### Шаг 4. Duplicate collapse
Разные evidence, относящиеся к одной и той же проблеме, должны быть collapsed в один problem unit.
### Шаг 5. Severity scoring inputs
На unit наслаиваются severity и ranking signals.
---
# 10. Схема данных problem unit
Ниже — обязательный target schema второго этапа.
```json
{
"problem_unit_id": "pu_...",
"problem_unit_type": "document_conflict",
"title": "Платёж отражён, но ожидаемое закрытие обязательства не подтверждено",
"mechanism_summary": "По цепочке payment -> settlement closure найдено отражение оплаты, но не подтверждён ожидаемый документный шаг закрытия",
"business_defect_class": "wrong_closure_path",
"severity": {
"score": 0.0,
"grade": "high"
},
"confidence": {
"score": 0.0,
"grade": "medium"
},
"affected_entities": [],
"affected_documents": [],
"affected_postings": [],
"affected_accounts": [],
"affected_counterparties": [],
"affected_contracts": [],
"expected_state": "closure by linked settlement chain",
"actual_state": "payment reflected without confirmed closure edge",
"failed_expected_edge": "statement_to_document -> payment_to_settlement",
"period_impact": {
"is_period_sensitive": true,
"impact_class": "close_risk"
},
"requires_neighbor_check": true,
"snapshot_limitations": [],
"evidence_pack": [],
"entity_backlinks": []
}
```
Эта схема должна быть реализована как first-class backend contract.
---
# 11. Ranking второго этапа
## 11.1. Общий принцип
Ranking больше не должен быть entity-first.
На этом этапе ranking должен отвечать на вопрос:
**какая problem unit важнее для бухгалтера**, а не **какая entity чаще всплыла**.
## 11.2. Базовые ranking factors
Для problem unit ranking обязателен набор факторов:
- mechanism severity;
- confidence of mechanism;
- period impact;
- repeatability;
- cross-branch involvement;
- number of affected documents/postings;
- unresolved state persistence;
- financial impact (не единственный и не всегда доминирующий);
- settlement criticality;
- lifecycle defect severity;
- manual intervention suspicion;
- cluster completeness.
## 11.3. Особое правило
Если пользователь explicitly спрашивает про:
- wrong document type;
- lifecycle defect;
- chain break;
- period close impact;
то ranking **не имеет права** доминировать по amount/frequency alone.
## 11.4. Mixed-unit transition policy
На втором этапе допускается mixed ranking:
- primary ranking unit = problem unit;
- secondary context = entity context (counterparty/document/account).
Но итоговый answer layer должен строиться от problem unit.
---
# 12. Изменения по модулям и слоям
## 12.1. `assistantDataLayer.ts` / route executors
### Что не меняем
- существующие route executors;
- semantic retrieval profile;
- retrieval narrowing logic как базу.
### Что добавляем
- обязательный output contract для candidate evidence;
- более жёсткую нормализацию relation pattern evidence;
- grouping-friendly identifiers;
- explicit expected/actual fields;
- normalized document references suitable for clustering.
### Что важно
Executors на этом этапе **не должны** превращаться в полноценные graph reasoners. Их задача — готовить candidate evidence, а не подменять assembler.
---
## 12.2. Новый модуль `problemUnitAssembler`
### Назначение
Собирает problem units из candidate evidence.
### Обязательные подфункции
- `clusterCandidateEvidence(...)`
- `detectProblemUnitType(...)`
- `buildProblemUnit(...)`
- `collapseDuplicates(...)`
- `scoreProblemSeverity(...)`
- `linkBackToEntities(...)`
### Что должно быть отдельно
Domain helpers могут быть вынесены в:
- bank/settlements;
- suppliers/customers;
- deferred expenses;
- fixed assets;
- VAT;
- period close.
Но core assembler должен оставаться общим.
---
## 12.3. `resultNormalization`
### Что меняем
Normalized payload должен научиться содержать два уровня:
- `raw_entities`
- `problem_units`
Для backward compatibility entity payload сохраняется.
### Новый принцип
Answer layer для определённых query classes работает прежде всего по `problem_units`.
---
## 12.4. `answerComposer`
### Что меняем
Composer должен получить новый режим сборки:
- direct factual / entity mode;
- problem-centric mode.
### Когда использовать problem-centric mode
- chain/anomaly questions;
- wrong-document questions;
- period-risk questions;
- lifecycle questions;
- cross-branch inconsistency questions.
### Новый narrative order
Для problem-centric mode answer composer обязан строить ответ в порядке:
1. problem unit;
2. mechanism;
3. affected documents/entities;
4. why this matters;
5. limitation / confidence;
6. next check.
### От чего отказываемся
От top-entity narrative по умолчанию для chain/anomaly/period-risk routes.
---
## 12.5. `assistantSessionStore` / session model
### Что меняем
`investigation_state` должен уметь хранить ссылки не только на entities, но и на `problem_units`.
### Что добавляем
- `active_problem_units`
- `resolved_problem_units`
- `problem_unit_backlinks`
- `investigation_focus.problem_types`
### Зачем
Чтобы follow-up мог продолжать анализ уже не по entities alone, а по problem structure.
---
## 12.6. Eval / benchmark harness
### Что добавляем
Новые метрики второго этапа:
- `problem_unit_precision`
- `problem_unit_recall_proxy`
- `duplicate_collapse_rate`
- `mechanism_coherence_score`
- `problem_clarity_score`
- `problem_first_answer_rate`
- `entity_leakage_rate`
### Новый benchmark suite
Канонические сценарии должны проверять, что top ответа — это problem unit, а не просто entity group.
---
# 13. Предметная привязка к данным 1С
Второй этап должен быть не абстрактным AI-слоем, а слоем, который структурно использует реальные сущности, забираемые из 1С snapshot/access contour.
## 13.1. Базовые типы данных, которые должны участвовать в problem assembly
### Документы
- банковские документы;
- платёжные документы;
- поступление товаров/услуг;
- реализация;
- счёт-фактура;
- корректировки;
- ручные операции;
- документы, связанные с РБП;
- документы ОС;
- close/period-sensitive docs.
### Проводки
- posting evidence;
- posting contexts;
- account hits;
- expected account-role vs actual account-role.
### Регистры
- VAT-related register records;
- accumulation/register evidence;
- other record types available in snapshot.
### Справочные сущности
- контрагент;
- договор;
- организация;
- ответственное лицо;
- объект ОС;
- object-like identifiers from snapshot.
### Периодные поля
- даты;
- boundary markers;
- period-sensitive groupings.
## 13.2. Как использовать эти данные
Нельзя ограничиться тем, чтобы просто передать их в answer layer.
Нужно:
- сгруппировать их в problem-centric clusters;
- определить, какая комбинация документов и проводок образует defect class;
- определить expected flow и actual flow;
- показать, как 1С-объекты подтверждают mechanism.
---
# 14. Реализация по классам бухгалтерских контуров
На Этапе 2 не надо покрывать всю бухгалтерию одинаково глубоко. Но нужно выбрать ключевые контуры, в которых problem-centric retrieval особенно нужен.
## 14.1. Банк / расчёты (`51/60`, `51/62`)
### Почему это P0-домен
Именно здесь чаще всего видны:
- wrong closure path;
- chain breaks;
- settlement inconsistencies;
- bank/document/posting divergence.
### Что должно появиться
- `document_conflict` по wrong closure type;
- `broken_chain_segment` для bank → document → settlement;
- `unresolved_settlement_cluster` по payment + closure mismatch.
---
## 14.2. Поставщики / покупатели (`60`, `62`, `76`)
### Что должно появиться
- clusters незакрытых расчётов;
- conflict groups, где несколько документов и оплат спорят между собой;
- problem units по repeated settlement issues.
---
## 14.3. `97` / deferred expenses
### Что должно появиться
- `lifecycle_anomaly_node`;
- period-sensitive risk cluster;
- explicit expected/actual lifecycle description.
---
## 14.4. ОС (`01/02/08`)
### Что должно появиться
- lifecycle anomaly units;
- cross-branch inconsistency between card/state and actual accounting behavior;
- period-sensitive risk where relevant.
---
## 14.5. НДС / tax-related cross-branch zones
### Что должно появиться
- `cross_branch_inconsistency_cluster`;
- problem unit between document basis and tax reflection;
- period-close-sensitive tax risk clusters where evidence supports it.
---
# 15. Порядок выполнения внутри этапа
Чтобы этап не расползся, он должен идти в строгой последовательности.
## Шаг 1. Спецификация problem units
Нужно зафиксировать:
- полный schema;
- типы units;
- базовые domain mappings;
- ranking inputs;
- answer requirements.
## Шаг 2. Candidate evidence contract hardening
Executors и normalization должны начать отдавать grouping-friendly evidence.
## Шаг 3. Реализация Problem Unit Assembler
Assembler должен появиться как отдельный backend service.
## Шаг 4. Mixed ranking
Переход от entity-first ranking к problem-first ranking.
## Шаг 5. Problem-centric answer mode
Answer composer должен уметь строить narrative от problem units.
## Шаг 6. Benchmarks и eval
Проверяем, что система реально стала problem-centric, а не только переименовала top entities.
---
# 16. Что не делаем на этапе 2
На этом этапе **не надо**:
- строить полный ontology graph;
- строить полный lifecycle engine с state machine по всем доменам;
- строить full investigation orchestrator;
- строить live verification bridge;
- охватывать абсолютно все бухгалтерские домены одинаково глубоко;
- превращать assembler в rule engine уровня полной онтологии;
- просто переименовывать entity groups в problem clusters без смены mechanics.
Особенно важно:
## Нельзя считать этап выполненным, если
- top retrieval unit всё ещё по сути entity-heavy;
- answer всё ещё строится вокруг counterparty/doc counts;
- problem cluster является только косметической группировкой;
- mechanism summary не лучше старых risk labels.
---
# 17. Критерии приёмки
Этап 2 считается принятым только если выполнены все условия ниже.
## 17.1. Архитектурные критерии
- реализован отдельный `ProblemUnitAssembler`;
- существует backend schema `problem_unit`;
- normalized payload поддерживает `problem_units`;
- session state умеет ссылаться на active/resolved problem units.
## 17.2. Retrieval criteria
- для key domains retrieval output может быть assembled в problem units;
- duplicate entity evidence collapse работает;
- ranking problem units работает отдельно от pure entity ranking.
## 17.3. User-facing criteria
- на вопрос “что именно сломано” top ответа — problem unit, а не просто entity group;
- ответ показывает механизм дефекта;
- ответ показывает затронутые документы/цепочки;
- ответ показывает, почему это проблема, а не просто кто оказался в top.
## 17.4. Accounting-domain criteria
Минимум в ключевых доменах должны быть рабочие problem units:
- bank/settlement chain;
- supplier/customer unresolved settlements;
- deferred expense lifecycle anomalies.
## 17.5. Eval criteria
- внедрены problem-centric metrics;
- benchmark suite показывает снижение entity-heavy leakage;
- есть before/after evidence по canonical scenarios.
---
# 18. Что не считается результатом этапа
Этап **не считается выполненным**, если сделано только одно из следующего:
- richer wording;
- grouping by counterparty with prettier labels;
- расширение current evidence pack без assembler;
- top-entity answer с новым названием “problem cluster”;
- новые шаблоны текста без смены retrieval unit.
Этап считается выполненным только в том случае, если problem unit действительно стал самостоятельной сущностью в архитектуре.
---
# 19. Идеальный результат этапа
После Этапа 2 система всё ещё не является финальным бухгалтерским copilot. Но она уже должна перестать быть ассистентом, который в основном знает “кто в top”, и начать быть ассистентом, который видит “что конкретно сломано”.
## На выходе этапа должно появиться:
- problem-centric retrieval;
- problem-centric ranking;
- problem-centric answer layer;
- problem-aware session continuity;
- measurable reduction of entity-heavy answers.
Это и есть первая настоящая архитектурная точка, после которой уже рационально переходить к:
- lifecycle formalization;
- ontology graph core;
- investigation engine.
---
# 20. Короткий итог
**Этап 2 не про то, чтобы лучше искать сущности. Он про то, чтобы научить систему искать, собирать, ранжировать и объяснять бухгалтерские проблемы как отдельные объекты.**
Без этого перехода дальнейшая формализация lifecycle и ontology graph будет подниматься наверх в виде всё тех же top-entities, а не problem reasoning.
Именно поэтому Этап 2 является критическим мостом между Foundation Hardening и взрослой бухгалтерской reasoning-архитектурой.
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md
+1043
View File
File diff suppressed because it is too large Load Diff
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md
+912
View File
@@ -0,0 +1,912 @@
# ТЗ Этап 4
## Accounting Ontology Graph Core для Assistant Mode
## 0. Смысл этапа
Этот этап не является попыткой «нарисовать онтологию бухгалтерии» как красивую абстракцию.
Его задача — ввести **рабочее графовое ядро бухгалтерской предметной области**, которое станет общим причинно-следственным слоем для:
- retrieval;
- lifecycle resolution;
- problem unit assembly;
- cross-branch analysis;
- investigation mode следующего этапа;
- future live verification bridge.
На предыдущих этапах система уже должна получить:
- усиленный текущий контур Assistant Mode;
- `investigation_state` baseline;
- mechanism-aware evidence pack;
- accountant-facing eval layer;
- problem-centric retrieval unit;
- lifecycle formalization по ключевым доменам.
Но даже после этого система всё ещё рискует мыслить слишком локально:
через набор сущностей, признаков, стадий и эвристических связок.
Чтобы перейти к следующему уровню reasoning, системе нужен **единый causal representation layer**, в котором:
- документ существует не сам по себе;
- проводка существует не сама по себе;
- контрагент не является главным контейнером смысла;
- lifecycle не живёт отдельно от связей;
- проблема существует как узел или подграф, а не как случайная выдача рядом лежащих сущностей.
Именно это и является предметом Этапа 4.
---
## 1. От чего идём: целевая способность системы
Если смотреть от конечной цели назад, то после Этапа 4 бухгалтерский ассистент должен приобрести следующую новую способность:
**работать не только с сущностями, problem units и lifecycle defects, а с типизированным графом бухгалтерской реальности, по которому можно проходить причинные маршруты, находить отсутствующие/конфликтующие связи и поднимать соседние ветки как архитектурно нормальную операцию.**
Это означает, что система должна уметь:
1. представлять бухгалтерские объекты как типизированные графовые узлы;
2. представлять связи между ними как типизированные рёбра, а не как общую “связанность”;
3. поддерживать причинные маршруты между документами, проводками, расчётами, налоговыми следствиями, lifecycle-переходами и влиянием на период;
4. использовать этот граф в runtime, а не только в документации;
5. улучшать retrieval, lifecycle reasoning и problem assembly именно за счёт graph layer.
---
## 2. Что не устраивает в текущем состоянии
По итогам предыдущих этапов у системы уже есть:
- нормализованные бухгалтерские сущности;
- semantic retrieval profile;
- problem-centric retrieval;
- lifecycle модели;
- evidence packs;
- answer policy;
- базовый investigation state.
Но даже в таком состоянии у неё остаются архитектурные ограничения:
### 2.1. Связи между сущностями ещё слишком локальны
Даже если retrieval находит правильную проблему, соседние сущности часто поднимаются:
- по фильтрам;
- по локальным relation patterns;
- по heuristics;
- по эвристическим rule bundles.
Это означает, что cross-domain traversal всё ещё слишком зависит от частных сценариев.
### 2.2. Нет единого пространства причинности
Сейчас причина и следствие часто живут в разных местах:
- проблема определяется в retrieval;
- lifecycle — в отдельном resolution слое;
- соседняя ветка подтягивается по дополнительным правилам;
- answer layer уже потом пытается из этого собрать narrative.
Без общего graph core такие reasoning-цепочки остаются хрупкими.
### 2.3. Missing/conflicting links ещё не являются first-class runtime objects
Пока разрыв связи зачастую определяется как:
- эвристика;
- дефект lifecycle;
- conflict label;
- absence of expected evidence.
Но система ещё не мыслит это как **типизированный дефект графа**:
- missing edge;
- invalid edge;
- conflicting edge;
- weakly supported edge;
- obsolete edge.
### 2.4. Investigation traversal ещё не имеет архитектурной базы
Следующий этап должен будет ввести полноценный investigation engine. Но без graph core этот движок будет вынужден жить на ad hoc secondary retrieval, а не на нормальном traversal.
---
## 3. Главная архитектурная цель этапа
К концу Этапа 4 система должна перейти из состояния:
**problem-centric assistant with lifecycle-aware reasoning**
в состояние:
**graph-backed accounting assistant, в котором retrieval, lifecycle и problem assembly опираются на единое causal representation бухгалтерских сущностей и связей.**
---
## 4. Что сохраняем, а что меняем
### 4.1. Что сохраняем
На этом этапе не ломаем уже построенные слои:
- `investigation_state` baseline;
- `semantic_retrieval_profile`;
- broad-query guard;
- mechanism-aware evidence pack;
- problem unit layer;
- lifecycle registry и lifecycle resolver;
- accountant-facing eval harness;
- answer contract предыдущих этапов.
Graph core должен встроиться **под** эти слои и усилить их, а не заменить весь контур с нуля.
### 4.2. Что меняем принципиально
На этом этапе меняем:
1. модель внутренних сущностей;
2. модель связей;
3. runtime-слой, который формирует causal representation;
4. retrieval execution для graph-eligible queries;
5. problem assembly, чтобы он использовал graph connectivity;
6. lifecycle reasoning, чтобы он использовал graph-backed transitions;
7. eval layer, чтобы она умела доказывать ценность graph layer.
### 4.3. От чего отказываемся
На этом этапе нужно осознанно отказаться от следующих паттернов:
- retrieval “по соседству” без явной модели связей;
- implicit relation semantics, зашитой в случайные правила;
- ad hoc cross-branch checks без graph traversal;
- формальной онтологии, которая не участвует в runtime;
- мысли о том, что graph = просто JSON-структура для объяснения.
---
## 5. Главные сущности этапа
Ниже — ключевые сущности Этапа 4. Не в виде пустого списка, а с объяснением, зачем они нужны, как связаны с бухгалтерией и как должны работать в архитектуре.
---
## 5.1. Сущность №1 — `AccountingGraphNode`
### Почему нужна
Система не может делать устойчивый traversal, пока объекты учёта существуют только как плоские normalized items.
Нужен единый типизированный контейнер для сущности в graph layer.
### Что это такое
`AccountingGraphNode` — это базовая графовая сущность, представляющая конкретный бухгалтерский объект или агрегированную аналитическую единицу.
### Базовые поля
- `node_id`
- `node_type`
- `source_type`
- `source_id`
- `domain`
- `subdomain`
- `attributes`
- `period_scope`
- `organization_scope`
- `confidence`
- `provenance`
- `temporal_markers`
- `lifecycle_binding`
- `graph_status`
### Какие типы узлов должны быть поддержаны
#### Документные узлы
- `BankStatementDocument`
- `PaymentOrderDocument`
- `ReceiptDocument`
- `SalesDocument`
- `InvoiceDocument`
- `AdjustmentDocument`
- `DeferredExpenseDocument`
- `AssetAcceptanceDocument`
- `AssetCommissioningDocument`
- `DepreciationDocument`
- `PeriodCloseOperation`
- `ManualOperationDocument`
#### Учётные узлы
- `Posting`
- `RegisterMovement`
- `Account`
- `Subaccount`
- `TaxEntry`
- `VATPosition`
- `DeferredExpensePosition`
- `AssetCard`
- `SettlementPosition`
- `ReceivablePosition`
- `PayablePosition`
#### Бизнес-узлы
- `Counterparty`
- `Contract`
- `Organization`
- `Department`
- `Project`
- `Warehouse`
- `Nomenclature`
- `AssetObject`
#### Аналитические узлы
- `ProblemUnit`
- `LifecycleStateNode`
- `PeriodRiskNode`
- `InvestigationFocusNode`
### Зачем это нужно бухгалтерски
В 1С одна и та же проблема часто размазана по разным слоям:
- документ;
- проводка;
- регистр;
- расчётная позиция;
- контрагент;
- договор;
- период;
- налоговое следствие.
Пока эти объекты не приведены к единому узловому представлению, система не может делать нормальный causal traversal.
---
## 5.2. Сущность №2 — `AccountingGraphEdge`
### Почему нужна
Graph без typed edges — это не рабочая причинная модель, а просто связанный список объектов.
### Что это такое
`AccountingGraphEdge` — типизированная связь между двумя graph nodes с чётким смыслом, confidence и provenance.
### Базовые поля
- `edge_id`
- `edge_type`
- `from_node_id`
- `to_node_id`
- `direction`
- `attributes`
- `confidence`
- `provenance`
- `is_expected`
- `is_observed`
- `is_conflicting`
- `is_missing_marker`
- `temporal_markers`
### Базовые классы рёбер
#### Документно-учётные связи
- `creates_posting`
- `affects_register`
- `references_document`
- `based_on_document`
- `generated_from`
- `belongs_to_period`
#### Расчётные связи
- `settles`
- `partially_settles`
- `linked_to_payment`
- `linked_to_receivable`
- `linked_to_payable`
- `linked_to_contract`
#### Lifecycle-связи
- `advances_to_state`
- `expected_next_state`
- `conflicts_with_state`
- `closes`
- `writes_off`
- `commissions`
- `depreciates`
#### Cross-domain связи
- `affects_vat`
- `affects_period_close`
- `depends_on_branch`
- `conflicts_with_branch`
- `requires_neighbor_check`
#### Проблемно-аналитические связи
- `evidence_for_problem`
- `part_of_problem_cluster`
- `supports_hypothesis`
- `contradicts_hypothesis`
### Зачем это нужно бухгалтерски
Для бухгалтера важно не только наличие объектов, а смысл связи между ними:
- документ создал проводку;
- платёж должен закрывать обязательство;
- РБП должно перейти в списание;
- ввод ОС должен вести к амортизации;
- счёт-фактура должна вести к налоговому следствию;
- один контур влияет на закрытие другого.
Именно эти причинные связи и должны стать first-class runtime objects.
---
## 5.3. Сущность №3 — `GraphSchemaRegistry`
### Почему нужна
Если node/edge типы живут в коде фрагментами, система быстро превратится в набор несогласованных graph rules.
### Что это такое
Единый реестр graph schema, где определяются:
- допустимые node types;
- допустимые edge types;
- обязательные атрибуты;
- domain bindings;
- lifecycle bindings;
- expected graph patterns;
- graph validation rules.
### Что он должен содержать
Для каждого node type:
- required attributes;
- optional attributes;
- provenance sources;
- domain membership;
- period semantics;
- lifecycle compatibility.
Для каждого edge type:
- допустимые типы from/to;
- допустимость направлений;
- допустимость по домену;
- допустимость по lifecycle;
- confidence policy;
- missing-edge semantics.
### Зачем это нужно
Чтобы graph оставался управляемой архитектурной системой, а не хаотичным набором типов и связей.
---
## 5.4. Сущность №4 — `GraphBuilder`
### Почему нужна
Graph schema без runtime-построения — это формальная документация, а не архитектурный слой.
### Что это такое
`GraphBuilder` — runtime-компонент, который из normalized accounting entities, lifecycle outputs и relation evidence строит graph core.
### Что он принимает на вход
- normalized documents;
- postings;
- register movements;
- domain-specific entities;
- lifecycle resolution outputs;
- problem assembly signals;
- source provenance metadata.
### Что он делает
1. создаёт graph nodes;
2. создаёт typed edges;
3. маркирует expected vs observed relations;
4. создаёт missing/conflicting edge markers;
5. формирует graph layer для retrieval/problem assembly/investigation;
6. присваивает confidence и provenance.
### Что важно
GraphBuilder не должен быть чисто offline-процедурой “раз в день”.
На этапе 4 допускается snapshot-based build, но он должен быть встроен в рабочий assistant runtime как доступный слой.
---
## 5.5. Сущность №5 — `GraphTraversalPolicy`
### Почему нужна
Наличие graph само по себе не означает, что система умеет им пользоваться.
### Что это такое
Политика traversal по graph layer для разных классов задач.
### Какие типы traversal должны быть поддержаны
#### Upstream traversal
От проблемы назад к причинам.
#### Downstream traversal
От объекта вперёд к последствиям.
#### Cross-domain traversal
Из одного домена в другой:
- банк → расчёты;
- документ → НДС;
- объект → период;
- документ → lifecycle state;
- issue → affected branches.
#### Period-impact traversal
Поиск того, как локальная проблема влияет на закрытие периода.
#### Neighbor-branch traversal
Переход в соседнюю ветку учёта для усиления доказательной базы.
### Что важно
Traversal не должен быть свободным «гулянием по графу». Нужны жёсткие policies:
- allowed traversal depth;
- allowed edge families;
- purpose-specific traversal;
- stop criteria;
- evidence sufficiency rules.
---
## 5.6. Сущность №6 — `GraphBackedProblemAssembly`
### Почему нужна
Problem unit layer второго этапа не должен оставаться чисто эвристическим, если мы уже строим graph core.
### Что это такое
Слой problem assembly, который использует graph connectivity и graph defects как основу для формирования problem units.
### Что меняется по сравнению с этапом 2
Раньше problem unit собирался в основном из:
- retrieval entities;
- relation patterns;
- lifecycle defects;
- evidence pack fields.
Теперь problem unit должен собираться также из:
- graph-connected nodes;
- missing edges;
- conflicting edges;
- weakly supported paths;
- graph neighborhoods;
- branch crossings.
### Что это даёт
- более чёткое отделение одной проблемы от другой;
- более сильное объяснение broken chain;
- better cross-branch inconsistency detection;
- better duplicate collapse;
- better evidence completeness.
---
## 5.7. Сущность №7 — `GraphBackedLifecycleBinding`
### Почему нужна
Lifecycle formalization из этапа 3 должна опираться на graph, а не существовать как отдельная state machine поверх плоских данных.
### Что это такое
Связь lifecycle registry/runtime с graph core.
### Что должно происходить
- lifecycle state node должен быть связан с domain object;
- expected transitions должны отображаться через expected edges;
- observed transitions должны отображаться через observed edges;
- missing transition = missing expected edge;
- invalid transition = conflicting edge pattern.
### Что это даст
Lifecycle становится не только временной логикой, но и логикой структурных переходов в графе.
---
## 5.8. Сущность №8 — `GraphProvenanceLayer`
### Почему нужна
В бухгалтерии нельзя строить reasoning по графу без ясного понимания, откуда взялась каждая связь.
### Что это такое
Слой provenance для nodes и edges.
### Что должен хранить
- источник (snapshot / live / inferred / derived);
- origin entity ids;
- confidence source;
- timestamp / period;
- inference path;
- lifecycle dependence;
- conflict flags.
### Зачем это нужно
Иначе graph будет выглядеть умно, но не будет доказуемым и пригодным для бухгалтерского ассистента.
---
## 5.9. Сущность №9 — `GraphValidationLayer`
### Почему нужна
Самый большой риск этапа — построить formal graph, который runtime почти не улучшает.
### Что это такое
Слой валидации graph core по двум осям:
1. structural validity;
2. product value validity.
### Structural validity
- корректность node/edge типов;
- корректность доменных связей;
- корректность confidence/provenance;
- отсутствие невалидных типов связей;
- отсутствие циклов там, где они запрещены.
### Product value validity
- улучшил ли graph causal retrieval;
- улучшил ли graph cross-branch reasoning;
- улучшил ли graph problem unit precision;
- улучшил ли graph lifecycle explanation;
- улучшил ли graph answer usefulness.
---
## 6. Домены этапа 4
Graph core должен строиться не для всей бухгалтерии сразу, а для ключевых доменов, уже подготовленных предыдущими этапами.
### 6.1. Банк / расчёты / 51–60
Узлы:
- выписка;
- платёжное поручение;
- проводка;
- settlement position;
- payable position;
- counterparty;
- contract.
Связи:
- payment ↔ statement;
- statement ↔ posting;
- payment ↔ settlement;
- settlement ↔ contract;
- settlement ↔ payable closure.
### 6.2. Покупатели / 62
Узлы:
- реализация;
- оплата;
- receivable position;
- contract;
- tax entry.
Связи:
- sales ↔ posting;
- payment ↔ receivable;
- receivable ↔ contract;
- sales ↔ VAT effect.
### 6.3. РБП / 97
Узлы:
- deferred expense document;
- deferred expense position;
- writeoff movement;
- period;
- supporting basis.
Связи:
- basis ↔ deferred expense;
- deferred expense ↔ writeoff;
- writeoff ↔ period;
- deferred expense ↔ lifecycle state.
### 6.4. ОС / 08–01–02
Узлы:
- asset acceptance document;
- asset commissioning document;
- asset card;
- depreciation movement;
- asset object.
Связи:
- acceptance ↔ asset card;
- commissioning ↔ asset object;
- asset object ↔ depreciation;
- capitalized value ↔ commissioned asset.
### 6.5. НДС / 19–68
Узлы:
- invoice;
- tax entry;
- VAT position;
- source document;
- period.
Связи:
- source document ↔ invoice;
- invoice ↔ VAT position;
- VAT position ↔ tax entry;
- VAT position ↔ period.
### 6.6. Закрытие периода
Узлы:
- period close operation;
- affected problem unit;
- affected domain object;
- period risk node.
Связи:
- domain object ↔ period close;
- problem unit ↔ period risk;
- unresolved chain ↔ close blocker.
---
## 7. Что именно меняется по цепи выполнения
---
## 7.1. Вход данных
### Сейчас
Система получает normalized accounting entities из snapshot/assistant data layer.
### Что меняем
После normalized entity layer вводится graph construction layer.
### Новый фрагмент контура
`Normalized entities → GraphBuilder → Graph core → retrieval / lifecycle / problem assembly / answer`
### Цель
Сделать graph не параллельной документацией, а рабочим промежуточным слоем.
---
## 7.2. Retrieval planning
### Сейчас
Retrieval planning строится на semantic profile и domain-specific filters.
### Что меняем
Добавляем `graph_eligibility` и `graph_traversal_policy` в retrieval plan.
### Что должно появиться
- для causal queries;
- для cross-branch queries;
- для period-impact queries;
- для neighbor-check-worthy problem units.
Retrieval planner должен уметь решать:
- нужен ли graph traversal;
- какой traversal type нужен;
- какая глубина допустима;
- какие edge families допустимы.
---
## 7.3. Retrieval execution
### Сейчас
Execution основан на semantic narrowing + problem-centric extraction.
### Что меняем
В graph-eligible режимах retrieval должен использовать:
- node lookup;
- typed edge traversal;
- missing/conflicting edge detection;
- graph neighborhood assembly.
### Что важно
Graph-backed retrieval не заменяет фильтры. Он расширяет их там, где нужен causal traversal.
---
## 7.4. Lifecycle reasoning
### Сейчас
Lifecycle работает по domain state models и evidence.
### Что меняем
Lifecycle resolver должен использовать graph edges для:
- проверки ожидаемых переходов;
- проверки observed transitions;
- маркировки missing/invalid transitions;
- cross-branch consistency.
---
## 7.5. Problem assembly
### Сейчас
Problem units собираются по evidence и relation patterns.
### Что меняем
Assembler должен использовать graph connectivity как первичный или равноправный признак assembly.
### Что это значит practically
Если есть broken chain, то assembler должен видеть:
- какие узлы входят в цепочку;
- какая связь отсутствует;
- какая связь конфликтует;
- какие соседние узлы усиливают проблему.
---
## 7.6. Answer synthesis
### Сейчас
Answer layer строит narrative по problem units и lifecycle-enriched evidence.
### Что меняем
Composer должен уметь включать graph-backed explanation fragments:
- между какими сущностями найден разрыв;
- какая ожидаемая связь отсутствует;
- какая ветка противоречит другой;
- как проблема проходит по causal path.
### Цель
Сделать explanation не просто case-specific, а структурно причинным.
---
## 8. Как не уткнуться в главный риск этапа
Пользователь специально просил отдельно раскрыть, как не скатиться в формальный этап. Это критично.
### Главный риск
Сделать онтологию как формальную схему, которую можно красиво показать, но которая почти не влияет на runtime.
### Как это обычно выглядит
- список узлов описан;
- список рёбер описан;
- graph builder формально есть;
- maybe есть storage;
- но retrieval почти не поменялся;
- problem assembly почти не поменялся;
- answer quality почти не выросло.
### Как этого избежать
#### 1. Graph должен иметь runtime-critical use cases
С первого релиза этапа graph должен использоваться хотя бы в:
- broken chain detection;
- cross-branch inconsistency checks;
- period-impact traversal;
- problem unit assembly.
#### 2. Нужно сразу доказать value, а не только correctness
Нужны before/after сценарии, где graph реально улучшает:
- causal answers;
- neighboring branch discovery;
- distinction between one problem and another;
- explanation clarity.
#### 3. Нельзя строить graph “вообще”
Graph schema должен строиться под уже существующие бухгалтерские домены и problem classes.
#### 4. Нельзя делать слабые edge types
“related_to” не подходит как основной тип связи.
Нужны typed edges с бухгалтерским смыслом.
#### 5. Нельзя оставлять provenance опциональным
Без provenance graph быстро превратится в недоказуемую inference-конструкцию.
#### 6. Нельзя считать этап успешным, если graph не вошёл в retrieval/problem assembly/lifecycle
Документация и storage сами по себе не считаются результатом.
---
## 9. Что должно быть переписано, а что только усилено
### Полностью переписывать на этапе 4 не надо
- весь assistant loop;
- normalizer;
- базовый routing engine;
- answer contract с нуля;
- lifecycle registry с нуля;
- problem unit layer с нуля.
### Существенно переделываем
- internal representation layer;
- relation semantics;
- graph-eligible retrieval execution;
- graph-backed problem assembly;
- lifecycle-to-graph binding;
- eval harness для graph value.
### Частично усиливаем
- evidence pack;
- traversal hints в retrieval profile;
- answer composer;
- investigation state integration.
### Оставляем на следующий этап
- полноценный investigation orchestrator;
- full branch automation;
- live verification bridge как core path;
- full enterprise graph beyond accounting core.
---
## 10. Архитектурные артефакты этапа
К концу этапа должны появиться следующие артефакты:
1. `AccountingGraphNode` schema
2. `AccountingGraphEdge` schema
3. `GraphSchemaRegistry`
4. `GraphBuilder` runtime spec
5. `GraphTraversalPolicy` spec
6. `GraphBackedProblemAssembly` spec
7. `GraphBackedLifecycleBinding` spec
8. `GraphProvenanceLayer` spec
9. `GraphValidationLayer` spec
10. domain graph definitions for selected accounting domains
11. graph-backed benchmark suite
12. graph value proof scenarios
---
## 11. Критерии приёмки этапа
Этап считается выполненным только при одновременном выполнении следующих условий.
### 11.1. По graph core
- есть рабочая node/edge schema;
- graph builder формирует runtime-usable graph;
- nodes и edges имеют provenance и confidence;
- graph покрывает agreed accounting domains.
### 11.2. По retrieval
- graph-eligible queries реально используют graph traversal;
- broken chain detection улучшается за счёт graph;
- cross-branch checks перестают быть чисто эвристическими;
- period-impact traversal использует graph relationships.
### 11.3. По problem assembly
- problem units собираются по graph connectivity, а не только по filter proximity;
- duplicate collapse quality улучшается;
- distinction between separate vs shared problem clusters становится лучше.
### 11.4. По lifecycle
- lifecycle resolver использует graph-backed transitions;
- missing/invalid transitions определяются через graph semantics;
- lifecycle explanation становится структурно точнее.
### 11.5. По answer usefulness
- ответы лучше объясняют, между чем и чем разрыв;
- ответы лучше показывают путь проблемы по связанным сущностям;
- ответы лучше поднимают соседние контуры и влияние на период.
### 11.6. По продуктовой ценности
- есть канонические сценарии before/after;
- доказано, что graph layer улучшает не только внутреннюю красоту, но и user-facing полезность.
---
## 12. Что не считается результатом этапа
Этап не считается выполненным, если произошло только что-то из этого:
- появилась formal ontology documentation;
- появилась graph storage representation;
- появились node/edge definitions, но runtime их почти не использует;
- graph builder есть, но retrieval/problem assembly почти не изменились;
- answers не стали заметно более причинными;
- graph оказался просто ещё одним способом сериализации старых entities.
---
## 13. Практический идеальный результат этапа
После завершения Этапа 4 система ещё не должна быть финальным бухгалтерским copilot.
Но она уже должна перестать быть:
- набором локальных retrieval и lifecycle правил;
- системой, которая тянет соседние сущности в основном по эвристике;
- assistant’ом, который знает problem units, но не имеет общего пространства связей.
И должна стать:
- graph-backed accounting assistant;
- системой, в которой causal traversal является нормальной архитектурной операцией;
- системой, где retrieval, lifecycle и problem assembly живут в одном пространстве типизированных связей;
- базой для Investigation Engine следующего этапа.
---
## 14. Короткое управленческое резюме этапа
**Этап 4 не строит “красивую онтологию”.
Он строит рабочее графовое ядро бухгалтерских сущностей и связей, чтобы retrieval, lifecycle reasoning и problem assembly опирались на единое causal representation.
Только после этого становится рационально строить полноценный investigation engine как следующий взрослый архитектурный слой.**
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_5_Investigation_Engine_Assistant_Mode.md
+1058
View File
File diff suppressed because it is too large Load Diff
docs/accounting-assistant/accounting-assistant/02_stages/TZ_Stage_6_Live_Verification_Product_Modes_Assistant_Mode.md
+985
View File
@@ -0,0 +1,985 @@
# ТЗ Этап 6 — Live Verification + Product Modes для Assistant Mode
## 0. Назначение этапа
Этап 6 завершает переход от архитектурного прототипа бухгалтерского ассистента к зрелой продуктовой системе.
Если предыдущие этапы строили внутреннюю способность системы понимать данные, поднимать problem units, формализовать lifecycle, работать через graph core и вести bounded investigation, то этот этап отвечает уже за другое:
- как ассистент работает в разных продуктовых режимах;
- когда он отвечает быстро, а когда запускает расследование;
- когда он может опираться на snapshot и inference, а когда обязан или должен рекомендовать live verification;
- как выполнять широкий audit / batch analysis, не превращая его в “очень длинный чат-ответ”;
- как формально различать уровни доверия к результату;
- как превратить reasoning-архитектуру в рабочий product contract.
Этап 6 не должен переписывать reasoning core.
Он должен сделать уже построенные слои:
- Foundation Hardening;
- Problem-centric Retrieval;
- Lifecycle Formalization;
- Accounting Ontology Graph Core;
- Investigation Engine;
— **общим основанием для трёх разных режимов продукта**.
---
## 1. Смысл этапа
### 1.1. От какой проблемы идём
До Этапа 6 ассистент уже может быть умным и архитектурно глубоким, но всё ещё может оставаться системой, у которой:
- один основной conversational loop;
- один базовый execution path;
- разная глубина ответа, но не разные режимы работы;
- нет формальной границы между direct answer, investigation и wide analysis;
- нет штатного слоя live verification;
- нет жёсткой модели доверия к результату.
Это означает, что даже сильный reasoning-движок остаётся продуктово не до конца оформленным.
### 1.2. Что должен решить этап
Этап 6 должен решить три системные задачи:
1. **развести execution modes**;
2. **ввести live verification как штатный runtime capability**;
3. **ввести trust / provenance model**, чтобы пользователь и система одинаково понимали, какой именно тип результата выдан.
---
## 2. Целевая способность системы после этапа
После завершения Этапа 6 ассистент должен поддерживать три полноценных режима:
### 2.1. Direct Answer Mode
Для локальных вопросов:
- что не бьётся;
- где разрыв;
- какие документы участвуют;
- почему объект завис;
- какие проблемы по конкретному счёту/контрагенту/объекту.
Система должна:
- отвечать быстро;
- не запускать сложное расследование без веской причины;
- уметь ограничить глубину;
- маркировать уровень уверенности;
- уметь рекомендовать escalation в investigation или live verification.
### 2.2. Investigation Mode
Для многосоставных и гипотезных вопросов:
- проверь несколько причин;
- сравни ветки;
- отдели локальный дефект от системного;
- покажи, что подтверждено;
- проверь влияние на соседний контур;
- разберись, почему всё выглядит неконсистентно.
Система должна:
- открыть investigation case;
- вести ветки и гипотезы;
- выполнять bounded multi-step flow;
- различать доказанное и вероятное;
- при необходимости запускать live verification;
- завершать расследование по формальным stop criteria.
### 2.3. Audit / Batch Analysis Mode
Для широких запросов:
- проведи полный анализ периода;
- найди системные дефекты;
- покажи recurring patterns;
- собери зоны риска;
- сгруппируй problem clusters;
- дай приоритеты для дальнейшей проверки.
Система должна:
- запускать отдельный batch pipeline;
- обрабатывать расширенный scope;
- собирать много problem units;
- агрегировать результаты;
- выдавать отчётный итог, а не обычный чат-ответ.
---
## 3. Что сохраняем, а что меняем
### 3.1. Что сохраняем
Этап 6 **не переписывает** уже построенные reasoning-слои. Он опирается на них как на substrate.
Сохраняются:
- semantic_retrieval_profile;
- mechanism-aware evidence pack;
- problem unit model;
- lifecycle knowledge layer;
- graph core;
- investigation case / hypothesis / branch / step model;
- bounded orchestration policy;
- answer contract;
- accountant-facing eval framework.
### 3.2. Что меняем принципиально
На Этапе 6 меняются:
- execution governance;
- mode selection;
- runtime contracts для различных режимов;
- provenance/trust model;
- способ живой верификации;
- отдельный audit pipeline;
- user-facing result contracts в зависимости от режима.
### 3.3. От чего отказываемся
На этом этапе нужно **сознательно отказаться** от скрытого предположения, что один и тот же pipeline может одинаково качественно обслуживать:
- быстрый factual вопрос;
- глубокое расследование;
- широкий аналитический прогон.
Это неверно.
Этап 6 официально фиксирует, что продукт имеет несколько execution modes, а не один loop с разной длиной ответа.
---
## 4. Архитектурная цель этапа
К концу Этапа 6 текущая система должна перейти из состояния:
**“сильный reasoning assistant с investigation capability”**
в состояние:
**“зрелый бухгалтерский copilot с явными execution modes, live verification и формальной моделью доверия к результату”**.
---
## 5. Главные сущности этапа
Ниже перечислены ключевые сущности Этапа 6 и детально объясняется, зачем каждая нужна, что с ней делается и как она встраивается в архитектуру.
---
## 5.1. Сущность №1 — `execution_mode`
### Почему нужна
До Этапа 6 режим работы ассистента чаще всего подразумевается неявно. Это допустимо на ранних этапах, но недопустимо для зрелой системы.
Если `execution_mode` не формализован, то система:
- отвечает одинаковым контуром на вопросы принципиально разной глубины;
- не может нормально управлять допустимой латентностью;
- не может формально различать allowed depth и stop policy;
- не может грамотно объяснять пользователю, почему в одном случае ответ быстрый, а в другом запускается расследование или audit.
### Что делаем
Вводим базовую продуктовую сущность `execution_mode`.
### Типы mode
- `direct_answer`
- `investigation`
- `audit_batch`
### Обязательные поля
- `mode_id`
- `mode_type`
- `allowed_depth`
- `allowed_branching`
- `allowed_secondary_checks`
- `live_verification_policy`
- `latency_profile`
- `output_contract`
- `stop_policy`
- `clarification_policy`
- `trust_display_policy`
### Что это даст
- система перестанет скрытно использовать один execution loop для всего;
- появится product-grade governance;
- можно будет жёстко различать не только ответы, но и внутреннюю стратегию исполнения.
---
## 5.2. Сущность №2 — `mode_router`
### Почему нужна
Semantic routing отвечает на вопрос: **по какому смысловому профилю искать и анализировать**.
Но этого недостаточно.
Нужен слой выше, который отвечает на вопрос:
- это быстрый direct answer?
- это investigation?
- это audit?
- требуется ли эскалация?
- разрешена ли live verification?
### Что делаем
Вводим `mode_router` как отдельный runtime-layer над semantic routing.
### Входы в `mode_router`
- исходный user query;
- decomposition result;
- query complexity;
- breadth estimate;
- expected evidence volume;
- active investigation_state;
- user intent markers;
- explicit requests типа “полный анализ”, “проверь глубоко”, “разберись”, “проведи аудит”, “сделай обзор”, “проверь гипотезу”;
- cost/latency policy.
### Выходы `mode_router`
- `execution_mode`
- `mode_confidence`
- `escalation_hint`
- `live_verification_allowed`
- `expected_output_contract`
### Что меняется по смыслу
До этого момента система в основном решала: **какой смысловой маршрут и какие retrieval constraints**.
Теперь она решает ещё и: **какой тип исполнения вообще уместен для данного запроса**.
---
## 5.3. Сущность №3 — `mode_transition_decision`
### Почему нужна
Даже если mode выбран на старте, в реальной работе ассистент может дойти до точки, где исходный режим перестаёт быть достаточным.
Примеры:
- direct answer упирается в противоречие и должен перейти в investigation;
- investigation упирается в snapshot-неопределённость и требует live verification;
- audit находит кластер высокой важности и предлагает drilldown;
- direct answer понимает, что вопрос фактически batch-scale.
### Что делаем
Вводим сущность `mode_transition_decision`.
### Поля
- `decision_id`
- `from_mode`
- `to_mode`
- `reason`
- `triggering_evidence`
- `confidence_before`
- `confidence_after`
- `user_visible`
- `accepted_automatically`
- `requires_user_confirmation`
### Что это даст
- режимы перестанут быть статичными;
- появится управляемая эскалация;
- переходы между режимами станут объяснимыми и контролируемыми.
---
## 5.4. Сущность №4 — `live_verification_request`
### Почему нужна
До Этапа 6 reasoning почти полностью опирается на:
- snapshot;
- normalized accounting entities;
- graph/lifecycle inference;
- investigation.
Но для части high-stakes кейсов этого недостаточно.
Нужен способ адресно проверять source-of-truth.
### Что делаем
Вводим `live_verification_request` как штатную сущность runtime.
### Поля
- `request_id`
- `case_id`
- `problem_unit_id`
- `source_entity_type`
- `source_entity_id`
- `verification_goal`
- `requested_fields`
- `verification_scope`
- `reason_for_verification`
- `urgency`
- `policy_basis`
- `status`
### Возможные цели verification
- подтвердить существование документа;
- подтвердить текущий статус;
- подтвердить наличие или отсутствие связи;
- подтвердить текущее состояние расчёта;
- подтвердить lifecycle stage;
- подтвердить периодную принадлежность;
- снять конфликт snapshot vs expected chain.
### Что важно
Live verification — это не новый способ reasoning с нуля.
Это механизм **подтверждения, эскалации и повышения доверия** к уже построенному reasoning.
---
## 5.5. Сущность №5 — `live_verification_result`
### Почему нужна
Недостаточно просто выполнить live-check.
Нужно, чтобы результат проверки влиял на кейс, доверие и итоговый ответ.
### Что делаем
Вводим `live_verification_result`.
### Поля
- `request_id`
- `verified_at`
- `verified_source`
- `verification_status`
- `verified_values`
- `missing_values`
- `discrepancies_vs_snapshot`
- `confidence_delta`
- `impact_on_problem_unit`
- `impact_on_hypothesis`
- `impact_on_case`
- `next_recommended_action`
### Что это даёт
- live verification становится частью расследования, а не внешней справкой;
- можно объяснять пользователю, что именно подтверждено живыми данными;
- появляется обновление trust state по кейсу.
---
## 5.6. Сущность №6 — `audit_run`
### Почему нужна
Широкий анализ нельзя обслуживать тем же контрактом, что и direct answer.
Он имеет другой scope, другой темп, другой тип результата.
### Что делаем
Вводим `audit_run` как отдельную сущность пакетного анализа.
### Поля
- `run_id`
- `requested_scope`
- `time_window`
- `included_domains`
- `included_accounts`
- `included_filters`
- `execution_status`
- `progress`
- `problem_units_count`
- `cluster_count`
- `top_patterns`
- `final_summary`
- `report_artifacts`
- `drilldown_recommendations`
### Что это даёт
- audit перестаёт быть giant-chat-response;
- появляется отдельный batch-mode contract;
- можно строить отчётную аналитическую логику поверх reasoning substrate.
---
## 5.7. Сущность №7 — `trust_state`
### Почему нужна
К моменту Этапа 6 система уже может выдавать результаты разной природы:
- snapshot-derived;
- graph-backed;
- lifecycle-enriched;
- investigation-supported;
- live-verified.
Если это не различать, то ассистент будет звучать одинаково уверенно там, где фактический уровень надёжности разный.
### Что делаем
Вводим `trust_state` как формальную сущность доверия к результату.
### Поля
- `trust_level`
- `evidence_basis`
- `snapshot_only`
- `graph_supported`
- `investigation_supported`
- `live_verified`
- `limitations`
- `confidence_components`
- `recommended_next_step`
### Уровни trust
Примерный набор:
- `snapshot_inferred`
- `graph_lifecycle_supported`
- `investigation_supported`
- `live_confirmed`
- `inconclusive`
### Что это даёт
- взрослая модель доверия;
- честность в ответах;
- контролируемое различение inferred vs confirmed.
---
## 5.8. Сущность №8 — `output_contract_by_mode`
### Почему нужна
Разные режимы не могут заканчиваться одинаковым ответом.
### Что делаем
Вводим разные result contracts для каждого режима.
### Для `direct_answer`
Результат должен содержать:
- краткий вывод;
- mechanism summary;
- ключевые документы/сущности;
- уровень доверия;
- ограничения;
- при необходимости — recommendation to investigate/live-check.
### Для `investigation`
Результат должен содержать:
- главную гипотезу;
- проверенные ветки;
- что подтверждено;
- что опровергнуто;
- что осталось неопределённым;
- trust state;
- нужна ли live verification.
### Для `audit_batch`
Результат должен содержать:
- scope анализа;
- grouped problem clusters;
- recurring patterns;
- top risk areas;
- impact areas;
- drilldown recommendations;
- provenance/trust summary.
### Что это даёт
- режимы начинают различаться не только глубиной работы, но и формой результата;
- пользователь начинает понимать, что система делает и чего ожидать.
---
## 6. Полная цепь изменений по архитектуре
Ниже изменения собраны не по сущностям, а по архитектурному контуру выполнения.
---
## 6.1. Вход сообщения и mode selection
### Сейчас
До Этапа 6 система в основном определяет semantic meaning и retrieval/investigation path.
### Что меняем
Добавляется `mode_router`, который до semantic execution определяет:
- это direct answer;
- investigation;
- audit;
- возможна ли автоматическая live escalation;
- нужен ли mode transition later.
### Цель
Ввести execution governance как отдельный слой.
---
## 6.2. Direct Answer Path
### Сейчас
Система может отвечать быстро, но ещё не отделяет это как отдельный продуктовый режим.
### Что меняем
Для `direct_answer` вводятся:
- ограниченная глубина анализа;
- ограниченное число secondary checks;
- явный отказ от неограниченного branching;
- явная политика эскалации в investigation/live;
- отдельный output contract.
### Цель
Сделать быстрый режим честным и продуктово предсказуемым.
---
## 6.3. Investigation Path
### Сейчас
После Этапа 5 bounded investigation уже существует как reasoning capability.
### Что меняем
Теперь investigation mode становится полноценным execution mode с:
- case lifecycle;
- mode-aware orchestration;
- live verification policy;
- stop policy;
- investigation-grade output contract.
### Цель
Перевести расследование из внутренней возможности в продуктовый режим.
---
## 6.4. Audit / Batch Path
### Сейчас
Широкие вопросы ещё потенциально могут идти через перегруженный conversational flow.
### Что меняем
Добавляется отдельный `audit_run` pipeline:
1. scope expansion;
2. domain/account selection;
3. retrieval over larger dataset;
4. batch problem-unit assembly;
5. lifecycle/graph enrichment;
6. grouping and prioritization;
7. report synthesis.
### Цель
Сделать широкий анализ отдельным execution contour.
---
## 6.5. Live Verification Path
### Сейчас
Живые проверки либо отсутствуют как штатный assistant path, либо не встроены в формальный trust model.
### Что меняем
Вводится два слоя:
- `live_verification_request`
- `live_verification_result`
А также policy:
- когда verification разрешён;
- когда он обязателен;
- когда он только рекомендован;
- как verification влияет на trust_state.
### Цель
Сделать live verification штатным способом подтверждения результата.
---
## 6.6. Trust / Provenance Layer
### Сейчас
Даже сильные ответы могут звучать слишком одинаково по степени уверенности.
### Что меняем
Каждый результат получает provenance/trust classification.
### Цель
Сделать выводы системы честными и операционно интерпретируемыми.
---
## 7. Правила mode router
### 7.1. Когда выбирать `direct_answer`
Использовать, если:
- вопрос узкий;
- scope локальный;
- ожидаемый evidence volume ограничен;
- нет явного запроса на глубокий анализ;
- достаточно snapshot + current reasoning;
- вопрос может быть закрыт accountant-grade answer без investigation case.
### 7.2. Когда выбирать `investigation`
Использовать, если:
- запрос многосоставный;
- есть гипотезы;
- нужно проверить несколько веток;
- нужен branch traversal;
- требуется доказательное отделение подтверждённого от вероятного;
- direct answer почти наверняка будет недостаточен.
### 7.3. Когда выбирать `audit_batch`
Использовать, если:
- пользователь просит полный анализ;
- scope охватывает период/зону/класс рисков;
- нужен обзор по множеству problem units;
- ожидается групповая аналитика, а не один вывод.
### 7.4. Когда поднимать live verification
Использовать, если:
- кейс high-stakes;
- snapshot явно недостаточен;
- есть значимый конфликт snapshot vs reasoning;
- без подтверждения source-of-truth вывод нельзя считать надёжным;
- пользователь требует подтверждения актуального состояния.
---
## 8. Подробная модель доверия
### 8.1. Источники trust
`trust_state` должен опираться на:
- snapshot quality;
- graph support;
- lifecycle support;
- problem unit completeness;
- investigation completeness;
- live verification;
- internal contradictions;
- unresolved branches.
### 8.2. Что нельзя делать
Нельзя вычислять trust только из “общей уверенности модели”.
Нужен составной trust, который отражает архитектурные слои, реально участвовавшие в результате.
### 8.3. Пример trust-логики
- если вывод опирается только на snapshot + basic retrieval → `snapshot_inferred`
- если есть graph + lifecycle + strong problem unit evidence → `graph_lifecycle_supported`
- если пройдён bounded investigation с подтверждёнными ветками → `investigation_supported`
- если ключевые точки подтверждены live → `live_confirmed`
---
## 9. Детальный разбор product modes
---
## 9.1. Direct Answer Mode — подробный смысл
Это режим, в котором ассистент должен отвечать быстро и предметно, не создавая лишней сложности.
### Что здесь важно
- не уходить в pseudo-investigation без причины;
- не скрывать ограничения;
- не делать вид, что direct answer доказал больше, чем реально доказал;
- явно рекомендовать investigation/live, если это нужно.
### Что является хорошим результатом
- короткий accountant-grade ответ;
- mechanism summary;
- документы и связи названы конкретно;
- trust level честно обозначен.
---
## 9.2. Investigation Mode — подробный смысл
Это режим, где система работает как bounded copilot for reasoning.
### Что здесь важно
- открытие investigation case;
- branch/hypothesis execution;
- evidence separation;
- explicit stop criteria;
- controlled escalation to live verification.
### Что является хорошим результатом
- пользователь видит логику расследования;
- знает, что подтверждено;
- понимает, что ещё не закрыто;
- получает recommendation on next step.
---
## 9.3. Audit / Batch Mode — подробный смысл
Это режим, где система превращается во внутренний аналитический инструмент.
### Что здесь важно
- отдельный execution contour;
- batch retrieval and assembly;
- группировка и приоритизация;
- итог не в форме “ответа на вопрос”, а в форме structured analytical output.
### Что является хорошим результатом
- зоны риска;
- problem clusters;
- recurring patterns;
- приоритеты drilldown;
- ясная граница между overview и detail.
---
## 10. Как не уткнуться в главный риск этапа
### Главный риск
Сделать режимы как UI-названия или разные “тона ответа”, но не как реально разные execution contracts.
Если:
- direct / investigation / audit отличаются только длиной ответа;
- live verification существует, но не влияет на trust_state;
- audit просто длиннее direct answer;
- investigation просто делает 2–3 retrieval вместо одного;
— этап не выполнен.
### Что делать, чтобы этого не произошло
1. У каждого mode должны быть собственные:
- allowed depth
- branching policy
- output contract
- stop policy
- live verification policy
2. `mode_router` должен быть отдельным runtime-layer.
3. `mode_transition_decision` должен быть формальной сущностью.
4. `trust_state` должен быть обязательной частью результата.
5. `audit_run` должен быть отдельным execution artifact.
---
## 11. Что именно должно быть разработано в коде и архитектуре
### 11.1. Новый runtime слой
- `mode_router`
- `mode_transition_decision`
- `execution_mode` config
### 11.2. Новый live слой
- `live_verification_request`
- `live_verification_result`
- `live_verification_policy`
### 11.3. Новый audit слой
- `audit_run`
- batch execution pipeline
- aggregation / grouping / reporting logic
### 11.4. Новый trust слой
- `trust_state`
- provenance markers
- trust computation policy
### 11.5. Новый output contract layer
- direct answer contract
- investigation result contract
- audit report contract
---
## 12. Что переписываем, а что только расширяем
### Не переписываем полностью
- retrieval core;
- lifecycle core;
- graph core;
- investigation engine;
- problem unit model.
### Существенно расширяем
- execution governance;
- user-facing output contracts;
- trust/provenance;
- live source integration;
- batch analysis contour.
### Частично усиливаем
- current assistant orchestration;
- clarification/escalation logic;
- benchmark/eval suite;
- frontend presentation layer for result types.
---
## 13. Артефакты этапа
К концу Этапа 6 должны появиться следующие артефакты:
1. `execution_mode` schema and config
2. `mode_router` specification
3. `mode_transition_decision` schema
4. `live_verification_request` schema
5. `live_verification_result` schema
6. `trust_state` specification
7. `audit_run` schema
8. `output_contract_by_mode` specification
9. `live_verification_policy` document
10. `mode_eval_harness` specification
---
## 14. Критерии приёмки этапа
Этап считается выполненным только если:
### 14.1. По execution modes
- система реально различает direct / investigation / audit;
- у режимов разные execution policies;
- mode selection объясним и предсказуем.
### 14.2. По live verification
- live verification существует как штатная сущность и runtime path;
- live verification влияет на trust_state и итоговый результат;
- система умеет честно разделять verified vs inferred.
### 14.3. По audit mode
- batch mode запускается как отдельный контур;
- итог audit — это аналитический output, а не просто длинный answer;
- есть grouped problem clusters и drilldown recommendations.
### 14.4. По trust/provenance
- каждый результат имеет trust/provenance classification;
- разные уровни подтверждённости различимы пользователю и системе.
### 14.5. По продуктовой зрелости
- пользователь ощущает реальную разницу между режимами;
- ассистент умеет не только думать, но и жить как product system.
---
## 15. Что не считается результатом этапа
Этап не считается выполненным, если произошло что-то из этого:
- просто добавили переключатель режима в UI;
- investigation и audit отличаются только размером ответа;
- live verification не встроен в trust/provenance;
- snapshot/live-ответы звучат одинаково уверенно;
- audit не имеет собственного execution artifact;
- mode transitions не формализованы.
---
## 16. Идеальный результат этапа
После завершения Этапа 6 ассистент ещё не обязан быть полностью enterprise-scale системой, но он уже должен стать зрелым бухгалтерским copilot’ом, который:
- умеет быстро отвечать на узкие вопросы;
- умеет вести bounded investigation;
- умеет запускать широкий batch analysis;
- умеет подтверждать выводы живыми данными;
- умеет честно различать уровни доверия;
- живёт как продукт, а не как набор архитектурных слоёв.
---
## 17. Управленческое резюме этапа
Этап 6 завершает формирование взрослой продуктовой архитектуры Assistant Mode.
Это этап, на котором:
- reasoning превращается в product behavior;
- investigation превращается в официальный execution mode;
- audit перестаёт быть перегруженным чат-ответом;
- live verification становится штатным механизмом подтверждения;
- trust/provenance перестаёт быть неявной уверенностью модели и становится формальным контрактом результата.
Именно после этого этапа ассистент можно считать не просто технически сильной системой, а зрелым бухгалтерским copilot’ом.
docs/accounting-assistant/accounting-assistant/03_execution/ACCEPTANCE_CHECKLIST_STAGE_01.md
+716
View File
@@ -0,0 +1,716 @@
ACCEPTANCE_CHECKLIST_STAGE_01.md
# ACCEPTANCE_CHECKLIST_STAGE_01
## Назначение документа
Этот документ используется для приёмки первой волны реализации Stage 1.
Его задача — не проверить “что-то поменялось”, а убедиться, что:
- foundation layer действительно усилен;
- текущий scope не расползся;
- structural gaps реально закрыты;
- изменения не маскируют проблемы косметикой;
- заложена корректная база для следующих этапов.
Документ обязателен для:
- Codex;
- разработчика;
- ручного review;
- финальной фиксации результата по Stage 1.
---
## Статус документа
- Статус: чеклист приёмки Stage 1
- Язык: русский
- Режим использования: обязателен при завершении каждой волны и при финальной приёмке Stage 1
- При конфликте по scope приоритет имеет `STAGE_01_TASK_CARD.md`
- При конфликте по архитектурным ограничениям приоритет имеет `ARCHITECTURE_GUARDRAILS.md`
- При конфликте по platform logic приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
---
## Правила оценки
Для каждого пункта допускаются только следующие статусы:
- `PASS` — выполнено полностью
- `PARTIAL` — выполнено частично, требуется доработка
- `FAIL` — не выполнено
- `N/A` — не применимо, только если это действительно обосновано
Для каждого пункта должен быть указан комментарий:
- что проверялось;
- где это реализовано;
- чем подтверждается;
- какие ограничения остались.
---
## Общая логика приёмки
Stage 1 считается принятым только если одновременно соблюдены условия:
1. Закрыт именно Stage 1, а не “произвольный улучшенный вариант”.
2. Текущий рабочий контур не разрушен.
3. Есть минимальный формальный `investigation_state`.
4. Есть улучшение broad/generic question handling.
5. Evidence стало более структурным.
6. Ответы стали полезнее для бухгалтерского сценария.
7. Есть baseline eval / benchmark harness.
8. Есть accountant-facing метрики.
9. Нет скрытого выезда в Stage 2–6.
10. Изменения совместимы с platform core.
Если хотя бы один из этих пунктов провален, Stage 1 не считается завершённым.
---
# Блок A. Scope discipline
## A1. Реализован именно Stage 1
Статус:
Комментарий:
Проверка:
- реализованы только foundation-hardening изменения;
- не добавлена скрытая логика следующих этапов;
- улучшения соответствуют текущему scope.
Критерии PASS:
- все ключевые изменения относятся к Stage 1;
- нет “заодно реализованных” future-stage подсистем.
---
## A2. Нет скрытого выезда в Stage 2
Статус:
Комментарий:
Проверка:
- не внедрён полноценный `problem unit architecture`;
- нет полной смены retrieval unit model;
- нет явного runtime problem decomposition как core path.
Критерии PASS:
- максимум заложена совместимость;
- полноценный Stage 2 runtime не реализован.
---
## A3. Нет скрытого выезда в Stage 3
Статус:
Комментарий:
Проверка:
- не внедрён lifecycle engine;
- нет полноценной дефектной/событийной модели lifecycle как core path;
- нет ранней формализации состояния документа/процесса на уровне Stage 3.
Критерии PASS:
- lifecycle как будущий слой не реализован.
---
## A4. Нет скрытого выезда в Stage 4
Статус:
Комментарий:
Проверка:
- не внедрён полноценный ontology/graph runtime;
- не добавлена тяжёлая graph-логика как обязательный путь ответа;
- не построен graph-first core.
Критерии PASS:
- graph runtime отсутствует;
- максимум есть совместимые контракты, но не core-layer.
---
## A5. Нет скрытого выезда в Stage 5
Статус:
Комментарий:
Проверка:
- не внедрён full investigation engine;
- нет полноценного branching case-runtime;
- нет сложного bounded investigation orchestration.
Критерии PASS:
- присутствует только minimal `investigation_state`, а не full engine.
---
## A6. Нет скрытого выезда в Stage 6
Статус:
Комментарий:
Проверка:
- не внедрён live verification core;
- нет product mode split `direct / investigation / audit` как основного runtime;
- нет полноценного trust-state live contour.
Критерии PASS:
- Stage 6 логика не реализована как текущий рабочий слой.
---
## A7. Не выполнен большой ненужный рефактор
Статус:
Комментарий:
Проверка:
- не переписан transport layer без необходимости;
- не переписан endpoint layer без необходимости;
- не переписан base routing без необходимости;
- не переписан assistant loop ради архитектурной красоты.
Критерии PASS:
- изменения локальны и обоснованы;
- рабочий контур сохранён.
---
# Блок B. Investigation state
## B1. Введён явный минимальный `investigation_state`
Статус:
Комментарий:
Проверка:
- существует отдельная state-сущность или эквивалентный контракт;
- state не размазан по случайным переменным;
- state не заменён chat history.
Критерии PASS:
- есть явный минимальный state layer;
- его поля и правила обновления понятны.
---
## B2. `investigation_state` реально используется
Статус:
Комментарий:
Проверка:
- state участвует в follow-up логике;
- state влияет на обработку продолжения разговора;
- state не является “мёртвой” сущностью.
Критерии PASS:
- есть реальные runtime-точки использования;
- поведение follow-up отличается от наивной одношаговой обработки.
---
## B3. `investigation_state` bounded и минимален
Статус:
Комментарий:
Проверка:
- state не пытается хранить всё подряд;
- нет скрытого full case-engine;
- state ограничен по назначению.
Критерии PASS:
- state минимален, но полезен;
- state не превращён в premature investigation runtime.
---
## B4. `investigation_state` future-compatible
Статус:
Комментарий:
Проверка:
- структура state не конфликтует с будущим Stage 5;
- контракты не тупиковые;
- state можно расширить без полного слома.
Критерии PASS:
- заложена совместимость без premature implementation.
---
# Блок C. Broad / generic query handling
## C1. Выявление broad/generic questions стало явным
Статус:
Комментарий:
Проверка:
- система различает широкий, недоопределённый и достаточно конкретный вопрос;
- broadness не определяется только постфактум красивым ответом.
Критерии PASS:
- есть явная логика или критерии определения broad/generic запросов.
---
## C2. Появился controlled narrowing
Статус:
Комментарий:
Проверка:
- система умеет сузить вопрос;
- либо умеет зафиксировать, что вопрос слишком общий;
- либо предлагает следующий прикладной шаг.
Критерии PASS:
- broad-вопрос не приводит автоматически к слабому общему ответу;
- narrowing выполняется или честно сигнализируется.
---
## C3. Generic-answer rate снизился
Статус:
Комментарий:
Проверка:
- по контрольному набору кейсов доля “общих, малооперабельных” ответов уменьшилась;
- это подтверждается eval/ручным review.
Критерии PASS:
- улучшение заметно и измеримо;
- это не только субъективное ощущение.
---
## C4. Улучшение broad-handling не сводится к prompt-only
Статус:
Комментарий:
Проверка:
- есть структурные изменения в логике;
- не всё улучшение сделано за счёт переписывания системного промпта.
Критерии PASS:
- prompt может помогать, но не является единственным решением.
---
# Блок D. Evidence structure
## D1. Evidence больше не является просто текстовым пересказом
Статус:
Комментарий:
Проверка:
- evidence имеет отдельную структуру или явные поля;
- evidence не существует только как часть prose-ответа.
Критерии PASS:
- evidence выделено как отдельный элемент логики/контракта.
---
## D2. У evidence есть источник / происхождение
Статус:
Комментарий:
Проверка:
- для evidence фиксируется source_type / source_ref / pointer или эквивалент;
- источник не теряется при сборке ответа.
Критерии PASS:
- происхождение каждого значимого evidence можно проследить.
---
## D3. У evidence есть связь с утверждением
Статус:
Комментарий:
Проверка:
- ответные утверждения опираются на конкретные evidence items;
- нет ситуации, где вывод существует отдельно от опоры.
Критерии PASS:
- связка claim ↔ evidence читаема и проверяема.
---
## D4. У evidence есть механизм/основание
Статус:
Комментарий:
Проверка:
- система показывает не только “что найдено”, но и “почему это подтверждает вывод”;
- есть mechanism note / reason / basis или эквивалент.
Критерии PASS:
- объяснение перестаёт быть чисто декларативным.
---
## D5. У evidence есть честная ограниченность / confidence
Статус:
Комментарий:
Проверка:
- степень уверенности или ограниченности не скрыта;
- не создаётся ложная определённость.
Критерии PASS:
- uncertainty явно видна;
- слабая опора не маскируется уверенным тоном.
---
# Блок E. Answer quality
## E1. Ответ стал полезнее для бухгалтерского сценария
Статус:
Комментарий:
Проверка:
- ответы стали более прикладными;
- пользователь понимает, что найдено, на чём основано и что делать дальше;
- ответ не ограничивается пересказом данных.
Критерии PASS:
- manual review показывает явный рост операбельности ответов.
---
## E2. Ответ стал более дисциплинированным по структуре
Статус:
Комментарий:
Проверка:
- различаются summary, direct answer, evidence, uncertainty, next step или эквивалент;
- ответ не разваливается в свободный текст.
Критерии PASS:
- есть управляемая и повторяемая структура ответа.
---
## E3. Недостаток данных обрабатывается честно
Статус:
Комментарий:
Проверка:
- если опоры недостаточно, система не симулирует точный вывод;
- явно обозначается ограниченность;
- предлагается следующий полезный шаг.
Критерии PASS:
- honest uncertainty работает не только в теории.
---
## E4. Улучшение качества не является чисто косметическим
Статус:
Комментарий:
Проверка:
- улучшение связано с state/evidence/narrowing;
- это не просто более гладкий текст ответа.
Критерии PASS:
- answer quality опирается на structural changes.
---
# Блок F. Eval / metrics
## F1. Добавлен baseline benchmark / eval harness
Статус:
Комментарий:
Проверка:
- существует минимальный воспроизводимый eval-контур;
- можно запускать сравнение до/после;
- можно фиксировать регрессии.
Критерии PASS:
- eval не остаётся ручной и разовой активностью.
---
## F2. Есть контрольный набор кейсов
Статус:
Комментарий:
Проверка:
- есть набор representative вопросов;
- в набор входят broad/generic/follow-up/evidence-sensitive кейсы;
- набор пригоден для повторного запуска.
Критерии PASS:
- eval основан на зафиксированном наборе, а не на случайных примерах.
---
## F3. Появились accountant-facing метрики
Статус:
Комментарий:
Проверка:
- измеряется не только техническая проходимость;
- есть метрики полезности ответа;
- есть метрики genericness / evidence quality / narrowing usefulness или эквиваленты.
Критерии PASS:
- продуктовая полезность стала измеримой.
---
## F4. Можно сравнить поведение до/после
Статус:
Комментарий:
Проверка:
- есть baseline;
- есть результаты после изменений;
- можно показать, что конкретно улучшилось или ухудшилось.
Критерии PASS:
- есть сравнимость, а не просто “кажется стало лучше”.
---
## F5. Green tests не являются единственным доказательством готовности
Статус:
Комментарий:
Проверка:
- решение не принято только на основании unit/integration success;
- есть ручной review и/или accountant-facing оценка.
Критерии PASS:
- продуктовая приёмка не подменена технической.
---
# Блок G. Observability / diagnostics
## G1. Новая логика диагностируема
Статус:
Комментарий:
Проверка:
- можно понять, как было принято решение;
- можно увидеть, что произошло при broad-handling/state/evidence assembly;
- при сбое путь анализа не непрозрачен.
Критерии PASS:
- есть хотя бы минимальная наблюдаемость новых решений.
---
## G2. Новая логика тестируема
Статус:
Комментарий:
Проверка:
- есть тесты или проверяемые контуры;
- критичные новые ветки поведения можно воспроизвести.
Критерии PASS:
- поведение не завязано только на ручной удачный сценарий.
---
## G3. Новые контракты описаны явно
Статус:
Комментарий:
Проверка:
- state/evidence/eval contracts формализованы;
- их поля и назначение понятны;
- они не существуют только имплицитно в коде.
Критерии PASS:
- нет неявной архитектуры “между строк”.
---
# Блок H. Migration / compatibility
## H1. Новые сущности имеют явный source of truth
Статус:
Комментарий:
Проверка:
- понятно, где хранится canonical form;
- понятно, что является derived form;
- нет размазанного состояния.
Критерии PASS:
- контракты и источники истины определены явно.
---
## H2. Изменения не создают тупик для будущих этапов
Статус:
Комментарий:
Проверка:
- нет архитектурного решения, которое мешает Stage 2–6;
- не принято временное решение, выдаваемое за целевое.
Критерии PASS:
- Stage 1 усиливает основание, а не закрывает путь вперёд.
---
## H3. Обратная совместимость и миграции понятны
Статус:
Комментарий:
Проверка:
- если появились новые контракты/хранилища/схемы, описано как они инициализируются;
- понятно, нужен ли migration step;
- понятно, что будет со старым поведением.
Критерии PASS:
- внедрение можно повторить и сопровождать без хаоса.
---
# Блок I. Documentation completeness
## I1. Есть итоговый отчёт по реализации
Статус:
Комментарий:
Проверка:
- описано, что сделано;
- описано, какие файлы изменены;
- описано, что осталось вне scope.
Критерии PASS:
- по результату можно быстро понять состояние системы.
---
## I2. Есть acceptance mapping
Статус:
Комментарий:
Проверка:
- для каждого ключевого изменения понятно, какой критерий Stage 1 оно закрывает;
- нет “непонятных улучшений”.
Критерии PASS:
- изменения привязаны к acceptance criteria.
---
## I3. Есть список сознательно не реализованного
Статус:
Комментарий:
Проверка:
- явно перечислено, что не делалось сейчас;
- причины отложенных вещей зафиксированы;
- нет скрытого scope drift.
Критерии PASS:
- границы текущего этапа прозрачны.
---
# Блок J. Финальное решение по этапу
## J1. Stage 1 можно считать принятым
Статус:
Комментарий:
Критерии PASS:
- блоки A–I не содержат критических FAIL;
- PARTIAL не влияют на core acceptance;
- foundation реально усилен.
---
## J2. Stage 1 нельзя считать принятым
Статус:
Комментарий:
Ставится `PASS`, если выполнено хотя бы одно из условий:
- отсутствует `investigation_state`;
- broad/generic handling не улучшен по сути;
- evidence осталось неструктурированным;
- accountant-facing eval отсутствует;
- был скрытый выезд в future stages;
- рабочий контур сломан;
- изменения чисто косметические.
---
# Итоговая сводка по приёмке
## Общий итог
- Результат: `PASS / PARTIAL / FAIL`
- Дата проверки:
- Проверял:
- Версия / ветка / commit:
- Связанные документы:
---
## Ключевые сильные стороны
1.
2.
3.
---
## Ключевые недочёты
1.
2.
3.
---
## Что обязательно исправить до приёмки
1.
2.
3.
---
## Что допустимо перенести в следующий этап
1.
2.
3.
---
## Явно подтверждено как non-scope текущего этапа
1.
2.
3.
---
## Финальное решение
- `Принять Stage 1`
- `Принять Stage 1 условно`
- `Вернуть на доработку`
Комментарий:
---
# Короткая практическая формула
Stage 1 считается успешным не тогда, когда:
- код стал “чище”;
- ответы стали “приятнее”;
- тесты стали зелёными.
Stage 1 считается успешным тогда, когда одновременно:
- foundation стал структурно крепче;
- state перестал быть неявным;
- evidence перестало быть просто текстом;
- broad-вопросы стали обрабатываться дисциплинированно;
- качество стало измеримым;
- путь к следующим этапам остался открыт.
docs/accounting-assistant/accounting-assistant/03_execution/ARCHITECTURE_GUARDRAILS.md
+533
View File
@@ -0,0 +1,533 @@
ARCHITECTURE_GUARDRAILS.md
# ARCHITECTURE_GUARDRAILS
## Назначение документа
Этот документ фиксирует **жёсткие архитектурные рамки** для работы Codex и разработчика по бухгалтерскому ассистенту.
Документ нужен, чтобы:
- не допустить расползания scope;
- не дать текущей реализации преждевременно превратиться в Stage 2–6;
- не допустить появления скрытых костылей под видом “улучшения архитектуры”;
- удержать изменения в рамках текущего этапа;
- сохранить совместимость с будущим развитием системы.
Документ не заменяет:
- `CODEX_MASTER_BRIEF.md`
- `STAGE_01_TASK_CARD.md`
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
- этапные ТЗ
Его задача — фиксировать **что можно**, **что нельзя** и **по каким признакам видно, что реализация пошла не туда**.
---
## Статус документа
- Статус: обязательный архитектурный ограничитель
- Язык: русский
- Режим использования: обязателен к применению до любых кодовых изменений
- При конфликте с текущим scope приоритет имеет `STAGE_01_TASK_CARD.md`
- При конфликте по платформенным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
---
## Базовая установка
Текущая задача — **не построить конечную архитектуру**, а **усилить существующую систему так, чтобы она стала устойчивой основой для следующих этапов**.
Следовательно:
- нельзя преждевременно тащить в код будущие слои;
- нельзя переписывать рабочий контур ради абстрактной чистоты;
- нельзя маскировать structural gaps косметикой;
- нельзя заменять архитектуру “умным” поведением промптов.
---
## Главный принцип
**Каждое изменение должно отвечать на вопрос:**
> Это действительно необходимо для текущего этапа, или это попытка заранее реализовать следующий уровень системы?
Если ответ неочевиден, изменение считается подозрительным и должно быть вынесено на отдельное согласование.
---
## Архитектурная позиция проекта
Развитие системы должно идти поэтапно.
### Текущая логика развития
1. Усиление foundation
2. Сдвиг retrieval units
3. Формализация lifecycle
4. Формирование graph core
5. Построение investigation engine
6. Live verification и product modes
Из этого следует:
- текущий этап не должен содержать скрытую реализацию graph runtime;
- текущий этап не должен содержать полноценный investigation engine;
- текущий этап не должен содержать полноценный mode router;
- текущий этап не должен содержать live verification core path;
- текущий этап не должен содержать premature orchestration architecture.
---
## Что считается архитектурно допустимым
Допустимы только такие изменения, которые одновременно:
1. закрывают конкретный gap текущего этапа;
2. дают прямую runtime-пользу уже сейчас;
3. не тянут в код полноразмерные future-stage слои;
4. не ломают текущий рабочий контур;
5. не создают новый труднообратимый архитектурный долг.
---
## Что считается архитектурно недопустимым
Недопустимы изменения, которые:
- реализуют будущее раньше, чем для него готов фундамент;
- создают тяжёлые абстракции без текущей пользы;
- требуют большого переписывания ради “красоты”;
- маскируют отсутствие структуры промптами;
- подменяют состояние чатом;
- подменяют evidence словами;
- вводят новые сервисы без необходимости;
- создают platform complexity, не нужную текущему шагу.
---
## Жёсткие guardrails
### 1. Не переписывать рабочий контур без прямой причины
Без крайней необходимости запрещено переписывать:
- transport layer;
- endpoint layer;
- base routing;
- normalizer pipeline;
- текущий путь сборки ответа;
- рабочий retrieval flow;
- уже действующий assistant loop.
Разрешены только точечные изменения, если они:
- прямо обязательны для Stage 1;
- не могут быть внесены более локально.
---
### 2. Не строить новую архитектуру вместо усиления текущей
Нельзя использовать текущий этап как повод для:
- полного redesign системы;
- переезда на другую базовую схему исполнения;
- внедрения большого orchestration layer;
- скрытого перехода на новую core-модель;
- замены существующей структуры на “более правильную” без немедленной пользы.
---
### 3. Не внедрять преждевременно Stage 2–6
До наступления соответствующих этапов запрещено внедрять как core-runtime:
- полноценный `problem unit architecture`;
- полноценный lifecycle engine;
- полноразмерный ontology/graph runtime;
- full investigation engine;
- live verification core;
- split product runtime `direct / investigation / audit`;
- тяжёлую multi-step orchestration system;
- систему ветвления расследований как основной путь выполнения.
Если требуется часть будущей совместимости, она должна реализовываться:
- минимально;
- локально;
- через совместимые контракты;
- без включения всего будущего слоя.
---
### 4. Не решать structural gaps только промптами
Запрещено считать, что следующие проблемы решены, если было сделано только prompt tuning:
- отсутствие формального state;
- слабое evidence-linking;
- generic response behavior;
- отсутствие boundedness;
- отсутствие quality metrics;
- неявная uncertainty handling;
- отсутствие управляемого narrowing.
Промпт может помогать, но не может быть единственной формой архитектурного решения.
---
### 5. Не подменять state историей чата
Запрещено считать, что:
- chat history,
- предыдущий ответ,
- контекст последнего сообщения
эквивалентны формальному state.
Если системе нужен state, он должен быть:
- явным;
- минимальным;
- ограниченным;
- типизированным;
- контролируемым.
---
### 6. Не подменять evidence текстовой убедительностью
Запрещено считать, что ответ “обоснован”, если модель просто написала убедительный текст.
Evidence должно иметь хотя бы минимально явную структуру:
- источник;
- тип опоры;
- связь с утверждением;
- механизм/основание;
- степень уверенности или ограниченности.
---
### 7. Не вводить абстракции “на будущее” без runtime-пользы
Любая новая абстракция должна быть оправдана текущей пользой.
Недопустимы:
- интерфейсы ради гипотетического расширения;
- service layers без прямой функции на текущем этапе;
- сложные фабрики/адаптеры/оркестраторы “на потом”;
- обобщения, которые пока ничего не упрощают.
---
### 8. Не раздувать сервисную архитектуру раньше времени
Запрещено добавлять отдельные сервисы, если задачу можно решить проще.
Не нужно сейчас:
- выделять отдельные сервисы ради формального микросервисного вида;
- дробить систему под будущий scale, которого ещё нет;
- вводить сетевое взаимодействие между модулями, где достаточно модульной декомпозиции в кодовой базе;
- строить платформенный контур сложнее, чем требует текущий этап.
---
### 9. Не вводить storage complexity без ясной причины
Разрешено вводить новые contracts и storage-слои только если понятно:
- что является source of truth;
- что хранится как runtime state;
- что хранится как derived artifacts;
- как обеспечивается совместимость;
- как это будет использоваться уже сейчас.
Недопустимо:
- размазывать состояние по случайным местам;
- хранить критичное состояние в ad hoc формате;
- смешивать runtime state, long-term artifacts и временные вспомогательные данные без явной дисциплины.
---
### 10. Не считать green tests доказательством качества продукта
Если изменения прошли технические тесты, это ещё не означает, что этап закрыт.
Архитектурно недостаточно:
- unit tests без проверки полезности ответа;
- integration tests без accountant-facing criteria;
- успешного пайплайна без оценки качества narrowing/evidence/usefulness.
---
## Разрешённые архитектурные паттерны
Ниже перечислено то, что допустимо и желательно.
### 1. Минимальный совместимый контракт
Если нужен новый слой, сначала вводится:
- минимальный тип;
- минимальный контракт;
- минимальный runtime-путь;
- без избыточной генерализации.
### 2. Локальное усиление точки принятия решения
Если есть конкретная слабая зона, допустимо:
- локально усилить её;
- формализовать решение;
- добавить проверку/метрику;
- не затрагивать весь контур.
### 3. Расширение через bounded сущности
Новые сущности допустимы, если они:
- ограничены по назначению;
- не претендуют на роль будущей полноразмерной подсистемы;
- не конфликтуют с дальнейшим развитием.
### 4. Явные интерфейсы вместо неявного поведения
Если логика уже существует, но живёт неявно, допустимо:
- вывести её в контракт;
- типизировать;
- сделать наблюдаемой;
- покрыть тестами.
### 5. Наблюдаемость как часть архитектуры
Если появляется новая логика, у неё должны быть:
- диагностика;
- traceability;
- метрики;
- понятная точка проверки.
---
## Decision rules перед любым изменением
Перед внесением любого изменения нужно проверить следующее.
### Вопрос 1
Это закрывает конкретный gap текущего этапа?
Если нет — изменение отклоняется.
### Вопрос 2
Это можно сделать локальнее?
Если да — выбирается более локальный вариант.
### Вопрос 3
Это не тянет Stage 2–6 раньше времени?
Если тянет — изменение откладывается или упрощается.
### Вопрос 4
Это даёт прямую runtime-пользу уже сейчас?
Если нет — изменение подозрительно.
### Вопрос 5
Это не создаёт новый трудный долг?
Если создаёт — нужен другой вариант.
### Вопрос 6
Это не решает проблему только косметикой?
Если решает только косметикой — изменение недостаточно.
---
## Проверка на scope drift
Признаки того, что реализация вышла за рамки:
- в код попали сущности, которые фактически образуют graph runtime;
- появилась логика сложного branching investigation;
- появился mode router для нескольких продуктовых режимов;
- появилась зависимость от live verification core;
- ради текущего этапа меняется половина репозитория;
- вводятся сущности, которые пока никто не использует;
- строится общий orchestration framework вместо локального усиления;
- Codex объясняет сложность тем, что “так будет лучше на будущее”.
Если наблюдается один или несколько признаков — нужно остановить изменения и сократить scope.
---
## Красные флаги
Следующие ситуации считаются тревожными:
1. Предлагается переписать base loop
2. Предлагается “сразу сделать правильно всю архитектуру”
3. Предлагается отдельный graph layer уже сейчас
4. Предлагается большой orchestration framework
5. Предлагается product split runtime уже на первом этапе
6. State остаётся неявным, но промпт становится длиннее
7. Evidence описывается красивее, но не структурируется
8. Метрики остаются только техническими
9. Добавляются новые сервисы без реальной необходимости
10. Временное решение подаётся как target architecture
---
## Правило minimal irreversible change
Любое изменение должно быть по возможности:
- минимальным;
- обратимым;
- наблюдаемым;
- проверяемым;
- совместимым с дальнейшими этапами.
Нельзя делать решение, которое:
- сложно откатить;
- сложно объяснить;
- сложно протестировать;
- сложно встроить в дальнейшую архитектуру;
- принято только потому, что “быстрее сейчас”.
---
## Правило explicit source of truth
Для каждой новой сущности должно быть явно определено:
- где находится источник истины;
- кто её обновляет;
- кто её читает;
- как она версионируется;
- что является derived form, а что canonical form.
Если это не определено, сущность не готова к внедрению.
---
## Правило bounded state
Любой новый state должен быть:
- ограниченным по объёму;
- ограниченным по назначению;
- независимым от случайного текстового контекста;
- пригодным для диагностики;
- пригодным для расширения в будущих этапах.
Нельзя вводить state, который:
- хранит всё подряд;
- не имеет чётких полей;
- зависит от неявных текстовых интерпретаций;
- фактически дублирует chat history;
- не имеет правил обновления.
---
## Правило honest uncertainty
Система не должна производить архитектурно ложную определённость.
Если данных недостаточно, допустимо и желательно:
- явно показать ограниченность;
- указать, чего не хватает;
- предложить следующий полезный шаг;
- удержаться от псевдоточного ответа.
Запрещено:
- маскировать отсутствие опоры уверенным тоном;
- расширять answer prose вместо усиления основания;
- выдавать общую формулировку как точный вывод.
---
## Правило compatibility without premature implementation
Система должна быть совместима с будущими этапами, но не должна их реализовывать заранее.
Допустимо:
- закладывать совместимые поля;
- делать совместимые интерфейсы;
- избегать тупиковых решений;
- оставлять расширяемые точки.
Недопустимо:
- включать полный будущий runtime;
- строить будущий слой целиком;
- обосновывать сложность только будущими гипотетическими выгодами.
---
## Как должен выглядеть хороший change proposal
Хорошее предложение по изменению должно содержать:
1. Какой конкретный gap закрывается
2. Почему это относится к текущему этапу
3. Какой минимальный вариант реализации выбран
4. Какие файлы затрагиваются
5. Какие сущности добавляются
6. Почему это не является скрытой реализацией будущего этапа
7. Как это тестируется
8. Как это наблюдается
9. Что сознательно не делается сейчас
Если хотя бы половина этих пунктов отсутствует, proposal недостаточно дисциплинирован.
---
## Как должен выглядеть плохой change proposal
Плохим считается предложение, если в нём есть формулировки типа:
- “сразу сделаем правильно на будущее”
- “заодно перепишем”
- “проще построить новый слой”
- “пусть пока будет так, потом переделаем”
- “можно промптом компенсировать”
- “сделаем универсальную архитектуру”
- “вдруг потом пригодится”
- “это подготовка к следующим этапам”
Без доказанной текущей пользы такие аргументы не принимаются.
---
## Эскалация при спорном решении
Если изменение спорное, применять следующий порядок:
1. Проверить соответствие текущему scope
2. Проверить соответствие platform core ТЗ
3. Проверить, не тянет ли изменение Stage 2–6
4. Проверить, можно ли сделать локальнее
5. Зафиксировать риски
6. Только после этого принимать решение
Если спор остаётся, решение не внедряется автоматически.
---
## Короткая практическая формула
### Что делать
- усиливать основание;
- формализовать неявное;
- добавлять минимально нужные контракты;
- повышать наблюдаемость;
- сохранять совместимость с будущим.
### Что не делать
- строить будущее раньше времени;
- переписывать рабочее;
- лечить архитектуру текстом;
- плодить абстракции;
- усложнять платформу без необходимости.
---
## Финальная установка
Архитектурная дисциплина в этом проекте важнее скорости декоративных изменений.
Главная цель текущего этапа:
**не сделать видимость зрелой системы, а реально уменьшить structural debt и подготовить прочную основу для следующих шагов.**
Любое изменение, которое противоречит этому принципу, должно считаться ошибочным, даже если оно выглядит “умным”, “масштабируемым” или “красивым”.
docs/accounting-assistant/accounting-assistant/03_execution/CODEX_MASTER_BRIEF.md
+414
View File
@@ -0,0 +1,414 @@
CODEX_MASTER_BRIEF.md
# CODEX_MASTER_BRIEF
## Назначение документа
Этот документ задаёт режим работы Codex по проекту бухгалтерского ассистента.
Документ не заменяет технические задания по этапам и не заменяет platform core ТЗ.
Его задача — зафиксировать:
- текущий рабочий scope;
- иерархию документов;
- архитектурные ограничения;
- допустимый порядок работы;
- требования к формату результата;
- правила, предотвращающие преждевременное усложнение и появление костылей.
---
## Статус документа
- Статус: основной управляющий бриф для Codex
- Язык: русский
- Режим использования: обязателен к прочтению перед любыми изменениями в коде
- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_01_TASK_CARD.md`
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
---
## Контекст проекта
Разрабатывается бухгалтерский ассистент, который уже находится в рабочем состоянии на уровне функционального MVP+ и способен:
- принимать пользовательские вопросы;
- обращаться к имеющимся контурам данных;
- маршрутизировать запрос;
- извлекать данные;
- формировать объяснение;
- возвращать ответ пользователю.
При этом текущая система ещё не является полноценным investigation copilot.
Основные текущие ограничения:
- snapshot-only truth contour;
- слабая формализация investigation state;
- entity-heavy retrieval;
- недостаточная структурность evidence;
- неполный accountant-facing eval;
- ограниченная управляемость broad / generic query handling;
- отсутствие полноценного bounded investigation runtime;
- отсутствие formal live verification trust model.
Проект развивается по поэтапной схеме.
На текущей итерации реализуется только **Stage 1 / Foundation Hardening**.
Этапы 2–6 задают forward-compatibility constraints, но не являются scope текущей реализации.
---
## Цель работы Codex на текущей итерации
Codex должен помочь реализовать **только Stage 1**, не разрушая текущий работающий контур и не подтягивая prematurely решения из следующих этапов.
Текущая цель:
- усилить существующий assistant mode;
- сделать архитектурно корректную базу для следующих этапов;
- убрать наиболее опасные structural gaps;
- не превращать текущий этап в скрытую реализацию Stage 2–6.
---
## Иерархия документов
При чтении и интерпретации материалов использовать следующий порядок приоритета.
### 1. Текущий рабочий scope
- `03_execution/STAGE_01_TASK_CARD.md`
Это главный документ по тому, что делать прямо сейчас.
### 2. Архитектурные ограничения и platform core
- `01_platform/TZ_Platform_Core_Accounting_Assistant_Mode.md`
Этот документ задаёт целевую платформенную рамку:
- storage;
- orchestration;
- trust/provenance;
- observability;
- migration discipline;
- security;
- live bridge policy.
### 3. Детальное ТЗ первого этапа
- `02_stages/stage-01-foundation-hardening.md`
Этот документ определяет содержимое Stage 1.
### 4. Текущий статус и общая логика развития
- `00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`
- `00_context/Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md`
- `00_context/ROADMAP_endToReal.md`
- `00_context/accounting_assistant_architecture_roadmap.xlsx`
Эти документы нужны для понимания:
- что уже сделано;
- где реальные потолки системы;
- почему Stage 1 выполняется именно сейчас;
- как Stage 1 стыкуется с дальнейшими этапами.
### 5. Этапы 2–6
- `02_stages/stage-02-...`
- `02_stages/stage-03-...`
- `02_stages/stage-04-...`
- `02_stages/stage-05-...`
- `02_stages/stage-06-...`
Эти документы используются только как:
- ограничители будущей совместимости;
- источник требований к тому, чего нельзя ломать сейчас;
- ориентир для проектирования расширяемых contracts и сущностей.
Эти документы **не являются** scope текущей реализации.
---
## Scope текущей итерации
Разрешено делать только то, что относится к Stage 1 и необходимо для его корректной реализации.
К текущему scope относятся:
- усиление foundation layer без переписывания всей системы;
- минимально необходимая формализация `investigation_state`;
- усиление answer policy;
- усиление broad-query / generic-query handling;
- более структурное представление evidence;
- accountant-facing metrics;
- baseline benchmark/eval harness;
- подготовка базы для следующих этапов без преждевременной реализации этих этапов.
---
## Что сейчас не является scope
На этой итерации нельзя фактически реализовывать как core-runtime следующие слои:
- полноценный problem unit architecture из Stage 2;
- полноценный lifecycle engine из Stage 3;
- полноразмерный ontology / graph runtime из Stage 4;
- investigation engine в полном виде из Stage 5;
- live verification runtime core и full product mode split из Stage 6;
- переезд на новую полную сервисную архитектуру;
- переписывание ассистента вокруг новых abstraction layers без крайней необходимости;
- большие инфраструктурные переделки ради “красоты”.
---
## Главный принцип текущей работы
**Не строить целевую систему раньше времени.**
Нужно не “сразу сделать правильно всё”, а “сделать Stage 1 так, чтобы он был структурно корректен, совместим с будущими этапами и не создал новые архитектурные долги”.
---
## Жёсткие архитектурные ограничения
### 1. Нельзя ломать текущий рабочий контур без прямой причины
Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 1.
### 2. Нельзя подменять архитектурные изменения промптами
Проблемы state, evidence structure, eval, traceability, narrowing и boundedness не должны решаться только промптами или “умной формулировкой ответа”.
### 3. Нельзя преждевременно тащить Stage 2–6 в кодовую базу
Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 1.
### 4. Нельзя делать большие рефакторы ради абстрактной чистоты
Разрешены только те изменения, которые:
- закрывают конкретный gap;
- повышают устойчивость текущего слоя;
- не разрушают траекторию дальнейшего развития.
### 5. Все новые сущности должны быть future-compatible
Любые новые:
- типы,
- storage contracts,
- runtime state contracts,
- evidence models,
- metric payloads,
- trace structures
должны проектироваться так, чтобы не конфликтовать со следующими этапами.
### 6. Нельзя маскировать structural gaps perceived-quality улучшениями
Недопустимо заменять структурное решение:
- более длинным ответом,
- более “умным” summarization,
- более агрессивной промптовой маршрутизацией,
- косметическим улучшением вывода.
---
## Порядок работы Codex
Работа должна идти строго по шагам.
### Шаг A. Изучение материалов
Сначала изучить:
- текущий статус;
- platform core ТЗ;
- Stage 1;
- roadmap;
- контекст следующих этапов.
### Шаг B. Анализ текущего кода
До внесения изменений определить:
- какие части системы уже существуют;
- какие из требований Stage 1 уже частично реализованы;
- где находятся реальные точки расширения;
- какие элементы являются хрупкими;
- какие изменения потребуют новых contracts;
- какие части лучше не трогать.
### Шаг C. Подготовка implementation plan
До написания кода выдать план:
- что меняется;
- зачем меняется;
- какие файлы будут затронуты;
- какие новые сущности появятся;
- какие тесты будут добавлены;
- что не будет делаться сейчас.
### Шаг D. Согласованная поэтапная реализация
Только после плана переходить к реализации.
Изменения должны вноситься малыми порциями, чтобы можно было проверить:
- не вышел ли scope за Stage 1;
- не сломан ли текущий контур;
- не появились ли premature abstractions.
### Шаг E. Проверка и фиксация результата
После каждой завершённой волны изменений предоставить:
- summary изменений;
- список изменённых файлов;
- тестовый результат;
- список ограничений;
- список нерешённых вопросов;
- оценку совместимости с дальнейшими этапами.
---
## Первый результат, который Codex должен вернуть до любого кода
До любых patch / refactor / implementation действий Codex должен вернуть документированный анализ следующего вида:
### 1. Summary текущего состояния
Краткое описание того, как текущая реализация устроена по коду.
### 2. Gap analysis относительно Stage 1
Перечень того, чего не хватает для соответствия Stage 1.
### 3. Предлагаемый file-level plan
Какие файлы нужно менять, создавать или расширять.
### 4. Предлагаемые contracts / types / schemas
Какие сущности и интерфейсы появятся.
### 5. Test plan
Какие тесты будут добавлены или обновлены.
### 6. Acceptance mapping
Какие критерии Stage 1 покрываются какими изменениями.
### 7. Explicit non-scope
Что сознательно не будет делаться сейчас.
---
## Требования к формату всех ответов Codex
Каждый содержательный ответ Codex должен быть структурирован.
Обязательная структура:
1. Что было проанализировано
2. Что обнаружено
3. Что предлагается изменить
4. Почему это соответствует Stage 1
5. Что не входит в текущий scope
6. Какие файлы затрагиваются
7. Какие риски есть
8. Какие тесты или проверки нужны
Если предлагается кодовое изменение, дополнительно обязательно указывать:
- это локальное изменение или системное;
- ломает ли оно обратную совместимость;
- требует ли миграции;
- влияет ли на transport / routing / state / answer composition;
- как это соотносится с будущими этапами.
---
## Правила реализации
### 1. Минимальность изменения
Предпочтительны минимальные архитектурно корректные изменения вместо больших переписываний.
### 2. Явные contracts
Всё, что касается:
- state,
- evidence,
- traceability,
- metrics,
- runtime decisions
должно оформляться через явные контракты, а не “как получится по месту”.
### 3. Контролируемая расширяемость
Расширяемость допустима, но только в той мере, в которой она:
- реально нужна Stage 1;
- не заставляет внедрять всю будущую архитектуру заранее.
### 4. Наблюдаемость изменений
Если добавляется новая логика, нужно продумать:
- как она тестируется;
- как она логируется;
- как проверяется её корректность;
- как она диагностируется в случае сбоя.
### 5. Миграционная дисциплина
Если изменение создаёт новый контракт или структуру хранения, нужно явно указать:
- где источник истины;
- как происходит инициализация;
- как будет обеспечена совместимость;
- требуется ли миграция данных.
---
## Запрещённые анти-паттерны
Следующие действия считаются ошибочными:
- попытка “сразу построить конечную архитектуру”;
- внедрение лишних сервисов без необходимости;
- скрытая реализация future-stage логики под видом Stage 1;
- замена structural fixes косметикой;
- создание новых абстракций без runtime-пользы;
- переписывание рабочего контура ради абстрактной чистоты;
- смешивание temporary workaround и target architecture без явной маркировки;
- неявное изменение scope;
- неконтролируемая генерация “умных” helper layers;
- перенос ответственности за структурный пробел в prompt layer.
---
## Признаки того, что решение идёт не туда
Если в процессе работы появляется одно или несколько из следующих явлений, нужно остановиться и пересобрать plan:
- предлагается большой platform refactor для реализации Stage 1;
- предлагается новая архитектура вместо усиления текущей;
- в код начинают подтягиваться сущности из Stages 4–6 как обязательные;
- вводятся новые сервисы, не дающие прямой пользы на текущем шаге;
- “для удобства” переписывается base loop;
- проблема объясняется как решаемая чисто промптом;
- предлагается сложный orchestrator без прямой необходимости;
- формируется новый data model слой без связи с acceptance criteria Stage 1.
---
## Definition of Done для текущей волны
Текущая волна считается завершённой только если выполнены одновременно все условия:
1. Реализован scope Stage 1, а не произвольный “улучшенный вариант”.
2. Текущий рабочий контур не разрушен.
3. Новые state / evidence / metrics contracts описаны явно.
4. Есть тесты и/или проверяемые критерии для внесённых изменений.
5. Нет скрытого уезда в Stage 2–6.
6. Изменения совместимы с platform core ТЗ.
7. Зафиксировано, что сознательно осталось за пределами текущего этапа.
---
## Практическая цель первой итерации
Первая итерация должна дать не “идеальную новую систему”, а следующий результат:
- структурно усиленный assistant mode;
- минимальную, но реальную формализацию foundation gaps;
- снижение зависимости от неявной логики и ad hoc поведения;
- более стабильную базу для перехода к следующим этапам.
---
## Финальная установка для Codex
Работать нужно в режиме **supervised implementation**.
Это означает:
- сначала анализ;
- потом план;
- потом небольшие контролируемые изменения;
- после каждого куска — отчёт о том, что сделано и что осталось;
- никакой самовольной замены roadmap;
- никакого расширения scope;
- никакой premature architecture.
Главный вопрос перед любым изменением:
**Это действительно необходимо для Stage 1, или это попытка преждевременно реализовать следующий этап?**
Если ответ неочевиден, изменение откладывается и выносится на отдельное согласование.
docs/accounting-assistant/accounting-assistant/03_execution/STAGE_01_TASK_CARD.md
+524
View File
@@ -0,0 +1,524 @@
STAGE_01_TASK_CARD.md
# STAGE_01_TASK_CARD
## Назначение документа
Этот документ фиксирует **рабочий scope первой итерации реализации** для Codex и разработчика.
Документ не заменяет Stage 1 ТЗ и не заменяет platform core ТЗ.
Его задача — перевести первый этап в **практический implementation scope**, который можно брать в работу без расползания в следующие этапы.
Документ должен использоваться как основной рабочий ориентир при реализации первой волны изменений.
---
## Статус документа
- Статус: рабочая карта реализации Stage 1
- Язык: русский
- Режим использования: обязателен к прочтению перед любыми изменениями по Stage 1
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
- При конфликте по общему режиму работы Codex приоритет имеет `CODEX_MASTER_BRIEF.md`
---
## Контекст
Текущий бухгалтерский ассистент уже работает на уровне функционального MVP+:
- принимает вопросы пользователя;
- обращается к доступным данным;
- извлекает информацию;
- формирует объяснение;
- возвращает ответ.
При этом система ещё не является полноценным investigation copilot.
На текущем этапе нужно **не перестроить ассистента целиком**, а **укрепить foundation layer**, чтобы:
- убрать самые опасные structural gaps;
- сделать поведение более управляемым;
- снизить зависимость от неявной логики;
- подготовить совместимую базу для Stage 2–6;
- не тащить prematurely будущую архитектуру в текущую реализацию.
---
## Цель Stage 1
Stage 1 должен дать **структурно усиленный assistant mode**, не ломая текущий рабочий контур.
Практический результат этапа:
- минимально формализованный `investigation_state`;
- более управляемое поведение на broad / generic questions;
- более структурное и объяснимое представление evidence;
- accountant-facing метрики качества;
- baseline benchmark/eval harness;
- улучшение answer policy без ухода в prompt-only компенсацию;
- база для следующих этапов без преждевременной реализации problem units / lifecycle / graph / investigation engine / live verification.
---
## Scope текущей реализации
В рамках Stage 1 разрешено реализовывать только то, что необходимо для foundation hardening.
### В scope входят
1. **Минимальная формализация investigation state**
- базовый state-контур для многошагового взаимодействия;
- фиксация контекста текущего вопроса и follow-up логики;
- хранение минимально необходимого состояния для продолжающегося разбора;
- отделение state от случайной chat-памяти.
2. **Усиление broad / generic query handling**
- обнаружение слишком широких, размытых или недоопределённых запросов;
- controlled narrowing;
- управляемый переход от broad-вопроса к более точной постановке;
- снижение generic explanation без опоры только на “умный текст”.
3. **Более структурное evidence-представление**
- evidence должно быть не просто текстовым пересказом;
- нужны явные поля/слоты под происхождение, тип опоры, степень уверенности, механизм/основание;
- ответ не должен строиться на неявной сборке “по месту”.
4. **Усиление answer policy**
- ответ должен быть полезным бухгалтеру;
- должен быть более дисциплинированный формат объяснения;
- должна снижаться доля общих и малооперабельных ответов;
- при отсутствии достаточной опоры система должна это явно обозначать.
5. **Accountant-facing metrics**
- нужны метрики не только технического прохождения пайплайна, но и полезности ответа для бухгалтерского сценария;
- должна появиться измеримость качества на уровне пользовательского результата.
6. **Baseline benchmark / eval harness**
- минимальный воспроизводимый контур проверки качества;
- возможность сравнивать поведение до/после изменений;
- возможность фиксировать деградации.
7. **Минимальные foundation-изменения в коде**
- только те изменения, которые необходимы для реализации пунктов выше;
- без большого переписывания существующей системы.
---
## Что не входит в scope
Следующие вещи **не должны** реализовываться в рамках Stage 1 как core-runtime или как полноценный новый слой.
### Не делать сейчас
- полный `problem unit architecture`;
- полноценный lifecycle engine;
- полноценный ontology / graph runtime;
- full investigation engine;
- live verification runtime core;
- full product mode split (`direct / investigation / audit`);
- новый большой orchestration layer;
- радикальную смену transport / endpoint / base routing;
- большой platform refactor;
- сервисную декомпозицию ради будущего масштаба;
- замену structural fixes косметическими prompt-улучшениями.
---
## Обязательные результаты этапа
По завершении Stage 1 в системе должны появиться следующие результаты.
### 1. Базовый investigation state
Должен существовать минимальный, но явный state-контур, который:
- поддерживает follow-up вопросы;
- позволяет не терять контекст разбора;
- не сводится к “последнему сообщению в чате”;
- не имитирует полноценный investigation engine;
- не противоречит будущему расширению в Stage 5.
### 2. Controlled broad-query narrowing
Система должна уметь:
- распознавать слишком общие вопросы;
- не выдавать сразу слабый обобщённый ответ как будто вопрос уже достаточно определён;
- либо сужать вопрос,
- либо честно сигнализировать о недостатке точности,
- либо предлагать следующий полезный шаг в рамках текущего контура.
### 3. Mechanism-aware evidence baseline
В ответной логике должна появиться хотя бы базовая evidence-структура, включающая:
- источник / происхождение;
- тип evidence;
- основание ответа;
- степень опоры / уверенности;
- связь между утверждением и evidence.
### 4. Accountant-facing answer discipline
Ответы должны стать более пригодными для прикладного использования бухгалтером:
- меньше generic prose;
- больше предметной объяснимости;
- больше локальной операбельности;
- ясное разделение между найденным, предполагаемым и недостающим.
### 5. Метрики и eval
Должен появиться baseline-контур, позволяющий измерять:
- качество narrowing;
- качество evidence-linking;
- долю generic answers;
- долю structurally useful answers;
- стабильность поведения на контрольном наборе вопросов.
---
## Рабочие deliverables от Codex
Codex должен вернуть не только код, но и набор артефактов.
### Обязательные deliverables
1. **Gap analysis по Stage 1**
- чего не хватает в текущем коде;
- что уже есть частично;
- где точки внедрения.
2. **Implementation plan**
- какие компоненты меняются;
- какие файлы меняются;
- какие сущности появляются;
- что остаётся нетронутым.
3. **Новые или обновлённые contracts / types / schemas**
- для state;
- для evidence;
- для answer policy;
- для eval/metrics.
4. **Кодовые изменения**
- малыми контролируемыми порциями;
- без скрытого выезда в Stage 2–6.
5. **Test / eval changes**
- unit / integration / regression checks;
- baseline benchmark updates;
- проверка, что Stage 1 реально усиливает foundation.
6. **Итоговый отчёт по волне**
- что сделано;
- что не сделано сознательно;
- какие риски остались;
- что готово для следующего этапа.
---
## Предпочтительные направления изменений в коде
Ниже перечислены типы изменений, которые допустимы и ожидаемы.
### 1. State layer
Можно и нужно:
- добавить минимальные state-типы;
- добавить state storage contract;
- добавить controlled state hydration / update;
- ограничить state только тем, что реально нужно Stage 1.
Нельзя:
- строить full investigation machine;
- вводить сложный branching runtime;
- реализовывать полноценные investigation cases.
### 2. Retrieval / interpretation boundary
Можно и нужно:
- усилить слой, где broad/generic вопрос распознаётся до финального ответа;
- добавить явную логику narrowing;
- отделить “данных недостаточно для узкого ответа” от “модель решила ответить общими словами”.
Нельзя:
- заменять structural logic prompt tuning-only подходом;
- внедрять problem unit runtime раньше Stage 2.
### 3. Evidence layer
Можно и нужно:
- сделать evidence более формализованным;
- добавить типизацию evidence;
- связать утверждение с основанием.
Нельзя:
- строить полный ontology graph;
- вводить тяжёлую графовую модель без реальной необходимости.
### 4. Answer composer / policy
Можно и нужно:
- дисциплинировать формат ответа;
- сделать явные режимы ответа внутри Stage 1;
- снизить долю размытых формулировок.
Нельзя:
- строить full mode router уровня Stage 6;
- подменять quality строгим шаблоном без связи с evidence.
### 5. Eval / metrics
Можно и нужно:
- добавить baseline метрики;
- добавить контрольные наборы вопросов;
- добавить сравнение до/после.
Нельзя:
- ограничиться только техническими green tests;
- считать этап завершённым без accountant-facing проверки.
---
## Ожидаемые сущности Stage 1
Ниже — не финальная схема данных, а минимальный набор сущностей, который допустимо и полезно ввести уже сейчас.
### 1. InvestigationState
Минимальный runtime state текущего разбора.
Примерный состав:
- `session_id`
- `question_id`
- `current_focus`
- `narrowing_status`
- `evidence_refs`
- `open_uncertainties`
- `last_answer_mode`
- `followup_context`
Это не должен быть полноценный case-engine.
### 2. EvidenceItem
Базовая единица evidence.
Примерный состав:
- `evidence_id`
- `source_type`
- `source_ref`
- `claim_ref`
- `evidence_kind`
- `mechanism_note`
- `confidence`
- `raw_excerpt_or_pointer`
### 3. AnswerStructure
Формализованный каркас ответа.
Примерный состав:
- `answer_summary`
- `direct_answer`
- `evidence_block`
- `uncertainty_block`
- `next_step_block`
### 4. EvalRecord
Запись о результате проверки на benchmark / control set.
Примерный состав:
- `case_id`
- `question_type`
- `broadness_level`
- `narrowing_result`
- `evidence_quality_score`
- `genericness_score`
- `accountant_usefulness_score`
- `notes`
---
## Жёсткие implementation-ограничения
### 1. Не трогать без необходимости
Без прямой нужды не переписывать:
- transport layer;
- endpoint layer;
- base routing;
- normalizer pipeline;
- рабочий контур выдачи ответа.
### 2. Не внедрять будущие этапы скрыто
Если предлагаемое изменение:
- требует graph runtime,
- требует lifecycle engine,
- требует full investigation runtime,
- требует live verification core,
то оно не относится к Stage 1 и должно быть отложено.
### 3. Не раздувать abstraction layer
Если новая абстракция:
- не даёт прямой пользы текущему этапу,
- не закрывает конкретный gap,
- добавляется “на будущее”,
она не должна внедряться.
### 4. Не подменять state чатом
State должен быть формализован минимально, но явно.
Нельзя считать, что “история переписки и так всё хранит”.
### 5. Не подменять evidence текстом
Evidence должно быть хотя бы базово структурировано.
Нельзя считать, что “если модель сослалась словами, этого достаточно”.
---
## Порядок работы по Stage 1
### Шаг 1. Прочитать материалы
Обязательно прочитать:
- `CODEX_MASTER_BRIEF.md`
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
- Stage 1 ТЗ
- status documents
- roadmap
### Шаг 2. Сделать code-level mapping
Нужно определить:
- где находится текущий assistant loop;
- где принимается решение по типу вопроса;
- где собирается evidence;
- где формируется финальный ответ;
- где можно безопасно внедрить state;
- где можно подключить eval/metrics.
### Шаг 3. Подготовить plan без кода
До начала реализации Codex должен выдать:
- gap analysis;
- file-level plan;
- список новых контрактов;
- список новых тестов;
- список non-scope.
### Шаг 4. Реализовывать малыми волнами
Рекомендуемая последовательность:
#### Волна 1
- mapping текущего кода;
- проектирование новых contracts;
- проектирование state baseline.
#### Волна 2
- внедрение minimal `investigation_state`;
- базовое сохранение и использование state.
#### Волна 3
- внедрение evidence-структуры;
- обновление answer composer.
#### Волна 4
- усиление broad/generic query handling;
- controlled narrowing.
#### Волна 5
- добавление accountant-facing metrics и baseline eval harness.
#### Волна 6
- regression pass;
- acceptance mapping;
- cleanup только по необходимости.
---
## Acceptance criteria
Stage 1 считается закрытым только если выполнены все критерии ниже.
### A. Investigation state
- существует явный минимальный state-контур;
- он реально участвует в follow-up логике;
- он не конфликтует с будущим расширением;
- он не имитирует Stage 5.
### B. Broad-query behavior
- broad/generic вопросы обрабатываются более дисциплинированно;
- система не скатывается в пустые общие ответы;
- narrowing либо выполняется, либо честно сигнализируется;
- поведение стало более предсказуемым.
### C. Evidence structure
- evidence имеет явную структуру;
- связь между ответом и evidence стала лучше;
- механизм/основание ответа отображается более прозрачно;
- “ответ без опоры” не маскируется уверенностью.
### D. Answer quality
- ответ стал более полезным для бухгалтерского сценария;
- genericness снизилась;
- uncertainty стала видимой и контролируемой;
- улучшение не сводится только к косметике.
### E. Eval / metrics
- существует baseline benchmark/eval harness;
- есть набор контрольных кейсов;
- можно сравнить поведение до/после;
- accountant-facing метрики зафиксированы.
### F. Scope discipline
- нет скрытого выезда в Stages 2–6;
- нет большого platform refactor;
- нет ненужной сервисной декомпозиции;
- нет замены structural fixes промптами.
---
## Что Codex обязан явно указать в конце работы
В финальном отчёте по Stage 1 обязательно должны быть разделы:
1. Что было сделано
2. Какие файлы изменены
3. Какие новые сущности введены
4. Какие тесты добавлены
5. Какие acceptance criteria закрыты
6. Что сознательно НЕ реализовано
7. Какие риски и ограничения остались
8. Что подготовлено для Stage 2
---
## Красные флаги
Если в ходе работы появляется одно из следующего, реализацию нужно остановить и пересобрать plan:
- Codex предлагает полный redesign ассистента;
- появляется зависимость от graph layer;
- появляется попытка строить investigation engine;
- broad-query проблема решается только красивым текстом;
- state превращается в неявную chat memory;
- evidence остаётся текстовым пересказом без структуры;
- метрики ограничиваются только техническими тестами;
- ради Stage 1 предлагается большой рефактор transport/routing.
---
## Definition of Done
Stage 1 завершён, если одновременно соблюдены все условия:
- foundation layer реально усилен;
- текущий рабочий контур не разрушен;
- введён минимальный `investigation_state`;
- broad/generic handling стал более управляемым;
- evidence стало более структурным;
- появились accountant-facing метрики;
- есть baseline eval harness;
- изменения совместимы с platform core;
- нет premature implementation из следующих этапов.
---
## Короткая практическая формула этапа
**Stage 1 = не новая архитектура, а жёсткое усиление основания.**
Нужно получить не “почти готовый конечный продукт”, а:
- более дисциплинированный assistant mode;
- более формализованный foundation layer;
- меньше неявности;
- меньше generic-ответов;
- больше контролируемости;
- больше готовности к Stage 2 и дальше.

Some files were not shown because too many files have changed in this diff Show More