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

АДРЕСНЫЙ РЕЖИМ - M2.3b тюнинг account-scope и диагностика стадий адресного рантайма

Browse Source
This commit is contained in:
dctouch
2026-03-29 20:57:55 +03:00
parent c82ebd70b7
commit 2bf16de4ea
498 changed files with 2619075 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/HARD_SEMANTIC/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/HARD_SEMANTIC/accounting-assistant.zip
BIN
View File
Binary file not shown.
docs/HARD_SEMANTIC/accounting_canonical_schema.md
+102
View File
@@ -0,0 +1,102 @@
# Accounting Canonical Schema (Layer 4)
Date: 2026-03-23
Status: implemented as MVP store (`canonical_layer/store.py`)
## 1. Purpose
Canonical schema is a normalized read-only store for accounting semantics extracted from 1C.
It decouples heavy analytics from live query bridge.
## 2. Physical store
Current implementation supports SQLAlchemy URLs:
- default local: `sqlite:///X:/1C/NDC_1C/data/canonical_store.db`
- production target: PostgreSQL URL
## 3. Tables
### `canonical_entities`
Main canonical facts table.
Fields:
- `source_entity` (original 1C/OData entity set)
- `source_id` (stable source key)
- `display_name` (best effort label)
- `attributes_json` (raw source payload)
- `first_seen_at`
- `updated_at`
- `last_refresh_run_id`
Constraint:
- unique key on (`source_entity`, `source_id`)
### `canonical_links`
Graph edges inferred from reference-like fields.
Fields:
- `source_entity`
- `source_id`
- `relation` (currently `reference`)
- `target_entity`
- `target_id`
- `source_field`
- `updated_at`
- `last_refresh_run_id`
### `refresh_runs`
Operational run log for extraction/refresh jobs.
Fields:
- `id`
- `mode` (`historical`, `incremental`, `targeted`)
- `status` (`running`, `success`, `partial_success`, `failed`)
- `started_at`, `finished_at`
- `requested_entity_sets_json`
- `date_from`, `date_to`
- `limit_per_set`
- `records_read`, `entities_written`, `links_written`, `checkpoints_updated`
- `details_json`, `error_message`
### `refresh_checkpoints`
Per-entity-set watermark/checkpoint state.
Fields:
- `entity_set` (PK)
- `last_success_at`
- `last_refresh_run_id`
- `last_date_from`, `last_date_to`
## 4. Entity model mapping
Current canonical model maps into:
- `Organization`
- `Counterparty`
- `Contract`
- `Account`
- `Subconto`
- `Document`
- `Posting`
- `RegisterMovement`
- `Period`
Mapping source:
- `canonical_layer/mappers.py`
## 5. Known limitations (MVP)
- `attributes_json` stores source row as-is; no typed column model yet.
- Links are heuristic until per-configuration adapters are added.
- No dedicated partitioning strategy yet (planned for PostgreSQL stage).
docs/HARD_SEMANTIC/analytics_store_design.md
+92
View File
@@ -0,0 +1,92 @@
# Analytics Store Design (Layer 5)
Date: 2026-03-23
Status: MVP implemented (`canonical_layer/features.py`, `feature_metrics`, `anomaly_signals`)
## 1. Purpose
Analytics store keeps derived metrics and anomaly signals on top of canonical accounting store.
It avoids running heavy reasoning directly against live 1C bridge.
## 2. Physical tables
### `feature_runs`
Tracks each feature-engine execution.
Core fields:
- `id`
- `status`
- `started_at`, `finished_at`
- `baseline_window_hours`
- `entities_total`
- `metrics_written`
- `anomalies_written`
- `details_json`
- `error_message`
### `feature_metrics`
Stores derived metric rows.
Core fields:
- `feature_run_id`
- `metric_key`
- `scope`
- `scope_id`
- `metric_type`
- `metric_value`
- `attributes_json`
- `computed_at`
### `anomaly_signals`
Stores anomaly events and active anomaly snapshot.
Core fields:
- `feature_run_id`
- `signal_type`
- `severity`
- `scope`
- `scope_id`
- `score`
- `details_json`
- `detected_at`
- `is_active`
## 3. Current metric families (MVP)
- Global volume metrics:
- `canonical_entities_total`
- `canonical_links_total`
- `canonical_entity_sets_total`
- Structural metrics:
- `avg_links_per_entity`
- `high_link_threshold`
- Per-source entity metrics:
- `entity_count`
- `empty_display_share`
- `avg_links_per_entity`
- Tokenized accounting hints:
- `account_token_frequency`
- Operational freshness:
- `refresh_age_hours`
- Optional drift:
- `entity_count_drift_ratio` (if previous successful feature run exists)
## 4. Access surface
API endpoints:
- `POST /features/run`
- `GET /features/stats`
- `GET /features/runs`
- `GET /features/metrics`
- `GET /features/anomalies`
CLI:
- `python scripts/run_features.py`
docs/HARD_SEMANTIC/anomaly_engine_spec.md
+98
View File
@@ -0,0 +1,98 @@
# Anomaly Engine Spec (Layer 5 MVP)
Date: 2026-03-23
Status: implemented in `canonical_layer/features.py`
## 1. Engine role
Detect suspicious patterns from canonical data and refresh operations without direct write access to 1C.
## 2. Input data
- `canonical_entities`
- `canonical_links`
- `refresh_runs` (for freshness context)
- previous successful `feature_runs` and `feature_metrics` (for drift context)
## 3. Implemented anomaly rules
### 3.1 `no_canonical_data`
Trigger:
- canonical entity count is zero.
Severity:
- `high`
### 3.2 `empty_display_share_high`
Trigger:
- per-source-entity count >= 50
- and `empty_display_share >= 0.2`
Severity:
- `medium`
### 3.3 `high_link_degree`
Trigger:
- entity link count exceeds dynamic threshold `max(10, mean + 3*std)`
Severity:
- `medium` or `high` by score multiplier over threshold.
### 3.4 `missing_refresh_baseline`
Trigger:
- no successful refresh run exists.
Severity:
- `high`
### 3.5 `stale_refresh`
Trigger:
- `refresh_age_hours` exceeds configured threshold (`ANOMALY_STALE_REFRESH_THRESHOLD_HOURS`)
Severity:
- `high`
### 3.6 `entity_count_drift`
Trigger:
- previous successful feature run exists
- absolute drift ratio for `entity_count` is >= 0.3
- and absolute count difference >= 10
Severity:
- `medium` or `high` (if drift ratio >= 1.0)
## 4. Output contract
Each anomaly signal contains:
- `signal_type`
- `severity`
- `scope`
- `scope_id`
- `score`
- `details`
- `is_active`
## 5. Execution
- API: `POST /features/run`
- CLI: `python scripts/run_features.py`
- PowerShell: `scripts/run_features.ps1`
docs/HARD_SEMANTIC/assistant_orchestration_spec.md
+80
View File
@@ -0,0 +1,80 @@
# Assistant Orchestration Spec (Layer 7)
Date: 2026-03-23
Status: architecture-ready, partial runtime implementation
## 1. Objective
Route user questions to the correct execution path:
- live read-only bridge (point drill-down)
- canonical/feature/risk stores (fast analytical answer)
- refresh/feature/risk jobs (if cached context is stale or missing)
## 2. Routing modes
### Mode A: Live Drill-down
Use when user asks for a specific object/fact:
- one document
- one posting
- one account entry chain
Path:
`Assistant -> runtime bridge tools -> user answer`
### Mode B: Cached Analytics
Use when answer is already represented in stores:
- features
- anomalies
- risk patterns
Path:
`Assistant -> /features/* + /risk/* + canonical store -> user answer`
### Mode C: Recompute Then Answer
Use when data freshness is not acceptable or context missing:
1. trigger refresh (`/refresh/run`)
2. trigger features (`/features/run`)
3. trigger risk (`/risk/run`)
4. return updated answer
## 3. Current API surface used by orchestrator
- `POST /refresh/run`
- `GET /refresh/runs`
- `GET /store/stats`
- `POST /features/run`
- `GET /features/stats`
- `GET /features/anomalies`
- `POST /risk/run`
- `GET /risk/patterns`
- `GET /risk/stats`
## 4. Freshness policy (MVP)
1. If `stale_refresh` signal exists, trigger Mode C.
2. If no feature run exists, trigger Mode C.
3. If no risk run exists, trigger Mode C.
4. Otherwise use Mode B with optional Mode A drill-down evidence.
## 5. Response shape (recommended)
Assistant output should include:
1. direct answer
2. evidence source (`live`, `canonical`, `feature`, `risk`)
3. freshness markers (timestamps/run ids)
4. optional next action (`rerun refresh/features/risk`)
## 6. Safety rule
Orchestrator never sends write commands to 1C.
All runtime access is read-only by policy.
docs/HARD_SEMANTIC/canonical_model.md
+50
View File
@@ -0,0 +1,50 @@
# Canonical Model (MVP)
## Goal
Normalize selected 1C OData entities into a stable internal schema for search, analysis, and assistant workflows.
## Core Entities
- `Organization`
- `Counterparty`
- `Contract`
- `Account`
- `Subconto`
- `Document`
- `Posting`
- `RegisterMovement`
- `Period`
## Common Entity Contract
Each canonical entity contains:
- `source_entity`: original OData entity set name
- `source_id`: stable source identifier (for example `Ref_Key`)
- `display_name`: best-effort display label
- `attributes`: source fields from OData row
- `links`: inferred references to related entities
## Link Semantics
`links[]` represent read-only graph edges inferred from reference-like fields:
- `relation`: currently `reference`
- `target_entity`: guessed target type by field name
- `target_id`: ID/GUID of referenced object
- `source_field`: field that produced the link
## Mapping Rules (v1)
1. Detect `source_id` from `Ref_Key`, `ID`, `Id`, `id`, `Key`.
2. Detect `display_name` from `Description`, `Presentation`, `Number`, `Code`, and Russian equivalents.
3. Treat `_Key`, `*Ref*`, and GUID-like values as link candidates.
4. Classify entity type by entity set name keywords (RU + EN).
## Limitations
- Mapping is heuristic before final per-configuration adapters.
- Some 1C links may require explicit OData navigation expansion.
- Date filtering in API is best effort until entity-specific query templates are added.
docs/HARD_SEMANTIC/decision_report_odata_vs_deeper_access.md
+40
View File
@@ -0,0 +1,40 @@
# decision_report_odata_vs_deeper_access
## Executive Verdict
`Not yet sufficient for MVP accounting ontology` under hard 3-check gate.
## Hard-Gate Result (2026-03-22)
Source: `logs/deep_accounting_mvp_gate.json`
1. `document -> posting -> debit/credit account`: `pass`
2. `posting -> subconto[1..3] -> counterparty/contract/item`: `fail`
3. Explain one real saldo by movement set: `pass`
Because check #2 is not fully closed (slot `3` not reproducibly proven), the gate verdict is:
`Not yet sufficient for MVP accounting ontology; deeper access is justified for failed checks.`
Additional slot `3` recon artifact:
- `logs/slot3_recon_report.json`
- Summary doc: `docs/slot3_recon_2026-03-22.md`
- UT compatibility status: `docs/ut_compatibility_blocker_2026-03-22.md`
## What Is Already Strong
1. OData endpoint is stable and metadata is readable.
2. Domain coverage is broad (`1189` entity sets).
3. Core document/register joins are reproducible.
4. Subconto linkage is derivable for practical cases (including counterparty/contract/item dimensions), but not yet complete for full `1..3` slot coverage.
## Required Next Move
1. Keep OData as baseline transport and canonical contract source.
2. Add deeper access only for the missing hard-check segment (`subconto slot 3` closure).
3. Use FoxyLink as primary deeper-access PoC candidate.
4. Treat Universal Tools branch as blocked for current `БП 2.0` test contour (no plug-and-play compatibility).
5. Follow execution plan: `docs/deeper_access_execution_plan_foxylink_ut_2026-03-22.md`.
6. Follow test rollout checklist: `docs/test_contour_runbook_foxylink_ut_2026-03-22.md`.
7. Re-run `scripts/run_probe.ps1` until all three checks pass.
docs/HARD_SEMANTIC/deeper_access_execution_plan_foxylink_ut_2026-03-22.md
+69
View File
@@ -0,0 +1,69 @@
# Deeper Access Execution Plan: FoxyLink Primary Track (UT Blocked)
## Goal
Close the only failed hard gate segment:
- `posting -> subconto[1..3] -> counterparty/contract/item` (missing reproducible slot `3` proof)
without replacing the working OData read-only contour.
## Architecture Direction
1. Keep OData as the base read-only contour for broad extraction and low-cost discovery.
2. Treat Universal Tools quick-probe branch as blocked for current `БП 2.0` lab contour (compatibility mismatch).
3. Run FoxyLink PoC as the main deeper-access candidate for stable retrieval of missing semantic links/aggregates.
4. Keep canonical layer as the only external contract (API/MCP sees one model, regardless of source mix).
5. UT may be revisited only as a separate adaptation project.
## Phase Plan
### Phase 1: Compatibility Gate (UT) - Closed as Blocked
1. `UI.cfe` installation attempt in lab copy failed.
2. Missing required BSP/configuration objects confirmed.
3. Branch status fixed as `blocked`.
Artifact:
- `docs/ut_compatibility_blocker_2026-03-22.md`
### Phase 2: FoxyLink PoC (Primary)
1. Deploy FoxyLink in isolated test contour.
2. Implement minimal extraction job for failed segment only (slot `3` closure).
3. Map result into existing canonical schema (no schema fork).
4. Run side-by-side with OData flow on the same sample period.
Exit criteria:
- Hard check #2 passes from reproducible FoxyLink-backed evidence.
- No regressions in checks #1 and #3.
### Phase 3: Integration Decision
1. If PoC passes, promote FoxyLink as primary deeper-access contour.
2. Keep OData as wide read-only baseline.
3. Keep Universal Tools out of critical path unless separate adaptation is approved.
Exit criteria:
- `scripts/deep_probe_accounting_mvp_gate.py` => all checks `pass`
- Final verdict in `logs/deep_accounting_mvp_gate.json` => `OData sufficient for MVP accounting ontology`
## Required Controls
1. Test-only installation for diagnostic/deeper-access tools.
2. Read-only policy remains mandatory for OData contour.
3. Role-level permission audit before production promotion.
4. License/legal review before rollout (FoxyLink AGPL, Universal Tools GPL-3.0).
5. Explicit record of UT incompatibility in the decision package.
## Deliverables
1. Updated gate artifact: `logs/deep_accounting_mvp_gate.json`
2. Updated decision report: `docs/decision_report_odata_vs_deeper_access.md`
3. Added evidence package for slot `3` closure (query + sample + mapping)
4. Readiness snapshot: `logs/deeper_access_readiness.json`
5. Test contour checklist: `docs/test_contour_runbook_foxylink_ut_2026-03-22.md`
6. UT blocker note: `docs/ut_compatibility_blocker_2026-03-22.md`
docs/HARD_SEMANTIC/foxylink_poc_runbook_2026-03-22.md
+105
View File
@@ -0,0 +1,105 @@
# FoxyLink PoC Runbook (2026-03-22)
## Goal
Close hard check #2 with reproducible evidence:
- `posting -> subconto[1..3] -> counterparty / contract / item`
while keeping OData as the baseline read-only contour.
## Current Fact Baseline
- OData baseline is working.
- UT `UI.cfe` quick path is blocked for the current test contour.
- FoxyLink HTTP probe to `http://localhost/buh_test/hs/AppEndpoint/v1/Self/Query/SYNC`
currently returns `404` in this workspace baseline.
This usually means FoxyLink is not merged/published in the currently exposed infobase
or HTTP services are not enabled for the publication.
## Local Artifacts
- FoxyLink source: `external/FoxyLink/src`
- Probe script: `scripts/foxylink_probe_endpoint.py`
- Probe wrapper: `scripts/run_foxylink_probe.ps1`
- Probe report output: `logs/foxylink_probe_report.json`
- Payload template: `docs/snapshots/foxylink_slot3_payload_template.json`
## Step 1: Deploy FoxyLink in Isolated Test Base
1. Open test base in 1C Configurator.
2. Merge configuration from `external/FoxyLink/src` (`Compare, merge with configuration from file...`).
3. Update database configuration.
4. Re-publish the test infobase on IIS with HTTP services enabled.
## Step 2: Initialize and Check Predefined Objects
Confirm these descriptions exist in the target base (they are used in URL routing):
- Exchange: `Self`
- Operation: `Query`
- Channel: `Self (Files)`
If subsystem initial fill was not executed automatically, run FoxyLink initialization
inside the test base so predefined objects and handlers are ready.
## Step 3: Minimal PoC Routing Setup
Create one minimal read-only route for operation `Query` that outputs a slot3-focused dataset:
1. In exchange `Self`, ensure `InUse = true`.
2. For operation `Query`, define Data Composition Schema/Settings that returns:
- document ref + line number
- posting recorder + line number
- debit/credit account
- subconto slot 1..3 values/types (or equivalent semantic columns)
3. Bind operation `Query` to channel `Self (Files)`.
4. Set channel resources for file output:
- `Path = X:\1C\NDC_1C\logs\foxylink_out`
- `BaseName = slot3_probe`
- `Extension = .json`
- `AddTimestamp = true` (optional)
## Step 4: Endpoint Smoke Check
Run:
```powershell
cd X:\1C\NDC_1C
powershell -ExecutionPolicy Bypass -File .\scripts\run_foxylink_probe.ps1 --strict
```
Expected:
- `logs/foxylink_probe_report.json` has `classification = reachable`
- `response.status_code = 200`
If status is `404`, re-check merge/publication path:
- publication base name (`ONEC_INFOBASE`)
- `ONEC_FOXY_PATH` (default `/hs/AppEndpoint/`)
- FoxyLink merge into the exact published infobase
## Step 5: Parameterized Semantic Probe
1. Put request payload JSON into
`docs/snapshots/foxylink_slot3_payload_template.json` (or another file).
2. Run:
```powershell
cd X:\1C\NDC_1C
python scripts/foxylink_probe_endpoint.py --payload-file docs/snapshots/foxylink_slot3_payload_template.json --strict
```
3. Verify exported data file appears in `logs/foxylink_out`.
4. Use that file to update slot3 evidence and re-run the hard gate scripts.
## Acceptance for Promotion
Promotion to "FoxyLink deeper path ready" is allowed when all are true:
1. FoxyLink probe endpoint is reachable (`HTTP 200`).
2. Slot3 evidence is reproducible from FoxyLink output.
3. All three hard checks pass in `logs/deep_accounting_mvp_gate.json`.
docs/HARD_SEMANTIC/historical_load_plan.md
+47
View File
@@ -0,0 +1,47 @@
# Historical Load Plan
Date: 2026-03-23
Status: executable in MVP mode
## 1. Objective
Build initial canonical baseline for analytics by loading a broad slice of entity sets.
## 2. Preconditions
1. OData access is healthy.
2. `entity_sets.json` or metadata is available.
3. Canonical DB is configured (`CANONICAL_DB_URL`).
## 3. Run command
Example:
```powershell
python scripts/run_refresh.py --mode historical --limit-per-set 500
```
Alternative explicit set list:
```powershell
python scripts/run_refresh.py --mode historical --entity-set DocumentSales --entity-set RegisterAccounting
```
## 4. Acceptance checks
1. `logs/refresh_last_run.json` exists.
2. Run status is `success` or `partial_success`.
3. `store_stats.entities_total > 0`.
4. `checkpoints_total > 0`.
## 5. Recovery rules
- If run is `failed`, fix connectivity/schema issue and rerun same command.
- If run is `partial_success`, rerun failed entity sets explicitly via `--entity-set`.
## 6. Post-load
After successful baseline load:
1. Freeze closed periods policy in ops notes.
2. Switch daily operations to incremental mode.
docs/HARD_SEMANTIC/incremental_refresh_plan.md
+47
View File
@@ -0,0 +1,47 @@
# Incremental Refresh Plan
Date: 2026-03-23
Status: executable in MVP mode
## 1. Objective
Keep canonical store current for open periods without running full historical load each time.
## 2. Schedule recommendation
- business hours: every 15-60 minutes for critical sets
- off-hours: one consolidation run
- manual targeted run on-demand for urgent drill-down
## 3. Standard command
Example incremental window:
```powershell
python scripts/run_refresh.py --mode incremental --from-date 2026-01-01T00:00:00 --limit-per-set 200
```
Targeted catch-up:
```powershell
python scripts/run_refresh.py --mode targeted --target-id 68.02 --limit-per-set 200
```
## 4. Operational controls
1. Watch latest run status via `GET /refresh/runs`.
2. Watch store health via `GET /store/stats`.
3. Alert on consecutive `failed` runs.
4. Alert on repeated growth of `failed_entity_sets`.
## 5. Idempotency and consistency
- Entity writes are upsert-based (`source_entity`, `source_id`).
- Links for each source entity are replaced each run to avoid stale edges.
- Checkpoints update only for successfully processed entity sets.
## 6. Known MVP limits
- Date filtering is best-effort from common date fields.
- No CDC stream; refresh is pull-based.
- Large enterprise-wide slices still require separate analytical batching strategy.
docs/HARD_SEMANTIC/linkage_report.md
+32
View File
@@ -0,0 +1,32 @@
# Linkage Report
## Status
- Date: `2026-03-22`
- Probe run ID: `2026-03-22T12:30:33Z`
## Verified Link Paths
1. `Document -> Counterparty`: `verified by inferred reference fields`
2. `Document -> Contract`: `verified by inferred reference fields`
3. `Document -> Organization`: `verified by inferred reference fields`
4. `Document -> RegisterMovement/Posting`: `partially verified, requires scenario-specific join`
5. `Posting -> Account/Subconto`: `partially verified from accounting register fields`
## Evidence
- Metadata file: `logs/metadata.xml`
- Entity sets summary: `logs/entity_sets.json`
- Probe report: `logs/probe_report.json`
- Sample links: `logs/sample_links.json`
## Gaps
1. `Need explicit document->posting linkage query templates for production scenarios`
2. `Need read-only denial test for write operations at role policy level`
3. `Some entity sets returned 0 rows in sample window and need broader date range`
## Decision
- OData viability: `yes`
- Next step: `stay on OData and build focused query templates for business scenarios`
docs/HARD_SEMANTIC/mapping_1c_odata_v0_1.md
+43
View File
@@ -0,0 +1,43 @@
# mapping_1c_odata_v0_1
## Priority Mapping
| 1C OData entity set | Canonical entity | Mapping status | Notes |
|---|---|---|---|
| `AccountingRegister_Хозрасчетный` | `Posting` | `derivable` | содержит `Recorder`, используется как мост к документу |
| `AccountingRegister_Хозрасчетный_RecordType` | `Posting` | `direct` | есть `AccountDr_Key`, `AccountCr_Key`, `Организация_Key`, `Recorder` |
| `ChartOfAccounts_Хозрасчетный` | `Account` | `direct` | читается, есть ключи и иерархия (`Parent_Key`) |
| `ChartOfCharacteristicTypes_ВидыСубконтоХозрасчетные` | `SubcontoType` | `direct` | сущность доступна, ключи читаются |
| `Catalog_Контрагенты` | `Counterparty` | `direct` | ключи и ссылочные поля доступны |
| `Catalog_ДоговорыКонтрагентов` | `Contract` | `direct` | есть `Owner_Key`, `Организация_Key` |
| `Catalog_Организации` | `Organization` | `direct` | стабильное чтение, есть ссылочные поля |
| `Catalog_БанковскиеСчета` | `BankAccount` | `direct` | есть связи `Owner`, `Банк_Key`, `ВалютаДенежныхСредств_Key` |
| `Catalog_Валюты` | `Currency` | `direct` | есть в metadata (в probe не был целевым объектом) |
| `Catalog_Номенклатура` | `Item` | `direct` | есть в metadata (в probe не был целевым объектом) |
| `Document_РеализацияТоваровУслуг` | `Document(type=sales)` | `direct` | ключевые связи на контрагента, договор, счета |
| `Document_ПоступлениеТоваровУслуг` | `Document(type=goods_receipt)` | `direct` | ключевые связи подтверждены |
| `Document_СписаниеСРасчетногоСчета` | `Document(type=bank_out)` | `direct` | есть связи на bank/account/counterparty |
| `Document_ПоступлениеНаРасчетныйСчет` | `Document(type=bank_in)` | `direct` | есть связи на bank/account/counterparty |
| `Document_ОперацияБух` | `Document(type=manual_entry)` | `direct` | связана с организацией и ответственным |
## Table Parts Mapping
| Pattern | Canonical target | Status |
|---|---|---|
| `Document_*_Товары` | `DocumentLine` / `ItemLine` | `direct` |
| `Document_*_Услуги` | `DocumentLine` / `ServiceLine` | `direct` |
| `Document_*_Оплата` | `PaymentLine` | `direct` |
| `Document_*_СчетаРасчетов` | `SettlementLine` | `direct` |
## Register Families Mapping
| Pattern | Canonical target | Strategy |
|---|---|---|
| `AccumulationRegister_*` | `RegisterMovement` | selective include by business scenarios |
| `InformationRegister_*` | `ReferenceFact` / `OperationalAttribute` | include only when chain evidence requires |
## Mapping Constraints
1. Один источник не создает независимые факты `Posting` и `RegisterMovement` без fixed precedence.
2. Для chain-level reasoning сначала используем `Document + AccountingRegister_Хозрасчетный_RecordType`.
3. `InformationRegister_*` подключаются инкрементально по KPI-сценариям.
docs/HARD_SEMANTIC/mcp_strategy.md
+48
View File
@@ -0,0 +1,48 @@
# MCP Strategy (Draft)
## Objective
Expose read-only accounting data to assistant tools through MCP while preserving integration safety.
## Variant A: OData -> MCP Bridge
Use external OData-to-MCP proxy first for fast validation:
- Candidate: `oisee/odata_mcp_go`
- Candidate: `lemaiwo/odata-mcp-proxy`
- Input: 1C OData endpoint + read-only credentials
- Output: MCP tools generated from metadata
### Pros
- Fastest prototype path
- Low custom code for initial tool exposure
### Cons
- Tool surface can be too broad
- Requires strict read-only guardrails
## Variant B: Canonical API -> Custom MCP
Build MCP on top of `canonical_layer` API endpoints:
- Source is normalized entities
- Tools are curated by scenario, not by raw OData entity set
### Pros
- Better assistant UX and stable semantics
- Easier security and observability control
### Cons
- More engineering work
## Recommended Sequence
1. Validate data depth with OData probe.
2. Ship API scenarios in canonical layer.
3. Start MCP with bridge for speed.
4. Migrate to custom MCP on canonical API if bridge is noisy or limited.
docs/HARD_SEMANTIC/mvp_gate_3_hard_checks_2026-03-22.md
+47
View File
@@ -0,0 +1,47 @@
# MVP Gate: 3 Hard Checks (2026-03-22)
## Context
- Endpoint: `http://localhost/buh_test/odata/standard.odata/`
- Generated artifact: `logs/deep_accounting_mvp_gate.json`
- Script: `scripts/deep_probe_accounting_mvp_gate.py`
## Results
### 1) `document -> posting -> debit/credit account`
- Status: `pass`
- Evidence:
- joined rows found: `1193`
- line sets scanned with joins: `9`
- sample shows one document line linked to posting row with both `AccountDr_Key` and `AccountCr_Key`
### 2) `posting -> subconto[1..3] -> counterparty / contract / item`
- Status: `fail`
- Evidence:
- dimensions found: `counterparty`, `contract`, `item`
- slots found: `1`, `2`
- required slots for hard check: `1`, `2`, `3`
- missing proof: stable slot `3` mapping in reproducible posting-linked evidence
- slot3 recon totals (`logs/slot3_recon_report.json`):
- `sets_with_slot3_fields`: `11`
- `sets_with_non_null_slot3`: `0`
- `rows_with_non_null_slot3_total`: `0`
### 3) Explain one real saldo by movements
- Status: `pass`
- Evidence:
- account key: `cbfac538-cfb6-4fd4-8566-c20f34f9a3b0`
- movement count: `547`
- debit turnover: `156116250.22`
- credit turnover: `225610120.25`
- saldo: `-69493870.03`
- movement-level deltas are included in `logs/deep_accounting_mvp_gate.json`
## Gate Verdict
`Not yet sufficient for MVP accounting ontology; deeper access is justified for failed checks.`
Reason: hard check #2 is not fully closed (slot `3` not reproducibly proven).
docs/HARD_SEMANTIC/odata_full_inventory_2026-03-22.md
+143
View File
@@ -0,0 +1,143 @@
# Полная Инвентаризация OData (2026-03-22)
## 1. Текущее Состояние Интеграции
- OData endpoint: `http://localhost/buh_test/odata/standard.odata/`
- Metadata endpoint: `http://localhost/buh_test/odata/standard.odata/$metadata`
- Web сервер: IIS (`Microsoft-IIS/10.0`)
- Аутентификация: Basic (`realm="1C:Enterprise 8.3"`)
- Интеграционный пользователь: `ndc_probe`
- Режим доступа: read-only (подтверждено командой; role-deny на запись нужно хранить и проверять в 1С)
## 2. Что Мы Имеем По Metadata
Из `logs/metadata.xml` и `logs/entity_sets_annotated.json`:
- Всего entity sets: `1189`
- Приоритетных по ключевым словам: `602`
- Семейств сущностей: `11`
### Разрез По Семействам
| Семейство | Кол-во |
|---|---:|
| `Document_*` | 517 |
| `InformationRegister_*` | 270 |
| `Catalog_*` | 162 |
| `AccumulationRegister_*` | 102 |
| `Constant_*` | 95 |
| `DocumentJournal_*` | 21 |
| `ExchangePlan_*` | 14 |
| `ChartOfCharacteristicTypes_*` | 4 |
| `AccountingRegister_*` | 2 |
| `ChartOfAccounts_*` | 1 |
| `ChartOfCalculationTypes_*` | 1 |
## 3. Ключевые Бизнес-Сущности (Проверка Наличия)
Подтверждено наличие в metadata:
- `Catalog_Контрагенты`
- `Catalog_ДоговорыКонтрагентов`
- `Catalog_Организации`
- `Catalog_БанковскиеСчета`
- `Catalog_Номенклатура`
- `Document_ПоступлениеТоваровУслуг`
- `Document_РеализацияТоваровУслуг`
- `Document_СписаниеСРасчетногоСчета`
- `Document_ПоступлениеНаРасчетныйСчет`
- `AccountingRegister_Хозрасчетный`
## 4. Что Подтверждено Probe-Запросами
Источник: `logs/probe_report.json` (прогон от `2026-03-22T12:30:33Z`).
- Целевых сущностей в прогоне: `8`
- Успешных: `8`
- Ошибок: `0`
| Сущность | Записей | Подозреваемых link-полей |
|---|---:|---:|
| `Catalog_Контрагенты` | 5 | 7 |
| `Catalog_ДоговорыКонтрагентов` | 5 | 9 |
| `Catalog_Организации` | 3 | 9 |
| `Catalog_БанковскиеСчета` | 5 | 5 |
| `Document_АвансовыйОтчет` | 5 | 7 |
| `Document_ПоступлениеТоваровУслуг` | 5 | 13 |
| `Document_РеализацияТоваровУслуг` | 5 | 24 |
| `AccountingRegister_Хозрасчетный` | 5 | 1 |
## 5. Связи, Которые Уже Видны В Данных
Источник: `logs/sample_links.json`.
### 5.1 Контрагенты
`Catalog_Контрагенты` содержит ссылочные поля:
- `ГоловнойКонтрагент_Key`
- `ОсновнойДоговорКонтрагента_Key`
- `ОсновнойБанковскийСчет_Key`
- `СтранаРегистрации_Key`
### 5.2 Договоры
`Catalog_ДоговорыКонтрагентов` содержит:
- `Owner_Key` (владелец/контрагент)
- `Организация_Key`
- `ВалютаВзаиморасчетов_Key`
- `ВидВзаиморасчетов_Key`
### 5.3 Документы
`Document_ПоступлениеТоваровУслуг` показывает связи на:
- `Контрагент_Key`
- `ДоговорКонтрагента_Key`
- `Организация_Key`
- `Склад_Key`
- `СчетУчетаРасчетовСКонтрагентом_Key`
`Document_РеализацияТоваровУслуг` показывает расширенный граф:
- контрагент и договор
- организация и банковский счет
- набор счетов учета расчетов/доходов/расходов
- дополнительные ролевые связи (ответственные, руководитель и т.д.)
### 5.4 Проводки/учетный регистр
`AccountingRegister_Хозрасчетный` читается и содержит ссылку `Recorder`, что дает базу для цепочки:
`Проводка -> Регистратор (документ) -> Контрагент/Договор/Организация`.
## 6. Что Это Значит Для MVP
Уже сейчас подтверждена техническая возможность:
1. Читать живые данные 1С по OData без ручных выгрузок.
2. Строить канонический слой не только по плоским записям, но и по ссылочным связям.
3. Реализовать прикладные эндпоинты:
- документы за период,
- документы контрагента,
- проводки по счету,
- граф связей документа.
## 7. Ограничения На Текущий Момент
1. Часть регистров в выборке может вернуть `0` строк из-за малого окна `top` и фактического наполнения данных.
2. Read-only модель подтверждена организационно, но технический контроль write-deny нужно держать на уровне роли 1С.
3. Для production-сценариев нужны целевые query-шаблоны, а не только универсальный `top`.
## 8. Где Лежит Полный Снэпшот Всех Сущностей
- Полный JSON-снэпшот: `docs/snapshots/entity_sets_snapshot_2026-03-22.json`
- Полный Markdown-снэпшот: `docs/snapshots/entity_sets_snapshot_2026-03-22.md`
Оба файла содержат весь список (`1189`) entity sets.
## 9. Артефакты Проверки
- `logs/metadata.xml`
- `logs/entity_sets.json`
- `logs/entity_sets_annotated.json`
- `logs/entity_sets_annotated.txt`
- `logs/probe_report.json`
- `logs/sample_links.json`
docs/HARD_SEMANTIC/ontology_v0_1.md
+95
View File
@@ -0,0 +1,95 @@
# ontology_v0_1
## Scope
Базовая каноническая онтология бухгалтерского контура для MVP и assistant layer.
## Core Facts
### Posting (primary fact)
`Posting` — основной факт бухгалтерского отражения.
Required fields:
- `posting_id`
- `period`
- `document_id`
- `organization_id`
- `debit_account_id`
- `credit_account_id`
- `amount`
- `source_register`
Optional fields:
- `currency_id`
- `subconto_1`
- `subconto_2`
- `subconto_3`
- `content`
- `is_active`
### RegisterMovement (secondary fact)
`RegisterMovement` — вспомогательный факт трассировки, не второй источник истины для учета.
Required fields:
- `movement_id`
- `register_name`
- `period`
- `recorder_document_id`
Optional fields:
- `organization_id`
- `dimensions`
- `resources`
- `is_active`
### Document
Required fields:
- `document_id`
- `document_type`
- `number`
- `date`
Optional fields:
- `organization_id`
- `counterparty_id`
- `contract_id`
- `posted_flag`
- `author_id`
- `comment`
- `source_entity_set`
## Main Dimensions
- `Account`
- `SubcontoType`
- `Counterparty`
- `Contract`
- `Organization`
- `BankAccount`
- `Currency`
- `Item`
## Canonical Relations
- `Document -> creates -> Posting`
- `Posting -> basedOn -> Document`
- `Posting -> debitAccount -> Account`
- `Posting -> creditAccount -> Account`
- `Posting -> belongsTo -> Organization`
- `Posting -> hasCurrency -> Currency`
- `Posting -> usesSubcontoType -> SubcontoType`
- `Counterparty -> hasContract -> Contract`
- `Organization -> ownsBankAccount -> BankAccount`
- `Document -> referencesCounterparty -> Counterparty`
- `Document -> referencesContract -> Contract`
- `Document -> referencesOrganization -> Organization`
- `Document -> referencesBankAccount -> BankAccount`
## Modeling Rules
1. `Posting` и `RegisterMovement` не дублируют один и тот же факт без явного правила приоритета.
2. Каждая связь имеет `probe_status`: `direct|derivable|opaque|missing`.
3. Источник связи фиксируется через `source_evidence` (metadata, navigation link, key-based join, inference).
docs/HARD_SEMANTIC/probe_matrix.md
+63
View File
@@ -0,0 +1,63 @@
# probe_matrix
## Probe Context
- Date: `2026-03-22`
- Endpoint: `http://localhost/buh_test/odata/standard.odata/`
- Source files:
- `logs/probe_report.json`
- `logs/sample_links.json`
- `logs/metadata.xml`
- `logs/deep_subconto_join_probe.json`
## Chain Status Matrix
| Chain | Description | Status | Evidence summary |
|---|---|---|---|
| A | `Document_Реализация -> Posting -> Account -> Subconto` | `derivable` | Proven by join: document lines (`Ref_Key + LineNumber`) to posting rows (`Recorder + LineNumber`), with account match and `Subconto_Type` present. |
| B | `Document_Поступление -> Posting -> Accounts` | `derivable` | Document rows are readable; account keys restored via `Recorder` bridge to accounting register. |
| C | `Counterparty -> Contract -> Documents -> Movements` | `derivable` | `Owner_Key`, `Контрагент_Key`, `ДоговорКонтрагента_Key` are available; movement path is derivable through recorder-based joins. |
| D | `Bank docs -> BankAccount -> Movements` | `derivable` | Bank documents and bank account keys are readable; movements are joinable via register records. |
| E | `Document_ОперацияБух -> AccountingRegister -> Explainability` | `derivable` | Manual operation docs and accounting register records are readable with stable account/recorder fields. |
| F | `ChartOfAccounts -> SubcontoType -> Posting` | `derivable` | Derivable in data-driven mode (posting account + linked document-line `Subconto_Type`), even though direct normative mapping from ChartOfAccounts fields is not exposed. |
## Relation-Level Status (core)
| Relation | Status | Evidence type |
|---|---|---|
| `Document -> Posting` | `derivable` | key-based join (`Ref_Key` <-> `Recorder`) plus `LineNumber` |
| `Posting -> debitAccount` | `direct` | `AccountDr_Key` in `AccountingRegister_Хозрасчетный_RecordType` |
| `Posting -> creditAccount` | `direct` | `AccountCr_Key` in `AccountingRegister_Хозрасчетный_RecordType` |
| `Posting -> Organization` | `direct` | `Организация_Key` in `AccountingRegister_Хозрасчетный_RecordType` |
| `Document -> Counterparty` | `direct` | `Контрагент_Key` in document entity sets |
| `Document -> Contract` | `direct` | `ДоговорКонтрагента_Key` in document entity sets |
| `Counterparty -> Contract` | `direct` | `Owner_Key` in `Catalog_ДоговорыКонтрагентов` |
| `Organization -> BankAccount` | `direct` | `ОсновнойБанковскийСчет_Key` / `СчетОрганизации_Key` |
| `Posting -> SubcontoType` | `derivable` | Proven in `logs/deep_subconto_join_probe.json` with joined rows and stable `Subconto_Type` extraction |
## Evidence Snapshot For Deep Subconto Probe
- Tested document key: `b8661088-b0f2-11e4-9980-5404a6c12c2c`
- Posting rows for document: `108`
- Document line rows: `36`
- Joined rows: `36`
- Account match in joined sample: `true`
- Chain A status in deep probe: `derivable`
- Chain F status in deep probe: `derivable`
## Caveat (important)
- `ChartOfAccounts -> SubcontoType` is currently reconstructed from observed data (`Posting + Line Subconto_Type`), not from an explicit normative field map exposed by OData metadata.
- For strict compliance scenarios, keep this caveat in model governance notes.
- Hard-gate check `posting -> subconto[1..3] -> counterparty/contract/item` is still incomplete: slots `1` and `2` are proven, slot `3` is not yet reproducibly proven (`logs/deep_accounting_mvp_gate.json`).
- Slot `3` recon artifact confirms this is a data/evidence gap on current sample (`logs/slot3_recon_report.json`): slot3 fields exist in metadata, but non-null slot3 values were not observed in sampled rows.
## Security Check (write deny)
Transport-level check on `$metadata`:
- `POST` -> `405`
- `PATCH` -> `405`
- `DELETE` -> `405`
Role-level read-only should still be audited in 1C permissions.
docs/HARD_SEMANTIC/refresh_strategy.md
+67
View File
@@ -0,0 +1,67 @@
# Refresh Strategy (Layer 3)
Date: 2026-03-23
Status: MVP implementation available (`canonical_layer/refresh.py`)
## 1. Goal
Provide controlled extraction from 1C into canonical store with reproducible runs,
checkpoints, and operational audit trail.
## 2. Refresh modes
### Historical
- bootstrap population of canonical store
- wide scan of selected entity sets
- used to build initial baseline
### Incremental
- regular updates for open periods
- optional date window (`date_from`, `date_to`)
- preferred default daily mode
### Targeted
- selective refresh for one account/document/counterparty context
- optional `target_id` text filter
- used for point recovery and drill-down gaps
## 3. Runtime behavior
1. Resolve entity sets (explicit list or keyword-based discovery).
2. Read records from 1C OData per entity set (bounded by `limit_per_set`).
3. Apply optional date and targeted filters.
4. Map rows to canonical entities and links.
5. Upsert entities/links to canonical store.
6. Update checkpoints for successful sets.
7. Persist run status and metrics into `refresh_runs`.
## 4. Run statuses
- `success`: all requested sets processed
- `partial_success`: at least one set processed, at least one failed
- `failed`: no sets processed successfully
## 5. Execution interfaces
CLI:
- `python scripts/run_refresh.py --mode incremental ...`
PowerShell wrapper:
- `scripts/run_refresh.ps1`
API:
- `POST /refresh/run`
- `GET /refresh/runs`
- `GET /store/stats`
## 6. Safety constraints
- Read-only integration policy stays unchanged.
- No write-back into 1C.
- Local canonical store is internal analytical cache, not source of truth.
docs/HARD_SEMANTIC/relationship_evidence.json
+140
View File
@@ -0,0 +1,140 @@
{
"generated_at": "2026-03-22T16:31:00",
"endpoint": "http://localhost/buh_test/odata/standard.odata/",
"source_files": [
"logs/metadata.xml",
"logs/probe_report.json",
"logs/sample_links.json",
"logs/deep_subconto_join_probe.json"
],
"chains": [
{
"chain": "A",
"name": "Document_Реализация -> Posting -> Account -> Subconto",
"status": "derivable",
"evidence": [
"Join proven by Ref_Key + LineNumber <-> Recorder + LineNumber",
"Account key consistency verified on joined sample",
"Subconto_Type extracted from linked document lines"
]
},
{
"chain": "B",
"name": "Document_Поступление -> Posting -> Accounts",
"status": "derivable",
"evidence": [
"Document_ПоступлениеТоваровУслуг readable",
"Recorder bridge to accounting register",
"AccountDr/AccountCr present"
]
},
{
"chain": "C",
"name": "Counterparty -> Contract -> Documents -> Movements",
"status": "derivable",
"evidence": [
"Catalog_Контрагенты + Catalog_ДоговорыКонтрагентов readable",
"Owner_Key / Контрагент_Key / ДоговорКонтрагента_Key present",
"Movement join via recorder derivable"
]
},
{
"chain": "D",
"name": "Bank docs -> BankAccount -> Movements",
"status": "derivable",
"evidence": [
"Document_СписаниеСРасчетногоСчета readable",
"Document_ПоступлениеНаРасчетныйСчет readable",
"Bank/account keys + register join available"
]
},
{
"chain": "E",
"name": "Document_ОперацияБух -> AccountingRegister -> Explainability",
"status": "derivable",
"evidence": [
"Document_ОперацияБух readable",
"AccountingRegister_Хозрасчетный and RecordType readable",
"Recorder/account fields allow explainability graph base"
]
},
{
"chain": "F",
"name": "ChartOfAccounts -> SubcontoType -> Posting",
"status": "derivable",
"evidence": [
"Posting account keys are directly readable",
"Subconto_Type is available on linked document line entities",
"Mapping is data-driven; direct normative chart field mapping is not exposed"
]
}
],
"relations": [
{
"relation": "Document->Posting",
"status": "derivable",
"evidence": "Recorder bridge in accounting register (+ LineNumber on deep probe)"
},
{
"relation": "Posting->debitAccount",
"status": "direct",
"evidence": "AccountDr_Key"
},
{
"relation": "Posting->creditAccount",
"status": "direct",
"evidence": "AccountCr_Key"
},
{
"relation": "Posting->Organization",
"status": "direct",
"evidence": "Организация_Key"
},
{
"relation": "Document->Counterparty",
"status": "direct",
"evidence": "Контрагент_Key in documents"
},
{
"relation": "Document->Contract",
"status": "direct",
"evidence": "ДоговорКонтрагента_Key in documents"
},
{
"relation": "Counterparty->Contract",
"status": "direct",
"evidence": "Owner_Key in contracts"
},
{
"relation": "Organization->BankAccount",
"status": "direct",
"evidence": "ОсновнойБанковскийСчет_Key and СчетОрганизации_Key"
},
{
"relation": "Posting->SubcontoType",
"status": "derivable",
"evidence": "Deep join proof in logs/deep_subconto_join_probe.json"
}
],
"write_guard": {
"endpoint": "http://localhost/buh_test/odata/standard.odata/$metadata",
"post_status": 405,
"patch_status": 405,
"delete_status": 405,
"note": "transport-level check; role-level deny should be audited in 1C"
},
"hard_gate_2026_03_22": {
"source": "logs/deep_accounting_mvp_gate.json",
"document_to_posting_to_accounts": "pass",
"posting_to_subconto123_to_counterparty_contract_item": "fail",
"saldo_explainability_from_movements": "pass",
"verdict": "Not yet sufficient for MVP accounting ontology; deeper access is justified for failed checks."
},
"deep_probe_snapshot": {
"tested_document_key": "b8661088-b0f2-11e4-9980-5404a6c12c2c",
"posting_rows_for_document": 108,
"line_rows_for_document": 36,
"joined_rows": 36,
"account_match": true
}
}
docs/HARD_SEMANTIC/risk_engine_spec.md
+74
View File
@@ -0,0 +1,74 @@
# Risk Engine Spec (Layer 6 MVP)
Date: 2026-03-23
Status: implemented in `canonical_layer/risk.py`
## 1. Purpose
Transform anomaly signals into explainable risk patterns and a global risk score.
## 2. Inputs
- `feature_runs` (latest successful run context)
- `anomaly_signals` for selected feature run
- optional explicit `source_feature_run_id`
## 3. Outputs
### `risk_runs`
Execution journal for each risk-scoring run:
- status, timestamps
- source feature run
- patterns written
- global score
- details/error
### `risk_patterns`
Explainable risk patterns:
- `pattern_key`
- `severity`
- `scope`, `scope_id`
- `score`, `confidence`
- `details` (breakdown + evidence examples)
- `is_active`
Always includes:
- `global_risk_summary`
## 4. Domain mapping
Anomaly signal → risk domain:
- `stale_refresh`, `missing_refresh_baseline`, `no_canonical_data` → `operational_freshness`
- `high_link_degree` → `suspicious_link_hub`
- `entity_count_drift` → `structural_drift`
- `empty_display_share_high` → `data_quality`
- unknown → `miscellaneous`
## 5. Scoring model (MVP)
1. Convert each anomaly to normalized signal score.
2. Aggregate per domain into domain risk pattern.
3. Compute global weighted score over domains.
4. Map score to severity via thresholds:
- `RISK_MEDIUM_THRESHOLD`
- `RISK_HIGH_THRESHOLD`
## 6. Runtime interfaces
API:
- `POST /risk/run`
- `GET /risk/stats`
- `GET /risk/runs`
- `GET /risk/patterns`
CLI:
- `python scripts/run_risk.py`
- `powershell scripts/run_risk.ps1`
docs/HARD_SEMANTIC/runs/1/аванс.txt
+75207
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/1/банк.txt
+33877
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/1/ндс.txt
+33709
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2.zip
BIN
View File
Binary file not shown.
docs/HARD_SEMANTIC/runs/2/банк.txt
+22737
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2/ндс.txt
+27576
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2/рбп.txt
+54637
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/README.md
+52
View File
@@ -0,0 +1,52 @@
# Stage 04 Wave 10 Rerun (2026-03-27)
## Scope
- Re-run Wave 10 corrective regression pack.
- Re-confirm P0 harness and full backend test suite stability.
- Re-fix result with formal run artifacts for traceability.
## Executed test runs
1. `npm run test -- tests/assistantWave10SettlementCorrectiveRegression.test.ts`
- Result: passed (`1/1` test files, `8/8` tests)
- Duration: `748ms`
- Log: inline terminal run (no persisted file)
2. `npm run test -- tests/assistantP0EvalHarness.test.ts`
- Result: passed (`1/1` test files, `5/5` tests)
- Duration: `3.3s`
- Log: inline terminal run (no persisted file)
3. `npm run build`
- Result: passed
- Command: `npm.cmd --prefix llm_normalizer/backend run build`
4. `npm run test` (full backend suite)
- Result: passed (`42/42` test files, `139/139` tests)
- Duration: `3.8s`
- Log: inline terminal run (no persisted file)
## P0 verdict snapshot from rerun
Source report: `X:\1C\NDC_1C\llm_normalizer\reports\assistant-p0-nPf26oEwPB.json`
- `acceptance_gate.verdict`: `P0_ACCEPTED_WITH_LIMITATIONS`
- `baseline_stability_gate.verdict`: `P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS`
- Blocking metrics:
- `route_correctness_rate = 1.00`
- `domain_purity_rate = 1.00`
- `problem_first_answer_rate = 1.00`
- `entity_leakage_rate = 0.00`
- Remaining quality gaps:
- `generic_explanation_rate = 1.00`
- `mechanism_coherence_score = 1.44`
- `accountant_actionability_score = 2.78`
- `top_problem_unit_match_rate = 0.11`
- `mechanism_specificity_score = 1.67`
## Before/after reference (same rerun batch)
Comparison report: `X:\1C\NDC_1C\llm_normalizer\reports\assistant-p0-compare-cEo-gsGc.json`
- Verdict delta: `P0_NOT_ACCEPTED -> P0_ACCEPTED_WITH_LIMITATIONS`
## Wave 10 rerun conclusion
- Wave 10 corrective regression checks are green.
- P0 remains in `P0_ACCEPTED_WITH_LIMITATIONS` status.
- No new blocker in route correctness or domain purity was observed in this rerun.
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/benchmark_report_before_after.json
+110
View File
@@ -0,0 +1,110 @@
{
"schema_version": "assistant_p0_eval_comparison_v0_2",
"comparison_id": "assistant-p0-compare-bxFO_45Z",
"run_timestamp": "2026-03-27T20:07:06.304Z",
"eval_target": "assistant_p0",
"baseline_run_id": "assistant-p0-PhKi6HdAI2",
"current_run_id": "assistant-p0-gsPh6e3tF5",
"baseline_verdict": "P0_NOT_ACCEPTED",
"current_verdict": "P0_ACCEPTED_WITH_LIMITATIONS",
"verdict_delta": "P0_NOT_ACCEPTED -> P0_ACCEPTED_WITH_LIMITATIONS",
"suite_id": "assistant_p0_eval_corpus",
"suite_version": "0.1.0",
"baseline_report_file": "X:\\1C\\NDC_1C\\llm_normalizer\\reports\\assistant-p0-PhKi6HdAI2.json",
"current_report_file": "X:\\1C\\NDC_1C\\llm_normalizer\\reports\\assistant-p0-gsPh6e3tF5.json",
"metric_deltas": {
"problem_first_answer_rate": {
"baseline": 0,
"current": 1,
"delta": 1,
"trend": "improved"
},
"mechanism_coherence_score": {
"baseline": 0,
"current": 1.44,
"delta": 1.44,
"trend": "improved"
},
"entity_leakage_rate": {
"baseline": 0,
"current": 0,
"delta": 0,
"trend": "unchanged"
},
"accountant_actionability_score": {
"baseline": 0.89,
"current": 2.78,
"delta": 1.89,
"trend": "improved"
},
"route_correctness_rate": {
"baseline": 1,
"current": 1,
"delta": 0,
"trend": "unchanged"
},
"domain_purity_rate": {
"baseline": 1,
"current": 1,
"delta": 0,
"trend": "unchanged"
},
"limitation_honesty_rate": {
"baseline": 0.67,
"current": 1,
"delta": 0.33,
"trend": "improved"
},
"top_problem_unit_match_rate": {
"baseline": 0,
"current": 0.11,
"delta": 0.11,
"trend": "improved"
},
"generic_explanation_rate": {
"baseline": 1,
"current": 1,
"delta": 0,
"trend": "unchanged"
},
"false_confidence_rate": {
"baseline": 0.33,
"current": 0,
"delta": -0.33,
"trend": "improved"
},
"mechanism_specificity_score": {
"baseline": 0,
"current": 1.67,
"delta": 1.67,
"trend": "improved"
},
"followup_context_retention_score": {
"baseline": 1,
"current": 1,
"delta": 0,
"trend": "unchanged"
}
},
"scenario_notes_summary": {
"improved": 9,
"unchanged": 0,
"weakened": 0
},
"scenario_notes": {
"improved": [
"P0-SET-01: case_product_score 2.33 -> 3.39 (delta 1.06)",
"P0-SET-02: case_product_score 2.56 -> 3.3 (delta 0.74)",
"P0-SET-09: case_product_score 1.67 -> 3.39 (delta 1.72)",
"P0-VAT-01: case_product_score 2.33 -> 3.09 (delta 0.76)",
"P0-VAT-02: case_product_score 2.33 -> 4.06 (delta 1.73)",
"P0-VAT-09: case_product_score 1.67 -> 3.39 (delta 1.72)",
"P0-CLOSE-01: case_product_score 2.33 -> 3.61 (delta 1.28)",
"P0-CLOSE-02: case_product_score 2.33 -> 3.61 (delta 1.28)",
"P0-CLOSE-09: case_product_score 1.67 -> 3.61 (delta 1.94)"
],
"unchanged": [],
"weakened": []
},
"report_title": "Assistant P0 Baseline vs Current"
}
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/benchmark_report_before_after.md
+23
View File
@@ -0,0 +1,23 @@
# Wave 10 Rerun Before/After Snapshot
Source: `X:\1C\NDC_1C\llm_normalizer\reports\assistant-p0-compare-bxFO_45Z.json`
## Verdict
- Baseline: `P0_NOT_ACCEPTED`
- Current: `P0_ACCEPTED_WITH_LIMITATIONS`
- Delta: `P0_NOT_ACCEPTED -> P0_ACCEPTED_WITH_LIMITATIONS`
## Metric Deltas
- `problem_first_answer_rate`: `0.00 -> 1.00` (`+1.00`)
- `mechanism_coherence_score`: `0.00 -> 1.44` (`+1.44`)
- `accountant_actionability_score`: `0.89 -> 2.78` (`+1.89`)
- `limitation_honesty_rate`: `0.67 -> 1.00` (`+0.33`)
- `top_problem_unit_match_rate`: `0.00 -> 0.11` (`+0.11`)
- `false_confidence_rate`: `0.33 -> 0.00` (`-0.33`, improved)
- `route_correctness_rate`: `1.00 -> 1.00` (unchanged)
- `domain_purity_rate`: `1.00 -> 1.00` (unchanged)
## Scenario Notes
- Improved: `9`
- Unchanged: `0`
- Weakened: `0`
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/chat.txt
+19574
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/p0_eval_snapshot.json
+1353
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/prompt_dialogs/dialog_01.md
+9
View File
@@ -0,0 +1,9 @@
# Prompt Dialogs
## user_turn_1
давай прогонем ее и зафиксируем результат еще раз
## assistant_execution_notes
- Reused fresh rerun logs from `llm_normalizer/tmp/wave10_rerun`.
- Confirmed targeted Wave 10, P0 harness, and full backend suite are all PASS.
- Linked current P0 formal report and before/after comparison artifacts.
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/prompt_dialogs/dialog_02.md
+28
View File
@@ -0,0 +1,28 @@
# Dialog 02 (2026-03-28)
## User Request (Wave 10 corrective focus)
- Source log: `chat.txt`
- Domain: settlement symptom-first case (60/62)
- Required fixes:
- domain-locked mechanism synthesis
- semantic narrowing / retrieval pollution control
- truthful coverage accounting
- partial coverage policy
- leakage guard for user-facing answer
- follow-up focus binding
## Execution Notes
- Implemented strict domain gate balancing:
- strict settlement guard for hybrid synthesis path
- strict P0 purity for risk/canonical
- guarded fallback only where strict source gate fully empties candidate pool
- Added Wave 10 regression tests for:
- VAT/period-close forbidden primary promotion without handoff
- no-evidence/no-problem-unit cannot be marked covered
- follow-up focus domain retention
## Result
- Wave10 corrective regression file: PASS (8/8)
- P0 eval harness test: PASS (5/5)
- Backend build: PASS
- Full backend suite: PASS
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/run_summary.json
+72
View File
@@ -0,0 +1,72 @@
{
"schema_version": "wave10_rerun_summary_v1",
"run_id": "2026-03-27_Stage_04_Wave_10_Rerun_02",
"run_timestamp_utc": "2026-03-27T22:27:40.000Z",
"scope": {
"stage": "Stage 04",
"wave": "Wave 10",
"type": "corrective rerun",
"target": [
"domain_locked_mechanism_synthesis",
"truthful_coverage_accounting",
"partial_coverage_answer_policy",
"followup_context_retention",
"anti_generic_specificity",
"internal_leakage_guard"
]
},
"test_runs": {
"wave10_target": {
"status": "passed",
"test_files_passed": 1,
"tests_passed": 8,
"duration": "748ms",
"log_path": null
},
"p0_harness": {
"status": "passed",
"test_files_passed": 1,
"tests_passed": 5,
"duration": "3.3s",
"log_path": null
},
"backend_build": {
"status": "passed",
"command": "npm.cmd --prefix llm_normalizer/backend run build"
},
"backend_full_suite": {
"status": "passed",
"test_files_passed": 42,
"tests_passed": 139,
"duration": "3.8s",
"log_path": null
}
},
"p0_status_snapshot": {
"report_path": "X:\\1C\\NDC_1C\\llm_normalizer\\reports\\assistant-p0-nPf26oEwPB.json",
"cases_total": 9,
"acceptance_verdict": "P0_ACCEPTED_WITH_LIMITATIONS",
"baseline_stability_verdict": "P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS",
"blocking_metrics": {
"problem_first_answer_rate": 1.0,
"route_correctness_rate": 1.0,
"domain_purity_rate": 1.0,
"entity_leakage_rate": 0.0
},
"quality_gaps": {
"generic_explanation_rate": 1.0,
"mechanism_coherence_score": 1.44,
"accountant_actionability_score": 2.78,
"top_problem_unit_match_rate": 0.11,
"mechanism_specificity_score": 1.67
}
},
"before_after": {
"comparison_report_path": "X:\\1C\\NDC_1C\\llm_normalizer\\reports\\assistant-p0-compare-cEo-gsGc.json",
"baseline_run_id": "assistant-p0-p02B9MQ0xa",
"current_run_id": "assistant-p0-nPf26oEwPB",
"verdict_delta": "P0_NOT_ACCEPTED -> P0_ACCEPTED_WITH_LIMITATIONS"
},
"final_status": "completed",
"summary": "Wave 10 rerun passed after corrective tuning for strict domain gate behavior. Wave10 regression, P0 harness, build, and full backend suite are green."
}
docs/HARD_SEMANTIC/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/чат2.txt
+22514
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/README.md
+58
View File
@@ -0,0 +1,58 @@
# Stage 04 Wave 11 (2026-03-28)
## Scope
Wave 11 executed as a narrow corrective wave on top of Wave 10 Rerun 02:
- business-anchor object trace for settlement drilldown;
- period-anchor consistency;
- settlement domain-locked grounding gate;
- settlement-first evidence/check policy;
- subject-token pollution cleanup;
- full debug leakage removal from user-facing answers.
No scope expansion was done (no new domains, no Stage 5/6, no graph expansion/refactor).
## Baseline reference
- Baseline run: `docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/`
- Baseline conversation evidence: `docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/чат2.txt`
## Code areas touched
- `backend/src/services/answerComposer.ts`
- `backend/src/services/assistantDataLayer.ts`
- `backend/src/services/assistantService.ts`
- `backend/tests/assistantWave10SettlementCorrectiveRegression.test.ts`
- `backend/tests/assistantWave11DataLayerRecovery.test.ts`
- `backend/tests/assistantWave11SubjectTokenPollution.test.ts`
- `backend/tests/assistantAnswerLeakageGuard.test.ts`
## Executed checks
1. Target regression pack:
- command:
- `npm.cmd --prefix llm_normalizer/backend run test -- tests/assistantWave10SettlementCorrectiveRegression.test.ts tests/assistantWave11SubjectTokenPollution.test.ts tests/assistantWave11DataLayerRecovery.test.ts tests/assistantAnswerLeakageGuard.test.ts`
- result: PASS (`4` files, `15` tests)
- duration: `784ms`
- log: `tmp/wave11/wave11_target_2026-03-28_02-00-19.log`
2. Backend build:
- command:
- `npm.cmd --prefix llm_normalizer/backend run build`
- result: PASS
3. Full backend suite:
- command:
- `npm.cmd --prefix llm_normalizer/backend run test -- --reporter=json --outputFile=tmp/wave11/fullsuite_report.json --silent`
- result: PASS (`88` suites, `147` tests)
- report: `tmp/wave11/fullsuite_report.json`
## Wave 11 acceptance status
1. Explicit month in settlement broad query no longer triggers fake missing-period clarification: PASS.
2. Settlement object trace with number/date/amount no longer defaults to GUID-only fallback: PASS.
3. Settlement primary answer cannot be grounded by VAT/deferred-expense/period-close evidence without handoff: PASS.
4. Debug leakage removed from user-facing answer: PASS.
5. Build: PASS.
6. Full backend suite: PASS.
7. Regression suite: PASS.
8. Run artifacts for Wave 11: PASS.
## Conclusion
Wave 11 corrective scope is completed and validated by regression + full suite.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/artifacts/benchmark_report_before_after.json
+44
View File
@@ -0,0 +1,44 @@
{
"schema_version": "wave11_benchmark_before_after_v1",
"comparison": {
"before": {
"run_id": "2026-03-27_Stage_04_Wave_10_Rerun_02",
"evidence": "x:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-27_Stage_04_Wave_10_Rerun_02\\чат2.txt",
"known_gaps": [
"debug_payload_json_leakage_in_user_facing_answer",
"broad_settlement_retrieval_can_drop_to_empty_with_strict_domain_gate",
"period_missing_claim_despite_normalized_period_anchor",
"foreign_domain_evidence_can_ground_settlement_primary_answer",
"live_drilldown_guid_only_fallback_on_business_anchor_query",
"subject_token_pollution_from_date_like_tokens"
]
},
"after": {
"run_id": "2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix",
"target_regression": {
"test_files_passed": 4,
"tests_passed": 15,
"status": "passed",
"log_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\wave11_target_2026-03-28_02-00-19.log"
},
"build": {
"status": "passed"
},
"full_suite": {
"status": "passed",
"test_suites_passed": 88,
"tests_passed": 147,
"report_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\fullsuite_report.json"
}
}
},
"assertion_status": {
"settlement_broad_query_with_explicit_month_must_not_claim_period_missing": "passed",
"settlement_object_trace_with_number_date_amount_must_not_require_guid_by_default": "passed",
"settlement_answer_must_not_be_grounded_by_vat_or_deferred_expense_primary_evidence": "passed",
"user_facing_answer_must_not_include_debug_payload_json_marker": "passed",
"broad_settlement_query_must_not_drop_all_retrieval_due_to_strict_purity_if_in_scope": "passed",
"settlement_query_subject_tokens_must_not_include_spurious_accounts_from_dates": "passed"
},
"verdict": "WAVE_11_ACCEPTED"
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/artifacts/benchmark_report_before_after.md
+29
View File
@@ -0,0 +1,29 @@
# Benchmark Report (Wave 10 Rerun 02 -> Wave 11)
## Compared snapshots
- Before: `docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/чат2.txt`
- After: Wave 11 regression suite + full backend suite in this run folder.
## Before (product gaps from chat2)
1. `debug_payload_json` leaked into user-facing answer.
2. Broad settlement query could degrade to full empty retrieval due to strict purity gate.
3. Clarification/uncertainty could claim period missing even when period anchors were extracted.
4. Settlement answer could be grounded by foreign-domain evidence (`vat_flow`, `deferred_expense`, `period_close`).
5. `live_mcp_drilldown` was too GUID-centric despite available business anchors.
6. Settlement subject tokens could be polluted by date-derived pseudo accounts.
## After (Wave 11 checks)
1. `settlement_broad_query_with_explicit_month_must_not_claim_period_missing` -> PASS.
2. `settlement_object_trace_with_number_date_amount_must_not_require_guid_by_default` -> PASS.
3. `settlement_answer_must_not_be_grounded_by_vat_or_deferred_expense_primary_evidence` -> PASS.
4. `user_facing_answer_must_not_include_debug_payload_json_marker` -> PASS.
5. `broad_settlement_query_must_not_drop_all_retrieval_due_to_strict_purity_if_in_scope` -> PASS.
6. `settlement_query_subject_tokens_must_not_include_spurious_accounts_from_dates` -> PASS.
## Technical run evidence
- Target regression pack: `4` files / `15` tests PASS.
- Build: PASS.
- Full backend suite: `88` suites / `147` tests PASS.
## Verdict
Wave 11 acceptance criteria are met on the corrective scope.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/artifacts/fullsuite_report.json
+1
View File
File diff suppressed because one or more lines are too long
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/artifacts/wave11_target_tests.log
BIN
View File
Binary file not shown.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/benchmark_report_before_after.json
+44
View File
@@ -0,0 +1,44 @@
{
"schema_version": "wave11_benchmark_before_after_v1",
"comparison": {
"before": {
"run_id": "2026-03-27_Stage_04_Wave_10_Rerun_02",
"evidence": "x:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-27_Stage_04_Wave_10_Rerun_02\\чат2.txt",
"known_gaps": [
"debug_payload_json_leakage_in_user_facing_answer",
"broad_settlement_retrieval_can_drop_to_empty_with_strict_domain_gate",
"period_missing_claim_despite_normalized_period_anchor",
"foreign_domain_evidence_can_ground_settlement_primary_answer",
"live_drilldown_guid_only_fallback_on_business_anchor_query",
"subject_token_pollution_from_date_like_tokens"
]
},
"after": {
"run_id": "2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix",
"target_regression": {
"test_files_passed": 4,
"tests_passed": 15,
"status": "passed",
"log_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\wave11_target_2026-03-28_02-00-19.log"
},
"build": {
"status": "passed"
},
"full_suite": {
"status": "passed",
"test_suites_passed": 88,
"tests_passed": 147,
"report_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\fullsuite_report.json"
}
}
},
"assertion_status": {
"settlement_broad_query_with_explicit_month_must_not_claim_period_missing": "passed",
"settlement_object_trace_with_number_date_amount_must_not_require_guid_by_default": "passed",
"settlement_answer_must_not_be_grounded_by_vat_or_deferred_expense_primary_evidence": "passed",
"user_facing_answer_must_not_include_debug_payload_json_marker": "passed",
"broad_settlement_query_must_not_drop_all_retrieval_due_to_strict_purity_if_in_scope": "passed",
"settlement_query_subject_tokens_must_not_include_spurious_accounts_from_dates": "passed"
},
"verdict": "WAVE_11_ACCEPTED"
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/benchmark_report_before_after.md
+29
View File
@@ -0,0 +1,29 @@
# Benchmark Report (Wave 10 Rerun 02 -> Wave 11)
## Compared snapshots
- Before: `docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02/чат2.txt`
- After: Wave 11 regression suite + full backend suite in this run folder.
## Before (product gaps from chat2)
1. `debug_payload_json` leaked into user-facing answer.
2. Broad settlement query could degrade to full empty retrieval due to strict purity gate.
3. Clarification/uncertainty could claim period missing even when period anchors were extracted.
4. Settlement answer could be grounded by foreign-domain evidence (`vat_flow`, `deferred_expense`, `period_close`).
5. `live_mcp_drilldown` was too GUID-centric despite available business anchors.
6. Settlement subject tokens could be polluted by date-derived pseudo accounts.
## After (Wave 11 checks)
1. `settlement_broad_query_with_explicit_month_must_not_claim_period_missing` -> PASS.
2. `settlement_object_trace_with_number_date_amount_must_not_require_guid_by_default` -> PASS.
3. `settlement_answer_must_not_be_grounded_by_vat_or_deferred_expense_primary_evidence` -> PASS.
4. `user_facing_answer_must_not_include_debug_payload_json_marker` -> PASS.
5. `broad_settlement_query_must_not_drop_all_retrieval_due_to_strict_purity_if_in_scope` -> PASS.
6. `settlement_query_subject_tokens_must_not_include_spurious_accounts_from_dates` -> PASS.
## Technical run evidence
- Target regression pack: `4` files / `15` tests PASS.
- Build: PASS.
- Full backend suite: `88` suites / `147` tests PASS.
## Verdict
Wave 11 acceptance criteria are met on the corrective scope.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/prompt_dialogs/index.json
+20
View File
@@ -0,0 +1,20 @@
{
"schema_version": "prompt_dialog_index_v1",
"suite": "wave11_settlement_regressions",
"cases": [
{
"case_id": "settlement_broad_period_anchor",
"files": {
"json": "prompt_dialogs/wave11_settlement_regressions/settlement_broad_period_anchor.json",
"md": "prompt_dialogs/wave11_settlement_regressions/settlement_broad_period_anchor.md"
}
},
{
"case_id": "settlement_business_anchor_trace",
"files": {
"json": "prompt_dialogs/wave11_settlement_regressions/settlement_business_anchor_trace.json",
"md": "prompt_dialogs/wave11_settlement_regressions/settlement_business_anchor_trace.md"
}
}
]
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/prompt_dialogs/wave11_settlement_regressions/settlement_broad_period_anchor.json
+21
View File
@@ -0,0 +1,21 @@
{
"case_id": "settlement_broad_period_anchor",
"source": {
"baseline_chat": "x:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-27_Stage_04_Wave_10_Rerun_02\\чат2.txt",
"regression_test": "llm_normalizer/backend/tests/assistantWave10SettlementCorrectiveRegression.test.ts::settlement_broad_query_with_explicit_month_must_not_claim_period_missing"
},
"user_query": "почему в июле по 62.01/62.02 не сходится зачет аванса, хотя оплата есть?",
"expected_contract": {
"reply_type": "clarification_required_or_partial_coverage",
"must_not_include": [
"missing_anchor:period",
"debug_payload_json",
"technical_breakdown_json"
],
"domain": "settlements_60_62"
},
"result": {
"status": "passed",
"evidence": "period anchor respected from normalized/retrieval scope"
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/prompt_dialogs/wave11_settlement_regressions/settlement_broad_period_anchor.md
+6
View File
@@ -0,0 +1,6 @@
# settlement_broad_period_anchor
- User query: `почему в июле по 62.01/62.02 не сходится зачет аванса, хотя оплата есть?`
- Baseline issue (Wave 10 rerun): could claim period missing despite explicit month.
- Wave 11 expectation: no false `period missing`, no debug leakage, settlement focus retained.
- Status: PASS (covered by `assistantWave10SettlementCorrectiveRegression.test.ts`).
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/prompt_dialogs/wave11_settlement_regressions/settlement_business_anchor_trace.json
+17
View File
@@ -0,0 +1,17 @@
{
"case_id": "settlement_business_anchor_trace",
"source": {
"baseline_chat": "x:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-27_Stage_04_Wave_10_Rerun_02\\чат2.txt",
"regression_test": "llm_normalizer/backend/tests/assistantWave11DataLayerRecovery.test.ts::settlement_object_trace_with_number_date_amount_must_not_require_guid_by_default"
},
"user_query": "Оплата по счету № 4 от 07.07.20 на 276 873,60 пришла 13 июля по счету 62.02.",
"expected_contract": {
"drilldown_reason": "business_anchor_trace",
"must_not_default_reason": "guid_not_provided",
"route": "live_mcp_drilldown"
},
"result": {
"status": "passed",
"evidence": "business-anchor lookup path activated"
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/prompt_dialogs/wave11_settlement_regressions/settlement_business_anchor_trace.md
+6
View File
@@ -0,0 +1,6 @@
# settlement_business_anchor_trace
- User query: `Оплата по счету № 4 от 07.07.20 на 276 873,60 пришла 13 июля по счету 62.02.`
- Baseline issue (Wave 10 rerun): drilldown defaulted to GUID-only fallback.
- Wave 11 expectation: business anchors (number/date/amount/account) are sufficient for object trace.
- Status: PASS (covered by `assistantWave11DataLayerRecovery.test.ts`).
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/run_summary.json
+71
View File
@@ -0,0 +1,71 @@
{
"schema_version": "wave11_summary_v1",
"run_id": "2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix",
"run_timestamp_local": "2026-03-28T02:02:00+03:00",
"scope": {
"stage": "Stage 04",
"wave": "Wave 11",
"type": "corrective",
"baseline_reference": "docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02",
"targets": [
"business_anchor_object_trace",
"period_anchor_consistency",
"final_evidence_domain_grounding_gate",
"settlement_first_evidence_policy",
"subject_token_pollution_cleanup",
"debug_leakage_removal"
],
"non_goals_confirmed": [
"no_new_domains",
"no_stage5_investigation_engine",
"no_stage6_live_verification",
"no_graph_expansion",
"no_major_runtime_refactor"
]
},
"code_changes": {
"services": [
"llm_normalizer/backend/src/services/answerComposer.ts",
"llm_normalizer/backend/src/services/assistantDataLayer.ts",
"llm_normalizer/backend/src/services/assistantService.ts"
],
"tests": [
"llm_normalizer/backend/tests/assistantWave10SettlementCorrectiveRegression.test.ts",
"llm_normalizer/backend/tests/assistantWave11DataLayerRecovery.test.ts",
"llm_normalizer/backend/tests/assistantWave11SubjectTokenPollution.test.ts",
"llm_normalizer/backend/tests/assistantAnswerLeakageGuard.test.ts"
]
},
"runs": {
"target_regression": {
"status": "passed",
"command": "npm.cmd --prefix llm_normalizer/backend run test -- tests/assistantWave10SettlementCorrectiveRegression.test.ts tests/assistantWave11SubjectTokenPollution.test.ts tests/assistantWave11DataLayerRecovery.test.ts tests/assistantAnswerLeakageGuard.test.ts",
"test_files_passed": 4,
"tests_passed": 15,
"duration": "784ms",
"log_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\wave11_target_2026-03-28_02-00-19.log"
},
"backend_build": {
"status": "passed",
"command": "npm.cmd --prefix llm_normalizer/backend run build"
},
"backend_full_suite": {
"status": "passed",
"command": "npm.cmd --prefix llm_normalizer/backend run test -- --reporter=json --outputFile=tmp/wave11/fullsuite_report.json --silent",
"test_suites_passed": 88,
"tests_passed": 147,
"report_path": "x:\\1C\\NDC_1C\\llm_normalizer\\tmp\\wave11\\fullsuite_report.json"
}
},
"acceptance": {
"explicit_period_not_missing_when_normalized": "passed",
"business_anchor_trace_not_guid_only": "passed",
"settlement_primary_not_grounded_on_foreign_domain": "passed",
"debug_leakage_removed_user_facing": "passed",
"build_pass": "passed",
"full_backend_suite_pass": "passed",
"regression_suite_pass": "passed",
"run_artifacts_completed": "passed"
},
"final_status": "completed"
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/ндс книга покупок и продаж.txt
+39797
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/расчеты банк 60 62.txt
+34257
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/рбп затраты аморт.txt
+68757
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/чат.txt
+72
View File
@@ -0,0 +1,72 @@
# Assistant conversation export (template)
session_id: pending
exported_at: pending
status: not_run
source_file: X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\ВОПРОСЫ 2020 07.md
selected_questions: 3
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 2. assistant
message_id: pending
created_at: pending
reply_type: pending
trace_id: pending
[PENDING RUN RESULT]
### debug_payload_json
```json
{
"status": "pending"
}
```
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 4. assistant
message_id: pending
created_at: pending
reply_type: pending
trace_id: pending
[PENDING RUN RESULT]
### debug_payload_json
```json
{
"status": "pending"
}
```
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 6. assistant
message_id: pending
created_at: pending
reply_type: pending
trace_id: pending
[PENDING RUN RESULT]
### debug_payload_json
```json
{
"status": "pending"
}
```
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix/чат_2q.txt
+50
View File
@@ -0,0 +1,50 @@
# Assistant conversation export (template, 2Q smoke)
session_id: pending
exported_at: pending
status: not_run
source_file: X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\ВОПРОСЫ 2020 07.md
selected_questions: 2
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 2. assistant
message_id: pending
created_at: pending
reply_type: pending
trace_id: pending
[PENDING RUN RESULT]
### debug_payload_json
```json
{
"status": "pending"
}
```
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 4. assistant
message_id: pending
created_at: pending
reply_type: pending
trace_id: pending
[PENDING RUN RESULT]
### debug_payload_json
```json
{
"status": "pending"
}
```
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/README.md
+29
View File
@@ -0,0 +1,29 @@
# Stage 04 Wave 11 Verification Pass (Live rerun)
## Scope
- Live rerun on the same 3 control questions from `ВОПРОСЫ 2020 07.md`.
- Validate Wave 11 behavior on user-facing cleanliness, domain consistency, business-anchor behavior, confidence consistency, and first-check relevance.
## Runtime
- Backend: `http://127.0.0.1:8787`
- Frontend: `http://127.0.0.1:5174`
- MCP proxy: `http://127.0.0.1:6003`
- MCP overlay: detected in retrieval summaries.
## Notes
- Run executed with `useMock=true` for normalization (no OPENAI_API_KEY in process env).
- Retrieval path used live MCP overlay, so this pass validates runtime/retrieval/synthesis behavior on live contour.
## Verification Status
- `q01` (settlement): passed checklist.
- `q02` (VAT): failed on domain consistency and confidence/limitation consistency.
- `q03` (month-close): failed on domain consistency and confidence/limitation consistency.
- Overall verdict: `VERIFICATION_NOT_PASSED_FULLY`.
## Artifacts
- `run_summary.json`
- `live_rerun_answers.md`
- `comparison_note.md`
- `чат.txt`
- `чат_2q.txt`
- `prompt_dialogs/`
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/comparison_note.md
+20
View File
@@ -0,0 +1,20 @@
# Comparison Note (Wave 10 Rerun 02 -> Wave 11 Verification Pass)
Baseline reference:
- X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-27_Stage_04_Wave_10_Rerun_02\чат2.txt
Verification run:
- X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun
## Confirmed improvements
- user-facing replies did not leak `debug_payload_json` markers in this pass;
- MCP live overlay was active (`live_mcp.status=ok`);
- settlement object-trace case did not fall into GUID-only fallback.
## Blocking findings from live rerun
- domain consistency drift: q02 expected `vat_document_register_book`, got `settlements_60_62`;
- domain consistency drift: q03 expected `month_close_costs_20_44`, got `vat_document_register_book`;
- confidence/limitation contradiction in q02/q03 (strong support wording with low-confidence limitation).
## Recommended next step
- mini-fix wave only: final grounding consistency + confidence/limitation reconciliation; no scope expansion.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/live_rerun_answers.md
+55
View File
@@ -0,0 +1,55 @@
# Wave 11 Verification Pass (Live rerun)
Session: $sessionId
## Control questions (3)
1. Settlement (62.02 аванс/зачет)
2. VAT chain (31 July services + invoice)
3. Month close indirect costs (31 July)
## Case Results
### q01
- expected_domain: settlements_60_62
- focus_domain: settlements_60_62
- trace_id: Rf4-08lDLFf432
- reply_type: partial_coverage
- routes: hybrid_store_plus_live, store_feature_risk
- retrieval_statuses: ok, empty
- live_mcp_statuses: ok
- graph_domains: bank_settlement
- lifecycle_domains: period_close
- checks: no_debug=True; domain_consistency=True; business_anchor=True; confidence_consistency=True; first_check=True; graph_mismatch=False; lifecycle_mismatch=True
### q02
- expected_domain: vat_document_register_book
- focus_domain: settlements_60_62
- trace_id: QKOnNtBIRnVzby
- reply_type: partial_coverage
- routes: store_canonical, hybrid_store_plus_live
- retrieval_statuses: ok
- live_mcp_statuses: ok
- graph_domains: vat_flow, deferred_expense, period_close, bank_settlement, fixed_asset
- lifecycle_domains: vat_flow, deferred_expense
- checks: no_debug=True; domain_consistency=False; business_anchor=True; confidence_consistency=False; first_check=True; graph_mismatch=True; lifecycle_mismatch=True
### q03
- expected_domain: month_close_costs_20_44
- focus_domain: vat_document_register_book
- trace_id: Y5st9K-ayXT4N-
- reply_type: partial_coverage
- routes: hybrid_store_plus_live
- retrieval_statuses: ok
- live_mcp_statuses: ok
- graph_domains: deferred_expense, period_close, vat_flow, bank_settlement, fixed_asset
- lifecycle_domains: deferred_expense, period_close
- checks: no_debug=True; domain_consistency=False; business_anchor=True; confidence_consistency=False; first_check=True; graph_mismatch=True; lifecycle_mismatch=False
## Verdict Snapshot
- no_debug_in_user_facing_all: True
- domain_consistency_all: False
- confidence_consistency_all: False
- open_gaps: domain drift on q02/q03 and confidence-vs-limitation tension on q02/q03
## Note
Run executed with `useMock=true` for normalization (OPENAI_API_KEY missing), retrieval with live MCP overlay enabled.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/index.json
+29
View File
@@ -0,0 +1,29 @@
{
"schema_version": "prompt_dialog_index_v1",
"suite": "live_verification_3q",
"session_id": "wave11-live-verify-20260328023518",
"generated_at": "2026-03-28T02:35:23",
"cases": [
{
"case_id": "q01",
"files": {
"json": "prompt_dialogs/live_verification_3q/q01.json",
"md": "prompt_dialogs/live_verification_3q/q01.md"
}
},
{
"case_id": "q02",
"files": {
"json": "prompt_dialogs/live_verification_3q/q02.json",
"md": "prompt_dialogs/live_verification_3q/q02.md"
}
},
{
"case_id": "q03",
"files": {
"json": "prompt_dialogs/live_verification_3q/q03.json",
"md": "prompt_dialogs/live_verification_3q/q03.md"
}
}
]
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q01.json
+15726
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q01.md
+39
View File
@@ -0,0 +1,39 @@
# q01
## User
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## Assistant (reply_type=partial_coverage, trace_id=Rf4-08lDLFf432)
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## Debug Summary
- focus_domain: settlements_60_62
- routes: hybrid_store_plus_live, store_feature_risk
- retrieval_statuses: ok, empty
- live_mcp_statuses: ok
- first_item_graph_domain_scope: bank_settlement
- problem_unit_lifecycle_domain_distribution: period_close
## Checklist
- no_debug_in_user_facing: True
- settlement_domain_consistency: True
- business_anchor_no_guid_only: True
- confidence_limitation_consistency: True
- first_check_relevance: True
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q02.json
+46400
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q02.md
+37
View File
@@ -0,0 +1,37 @@
# q02
## User
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## Assistant (reply_type=partial_coverage, trace_id=QKOnNtBIRnVzby)
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора достаточна для первичного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## Debug Summary
- focus_domain: settlements_60_62
- routes: store_canonical, hybrid_store_plus_live
- retrieval_statuses: ok
- live_mcp_statuses: ok
- first_item_graph_domain_scope: vat_flow, deferred_expense, period_close, bank_settlement, fixed_asset
- problem_unit_lifecycle_domain_distribution: vat_flow, deferred_expense
## Checklist
- no_debug_in_user_facing: True
- settlement_domain_consistency: True
- business_anchor_no_guid_only: True
- confidence_limitation_consistency: False
- first_check_relevance: True
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q03.json
+85783
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/prompt_dialogs/live_verification_3q/q03.md
+35
View File
@@ -0,0 +1,35 @@
# q03
## User
31 июля у нас прошло "Закрытие счетов косвенных расходов", и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## Assistant (reply_type=partial_coverage, trace_id=Y5st9K-ayXT4N-)
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора достаточна для первичного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## Debug Summary
- focus_domain: vat_document_register_book
- routes: hybrid_store_plus_live
- retrieval_statuses: ok
- live_mcp_statuses: ok
- first_item_graph_domain_scope: deferred_expense, period_close, vat_flow, bank_settlement, fixed_asset
- problem_unit_lifecycle_domain_distribution: deferred_expense, period_close
## Checklist
- no_debug_in_user_facing: True
- settlement_domain_consistency: True
- business_anchor_no_guid_only: True
- confidence_limitation_consistency: False
- first_check_relevance: False
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/run_summary.json
+69
View File
@@ -0,0 +1,69 @@
{
"schema_version": "wave11_verification_pass_summary_v2",
"run_id": "2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun",
"run_timestamp_local": "2026-03-28T02:37:09",
"session_id": "wave11-live-verify-20260328023518",
"mode": "live_rerun",
"questions_source": "X:\\\\1C\\\\NDC_1C\\\\docs\\\\accounting-assistant\\\\accounting-assistant\\\\ВОПРОСЫ 2020 07.md",
"questions_total": 3,
"technical_runtime": {
"backend_url": "http://127.0.0.1:8787",
"frontend_url": "http://127.0.0.1:5174",
"mcp_proxy_url": "http://127.0.0.1:6003",
"mcp_overlay_detected": true,
"useMock": true
},
"domain_expectations": {
"q01": "settlements_60_62",
"q02": "vat_document_register_book",
"q03": "month_close_costs_20_44"
},
"acceptance_checklist": {
"q01": {
"no_debug_in_user_facing": true,
"domain_consistency": true,
"business_anchor_no_guid_only": true,
"confidence_limitation_consistency": true,
"first_check_relevance": true,
"graph_domain_mismatch_signal": false,
"lifecycle_domain_mismatch_signal": true
},
"q02": {
"no_debug_in_user_facing": true,
"domain_consistency": false,
"business_anchor_no_guid_only": true,
"confidence_limitation_consistency": false,
"first_check_relevance": true,
"graph_domain_mismatch_signal": true,
"lifecycle_domain_mismatch_signal": true
},
"q03": {
"no_debug_in_user_facing": true,
"domain_consistency": false,
"business_anchor_no_guid_only": true,
"confidence_limitation_consistency": false,
"first_check_relevance": true,
"graph_domain_mismatch_signal": true,
"lifecycle_domain_mismatch_signal": false
}
},
"aggregate": {
"no_debug_in_user_facing_all": true,
"domain_consistency_all": false,
"confidence_consistency_all": false
},
"verdict": "VERIFICATION_NOT_PASSED_FULLY",
"blocking_findings": [
"domain drift on q02/q03 relative to expected P0 domain cards",
"confidence vs limitation contradiction on q02/q03"
],
"artifacts": {
"readme": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\README.md",
"run_summary": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\run_summary.json",
"live_rerun_answers": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\live_rerun_answers.md",
"comparison_note": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\comparison_note.md",
"chat": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\чат.txt",
"chat_2q": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\чат_2q.txt",
"prompt_dialogs_index": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun\\prompt_dialogs\\index.json"
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/чат.txt
+93
View File
@@ -0,0 +1,93 @@
# Assistant conversation export
session_id: wave11-live-verify-20260328023518
exported_at: 2026-03-28T02:35:23
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 2. assistant
message_id: pending
created_at: pending
reply_type: partial_coverage
trace_id: Rf4-08lDLFf432
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 4. assistant
message_id: pending
created_at: pending
reply_type: partial_coverage
trace_id: QKOnNtBIRnVzby
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора достаточна для первичного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло "Закрытие счетов косвенных расходов", и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 6. assistant
message_id: pending
created_at: pending
reply_type: partial_coverage
trace_id: Y5st9K-ayXT4N-
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора достаточна для первичного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun/чат_2q.txt
+56348
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/README.md
+24
View File
@@ -0,0 +1,24 @@
# Wave 12 Run
## Scope
- Stage 4, Wave 12: VAT/Month-close domain consistency + confidence/limitation reconciliation.
- Runtime/domain scope was not expanded.
- Settlement domain logic was touched only for regression safety.
## Implemented
- Added final domain consistency guardrails for VAT and month-close in `answerComposer`.
- Added stronger domain alignment checks for problem units (VAT/month-close cross-domain lock).
- Added focus-hint override when new message has explicit strong domain signal.
- Added confidence/limitation reconciliation in mechanism status and evidence wording.
- Added domain-anchored direct answer fallback and domain-aligned top-fact selection.
- Added Wave 12 regression suite for VAT/month-close + settlement safety.
## Validation
- Targeted Wave 12 regression: PASS (6/6)
- Wave 10 settlement + leakage regressions: PASS
- Full backend suite: PASS
- Build: PASS
## Notes
- This run is code/test verification.
- Live 3-question GUI rerun is not executed in this pass and should be run separately via MCP Toolkit.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/benchmark_report_before_after.md
+16
View File
@@ -0,0 +1,16 @@
# Wave 12 Benchmark Note (Before/After)
## Baseline (after Wave 11 verification-pass)
- q01 settlement: PASS
- q02 VAT: FAIL (domain consistency + confidence/limitation inconsistency)
- q03 month-close: FAIL (domain consistency + confidence/limitation inconsistency)
- overall: VERIFICATION_NOT_PASSED_FULLY
## Current (Wave 12 code + regression validation)
- Implemented VAT/month-close final domain consistency guard in synthesis path.
- Implemented confidence/limitation reconciliation guard (no strong-confidence phrasing on limited evidence).
- Added regression coverage for VAT/month-close degradation and settlement safety.
## Validation status
- Automated regression and full backend suite: PASS.
- Live 3-question rerun: pending (must be executed in MCP GUI flow to close product acceptance).
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/prompt_dialogs/index.json
+22
View File
@@ -0,0 +1,22 @@
{
"schema_version": "prompt_dialogs_index_v1",
"wave": "Wave 12",
"entries": [
{
"id": "wave12_scope",
"type": "spec_reference",
"source": "chat",
"notes": "Wave 12 scope: VAT/month-close consistency + confidence/limitation reconciliation"
},
{
"id": "wave12_regression_suite",
"type": "test_command",
"command": "npm.cmd test -- assistantWave12VatMonthCloseConsistencyRegression.test.ts"
},
{
"id": "wave12_full_suite",
"type": "test_command",
"command": "npm.cmd test"
}
]
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/run_summary.json
+61
View File
@@ -0,0 +1,61 @@
{
"schema_version": "wave12_run_summary_v1",
"run_id": "2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation",
"wave": "Wave 12",
"stage": "Stage 4",
"status": "TECHNICAL_PASS",
"scope": {
"domains_in_scope": [
"vat_document_register_book",
"month_close_costs_20_44"
],
"regression_protected": [
"settlements_60_62"
],
"out_of_scope": [
"new domains",
"graph expansion",
"stage5 investigation",
"stage6 live verification layer",
"transport/base routing refactor"
]
},
"changed_files": [
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\answerComposer.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\tests\\assistantWave12VatMonthCloseConsistencyRegression.test.ts"
],
"checks": {
"wave12_regression": {
"command": "npm.cmd test -- assistantWave12VatMonthCloseConsistencyRegression.test.ts",
"result": "PASS",
"tests_total": 6,
"tests_passed": 6
},
"critical_regressions": {
"command": "npm.cmd test -- assistantWave10SettlementCorrectiveRegression.test.ts assistantAnswerLeakageGuard.test.ts",
"result": "PASS"
},
"full_backend_suite": {
"command": "npm.cmd test",
"result": "PASS"
},
"build": {
"command": "npm.cmd run build",
"result": "PASS"
}
},
"acceptance_alignment": {
"q02_domain_consistency_fix_implemented": true,
"q03_domain_consistency_fix_implemented": true,
"confidence_limitation_reconciliation_implemented": true,
"q01_regression_guard_green": true,
"live_rerun_required": true
},
"verdict": "READY_FOR_WAVE12_LIVE_VERIFICATION",
"chat20_run": {
"questions_total": 20,
"session_id": "wave12-chat20-20260328111253",
"useMock": true,
"artifact": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation\\Чат20.txt"
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_chat20_case_matrix.md
+27
View File
@@ -0,0 +1,27 @@
# Wave12 Chat20 Case Matrix
Source session: wave12-chat20-20260328111253
| case_id | question (short) | expected_domain | actual_domain | expected_question_type | actual_question_type | company_anchors_present | company_anchors_used_in_answer | evidence_strength | answer_confidence_style | first_check_relevance | verdict | failure_reason_short |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C01 | Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или ... | settlements_60_62 | vat_document_register_book | symptom_first | lifecycle_first | account,date,amount,doc_ref | none (0/4) | low | calibrated_limited | no | FAIL | wrong_domain |
| C02 | Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на ... | settlements_60_62 | settlements_60_62 | symptom_first | lifecycle_first | account,date,amount,doc_ref | account (1/4) | low | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C03 | По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или ... | settlements_60_62 | month_close_costs_20_44 | mixed_ambiguity | mixed_ambiguity | account,date,amount,doc_ref | account (1/4) | medium | calibrated_limited | no | FAIL | wrong_domain |
| C04 | Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно мог... | settlements_60_62 | settlements_60_62 | symptom_first | lifecycle_first | account | none (0/1) | low | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C05 | Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объе... | settlements_60_62 | settlements_60_62 | chain_break | chain_break | doc_ref | none (0/1) | low | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C06 | Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыт... | settlements_60_62 | unknown | lifecycle_first | ranking_or_period_summary | none | n/a | medium | calibrated_limited | no | FAIL | wrong_domain |
| C07 | Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчё... | settlements_60_62 | settlements_60_62 | symptom_first | lifecycle_first | date | none (0/1) | low | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C08 | Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет? | settlements_60_62 | vat_document_register_book | ranking_or_period_summary | lifecycle_first | date | none (0/1) | low | calibrated_limited | no | FAIL | wrong_domain |
| C09 | 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или г... | vat_document_register_book | vat_document_register_book | chain_break | canonical_fact_lookup | date | none (0/1) | low | calibrated_limited | yes | SOFT_PASS | wrong_question_type |
| C10 | По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действител... | vat_document_register_book | settlements_60_62 | canonical_fact_lookup | lifecycle_first | account,date,amount | account (1/3) | low | calibrated_limited | yes | FAIL | wrong_domain |
| C11 | 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок мог... | vat_document_register_book | vat_document_register_book | symptom_first | canonical_fact_lookup | date,amount | none (0/2) | medium | calibrated_limited | yes | SOFT_PASS | wrong_question_type |
| C12 | Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка... | vat_document_register_book | vat_document_register_book | chain_break | lifecycle_first | date | none (0/1) | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C13 | Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно? | vat_document_register_book | month_close_costs_20_44 | lifecycle_first | ranking_or_period_summary | none | n/a | medium | calibrated_limited | no | FAIL | wrong_domain |
| C14 | Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на про... | vat_document_register_book | vat_document_register_book | canonical_fact_lookup | lifecycle_first | account,date | none (0/2) | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C15 | Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными? | vat_document_register_book | vat_document_register_book | symptom_first | lifecycle_first | none | n/a | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C16 | Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтвержд... | vat_document_register_book | vat_document_register_book | lifecycle_first | symptom_first | none | n/a | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C17 | 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё л... | month_close_costs_20_44 | month_close_costs_20_44 | period_impact | period_impact | date,amount | none (0/2) | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C18 | 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу ... | month_close_costs_20_44 | month_close_costs_20_44 | lifecycle_first | canonical_fact_lookup | date,amount | none (0/2) | medium | calibrated_limited | yes | SOFT_PASS | wrong_question_type |
| C19 | 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июл... | month_close_costs_20_44 | month_close_costs_20_44 | period_impact | lifecycle_first | date,amount | none (0/2) | medium | calibrated_limited | yes | SOFT_PASS | generic_answer |
| C20 | После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — ... | month_close_costs_20_44 | month_close_costs_20_44 | ranking_or_period_summary | lifecycle_first | none | n/a | medium | calibrated_limited | yes | SOFT_PASS | wrong_question_type |
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_chat20_failure_taxonomy.md
+13
View File
@@ -0,0 +1,13 @@
# Wave12 Chat20 Failure Taxonomy
Coverage: FAIL + SOFT_PASS cases only.
| defect_class | cases_count | case_ids | note |
|---|---:|---|---|
| generic_answer | 20 | C01, C02, C03, C04, C05, C06, C07, C08, C09, C10, C11, C12, C13, C14, C15, C16, C17, C18, C19, C20 | Answer collapses to generic wording with weak case specificity. |
| partial_coverage_misleading | 16 | C01, C03, C04, C05, C07, C08, C10, C11, C12, C14, C15, C16, C17, C18, C19, C20 | Partial mode does not clearly separate confirmed vs unconfirmed parts. |
| weak_company_anchor_usage | 15 | C01, C02, C03, C04, C05, C07, C08, C09, C10, C11, C12, C14, C17, C18, C19 | Company-specific anchors from question are weakly reused in answer narrative. |
| wrong_question_type | 7 | C06, C08, C09, C11, C13, C18, C20 | Router query class does not fit expected intent class for the question. |
| wrong_domain | 6 | C01, C03, C06, C08, C10, C13 | Primary narrative domain in final answer diverges from expected P0 domain. |
| wrong_first_check | 5 | C01, C03, C06, C08, C13 | First-check block is not aligned with expected domain mechanics. |
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_chat20_metrics.json
+20
View File
@@ -0,0 +1,20 @@
{
"total_cases": 20,
"domain_correctness_rate": 0.7,
"question_type_fit_rate": 0.65,
"company_anchor_usage_rate": 0.4,
"generic_answer_rate": 1,
"confidence_limitation_conflict_rate": 0,
"first_check_relevance_rate": 0.75,
"counts": {
"pass": 0,
"soft_pass": 14,
"fail": 6,
"domain_correct": 14,
"type_fit": 13,
"anchor_usage_good": 8,
"generic_answer": 20,
"confidence_limitation_conflict": 0,
"first_check_relevant": 15
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_chat20_root_causes.md
+11
View File
@@ -0,0 +1,11 @@
# Wave12 Chat20 Root Causes (FAIL Cases)
| case_id | where_it_breaks | primary_cause | notes |
|---|---|---|---|
| C01 | final synthesis | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
| C03 | final synthesis | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
| C06 | domain selection | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
| C08 | domain selection | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
| C10 | final synthesis | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
| C13 | domain selection | wrong_domain | Expected P0 domain and final narrative domain diverged on final answer composition. |
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_next_wave_proposal.md
+46
View File
@@ -0,0 +1,46 @@
# Next Wave Proposal
wave_title: Wave 13 - Domain Routing Stabilization + Anchor-Grounded Answering for Chat20
goal:
- Reduce dominant defect classes from Chat20 run by fixing domain drift, query-class mismatch, and generic/anchor-light narratives without scope expansion.
in_scope:
- Query-class calibration for VAT and month-close cases in mixed sessions.
- Final synthesis domain lock enforcement per expected P0 domain card.
- Company-anchor carry-through into direct answer and first-check blocks.
- Confidence/limitation wording reconciliation hard gate in user-facing answer contract.
out_of_scope:
- New domains.
- Graph/schema expansion.
- Stage 5 investigation orchestration.
- Stage 6 live verification product layer.
- Large transport/base refactor.
Top-5 dominant defect classes (from Chat20):
- generic_answer: 20
- partial_coverage_misleading: 16
- weak_company_anchor_usage: 15
- wrong_question_type: 7
- wrong_domain: 6
what_to_fix_first:
1. wrong_domain
2. wrong_question_type
3. generic_answer
4. weak_company_anchor_usage
5. confidence_limitation_conflict
what_not_to_touch_now:
1. New problem families and ontology growth.
2. New runtime routes and broad router redesign.
3. Live verification integrations beyond current MCP overlay.
expected_metric_delta:
- domain_correctness_rate: +0.20 to +0.30
- question_type_fit_rate: +0.15 to +0.25
- company_anchor_usage_rate: +0.20 to +0.35
- generic_answer_rate: -0.20 to -0.35
- confidence_limitation_conflict_rate: -0.10 to -0.20
- first_check_relevance_rate: +0.15 to +0.25
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/wave12_next_wave_proposal.zip
BIN
View File
Binary file not shown.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/Чат20.txt
+586
View File
@@ -0,0 +1,586 @@
# Assistant conversation export
session_id: wave12-chat20-20260328111253
exported_at: 2026-03-28T11:12:53+03:00
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
## 2. assistant
message_id: msg-4fsXbrodm-
created_at: 2026-03-28T08:12:54.980Z
reply_type: partial_coverage
trace_id: QJci5WyX3ft81x
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 4. assistant
message_id: msg-39DQpdF6cI
created_at: 2026-03-28T08:12:56.045Z
reply_type: partial_coverage
trace_id: -uJx3CbCyD6efa
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
## 6. assistant
message_id: msg-Mgk0pGaNUh
created_at: 2026-03-28T08:12:58.045Z
reply_type: partial_coverage
trace_id: kn6zJbWS6qu9fq
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 7. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
## 8. assistant
message_id: msg-MLoHzjLY5h
created_at: 2026-03-28T08:12:59.026Z
reply_type: partial_coverage
trace_id: EtBxpA7565d4BI
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 9. user
message_id: pending
created_at: pending
reply_type: n/a
Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
## 10. assistant
message_id: msg-sVKuqSSyn7
created_at: 2026-03-28T08:13:00.093Z
reply_type: partial_coverage
trace_id: Q_RQ1o0y08SLvq
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 11. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
## 12. assistant
message_id: msg-oxmpmheuxc
created_at: 2026-03-28T08:13:00.381Z
reply_type: factual_with_explanation
trace_id: -DQPlpaNx_GMeY
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 13. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
## 14. assistant
message_id: msg-ysTXXg_uWo
created_at: 2026-03-28T08:13:01.044Z
reply_type: partial_coverage
trace_id: XXuSMowCWA7ZE0
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 15. user
message_id: pending
created_at: pending
reply_type: n/a
Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
## 16. assistant
message_id: msg-C39aNBxVtK
created_at: 2026-03-28T08:13:02.105Z
reply_type: partial_coverage
trace_id: WN0Y4906MCjspk
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 17. user
message_id: pending
created_at: pending
reply_type: n/a
13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
## 18. assistant
message_id: msg-96orOIY0ka
created_at: 2026-03-28T08:13:04.126Z
reply_type: partial_coverage
trace_id: SquchuSqFRZcOx
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1, R2, R3.
- Отдельно не подтверждено или покрыто частично: R4. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 19. user
message_id: pending
created_at: pending
reply_type: n/a
По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
## 20. assistant
message_id: msg--_iUlZkpbE
created_at: 2026-03-28T08:13:05.195Z
reply_type: partial_coverage
trace_id: N2Hc1k-qsgrfip
Коротко: Проблема с закрытием расчета подтверждается частично. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте договор, объект расчетов, регистр расчетов и документ закрытия (зачет аванса или взаимозачет).
- Сверьте связку платеж -> расчетный документ -> проводки по 60/62/76 и подтверждение закрытия хвоста.
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 21. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 22. assistant
message_id: msg-7qtvoAf0c5
created_at: 2026-03-28T08:13:06.153Z
reply_type: partial_coverage
trace_id: xdqJUY2maGj7vy
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 23. user
message_id: pending
created_at: pending
reply_type: n/a
Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
## 24. assistant
message_id: msg-qEtMwR_aJ_
created_at: 2026-03-28T08:13:07.195Z
reply_type: partial_coverage
trace_id: FRVMcRZ0qiDpzG
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 25. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
## 26. assistant
message_id: msg-Ok-j19vxRQ
created_at: 2026-03-28T08:13:07.775Z
reply_type: factual_with_explanation
trace_id: 9MuMurq3F9CmFc
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 27. user
message_id: pending
created_at: pending
reply_type: n/a
Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
## 28. assistant
message_id: msg-JCdEfc8Mar
created_at: 2026-03-28T08:13:09.194Z
reply_type: partial_coverage
trace_id: 1dDiXyWKvPDZpf
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 29. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
## 30. assistant
message_id: msg-wpl3TCjztH
created_at: 2026-03-28T08:13:10.223Z
reply_type: partial_coverage
trace_id: VSRhbuuVNt2H-w
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 31. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
## 32. assistant
message_id: msg-4itIqauy5f
created_at: 2026-03-28T08:13:11.176Z
reply_type: partial_coverage
trace_id: uEKTeObyKnx77p
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 33. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 34. assistant
message_id: msg-_Tt6Z0eAIf
created_at: 2026-03-28T08:13:13.226Z
reply_type: partial_coverage
trace_id: 5Rcd5Axn3mMjyO
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 35. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
## 36. assistant
message_id: msg-gmTvHh1Mbu
created_at: 2026-03-28T08:13:14.085Z
reply_type: partial_coverage
trace_id: go1H83IxwsAKCC
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 37. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
## 38. assistant
message_id: msg-ydS8wrXn9w
created_at: 2026-03-28T08:13:16.293Z
reply_type: partial_coverage
trace_id: LtCZFtySkQlEXF
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
## 39. user
message_id: pending
created_at: pending
reply_type: n/a
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
## 40. assistant
message_id: msg-_cIITKdS2L
created_at: 2026-03-28T08:13:18.290Z
reply_type: partial_coverage
trace_id: Dk-ipu0GMt0rYB
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Live probe использует ограниченный выборочный read-only запрос к 1С.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/чат.txt
+8
View File
@@ -0,0 +1,8 @@
# чат.txt (Wave 12 template)
Контрольные 3 вопроса для live verification pass:
1) Settlement (60/62)
2) VAT chain
3) Month-close costs (20-44)
Заполняется после живого прогона из GUI/MCP Toolkit.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation/чат_2q.txt
+7
View File
@@ -0,0 +1,7 @@
# чат_2q.txt (Wave 12 template)
Контрольный 2-question smoke:
1) Settlement reference case
2) VAT or month-close reference case
Заполняется после живого прогона из GUI/MCP Toolkit.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/Chat20.txt
+579
View File
@@ -0,0 +1,579 @@
# Assistant conversation export
session_id: wave13-chat20-rerun-20260328
exported_at: 2026-03-28T09:28:47.957Z
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
## 2. assistant
message_id: msg-upD-bMprM4
created_at: 2026-03-28T09:28:44.883Z
reply_type: partial_coverage
trace_id: 0w-kA6MGaoltiN
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2019, period:2019. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 01/19-ПТ, 09.01.2019, 09.01, 55 200.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 4. assistant
message_id: msg-IKNCGwkEZ1
created_at: 2026-03-28T09:28:45.031Z
reply_type: partial_coverage
trace_id: Q1HIFYuSfcXbSU
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 2 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 1 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 07.07.20, 07.07, 276 873,60, 62.02.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_62.02),.
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
## 6. assistant
message_id: msg-QYHXtKK2Z4
created_at: 2026-03-28T09:28:45.202Z
reply_type: partial_coverage
trace_id: UVTLF11f6c6oeV
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, 05.06.2020, 05.06, 40 860, 20 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 7. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
## 8. assistant
message_id: msg-UT6NYO__RN
created_at: 2026-03-28T09:28:45.342Z
reply_type: partial_coverage
trace_id: NQX8HsQ8Rbe6j4
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 62.01/62, 62.01, 62.02, счет 62.01, счет 62.02, account:62.01, account:62.02.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_62.01, account_62.02),.
## 9. user
message_id: pending
created_at: pending
reply_type: n/a
Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
## 10. assistant
message_id: msg-ZGPBF1_WEe
created_at: 2026-03-28T09:28:45.417Z
reply_type: partial_coverage
trace_id: cYTLbNZBAaUWm_
Коротко: Приоритет ответа: локализовать разрыв внутри расчетного контура. Что сломано:
- Вероятный узел разрыва: привязка оплаты к объекту расчетов и документу закрытия.
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, договор № е.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 11. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
## 12. assistant
message_id: msg-r-LbZsryOd
created_at: 2026-03-28T09:28:45.480Z
reply_type: factual_with_explanation
trace_id: ci0gn7kDUn1TKL
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 13. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
## 14. assistant
message_id: msg-b6ATO7kADd
created_at: 2026-03-28T09:28:45.582Z
reply_type: partial_coverage
trace_id: ycGHtDI9H1VDgH
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 15. user
message_id: pending
created_at: pending
reply_type: n/a
Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
## 16. assistant
message_id: msg-agpwtAt8LP
created_at: 2026-03-28T09:28:45.698Z
reply_type: partial_coverage
trace_id: ljjEEwyd8IIIRe
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 17. user
message_id: pending
created_at: pending
reply_type: n/a
13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
## 18. assistant
message_id: msg-gJcfS4gyGm
created_at: 2026-03-28T09:28:45.849Z
reply_type: partial_coverage
trace_id: aUaHCqPv6nJweq
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 19. user
message_id: pending
created_at: pending
reply_type: n/a
По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
## 20. assistant
message_id: msg-ElyoFAulGa
created_at: 2026-03-28T09:28:45.981Z
reply_type: partial_coverage
trace_id: qFTtxnt5BndooX
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Якоря из вопроса без прямого подтверждения: 276 873,60, 46 145,60.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 21. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 22. assistant
message_id: msg-4EFHvPOYED
created_at: 2026-03-28T09:28:46.262Z
reply_type: partial_coverage
trace_id: dxg2PheabfzvZj
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: 1 166,67, 233,33.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 23. user
message_id: pending
created_at: pending
reply_type: n/a
Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
## 24. assistant
message_id: msg-veCZAigzCH
created_at: 2026-03-28T09:28:46.402Z
reply_type: partial_coverage
trace_id: RmSHKI40EemuVf
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 25. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
## 26. assistant
message_id: msg-ZhHR7g83t6
created_at: 2026-03-28T09:28:46.509Z
reply_type: factual_with_explanation
trace_id: G2O8raZ_smMdZO
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 27. user
message_id: pending
created_at: pending
reply_type: n/a
Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
## 28. assistant
message_id: msg--9HLhAL7LM
created_at: 2026-03-28T09:28:46.646Z
reply_type: partial_coverage
trace_id: WdrZQ1DtDt6iBz
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 3 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 3 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 29. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
## 30. assistant
message_id: msg-cYnRR8YEr5
created_at: 2026-03-28T09:28:46.827Z
reply_type: partial_coverage
trace_id: 8a3LMF-VjZx_Oj
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 31. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
## 32. assistant
message_id: msg-PL-7f7FVm6
created_at: 2026-03-28T09:28:47.030Z
reply_type: partial_coverage
trace_id: jBjgx206kYqz9V
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 33. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 34. assistant
message_id: msg-NKaO-xOibb
created_at: 2026-03-28T09:28:47.248Z
reply_type: partial_coverage
trace_id: 39t_3TJ3zJ66Wc
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 148 050, 27 954,50, 5 786,63, 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 35. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
## 36. assistant
message_id: msg-sXRbGSC-XL
created_at: 2026-03-28T09:28:47.455Z
reply_type: partial_coverage
trace_id: wmcTsfwqF8UiV4
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 37. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
## 38. assistant
message_id: msg-tz_G2BMu9E
created_at: 2026-03-28T09:28:47.671Z
reply_type: partial_coverage
trace_id: 3pW2hBxfBWeZKo
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R2.
- Отдельно не подтверждено или покрыто частично: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 2 471,52, 2 465,28, 849,83.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 39. user
message_id: pending
created_at: pending
reply_type: n/a
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
## 40. assistant
message_id: msg-I0IAc9ViP9
created_at: 2026-03-28T09:28:47.843Z
reply_type: partial_coverage
trace_id: og6puwuxit3xNg
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/README.md
+38
View File
@@ -0,0 +1,38 @@
# Wave 13 Run
## Scope
- Stage 4, Wave 13: Domain Fit + Question-Type Fit + Company-Anchor Grounding.
- Runtime scope did not expand beyond P0 domains.
- Focus: domain fit, question-type fit, company-anchor grounding, anti-generic shaping.
## Implemented
- Added `questionTypeResolver` and integrated question-type hint into assistant pipeline.
- Added `companyAnchorResolver` and integrated anchor extraction into answer synthesis.
- Extended `answerComposer` with:
- question-type-aware rendering overlays;
- company-anchor usage evaluation and user-facing anchor grounding lines;
- stronger domain inference scoring for narrative synthesis.
- Added follow-up domain-shift guard in `assistantService` to prevent stale focus lock.
- Added Wave 13 regression tests: `assistantWave13DomainFitQuestionTypeAnchorRegression.test.ts`.
- Added reproducible Chat20 tooling:
- `backend/scripts/runCompanyQuestionBatch.js`
- `backend/scripts/analyzeWave13Chat20.js`
## Validation
- Full backend suite: PASS
- Build: PASS
- Chat20 rerun: completed (`wave13-chat20-rerun-20260328`)
## Chat20 Snapshot
- total cases: 20
- PASS: 1
- SOFT_PASS: 4
- FAIL: 15
- domain_correctness_rate: 0.25
- question_type_fit_rate: 0.45
- company_anchor_usage_rate: 1.00 (0.50 global)
- generic_answer_rate: 0.60
- first_check_relevance_rate: 0.85
## Notes
- Wave 13 is process-complete (artifacts + reproducible runner + analysis), but quality acceptance is NOT reached due high `wrong_domain` and remaining `wrong_question_type/generic_answer` failures on Chat20.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/chat20_wave13_raw.json
+156948
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/prompt_dialogs/chat20_prompts.md
+39
View File
@@ -0,0 +1,39 @@
1. Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
2. Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
3. По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
4. Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
5. Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
6. Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
7. Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
8. Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
9. 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
10. По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
11. 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
12. Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
13. Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
14. Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
15. Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
16. Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
17. 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
18. 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
19. 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
20. После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/questions20_utf8.json
+22
View File
@@ -0,0 +1,22 @@
[
"Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?",
"Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?",
"По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?",
"Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?",
"Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?",
"Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?",
"Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?",
"Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?",
"13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?",
"По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?",
"31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?",
"Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?",
"Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?",
"Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?",
"Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?",
"Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?",
"31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?",
"31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?",
"31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?",
"После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?"
]
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/run_summary.json
+81
View File
@@ -0,0 +1,81 @@
{
"schema_version": "wave13_run_summary_v1",
"run_id": "2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding",
"wave": "Wave 13",
"stage": "Stage 4",
"status": "IMPLEMENTED_NOT_ACCEPTED",
"scope": {
"domains_in_scope": [
"settlements_60_62",
"vat_document_register_book",
"month_close_costs_20_44"
],
"focus": [
"domain_selection",
"final_synthesis_domain_consistency",
"question_type_fit",
"company_anchor_usage",
"anti_generic_answer_policy"
],
"out_of_scope": [
"new domains",
"stage5 investigation engine",
"stage6 live verification layer",
"graph expansion",
"transport/base routing refactor"
]
},
"changed_files": [
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\assistantService.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\assistantDataLayer.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\answerComposer.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\questionTypeResolver.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\companyAnchorResolver.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\tests\\assistantWave13DomainFitQuestionTypeAnchorRegression.test.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\scripts\\runCompanyQuestionBatch.js",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\scripts\\analyzeWave13Chat20.js"
],
"checks": {
"full_backend_suite": {
"command": "npm.cmd test",
"result": "PASS"
},
"build": {
"command": "npm.cmd run build",
"result": "PASS"
}
},
"chat20_run": {
"session_id": "wave13-chat20-rerun-20260328",
"questions_total": 20,
"useMock": true,
"artifacts": {
"chat": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\Chat20.txt",
"chat_ru": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\Чат20.txt",
"raw": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\chat20_wave13_raw.json",
"case_matrix": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\wave13_chat20_case_matrix_updated.md",
"metrics": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\wave13_chat20_metrics.json",
"report": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\wave13_regression_report.md",
"prompt_dialogs": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding\\prompt_dialogs"
}
},
"metrics_snapshot": {
"domain_correctness_rate": 0.25,
"question_type_fit_rate": 0.45,
"company_anchor_usage_rate": 1.0,
"company_anchor_usage_rate_global": 0.5,
"generic_answer_rate": 0.6,
"first_check_relevance_rate": 0.85,
"totals": {
"pass": 1,
"soft_pass": 4,
"fail": 15
}
},
"dominant_defects": [
"wrong_domain",
"generic_answer",
"wrong_question_type"
],
"verdict": "WAVE13_NOT_ACCEPTED_REQUIRES_NEXT_CORRECTIVE_WAVE"
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/wave13_chat20_case_matrix_updated.md
+25
View File
@@ -0,0 +1,25 @@
# Wave 13 Chat20 Case Matrix (Updated)
| case_id | question_short | expected_domain | actual_domain | expected_question_type | actual_question_type | company_anchors_present | company_anchors_used_in_answer | evidence_strength | answer_confidence_style | first_check_relevance | verdict | failure_reason_short |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| q01 | Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться... | settlements_60_62 | month_close_costs_20_44 | why_breaks | why_breaks | true | true | strong | mixed | true | FAIL | wrong_domain, generic_answer |
| q02 | Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июл... | settlements_60_62 | settlements_60_62 | prove_or_guess | why_breaks | true | true | weak | mixed | true | SOFT_PASS | wrong_question_type, generic_answer |
| q03 | По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реали... | settlements_60_62 | month_close_costs_20_44 | prove_or_guess | why_breaks | true | true | strong | mixed | true | FAIL | wrong_domain, wrong_question_type |
| q04 | Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё... | settlements_60_62 | month_close_costs_20_44 | why_breaks | why_breaks | true | true | weak | mixed | true | FAIL | wrong_domain, generic_answer |
| q05 | Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в догово... | settlements_60_62 | month_close_costs_20_44 | where_break_is | where_break_is | true | true | strong | mixed | true | FAIL | wrong_domain, generic_answer |
| q06 | Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно б... | settlements_60_62 | month_close_costs_20_44 | prove_or_guess | why_breaks | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_question_type, wrong_first_check |
| q07 | Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот об... | settlements_60_62 | month_close_costs_20_44 | why_breaks | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, generic_answer |
| q08 | Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет? | settlements_60_62 | month_close_costs_20_44 | which_chains_are_complete_vs_incomplete | why_breaks | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_question_type, wrong_first_check, generic_answer |
| q09 | 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас по... | vat_document_register_book | month_close_costs_20_44 | which_chains_are_complete_vs_incomplete | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, wrong_question_type, generic_answer |
| q10 | По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже ... | vat_document_register_book | month_close_costs_20_44 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | FAIL | wrong_domain |
| q11 | 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга п... | vat_document_register_book | month_close_costs_20_44 | why_breaks | why_breaks | true | true | strong | mixed | true | FAIL | wrong_domain, generic_answer |
| q12 | Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, и... | vat_document_register_book | month_close_costs_20_44 | prove_or_guess | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, wrong_question_type, generic_answer |
| q13 | Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно? | vat_document_register_book | month_close_costs_20_44 | why_breaks | why_breaks | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_first_check |
| q14 | Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-факту... | vat_document_register_book | month_close_costs_20_44 | what_is_it_grounded_on | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, wrong_question_type, generic_answer |
| q15 | Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными? | vat_document_register_book | month_close_costs_20_44 | why_breaks | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, generic_answer |
| q16 | Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не... | vat_document_register_book | month_close_costs_20_44 | which_chains_are_complete_vs_incomplete | why_breaks | false | false | strong | mixed | true | FAIL | wrong_domain, wrong_question_type, generic_answer |
| q17 | 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и дру... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | why_breaks | true | true | strong | mixed | true | SOFT_PASS | wrong_question_type |
| q18 | 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБ... | month_close_costs_20_44 | month_close_costs_20_44 | what_is_it_grounded_on | why_breaks | true | true | strong | mixed | true | SOFT_PASS | wrong_question_type |
| q19 | 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объек... | month_close_costs_20_44 | month_close_costs_20_44 | why_breaks | why_breaks | true | true | weak | mixed | true | PASS | none |
| q20 | После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых резу... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | why_breaks | false | false | strong | mixed | true | SOFT_PASS | wrong_question_type |
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/wave13_chat20_metrics.json
+34
View File
@@ -0,0 +1,34 @@
{
"schema_version": "wave13_chat20_metrics_v2",
"run_id": "2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding",
"source_session_id": "wave13-chat20-rerun-20260328",
"totals": {
"cases": 20,
"pass": 1,
"soft_pass": 4,
"fail": 15
},
"domain_correctness_rate": 0.25,
"question_type_fit_rate": 0.45,
"company_anchor_usage_rate": 1,
"company_anchor_usage_rate_global": 0.5,
"generic_answer_rate": 0.6,
"first_check_relevance_rate": 0.85,
"anchors_present_cases": 10,
"anchors_used_cases": 10,
"baseline_reference": "wave12_chat20_metrics.json",
"baseline_metrics": {
"domain_correctness_rate": 0.7,
"question_type_fit_rate": 0.65,
"company_anchor_usage_rate": 0.4,
"generic_answer_rate": 1,
"first_check_relevance_rate": 0.75
},
"delta_vs_baseline": {
"domain_correctness_rate_delta": -0.45,
"question_type_fit_rate_delta": -0.2,
"company_anchor_usage_rate_delta": 0.6,
"generic_answer_rate_delta": -0.4,
"first_check_relevance_rate_delta": 0.1
}
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/wave13_regression_report.md
+44
View File
@@ -0,0 +1,44 @@
# Wave 13 Regression Report
- Cases: 20
- PASS: 1
- SOFT_PASS: 4
- FAIL: 15
## Metric Snapshot
- domain_correctness_rate: 0.25
- question_type_fit_rate: 0.45
- company_anchor_usage_rate: 1
- generic_answer_rate: 0.6
- first_check_relevance_rate: 0.85
## Delta vs Baseline
- domain_correctness_rate: 0.7 -> 0.25 (delta -0.45)
- question_type_fit_rate: 0.65 -> 0.45 (delta -0.2)
- company_anchor_usage_rate: 0.4 -> 1 (delta +0.6)
- generic_answer_rate: 1 -> 0.6 (delta -0.4)
- first_check_relevance_rate: 0.75 -> 0.85 (delta +0.1)
## Top Defects
- wrong_domain: 15
- generic_answer: 12
- wrong_question_type: 11
- wrong_first_check: 3
## FAIL Cases
- q01: wrong_domain, generic_answer
- q03: wrong_domain, wrong_question_type
- q04: wrong_domain, generic_answer
- q05: wrong_domain, generic_answer
- q06: wrong_domain, wrong_question_type, wrong_first_check
- q07: wrong_domain, generic_answer
- q08: wrong_domain, wrong_question_type, wrong_first_check, generic_answer
- q09: wrong_domain, wrong_question_type, generic_answer
- q10: wrong_domain
- q11: wrong_domain, generic_answer
- q12: wrong_domain, wrong_question_type, generic_answer
- q13: wrong_domain, wrong_first_check
- q14: wrong_domain, wrong_question_type, generic_answer
- q15: wrong_domain, generic_answer
- q16: wrong_domain, wrong_question_type, generic_answer
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding/Чат20.txt
+579
View File
@@ -0,0 +1,579 @@
# Assistant conversation export
session_id: wave13-chat20-rerun-20260328
exported_at: 2026-03-28T09:28:47.957Z
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
## 2. assistant
message_id: msg-upD-bMprM4
created_at: 2026-03-28T09:28:44.883Z
reply_type: partial_coverage
trace_id: 0w-kA6MGaoltiN
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2019, period:2019. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 01/19-ПТ, 09.01.2019, 09.01, 55 200.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 4. assistant
message_id: msg-IKNCGwkEZ1
created_at: 2026-03-28T09:28:45.031Z
reply_type: partial_coverage
trace_id: Q1HIFYuSfcXbSU
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 2 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 1 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 07.07.20, 07.07, 276 873,60, 62.02.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_62.02),.
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
## 6. assistant
message_id: msg-QYHXtKK2Z4
created_at: 2026-03-28T09:28:45.202Z
reply_type: partial_coverage
trace_id: UVTLF11f6c6oeV
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, 05.06.2020, 05.06, 40 860, 20 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 7. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
## 8. assistant
message_id: msg-UT6NYO__RN
created_at: 2026-03-28T09:28:45.342Z
reply_type: partial_coverage
trace_id: NQX8HsQ8Rbe6j4
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 62.01/62, 62.01, 62.02, счет 62.01, счет 62.02, account:62.01, account:62.02.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_62.01, account_62.02),.
## 9. user
message_id: pending
created_at: pending
reply_type: n/a
Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
## 10. assistant
message_id: msg-ZGPBF1_WEe
created_at: 2026-03-28T09:28:45.417Z
reply_type: partial_coverage
trace_id: cYTLbNZBAaUWm_
Коротко: Приоритет ответа: локализовать разрыв внутри расчетного контура. Что сломано:
- Вероятный узел разрыва: привязка оплаты к объекту расчетов и документу закрытия.
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, договор № е.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 11. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
## 12. assistant
message_id: msg-r-LbZsryOd
created_at: 2026-03-28T09:28:45.480Z
reply_type: factual_with_explanation
trace_id: ci0gn7kDUn1TKL
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 13. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
## 14. assistant
message_id: msg-b6ATO7kADd
created_at: 2026-03-28T09:28:45.582Z
reply_type: partial_coverage
trace_id: ycGHtDI9H1VDgH
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 15. user
message_id: pending
created_at: pending
reply_type: n/a
Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
## 16. assistant
message_id: msg-agpwtAt8LP
created_at: 2026-03-28T09:28:45.698Z
reply_type: partial_coverage
trace_id: ljjEEwyd8IIIRe
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 17. user
message_id: pending
created_at: pending
reply_type: n/a
13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
## 18. assistant
message_id: msg-gJcfS4gyGm
created_at: 2026-03-28T09:28:45.849Z
reply_type: partial_coverage
trace_id: aUaHCqPv6nJweq
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 19. user
message_id: pending
created_at: pending
reply_type: n/a
По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
## 20. assistant
message_id: msg-ElyoFAulGa
created_at: 2026-03-28T09:28:45.981Z
reply_type: partial_coverage
trace_id: qFTtxnt5BndooX
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Якоря из вопроса без прямого подтверждения: 276 873,60, 46 145,60.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 21. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 22. assistant
message_id: msg-4EFHvPOYED
created_at: 2026-03-28T09:28:46.262Z
reply_type: partial_coverage
trace_id: dxg2PheabfzvZj
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: 1 166,67, 233,33.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 23. user
message_id: pending
created_at: pending
reply_type: n/a
Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
## 24. assistant
message_id: msg-veCZAigzCH
created_at: 2026-03-28T09:28:46.402Z
reply_type: partial_coverage
trace_id: RmSHKI40EemuVf
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 25. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
## 26. assistant
message_id: msg-ZhHR7g83t6
created_at: 2026-03-28T09:28:46.509Z
reply_type: factual_with_explanation
trace_id: G2O8raZ_smMdZO
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 27. user
message_id: pending
created_at: pending
reply_type: n/a
Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
## 28. assistant
message_id: msg--9HLhAL7LM
created_at: 2026-03-28T09:28:46.646Z
reply_type: partial_coverage
trace_id: WdrZQ1DtDt6iBz
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 3 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 3 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 29. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
## 30. assistant
message_id: msg-cYnRR8YEr5
created_at: 2026-03-28T09:28:46.827Z
reply_type: partial_coverage
trace_id: 8a3LMF-VjZx_Oj
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 31. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
## 32. assistant
message_id: msg-PL-7f7FVm6
created_at: 2026-03-28T09:28:47.030Z
reply_type: partial_coverage
trace_id: jBjgx206kYqz9V
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 33. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 34. assistant
message_id: msg-NKaO-xOibb
created_at: 2026-03-28T09:28:47.248Z
reply_type: partial_coverage
trace_id: 39t_3TJ3zJ66Wc
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 148 050, 27 954,50, 5 786,63, 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 35. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
## 36. assistant
message_id: msg-sXRbGSC-XL
created_at: 2026-03-28T09:28:47.455Z
reply_type: partial_coverage
trace_id: wmcTsfwqF8UiV4
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 37. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
## 38. assistant
message_id: msg-tz_G2BMu9E
created_at: 2026-03-28T09:28:47.671Z
reply_type: partial_coverage
trace_id: 3pW2hBxfBWeZKo
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R2.
- Отдельно не подтверждено или покрыто частично: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Якоря из вопроса без прямого подтверждения: 2 471,52, 2 465,28, 849,83.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 39. user
message_id: pending
created_at: pending
reply_type: n/a
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
## 40. assistant
message_id: msg-I0IAc9ViP9
created_at: 2026-03-28T09:28:47.843Z
reply_type: partial_coverage
trace_id: og6puwuxit3xNg
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/Chat20.txt
+577
View File
@@ -0,0 +1,577 @@
# Assistant conversation export
session_id: wave13-chat20-1774692067716
exported_at: 2026-03-28T10:01:11.125Z
## 1. user
message_id: pending
created_at: pending
reply_type: n/a
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
## 2. assistant
message_id: msg-YxXSaf6Ln3
created_at: 2026-03-28T10:01:07.969Z
reply_type: partial_coverage
trace_id: 75EqfESpr2eOVD
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2019, period:2019. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 01/19-ПТ, 09.01.2019, 09.01, 55 200.
- Связка между источниками подтверждена частично.
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_55),.
## 3. user
message_id: pending
created_at: pending
reply_type: n/a
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
## 4. assistant
message_id: msg-4E_F-NHnK5
created_at: 2026-03-28T10:01:08.127Z
reply_type: partial_coverage
trace_id: e3qrctNEI_Y49k
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Переход от оплаты к закрытию расчета не подтвержден.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 2 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 1 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора частичная: часть требований покрыта не полностью.
- Подтверждено по требованиям: R1.
- Отдельно не подтверждено или покрыто частично: R2. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 07.07.20, 07.07, 276 873,60, 62.02.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_13, account_62.02),.
## 5. user
message_id: pending
created_at: pending
reply_type: n/a
По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
## 6. assistant
message_id: msg-KEiFbZNfRX
created_at: 2026-03-28T10:01:08.218Z
reply_type: partial_coverage
trace_id: 93w_YAABVRWo4U
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- misclosed_payment; settlement_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, 05.06.2020, 05.06, 40 860, 20 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 7. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
## 8. assistant
message_id: msg-d_USEIit0K
created_at: 2026-03-28T10:01:08.338Z
reply_type: partial_coverage
trace_id: LbXkk3ZZgG7_-H
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- stale_receivable; receivable_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: 62.01/62, 62.01, 62.02, счет 62.01, счет 62.02, account:62.01, account:62.02.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- (account_62.01, account_62.02),.
## 9. user
message_id: pending
created_at: pending
reply_type: n/a
Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
## 10. assistant
message_id: msg-O9N7_iyJnL
created_at: 2026-03-28T10:01:08.441Z
reply_type: partial_coverage
trace_id: x1sHB0osP6_lwR
Коротко: Приоритет ответа: локализовать разрыв внутри расчетного контура. Что сломано:
- Вероятный узел разрыва: привязка оплаты к объекту расчетов и документу закрытия.
- stale_receivable; receivable_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Якоря из вопроса без прямого подтверждения: договор № 1-ПМ/2020, договор № е.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 11. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
## 12. assistant
message_id: msg-jy2VSjSi53
created_at: 2026-03-28T10:01:08.561Z
reply_type: factual_with_explanation
trace_id: NUdqXqLiKMMlqr
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- stale_unlinked_payment; settlement_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 13. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
## 14. assistant
message_id: msg-3EUPE2GFWq
created_at: 2026-03-28T10:01:08.656Z
reply_type: partial_coverage
trace_id: hBJTrO8cm5h6mF
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- stale_receivable; receivable_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 15. user
message_id: pending
created_at: pending
reply_type: n/a
Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
## 16. assistant
message_id: msg-Lm2k6hvmPG
created_at: 2026-03-28T10:01:08.744Z
reply_type: partial_coverage
trace_id: H5vu4wSQtbGNBc
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- misclosed_payment; settlement_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте договор и объект расчетов по платежу/зачету.
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 17. user
message_id: pending
created_at: pending
reply_type: n/a
13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
## 18. assistant
message_id: msg-6sgffwBJCq
created_at: 2026-03-28T10:01:08.925Z
reply_type: partial_coverage
trace_id: ItPnMm6F9FEyQm
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 19. user
message_id: pending
created_at: pending
reply_type: n/a
По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
## 20. assistant
message_id: msg-ZBsGLJsAK5
created_at: 2026-03-28T10:01:09.161Z
reply_type: partial_coverage
trace_id: 7aIH5xVUFuY0IF
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Якоря из вопроса без прямого подтверждения: 276 873,60, 46 145,60.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 21. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
## 22. assistant
message_id: msg-FktOs9sTQM
created_at: 2026-03-28T10:01:09.397Z
reply_type: partial_coverage
trace_id: 0IHlTYB0KzOyGx
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: 1 166,67, 233,33.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 23. user
message_id: pending
created_at: pending
reply_type: n/a
Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
## 24. assistant
message_id: msg-Wxxaf4g91M
created_at: 2026-03-28T10:01:09.627Z
reply_type: partial_coverage
trace_id: dIt3tJrisqo5GC
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 25. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
## 26. assistant
message_id: msg-mdJcXQWvk3
created_at: 2026-03-28T10:01:09.726Z
reply_type: factual_with_explanation
trace_id: vEYMn2LzmkRf-i
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- stale_unlinked_payment; settlement_closed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 5 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 5 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Механизм проблемы подтвержден не полностью.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
## 27. user
message_id: pending
created_at: pending
reply_type: n/a
Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
## 28. assistant
message_id: msg-OvEtlGDIQn
created_at: 2026-03-28T10:01:09.895Z
reply_type: partial_coverage
trace_id: K7EuG-Yg5d8svP
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
- В цепочке НДС не подтвержден ожидаемый переход от документа к регистру и книге; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 3 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 3 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 29. user
message_id: pending
created_at: pending
reply_type: n/a
Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
## 30. assistant
message_id: msg-ASHc95QDIE
created_at: 2026-03-28T10:01:10.019Z
reply_type: partial_coverage
trace_id: LXGUy28KlYl2Qo
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 31. user
message_id: pending
created_at: pending
reply_type: n/a
Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
## 32. assistant
message_id: msg--Vpy-Cp6pM
created_at: 2026-03-28T10:01:10.187Z
reply_type: partial_coverage
trace_id: mvkZgtcMpiuQvm
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 33. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
## 34. assistant
message_id: msg-0vTifSkyW4
created_at: 2026-03-28T10:01:10.457Z
reply_type: partial_coverage
trace_id: HlJPhZ6nPy7yHy
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- close_contradicted; close_completed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: 148 050, 27 954,50, 5 786,63, 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 35. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
## 36. assistant
message_id: msg-IjcNpF1inx
created_at: 2026-03-28T10:01:10.622Z
reply_type: partial_coverage
trace_id: 4mLTN2tj3ijPle
Коротко: Приоритет ответа: развести доказано и гипотезу. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Здесь честно разводится что уже подтверждено и что пока остается гипотезой.
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Сила вывода оценена по прямой опоре, а не по догадкам.
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2.
- В опоре использованы якоря вопроса: 2020, period:2020. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
- Якоря из вопроса без прямого подтверждения: 5 000.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
- Canonical output ограничен доменным runtime-контрактом.
## 37. user
message_id: pending
created_at: pending
reply_type: n/a
31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
## 38. assistant
message_id: msg-oEVgxoW0l3
created_at: 2026-03-28T10:01:10.824Z
reply_type: partial_coverage
trace_id: yirYMT4Nq9-rYR
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
- close_contradicted; close_completed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1, R2. Что проверить первым:
- Проверьте связку документов и проводок по проблемному участку в указанном периоде. Ограничения:
- Якоря из вопроса без прямого подтверждения: 2 471,52, 2 465,28, 849,83.
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
## 39. user
message_id: pending
created_at: pending
reply_type: n/a
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
## 40. assistant
message_id: msg-agMC3ju8S2
created_at: 2026-03-28T10:01:10.999Z
reply_type: partial_coverage
trace_id: gD0YQgAeODxcQ1
Коротко: Проблема в контуре закрытия месяца подтверждается частично. Что сломано:
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
- Ожидаемая цепочка списания выглядит незавершенной.
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
- Проверены связанные документы и проводки по 6 источникам.
- Есть связка между основным выводом и подтверждающими записями.
- Опора есть, но достаточна только для предварительного вывода.
- Подтверждено по требованиям: R1. Что проверить первым:
- Проверьте накопление и распределение затрат по счетам 20-44 перед закрытием месяца.
- Сверьте регламентную операцию закрытия и остатки, которые должны быть нулевыми или объясненными. Ограничения:
- Связка между источниками подтверждена частично.
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
- Вывод сделан по snapshot и может не включать часть цепочки.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/README.md
+34
View File
@@ -0,0 +1,34 @@
# Wave 14 Run
## Scope
- Stage 4, Wave 14: Domain Regression Rollback + Domain-Locked Anchor Usage.
- Scope remained inside the same 3 P0 domains.
- Objective: remove Wave 13 domain regression while keeping anchor-grounding and anti-generic gains.
## Implemented
- Strengthened account extraction and month-close lexical gating in `assistantDataLayer` to prevent accidental domain drift from date/amount noise.
- Added domain-safe account pair extraction (`60/62`, `20/44`) and high-signal suffix account parsing (`97-му`, etc.).
- Added domain hints propagation from retrieval summary into problem-unit assembly (`problemUnitAssembler`).
- Added explicit lifecycle domain-hint priority in `lifecycleRuntime` so explicit domain lock is stronger than noisy cross-domain markers.
- Preserved Wave 13 anchor usage and question-type layers while decoupling them from primary domain selection.
## Validation
- Full backend suite: PASS
- Build: PASS
- Chat20 rerun: completed (`wave13-chat20-1774692067716`)
## Chat20 Snapshot
- total cases: 20
- PASS: 1
- SOFT_PASS: 11
- FAIL: 8
- domain_correctness_rate: 0.90
- question_type_fit_rate: 0.50
- company_anchor_usage_rate: 1.00 (0.50 global)
- generic_answer_rate: 0.35
- first_check_relevance_rate: 0.65
## Notes
- Core Wave 14 blocker (`wrong_domain`) is substantially reduced vs Wave 13 and baseline-restored above Wave 12.
- Remaining gaps are mostly `wrong_question_type` and `wrong_first_check` on VAT-heavy and broad prompts.
- Wave 14 is accepted with limitations; next narrow step should target question-type contract and first-check relevance recovery without reopening runtime scope.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/benchmark_report_before_after.md
+17
View File
@@ -0,0 +1,17 @@
# Benchmark Before/After
## Metrics Delta (Chat20)
| metric | Wave 12 baseline | Wave 13 | Wave 14 | delta W13 -> W14 | delta W12 -> W14 |
|---|---:|---:|---:|---:|---:|
| domain_correctness_rate | 0.70 | 0.25 | 0.90 | +0.65 | +0.20 |
| question_type_fit_rate | 0.65 | 0.45 | 0.50 | +0.05 | -0.15 |
| company_anchor_usage_rate | 0.40 | 1.00 | 1.00 | +0.00 | +0.60 |
| generic_answer_rate | 1.00 | 0.60 | 0.35 | -0.25 | -0.65 |
| first_check_relevance_rate | 0.75 | 0.85 | 0.65 | -0.20 | -0.10 |
## Verdict
- Domain rollback objective: achieved.
- Anchor-grounding objective: preserved.
- Anti-generic objective: improved.
- Remaining limitations: question-type fit and first-check relevance.
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/chat20_wave14_raw.json
+165921
View File
File diff suppressed because it is too large Load Diff
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/prompt_dialogs/chat20_prompts.md
+39
View File
@@ -0,0 +1,39 @@
1. Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
2. Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
3. По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
4. Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
5. Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
6. Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
7. Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
8. Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
9. 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
10. По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
11. 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
12. Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
13. Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
14. Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
15. Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
16. Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
17. 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
18. 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
19. 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
20. После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/run_summary.json
+81
View File
@@ -0,0 +1,81 @@
{
"schema_version": "wave14_run_summary_v1",
"run_id": "2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage",
"wave": "Wave 14",
"stage": "Stage 4",
"status": "IMPLEMENTED_ACCEPTED_WITH_LIMITATIONS",
"scope": {
"domains_in_scope": [
"settlements_60_62",
"vat_document_register_book",
"month_close_costs_20_44"
],
"focus": [
"domain_selection",
"domain_locked_answer_synthesis",
"anchor_usage_without_domain_override",
"month_close_activation_gating",
"domain_preservation_vs_wave12"
],
"out_of_scope": [
"new domains",
"graph expansion",
"stage5 investigation engine",
"stage6 live verification layer",
"transport/base routing refactor"
]
},
"changed_files": [
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\assistantDataLayer.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\lifecycleRuntime.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\problemUnitAssembler.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\assistantService.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\answerComposer.ts",
"X:\\1C\\NDC_1C\\llm_normalizer\\backend\\src\\services\\questionTypeResolver.ts"
],
"checks": {
"full_backend_suite": {
"command": "npm.cmd test",
"result": "PASS"
},
"build": {
"command": "npm.cmd run build",
"result": "PASS"
}
},
"chat20_run": {
"session_id": "wave13-chat20-1774692067716",
"questions_total": 20,
"useMock": true,
"artifacts": {
"chat": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\Chat20.txt",
"chat_ru": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\Чат20.txt",
"raw": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\chat20_wave14_raw.json",
"case_matrix": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\wave14_chat20_case_matrix_updated.md",
"metrics": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\wave14_chat20_metrics.json",
"report": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\wave14_regression_report.md",
"benchmark": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\benchmark_report_before_after.md",
"prompt_dialogs": "X:\\1C\\NDC_1C\\llm_normalizer\\docs\\runs\\2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage\\prompt_dialogs"
}
},
"metrics_snapshot": {
"domain_correctness_rate": 0.9,
"question_type_fit_rate": 0.5,
"company_anchor_usage_rate": 1.0,
"company_anchor_usage_rate_global": 0.5,
"generic_answer_rate": 0.35,
"first_check_relevance_rate": 0.65,
"totals": {
"pass": 1,
"soft_pass": 11,
"fail": 8
}
},
"baseline_comparison": {
"wave12_domain_correctness_rate": 0.7,
"wave13_domain_correctness_rate": 0.25,
"wave14_domain_correctness_rate": 0.9,
"wrong_domain_collapsed_to_month_close": "resolved_from_mass_failure"
},
"verdict": "WAVE14_ACCEPTED_WITH_LIMITATIONS"
}
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/wave14_chat20_case_matrix_updated.md
+25
View File
@@ -0,0 +1,25 @@
# Wave 13 Chat20 Case Matrix (Updated)
| case_id | question_short | expected_domain | actual_domain | expected_question_type | actual_question_type | company_anchors_present | company_anchors_used_in_answer | evidence_strength | answer_confidence_style | first_check_relevance | verdict | failure_reason_short |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| q01 | Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | true | true | weak | mixed | true | SOFT_PASS | generic_answer |
| q02 | Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июл... | settlements_60_62 | settlements_60_62 | prove_or_guess | why_breaks | true | true | weak | mixed | true | SOFT_PASS | wrong_question_type, generic_answer |
| q03 | По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реали... | settlements_60_62 | settlements_60_62 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | SOFT_PASS | generic_answer |
| q04 | Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | true | true | weak | mixed | true | SOFT_PASS | generic_answer |
| q05 | Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в догово... | settlements_60_62 | settlements_60_62 | where_break_is | where_break_is | true | true | strong | mixed | true | SOFT_PASS | generic_answer |
| q06 | Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно б... | settlements_60_62 | settlements_60_62 | prove_or_guess | prove_or_guess | false | false | strong | mixed | false | FAIL | wrong_first_check |
| q07 | Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот об... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | false | false | strong | mixed | true | SOFT_PASS | generic_answer |
| q08 | Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет? | settlements_60_62 | settlements_60_62 | which_chains_are_complete_vs_incomplete | why_breaks | false | false | strong | mixed | true | SOFT_PASS | wrong_question_type, generic_answer |
| q09 | 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас по... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | why_breaks | false | false | strong | mixed | false | FAIL | wrong_question_type, wrong_first_check |
| q10 | По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже ... | vat_document_register_book | settlements_60_62 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | FAIL | wrong_domain |
| q11 | 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга п... | vat_document_register_book | vat_document_register_book | why_breaks | why_breaks | true | true | strong | mixed | false | FAIL | wrong_first_check |
| q12 | Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, и... | vat_document_register_book | vat_document_register_book | prove_or_guess | why_breaks | false | false | strong | mixed | false | FAIL | wrong_question_type, wrong_first_check |
| q13 | Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно? | vat_document_register_book | settlements_60_62 | why_breaks | prove_or_guess | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_question_type, wrong_first_check |
| q14 | Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-факту... | vat_document_register_book | vat_document_register_book | what_is_it_grounded_on | why_breaks | false | false | strong | mixed | true | SOFT_PASS | wrong_question_type |
| q15 | Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными? | vat_document_register_book | vat_document_register_book | why_breaks | why_breaks | false | false | strong | mixed | false | FAIL | wrong_first_check |
| q16 | Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | prove_or_guess | false | false | strong | mixed | false | FAIL | wrong_question_type, wrong_first_check |
| q17 | 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и дру... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | why_breaks | true | true | strong | mixed | true | SOFT_PASS | wrong_question_type |
| q18 | 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБ... | month_close_costs_20_44 | month_close_costs_20_44 | what_is_it_grounded_on | prove_or_guess | true | true | strong | mixed | true | SOFT_PASS | wrong_question_type |
| q19 | 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объек... | month_close_costs_20_44 | month_close_costs_20_44 | why_breaks | why_breaks | true | true | strong | mixed | true | PASS | none |
| q20 | После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых резу... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | why_breaks | false | false | strong | mixed | true | SOFT_PASS | wrong_question_type |
docs/HARD_SEMANTIC/runs/2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage/wave14_chat20_metrics.json
+34
View File
@@ -0,0 +1,34 @@
{
"schema_version": "wave13_chat20_metrics_v2",
"run_id": "2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage",
"source_session_id": "wave13-chat20-1774692067716",
"totals": {
"cases": 20,
"pass": 1,
"soft_pass": 11,
"fail": 8
},
"domain_correctness_rate": 0.9,
"question_type_fit_rate": 0.5,
"company_anchor_usage_rate": 1,
"company_anchor_usage_rate_global": 0.5,
"generic_answer_rate": 0.35,
"first_check_relevance_rate": 0.65,
"anchors_present_cases": 10,
"anchors_used_cases": 10,
"baseline_reference": "wave12_chat20_metrics.json",
"baseline_metrics": {
"domain_correctness_rate": 0.7,
"question_type_fit_rate": 0.65,
"company_anchor_usage_rate": 0.4,
"generic_answer_rate": 1,
"first_check_relevance_rate": 0.75
},
"delta_vs_baseline": {
"domain_correctness_rate_delta": 0.2,
"question_type_fit_rate_delta": -0.15,
"company_anchor_usage_rate_delta": 0.6,
"generic_answer_rate_delta": -0.65,
"first_check_relevance_rate_delta": -0.1
}
}

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