Этап 4 / Волна 18 закрытие блокеров по времени, доменной полярности и допуску доказательной базы
This commit is contained in:
+109
@@ -0,0 +1,109 @@
|
||||
# 7 - assistant_runtime_ground_truth_audit_2026-03-28
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Status: `COMPLETED`
|
||||
|
||||
Final verdict: `MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`
|
||||
|
||||
Why this verdict:
|
||||
- The runtime path is technically complete and traceable end-to-end.
|
||||
- But evidence admissibility and mechanism discrimination are not strict enough for reliable accounting-grade grounding.
|
||||
- Multiple control traces still show temporal drift, domain polarity drift, and weak evidence admitted into claim support.
|
||||
|
||||
Primary evidence used in this audit:
|
||||
- `audit_artifacts/raw_traces/chat20_wave15_raw.json`
|
||||
- `audit_artifacts/raw_traces/1.txt`
|
||||
- `audit_artifacts/raw_traces/2.txt`
|
||||
- `audit_artifacts/live_calls/wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `audit_artifacts/live_calls/hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `audit_artifacts/snapshot_inspection/snapshot_2020_export_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/monthly_asof_ndjson_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/runtime_snapshot_wiring.md`
|
||||
|
||||
## 2. Scope And Constraints
|
||||
|
||||
Scope:
|
||||
- Stage 4 runtime in P0 accounting domains.
|
||||
- Full path verification: question -> normalization/router -> route -> retrieval -> evidence/problem units -> answer.
|
||||
- Control focus: settlement / VAT / month-close core questions.
|
||||
|
||||
Constraints followed:
|
||||
- No redesign in this audit.
|
||||
- No architectural rewrite in this audit.
|
||||
- No declarative conclusions without trace/code evidence.
|
||||
|
||||
## 3. Verified Runtime Architecture
|
||||
|
||||
Status: `verified` for call chain presence, `partially verified` for semantic correctness.
|
||||
|
||||
See: `7A - runtime_call_graph.md`.
|
||||
|
||||
## 4. Snapshot Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Runtime is wired to `docs/ARCH/2020экспорт` sample JSONs (422 total records across runtime-used files).
|
||||
- `docs/ARCH/2020_monthly_company_asof_full` exists (~7.06 GB NDJSON), but is not wired into backend runtime retrieval path.
|
||||
|
||||
See: `7B - snapshot_inventory_and_coverage.md`.
|
||||
|
||||
## 5. MCP/Live Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Live call summaries are present and can be traced per `trace_id`.
|
||||
- In critical traces (`ty6aQD9O0LnTvg`, `-PdAdyMXYlf23K`) `matched_rows = 0` but `returned_rows = 12` and weakly-mapped evidence is still admitted into answer evidence block.
|
||||
|
||||
See: `7C - live_mcp_call_inventory.md`.
|
||||
|
||||
## 6. Evidence Acquisition Reality
|
||||
|
||||
Status: `not verified` for strict proof-first guarantees.
|
||||
|
||||
Key failures:
|
||||
- Temporal anchor drift: `q01` (Wave 15) normalized to `2019` for a July 2020 scenario; `ty6aQD9O0LnTvg` normalized to `2023-07-06`.
|
||||
- Domain polarity drift: settlement cases mapped to `customer_settlement` lifecycle (`stale_receivable -> receivable_closed`) in supplier/payable contexts.
|
||||
- Evidence admissibility drift: weak mappings and out-of-window years (2023/2025/2026/2030) included in evidence refs for July 2020 snapshot scenarios.
|
||||
|
||||
See: `7D - control_question_trace_matrix.md` and `7E - structural_gap_register.md`.
|
||||
|
||||
## 7. Answer Synthesis Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Answer contract structure is present (`direct_answer`, `mechanism_block`, `evidence_block`, `uncertainty_block`, `next_step_block`).
|
||||
- But mechanism discrimination is often weak: Wave 15 matrix marks multiple settlement core cases as `SOFT_PASS / generic_answer`.
|
||||
|
||||
## 8. Control Question Audit
|
||||
|
||||
Status: `completed`
|
||||
|
||||
Core 8 matrix is populated with trace-backed rows.
|
||||
|
||||
See: `7D - control_question_trace_matrix.md`.
|
||||
|
||||
## 9. Structural Gaps
|
||||
|
||||
Status: `completed`
|
||||
|
||||
Gap register with severity and acceptance criteria is added.
|
||||
|
||||
See: `7E - structural_gap_register.md`.
|
||||
|
||||
## 10. Minimum Required Architectural Correction (Stage 4 Close Criteria)
|
||||
|
||||
Minimum mandatory correction layer before Stage 4 close:
|
||||
1. Temporal hard lock for fixed company snapshot windows (no relative/default-year override).
|
||||
2. Supplier/customer polarity guard (`60/supplier/payable` vs `62/customer/receivable`) at routing/problem-unit level.
|
||||
3. Evidence admissibility gate (`matched_rows = 0`, weak mapping, out-of-window dates, account-scope mismatch).
|
||||
4. Mechanism-specific answer contract (single dominant mechanism + explicit exclusion rationale).
|
||||
|
||||
## 11. What Not To Do Next
|
||||
|
||||
- Do not treat wording improvements as proof-layer closure.
|
||||
- Do not declare Stage 4 closed only from controlled-chat aggregate metrics.
|
||||
- Do not postpone admissibility/polarity/temporal guards to later ontology waves.
|
||||
@@ -0,0 +1,21 @@
|
||||
# 7A - runtime_call_graph
|
||||
|
||||
## Runtime Steps (Code + Trace Evidence)
|
||||
|
||||
| Step | Runtime block | Code evidence | Trace evidence | Verification |
|
||||
|---|---|---|---|---|
|
||||
| S1 | API ingress | `backend/src/routes/assistant.ts` (`POST /api/assistant/message`, calls `assistantService.handleMessage`) | conversation exports contain per-turn `trace_id` and timestamps | verified |
|
||||
| S2 | Follow-up binding | `backend/src/services/assistantService.ts` (`buildFollowupStateBinding`, around line 992) | investigation snapshot fields visible in exported debug payloads | partially verified |
|
||||
| S3 | Normalization/router | `assistantService.ts` uses normalizer output and route summary | payload contains `route_summary`, `fragments`, `question_type_class` | verified |
|
||||
| S4 | Execution plan | `assistantService.ts` `toExecutionPlan` (around line 339), invoked in main flow | payload has per-fragment `route` and `route_status` | verified |
|
||||
| S5 | Retrieval runtime | `backend/src/services/assistantDataLayer.ts` `executeRouteRuntime` (around line 2520) | payload `retrieval_results` present per fragment | verified |
|
||||
| S6 | Live overlay merge | `assistantDataLayer.ts` merges `live_mcp` into `summary` (around line 2550-2552) | traces show `live_mcp.fetched_rows/matched_rows/returned_rows` | verified |
|
||||
| S7 | Coverage + grounding checks | `assistantService.ts` `evaluateCoverage`/`checkGrounding` (around lines 1255-1271) | payload has `coverage_report` and `answer_grounding_check` | verified |
|
||||
| S8 | Answer composition | `assistantService.ts` calls `composeAssistantAnswer`; sanitization barriers around line 1282 | payload has `answer_structure_v11`; user-facing reply type persisted | verified |
|
||||
| S9 | Investigation state update | `backend/src/services/investigationState.ts` used in service flow | `investigation_state_snapshot` present in debug payload | partially verified |
|
||||
| S10 | Debug/export persistence | `assistantService.ts` emits debug payload fields and export-safe response | raw exports (`1.txt`,`2.txt`) include full technical blocks | verified |
|
||||
|
||||
## Notes
|
||||
|
||||
- Call chain existence is verified.
|
||||
- Semantic correctness of interpretation/evidence is not guaranteed by call-chain verification alone and is audited in `7C/7D/7E`.
|
||||
@@ -0,0 +1,43 @@
|
||||
# 7B - snapshot_inventory_and_coverage
|
||||
|
||||
## Snapshot Inventory (Observed)
|
||||
|
||||
### Runtime-wired snapshot source (`docs/ARCH/2020экспорт`)
|
||||
|
||||
| File | Bytes | Records | Runtime wired |
|
||||
|---|---:|---:|---|
|
||||
| `03_snapshot_fragment_problem_cases.json` | 302,520 | 80 | yes |
|
||||
| `04_samples_SpisanieSRaschetnogoScheta.json` | 196,178 | 27 | yes |
|
||||
| `05_samples_RealizaciyaTovarovUslug.json` | 132,032 | 5 | yes |
|
||||
| `06_samples_PostuplenieTovarovUslug.json` | 181,409 | 10 | yes |
|
||||
| `07_samples_DocumentJournals.json` | 292,931 | 80 | yes |
|
||||
| `08_samples_NDS_registers.json` | 291,547 | 80 | yes |
|
||||
| `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json` | 511,133 | 140 | yes |
|
||||
| **Total** | **1,907,750** | **422** | |
|
||||
|
||||
Code proof:
|
||||
- `backend/src/config.ts`: `ARCH_EXPORT_2020_DIR`.
|
||||
- `backend/src/services/assistantDataLayer.ts`: `ensureData()` reads files 03/04/05/06/07/08/09.
|
||||
|
||||
### Monthly as-of corpus (`docs/ARCH/2020_monthly_company_asof_full/_tmp_ndjson`)
|
||||
|
||||
| Asset | Value |
|
||||
|---|---|
|
||||
| NDJSON files | 12 (`snapshot_2020-01` ... `snapshot_2020-12`) |
|
||||
| Total size | 7,059,009,054 bytes (~7.06 GB) |
|
||||
| Runtime wired in backend path | no direct reference found |
|
||||
|
||||
## Coverage Reality
|
||||
|
||||
| Question class | Snapshot-only coverage | Reality |
|
||||
|---|---|---|
|
||||
| Settlement chain diagnostics | partial | Works for sample-level hints, but temporal/polarity drift still appears in traces |
|
||||
| VAT document-register-book chain | partial to good | Better in VAT-specific cases, but cross-domain contamination still occurs in mixed traces |
|
||||
| Month-close / RBP diagnostics | partial to good | Core traces exist, but still often `partial_coverage` with weak-confidence qualifiers |
|
||||
| Strict as-of monthly proof | not covered | Large monthly corpus exists, but runtime retrieval path is not wired to it |
|
||||
|
||||
## Audit Artifacts
|
||||
|
||||
- `audit_artifacts/snapshot_inspection/snapshot_2020_export_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/monthly_asof_ndjson_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/runtime_snapshot_wiring.md`
|
||||
@@ -0,0 +1,30 @@
|
||||
# 7C - live_mcp_call_inventory
|
||||
|
||||
## Live Call Matrix (Trace-backed)
|
||||
|
||||
| Trace ID | Question type | `matched_rows` | `returned_rows` | Account scope | Key observation | Verification value |
|
||||
|---|---|---:|---:|---|---|---|
|
||||
| `ty6aQD9O0LnTvg` | `why_breaks` | 0 | 12 | `60` | Settlement trace still carries `customer_settlement` units; evidence years include 2023/2025/2026/2030; evidence account context contains `60`, `68.02`, `19.04` | low |
|
||||
| `-PdAdyMXYlf23K` | `what_is_it_grounded_on` | 0 | 12 | `60` | Same admissibility issue pattern as above with weak mapping admitted | low |
|
||||
| `4D6ALjsjEDHlL1` | `which_chains_are_complete_vs_incomplete` | 24 | 12 | empty | Live match exists, but weak mapping count remains high and evidence years include outlier (`2086`) | medium |
|
||||
| `8zDUwtS3MOHUYQ` | `prove_or_guess` | 24 | 12 | empty | Live match exists, but same weak-source pattern persists | medium |
|
||||
| `kFr2noz4jZ801u` | `why_breaks` | 24 | 12 | empty | Month-close interpretation with broad account contexts mixed into evidence set | medium |
|
||||
| `YcYGBW0Fqpd3Au` | `prove_or_guess` | 24 | 12 | empty | Similar period-close pattern; admissibility gate still permissive | medium |
|
||||
|
||||
## Specific Acceptance Checks
|
||||
|
||||
1. `matched_rows = 0` should prevent live evidence from strengthening claims.
|
||||
- Result: **not satisfied** (see `ty6aQD9O0LnTvg`, `-PdAdyMXYlf23K`).
|
||||
|
||||
2. Weak mapping should remain limitation-only, not claim-supporting evidence.
|
||||
- Result: **not satisfied** (weak-mapped refs still present in evidence blocks).
|
||||
|
||||
3. Cross-domain contamination should be blocked for settlement claims.
|
||||
- Result: **not satisfied** (VAT accounts `68.02/19.04` appear in settlement-oriented hard-fail trace context).
|
||||
|
||||
## Audit Artifacts
|
||||
|
||||
- `audit_artifacts/live_calls/wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `audit_artifacts/live_calls/hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `audit_artifacts/raw_traces/1.txt`
|
||||
- `audit_artifacts/raw_traces/2.txt`
|
||||
@@ -0,0 +1,29 @@
|
||||
# 7D - control_question_trace_matrix
|
||||
|
||||
## Core 8 Matrix (Filled)
|
||||
|
||||
| Case ID | Mapped source case | Trace ID | Route selected | Snapshot sources used | Live calls used | Primary interpretation | Evidence basis | Claim status | Answer type | Verification |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Q1 | `q01` (payment 55,200 tail) | `pz7NdUwSCPV_JL` | `hybrid_store_plus_live` | `problemCases,keyFields,docs` | not explicit in this export | `customer_settlement` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `why_breaks` | partially verified (temporal anchor drift) |
|
||||
| Q2 | `q02` (advance offset 276,873.60) | `HIQhphOlB4zfX_` | `hybrid_store_plus_live` | `problemCases,keyFields,docs` | not explicit in this export | `customer_settlement` | candidate evidence: 2; problem units: 1 | `partial_coverage` | `prove_or_guess` | partially verified (polarity risk) |
|
||||
| Q3 | `q03` (40,860 / 20,000 semantics) | `mMgTQT2ujRmX6F` | `hybrid_store_plus_live` | `keyFields,journals,docs` | not explicit in this export | `bank_settlement` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | partially verified (classification instability) |
|
||||
| Q4 | `q11` (VAT invoice 233.33 chain) | `vu46dXSfvmn6hf` | `store_canonical` | `ndsRegisters,keyFields,docs` | no | `vat_flow` | candidate evidence: 6; problem units: 6 | `partial_coverage` | `why_breaks` | verified |
|
||||
| Q5 | `q13` (July purchases with partial VAT contour) | `0Q3E5aD5mJP1d7` | `batch_refresh_then_store` | not locked by domain card | unclear | `bank_settlement` (expected VAT) | candidate evidence: 5; problem units: 5 | `factual_with_explanation` | `why_breaks` | not verified (wrong domain) |
|
||||
| Q6 | `q17` (month-close indirect costs tail) | `NDst4BruRfYAB3` | `hybrid_store_plus_live` | `problemCases,docs,journals,keyFields` | not explicit in this export | `period_close` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | verified |
|
||||
| Q7 | `q18` (RBP stale tail) | `UG5L7JqS3cyXU2` | `store_canonical` | `docs,journals,keyFields` | no | `period_close` | candidate evidence: 6; problem units: 6 | `partial_coverage` | `what_is_it_grounded_on` | verified |
|
||||
| Q8 | `q20` (limitation honesty after month-end) | `4F7HdHzqV2v1Ir` | `hybrid_store_plus_live` | `problemCases,docs,journals,keyFields` | not explicit in this export | `period_close` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | partially verified |
|
||||
|
||||
## Additional Hard-Fail Supporting Trace
|
||||
|
||||
- `ty6aQD9O0LnTvg` (Wave 16 export debug):
|
||||
- `time_scope = 2023-07-06` for a July 2020 settlement scenario.
|
||||
- `live_mcp.matched_rows = 0`, `returned_rows = 12`.
|
||||
- problem-unit lifecycle domain: `customer_settlement:9`.
|
||||
- evidence refs include out-of-window years (2023/2025/2026/2030).
|
||||
|
||||
## Source Artifacts
|
||||
|
||||
- `audit_artifacts/raw_traces/wave15_chat20_case_matrix_updated.md`
|
||||
- `audit_artifacts/raw_traces/wave15_core_cases_q01_q02_q11_q17_q18_q20.json`
|
||||
- `audit_artifacts/debug_payloads/wave15_*.debug.json`
|
||||
- `audit_artifacts/debug_payloads/wave16_export_ty6aQD9O0LnTvg.debug.json`
|
||||
@@ -0,0 +1,25 @@
|
||||
# 7E - structural_gap_register
|
||||
|
||||
## Purpose
|
||||
|
||||
Реестр structural gaps между декларируемой архитектурой и фактическим runtime.
|
||||
|
||||
## Gap Register
|
||||
|
||||
| Gap ID | Gap Title | Description | Severity | Evidence | Affected Steps | Recommended Minimal Correction | Status |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| GAP-01 | Mandatory proof acquisition step missing or weak | TBD | blocker | TBD | TBD | TBD | open |
|
||||
| GAP-02 | Early interpretation before sufficient facts | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-03 | Weak/inadmissible evidence enters grounded answer | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-04 | Snapshot completeness mismatch for control questions | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-05 | MCP/live acts as weak enrichment not verification | TBD | medium | TBD | TBD | TBD | open |
|
||||
|
||||
## Severity Scale
|
||||
|
||||
- `blocker`
|
||||
- `high`
|
||||
- `medium`
|
||||
|
||||
## Notes
|
||||
|
||||
Каждая строка должна иметь конкретные trace/code ссылки.
|
||||
@@ -0,0 +1,20 @@
|
||||
# 7F - instrumentation_notes
|
||||
|
||||
## Instrumentation Change Log (This Audit)
|
||||
|
||||
| Change ID | File/Module | What added | Why | Runtime risk | Revert plan | Status |
|
||||
|---|---|---|---|---|---|---|
|
||||
| INST-00 | runtime code | no runtime instrumentation code added | audit was evidence-first from existing traces/exports | none | n/a | completed |
|
||||
| INST-01 | audit artifacts only | extraction/packaging of existing debug payloads and trace summaries into `audit_artifacts/` | provide process-log-grade proof pack | none (offline processing) | delete audit artifacts if not needed | completed |
|
||||
|
||||
## Captured Through Existing Runtime Exports
|
||||
|
||||
- route selection and route status per fragment
|
||||
- normalized fragments, time scope, business scope
|
||||
- retrieval summary and problem-unit stats
|
||||
- live MCP summary (`fetched_rows`, `matched_rows`, `returned_rows`, `account_scope`)
|
||||
- answer structure blocks with evidence and limitations
|
||||
|
||||
## Note
|
||||
|
||||
This audit intentionally avoided changing runtime behavior. All conclusions are based on already produced runtime outputs and code-path inspection.
|
||||
@@ -0,0 +1,25 @@
|
||||
# audit_artifacts
|
||||
|
||||
Evidence pack for Stage 4 runtime ground-truth audit.
|
||||
|
||||
## Subfolders
|
||||
|
||||
- `raw_traces/`
|
||||
- copied raw exports (`1.txt`, `2.txt`), Wave15 raw chat export, case matrix
|
||||
- extracted subset: `wave15_core_cases_q01_q02_q11_q17_q18_q20.json`
|
||||
- `debug_payloads/`
|
||||
- per-case debug payload JSON (Wave15 core + Wave16 export traces)
|
||||
- `dialogs/`
|
||||
- `wave15_core_control_dialogs.md`
|
||||
- `live_calls/`
|
||||
- `wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `snapshot_inspection/`
|
||||
- runtime snapshot inventory and monthly NDJSON inventory
|
||||
- runtime wiring note
|
||||
- `diagrams/`
|
||||
- reserved for optional visual diagrams
|
||||
|
||||
## Rule
|
||||
|
||||
Every artifact must remain traceable to `case_id` and/or `trace_id`.
|
||||
+7150
File diff suppressed because it is too large
Load Diff
+2524
File diff suppressed because it is too large
Load Diff
+11289
File diff suppressed because it is too large
Load Diff
+17506
File diff suppressed because it is too large
Load Diff
+6371
File diff suppressed because it is too large
Load Diff
+9125
File diff suppressed because it is too large
Load Diff
+4407
File diff suppressed because it is too large
Load Diff
+10229
File diff suppressed because it is too large
Load Diff
+10226
File diff suppressed because it is too large
Load Diff
+22960
File diff suppressed because it is too large
Load Diff
+22943
File diff suppressed because it is too large
Load Diff
+4367
File diff suppressed because it is too large
Load Diff
+175
@@ -0,0 +1,175 @@
|
||||
# Core Control Dialogs (Wave 15)
|
||||
|
||||
## q01 | trace: pz7NdUwSCPV_JL
|
||||
|
||||
### user
|
||||
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
|
||||
|
||||
### assistant
|
||||
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
|
||||
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
|
||||
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
|
||||
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1.
|
||||
- В опоре использованы якоря вопроса: 2019, period:2019. Что проверить первым:
|
||||
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
|
||||
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
|
||||
- Якоря из вопроса без прямого подтверждения: договор № 01/19-ПТ, 09.01.2019, 09.01, 55 200.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- (account_55),.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:41.201Z
|
||||
|
||||
## q02 | trace: HIQhphOlB4zfX_
|
||||
|
||||
### user
|
||||
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Переход от оплаты к закрытию расчета не подтвержден.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 2 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 1 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора частичная: часть требований покрыта не полностью.
|
||||
- Подтверждено по требованиям: R1. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Отдельно отметьте, что доказано документами и проводками, а что остается гипотезой.
|
||||
- Для доказательства проверьте связку платеж -> расчетный документ -> регистр расчетов -> 60/62/76.
|
||||
- Проверьте договор и объект расчетов по платежу/зачету.
|
||||
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 07.07.20, 07.07, 276 873,60, 62.02.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- (account_13, account_62.02),.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:41.412Z
|
||||
|
||||
## q11 | trace: vu46dXSfvmn6hf
|
||||
|
||||
### user
|
||||
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
|
||||
|
||||
### assistant
|
||||
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
|
||||
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
|
||||
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
|
||||
- Якоря из вопроса без прямого подтверждения: 1 166,67, 233,33.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- Canonical output ограничен доменным runtime-контрактом.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:42.818Z
|
||||
|
||||
## q17 | trace: NDst4BruRfYAB3
|
||||
|
||||
### user
|
||||
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- close_contradicted; close_completed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Разделите доказанные и предположительные участки в цепочке закрытия месяца.
|
||||
- Проверьте подтверждение: операция закрытия -> распределение -> остатки по 20/25/26/44. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 148 050, 27 954,50, 5 786,63, 5 000.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:43.820Z
|
||||
|
||||
## q18 | trace: UG5L7JqS3cyXU2
|
||||
|
||||
### user
|
||||
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
|
||||
|
||||
### assistant
|
||||
Коротко: Ниже перечислены основания вывода по данным учета. Что сломано:
|
||||
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Фокус ответа смещен в доказательные источники, а не в общий narrative.
|
||||
- Ожидаемая цепочка списания выглядит незавершенной.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- В этом ответе в приоритете показаны именно основания вывода.
|
||||
- Основание вывода перечислено по подтвержденным документам, регистрам и проводкам.
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Сначала перечислите опорные документы и регистры, затем подтверждающие проводки.
|
||||
- Перечислите основание: операция закрытия, база распределения, проводки по затратам, остатки после закрытия. Ограничения:
|
||||
- В основание включены только подтвержденные источники; неподтвержденные вынесены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 5 000.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- Canonical output ограничен доменным runtime-контрактом.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:43.983Z
|
||||
|
||||
## q20 | trace: 4F7HdHzqV2v1Ir
|
||||
|
||||
### user
|
||||
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Ожидаемая цепочка списания выглядит незавершенной.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Разделите доказанные и предположительные участки в цепочке закрытия месяца.
|
||||
- Проверьте подтверждение: операция закрытия -> распределение -> остатки по 20/25/26/44. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:44.365Z
|
||||
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
# Hard-Fail Trace Note
|
||||
|
||||
trace_id: ty6aQD9O0LnTvg
|
||||
question_type_class: why_breaks
|
||||
route: hybrid_store_plus_live
|
||||
business_scope: generic_accounting
|
||||
time_scope: 2023-07-06
|
||||
account_hints: 60
|
||||
live_mcp.matched_rows: 0
|
||||
live_mcp.returned_rows: 12
|
||||
problem_unit_lifecycle_domain_distribution: customer_settlement:9
|
||||
uncertainty.limitations: Problem units remain weak-confidence; conclusions are intentionally limited. | Source mapping is weak for part of the evidence. | в” snapshot 2020 (read-only), live | Live probe использует ограниченный выборочный read-only запрос к 1С.
|
||||
evidence_source_refs_sample:
|
||||
- evidence_source_ref_v1|unknown|document_%D1%81%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5%D1%81%D1%80%D0%B0%D1%81%D1%87%D0%B5%D1%82%D0%BD%D0%BE%D0%B3%D0%BE%D1%81%D1%87%D0%B5%D1%82%D0%B0|b42999dd-b08e-11ea-a2db-00155d012600|2020-06-16t12%3A00%3A00
|
||||
- evidence_source_ref_v1|unknown|mcplivemovement|hybrid_store_plus_live-mcp-1-2030-08-03t12%3A00%3A00z|2030-08-03t12%3A00%3A00z
|
||||
- evidence_source_ref_v1|unknown|mcplivemovement|hybrid_store_plus_live-mcp-2-2026-03-31t00%3A00%3A00z|2026-03-31t00%3A00%3A00z
|
||||
+237
@@ -0,0 +1,237 @@
|
||||
[
|
||||
{
|
||||
"trace_id": "4D6ALjsjEDHlL1",
|
||||
"question_type_class": "which_chains_are_complete_vs_incomplete",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-13, 2023-07-15",
|
||||
"account_hints": [
|
||||
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"vat_flow": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"19",
|
||||
"68",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2086"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "-PdAdyMXYlf23K",
|
||||
"question_type_class": "what_is_it_grounded_on",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "Рюль 2020",
|
||||
"account_hints": [
|
||||
"60",
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 0,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
"60"
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 10,
|
||||
"problem_units_count": 9,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"customer_settlement": 9
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 10,
|
||||
"evidence_account_context_detected": [
|
||||
"60",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2030",
|
||||
"2026",
|
||||
"2025",
|
||||
"2023"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "kFr2noz4jZ801u",
|
||||
"question_type_class": "why_breaks",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07",
|
||||
"account_hints": [
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"period_close": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"25",
|
||||
"20",
|
||||
"01",
|
||||
"19",
|
||||
"21",
|
||||
"23",
|
||||
"26",
|
||||
"28",
|
||||
"29",
|
||||
"02",
|
||||
"68",
|
||||
"08",
|
||||
"51",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "ty6aQD9O0LnTvg",
|
||||
"question_type_class": "why_breaks",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-06",
|
||||
"account_hints": [
|
||||
"60"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 0,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
"60"
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 10,
|
||||
"problem_units_count": 9,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"customer_settlement": 9
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 10,
|
||||
"evidence_account_context_detected": [
|
||||
"60",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2030",
|
||||
"2026",
|
||||
"2025",
|
||||
"2023"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "8zDUwtS3MOHUYQ",
|
||||
"question_type_class": "prove_or_guess",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-13",
|
||||
"account_hints": [
|
||||
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"vat_flow": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"19",
|
||||
"68",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2086"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "YcYGBW0Fqpd3Au",
|
||||
"question_type_class": "prove_or_guess",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "31 июля",
|
||||
"account_hints": [
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"period_close": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"25",
|
||||
"20",
|
||||
"01",
|
||||
"19",
|
||||
"21",
|
||||
"23",
|
||||
"26",
|
||||
"28",
|
||||
"29",
|
||||
"02",
|
||||
"68",
|
||||
"08",
|
||||
"51",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020"
|
||||
]
|
||||
}
|
||||
]
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
+165921
File diff suppressed because it is too large
Load Diff
+26
@@ -0,0 +1,26 @@
|
||||
# Wave 15 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 | prove_or_guess | true | true | weak | mixed | true | SOFT_PASS | 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 | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | SOFT_PASS | generic_answer |
|
||||
| q09 | 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас по... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | PASS | none |
|
||||
| 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 | true | PASS | none |
|
||||
| q12 | Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, и... | vat_document_register_book | vat_document_register_book | prove_or_guess | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | SOFT_PASS | wrong_question_type |
|
||||
| q13 | Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно? | vat_document_register_book | settlements_60_62 | why_breaks | why_breaks | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_first_check |
|
||||
| q14 | Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-факту... | vat_document_register_book | vat_document_register_book | what_is_it_grounded_on | what_is_it_grounded_on | false | false | strong | mixed | true | PASS | none |
|
||||
| q15 | Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными? | vat_document_register_book | vat_document_register_book | why_breaks | why_breaks | false | false | strong | mixed | true | PASS | none |
|
||||
| q16 | Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | PASS | none |
|
||||
| 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 | prove_or_guess | true | true | strong | mixed | true | PASS | none |
|
||||
| q18 | 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБ... | month_close_costs_20_44 | month_close_costs_20_44 | what_is_it_grounded_on | what_is_it_grounded_on | true | true | strong | mixed | true | PASS | none |
|
||||
| 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 | prove_or_guess | false | false | strong | mixed | true | PASS | none |
|
||||
|
||||
|
||||
+54027
File diff suppressed because it is too large
Load Diff
+53
@@ -0,0 +1,53 @@
|
||||
{
|
||||
"total_bytes": 7059009054,
|
||||
"files": [
|
||||
{
|
||||
"file": "snapshot_2020-01.ndjson",
|
||||
"bytes": 580029464
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-02.ndjson",
|
||||
"bytes": 581189065
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-03.ndjson",
|
||||
"bytes": 583880766
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-04.ndjson",
|
||||
"bytes": 584715096
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-05.ndjson",
|
||||
"bytes": 585503134
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-06.ndjson",
|
||||
"bytes": 588644783
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-07.ndjson",
|
||||
"bytes": 589576497
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-08.ndjson",
|
||||
"bytes": 590584465
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-09.ndjson",
|
||||
"bytes": 592120603
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-10.ndjson",
|
||||
"bytes": 592460410
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-11.ndjson",
|
||||
"bytes": 593521104
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-12.ndjson",
|
||||
"bytes": 596783667
|
||||
}
|
||||
]
|
||||
}
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# Runtime Snapshot Wiring (Code Evidence)
|
||||
|
||||
- backend/src/config.ts: `ARCH_EXPORT_2020_DIR` points to `docs/ARCH/2020экспорт`.
|
||||
- backend/src/services/assistantDataLayer.ts: `ensureData()` reads:
|
||||
- 09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json
|
||||
- 03_snapshot_fragment_problem_cases.json
|
||||
- 07_samples_DocumentJournals.json
|
||||
- 08_samples_NDS_registers.json
|
||||
- 04/05/06 samples for payment/sales/purchase docs
|
||||
- No direct code reference found to `docs/ARCH/2020_monthly_company_asof_full` in backend/src runtime path.
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
[
|
||||
{
|
||||
"file": "03_snapshot_fragment_problem_cases.json",
|
||||
"bytes": 302520,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "04_samples_SpisanieSRaschetnogoScheta.json",
|
||||
"bytes": 196178,
|
||||
"records": 27
|
||||
},
|
||||
{
|
||||
"file": "05_samples_RealizaciyaTovarovUslug.json",
|
||||
"bytes": 132032,
|
||||
"records": 5
|
||||
},
|
||||
{
|
||||
"file": "06_samples_PostuplenieTovarovUslug.json",
|
||||
"bytes": 181409,
|
||||
"records": 10
|
||||
},
|
||||
{
|
||||
"file": "07_samples_DocumentJournals.json",
|
||||
"bytes": 292931,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "08_samples_NDS_registers.json",
|
||||
"bytes": 291547,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json",
|
||||
"bytes": 511133,
|
||||
"records": 140
|
||||
}
|
||||
]
|
||||
+567
@@ -0,0 +1,567 @@
|
||||
execution-pack на закрытие трёх blocker-gap внутри текущего Stage 4.md
|
||||
|
||||
---
|
||||
|
||||
# ТЗ для Codex
|
||||
|
||||
## Stage 4 Blocker Closure Execution Pack — GAP-01 / GAP-02 / GAP-03
|
||||
|
||||
### 1. Контекст
|
||||
|
||||
По итогам архитектурного аудита текущий runtime-контур квалифицирован как:
|
||||
|
||||
**`MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`**
|
||||
|
||||
На этом основании Stage 4 **нельзя считать закрытым по живому reasoning-слою**, пока не сняты три blocker-gap’а:
|
||||
|
||||
* **GAP-01** — temporal anchor / period lock
|
||||
* **GAP-02** — domain polarity (supplier/customer, payable/receivable, 60/62)
|
||||
* **GAP-03** — evidence admissibility / недопустимое evidence в grounded answer
|
||||
|
||||
Важно: текущий execution-pack должен оставаться **в рамках Stage 4 P0-only**, без расширения domain scope, без graph/schema expansion, без втягивания Stage 5/6 как нового core path и без больших transport/routing refactor. Это соответствует зафиксированной рамке Stage 4.
|
||||
|
||||
---
|
||||
|
||||
## 2. Цель execution-pack
|
||||
|
||||
Не строить новую архитектуру и не делать “proof engine целиком”, а **снять три blocker-а**, из-за которых текущий ответный слой:
|
||||
|
||||
* искажает период,
|
||||
* путает бухгалтерскую полярность,
|
||||
* использует нерелевантное или слабое evidence как основание ответа.
|
||||
|
||||
Итогом должно стать:
|
||||
|
||||
1. корректное temporal grounding на company snapshot July 2020;
|
||||
2. корректная supplier/customer polarity на P0-доменах;
|
||||
3. жёсткий admissibility gate для evidence;
|
||||
4. trace-backed rerun, подтверждающий снятие blocker-gap’ов.
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
### Входит в scope
|
||||
|
||||
* только P0-домены:
|
||||
|
||||
* `settlements_60_62`
|
||||
* `vat_document_register_book`
|
||||
* `month_close_costs_20_44`
|
||||
* runtime logic:
|
||||
|
||||
* normalizer / router
|
||||
* domain profile selection
|
||||
* retrieval → live/snapshot evidence handoff
|
||||
* answer composer guards
|
||||
* debug/export traces
|
||||
* harness / regression / run artifacts
|
||||
|
||||
### Не входит в scope
|
||||
|
||||
* новые домены;
|
||||
* Stage 5 investigation state как отдельный слой;
|
||||
* новая онтология / graph expansion;
|
||||
* большой рефактор MCP toolkit;
|
||||
* новый orchestration layer;
|
||||
* попытка “вообще решить proof architecture”.
|
||||
|
||||
---
|
||||
|
||||
## 4. Рабочая гипотеза execution-pack
|
||||
|
||||
Нужно исходить из следующего:
|
||||
|
||||
### Сейчас система ломается не в одной точке, а в связке трёх искажений
|
||||
|
||||
1. **Неверное окно времени**
|
||||
Вопрос по July 2020 может уехать в другой год/период.
|
||||
|
||||
2. **Неверная бухгалтерская полярность**
|
||||
Supplier/60/case может резолвиться в customer/receivable semantics.
|
||||
|
||||
3. **Слабый допуск evidence**
|
||||
Live/snapshot сигналы с weak mapping, wrong period, wrong domain или `matched_rows = 0` всё ещё могут усиливать grounded answer.
|
||||
|
||||
Эти три искажения надо снимать **вместе**, а не как несвязанные косметические фиксы.
|
||||
|
||||
---
|
||||
|
||||
# 5. Subwave 1 — GAP-01 Temporal Hard Lock
|
||||
|
||||
## 5.1 Цель
|
||||
|
||||
Исключить ложную temporal интерпретацию company-specific July 2020 вопросов.
|
||||
|
||||
## 5.2 Что сделать
|
||||
|
||||
1. В normalizer/router добавить жёсткий `company_snapshot_temporal_lock`.
|
||||
2. Для контрольного корпуса July 2020:
|
||||
|
||||
* не допускать авто-подстановку текущего/дефолтного года;
|
||||
* не допускать relative reinterpretation;
|
||||
* если вопрос про “июльский срез” без дня — резолвить в fixed month window;
|
||||
* если указан конкретный день июля — резолвить в `2020-07-DD`.
|
||||
3. Ввести hard guard:
|
||||
|
||||
* если resolved time_scope уходит за допустимое окно company snapshot, grounded answer не должен собираться.
|
||||
4. В debug/export добавить обязательные поля:
|
||||
|
||||
* `raw_time_anchor`
|
||||
* `resolved_time_anchor`
|
||||
* `temporal_resolution_source`
|
||||
* `temporal_guard_applied`
|
||||
* `temporal_guard_outcome`
|
||||
|
||||
## 5.3 Acceptance
|
||||
|
||||
* Ни один контрольный вопрос July 2020 не должен уходить в 2023/2025/2026/2030.
|
||||
* Все temporal decisions должны быть видны в debug payload.
|
||||
* При temporal ambiguity ответ должен честно деградировать в limited answer.
|
||||
|
||||
---
|
||||
|
||||
# 6. Subwave 2 — GAP-02 Domain Polarity Guard
|
||||
|
||||
## 6.1 Цель
|
||||
|
||||
Убрать путаницу между:
|
||||
|
||||
* supplier vs customer
|
||||
* payable vs receivable
|
||||
* account 60 vs 62
|
||||
* settlements vs VAT vs month-close cross-contamination
|
||||
|
||||
## 6.2 Что сделать
|
||||
|
||||
1. Ввести `domain_polarity_guard` до retrieval ranking и до problem-unit / answer assembly.
|
||||
2. Минимальные правила:
|
||||
|
||||
* `supplier + account 60 + obligation/tail/not closed` → только supplier/payable semantics
|
||||
* `customer/buyer + 62 + advance/receivable` → только customer/receivable semantics
|
||||
* VAT не усиливает settlement answer без явного VAT claim
|
||||
* month-close не подменяет settlement по общим lifecycle hints
|
||||
3. Запретить mixed semantic profile для single-focus вопросов:
|
||||
|
||||
* `suppliers + customers` одновременно недопустимо, если вопрос не cross-entity by design
|
||||
4. Внутренне развести problem semantics хотя бы на уровне mapping:
|
||||
|
||||
* supplier cases
|
||||
* customer cases
|
||||
5. Если polarity не определена надёжно:
|
||||
|
||||
* answer не должен выдавать жёсткий механизм;
|
||||
* обязан уходить в limited mode с явным указанием неразрешённой полярности.
|
||||
|
||||
## 6.3 Acceptance
|
||||
|
||||
* Supplier/60 вопросы не должны порождать `customer_settlement`, `stale_receivable`, `receivable_closed`.
|
||||
* Customer/62 вопросы не должны уходить в supplier payable semantics.
|
||||
* Domain drift между settlement/VAT/month-close должен исчезнуть не только в answer text, но и в debug/runtime trace.
|
||||
|
||||
---
|
||||
|
||||
# 7. Subwave 3 — GAP-03 Evidence Admissibility Gate
|
||||
|
||||
## 7.1 Цель
|
||||
|
||||
Запретить попадание недопустимого evidence в grounded answer.
|
||||
|
||||
## 7.2 Что сделать
|
||||
|
||||
1. Ввести `evidence_admissibility_gate` между retrieval/live layers и answer composer.
|
||||
2. Evidence может считаться admissible только если одновременно выполнено:
|
||||
|
||||
* дата попадает в допустимое окно вопроса;
|
||||
* домен совпадает с текущим active domain;
|
||||
* account scope совместим с вопросом;
|
||||
* source mapping не weak/ambiguous как основание вывода;
|
||||
* `matched_rows > 0`, если live evidence заявляется как подтверждение.
|
||||
3. Развести evidence на категории:
|
||||
|
||||
* `hard_evidence`
|
||||
* `supporting_signal`
|
||||
* `inadmissible_noise`
|
||||
4. Ввести причины отбраковки:
|
||||
|
||||
* `wrong_period`
|
||||
* `wrong_domain`
|
||||
* `wrong_account_scope`
|
||||
* `weak_source_mapping`
|
||||
* `zero_live_match`
|
||||
* `future_dated_or_out_of_window`
|
||||
5. В debug/export показывать:
|
||||
|
||||
* общее число candidate evidence;
|
||||
* число admissible evidence;
|
||||
* число rejected evidence;
|
||||
* breakdown причин reject-а.
|
||||
6. Если admissible evidence недостаточно:
|
||||
|
||||
* grounded answer запрещён;
|
||||
* answer обязан уходить в `insufficient evidence / limited answer`.
|
||||
|
||||
## 7.3 Acceptance
|
||||
|
||||
* При `matched_rows = 0` live probe не может усиливать grounded answer.
|
||||
* VAT evidence не должно попадать в settlement answer.
|
||||
* Future-dated и out-of-window rows не должны использоваться как доказательная база.
|
||||
* weak mapping может фигурировать только как limitation, но не как опора основного вывода.
|
||||
|
||||
---
|
||||
|
||||
# 8. Интеграционный guard после трёх subwaves
|
||||
|
||||
После внедрения GAP-01/02/03 добавить общий runtime guard:
|
||||
|
||||
## `grounded_answer_eligibility_guard`
|
||||
|
||||
Grounded answer разрешён только если:
|
||||
|
||||
* temporal guard passed;
|
||||
* polarity guard passed;
|
||||
* admissible evidence count > 0;
|
||||
* no critical contradiction in domain/account scope.
|
||||
|
||||
Если хотя бы одно из условий не выполнено:
|
||||
|
||||
* answer переходит в `limited / insufficient evidence`;
|
||||
* debug/export явно показывает причину деградации.
|
||||
|
||||
---
|
||||
|
||||
# 9. Контрольный набор прогонов
|
||||
|
||||
Обязательный rerun — минимум по core-8 July 2020 вопросам, особенно по этим кейсам:
|
||||
|
||||
1. Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
|
||||
2. Поступление 276 873,60 — зачёлся ли аванс 15 июля.
|
||||
3. Платежи 40 860 и 20 000 — аванс или закрытие дебиторки.
|
||||
4. Услуги связи + НДС 233,33 + счёт-фактура — полная ли НДС-цепочка.
|
||||
5. Есть ли покупки июля с неполным НДС-контуром.
|
||||
6. Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
|
||||
7. Списание РБП — не живёт ли часть РБП дольше ожидаемого.
|
||||
8. После полного month-end — что реально проблема, а что нормальный остаток.
|
||||
|
||||
---
|
||||
|
||||
# 10. Метрики rerun
|
||||
|
||||
Добавить/обновить следующие метрики:
|
||||
|
||||
* `temporal_anchor_correctness_rate`
|
||||
* `domain_polarity_correctness_rate`
|
||||
* `evidence_admissibility_rate`
|
||||
* `grounded_answer_eligibility_correctness_rate`
|
||||
* `inadmissible_evidence_leak_rate`
|
||||
* `limited_answer_honesty_rate`
|
||||
|
||||
## Минимальный порог приёмки
|
||||
|
||||
* `temporal_anchor_correctness_rate = 1.00`
|
||||
* `domain_polarity_correctness_rate = 1.00` на core P0 cases
|
||||
* `inadmissible_evidence_leak_rate = 0`
|
||||
* `grounded_answer_eligibility_correctness_rate >= 0.95`
|
||||
* `limited_answer_honesty_rate >= 0.95`
|
||||
|
||||
---
|
||||
|
||||
# 11. Обязательные run-артефакты
|
||||
|
||||
В `llm_normalizer/docs/runs/<new_run_folder>` обязательно положить:
|
||||
|
||||
1. `README.md`
|
||||
2. `run_summary.json`
|
||||
3. `before_after_metrics.json`
|
||||
4. `control_case_matrix.md`
|
||||
5. `gap_closure_report.md`
|
||||
6. `chat_export_core8.md` или `чат.txt`
|
||||
7. `debug_payloads/`
|
||||
|
||||
* supplier 60 case
|
||||
* customer 62 case
|
||||
* VAT case
|
||||
* month-close / RBP case
|
||||
8. `live_call_inventory.json`
|
||||
9. `evidence_gate_breakdown.json`
|
||||
10. `temporal_resolution_audit.json`
|
||||
11. `polarity_guard_audit.json`
|
||||
|
||||
---
|
||||
|
||||
# 12. Формат финального вывода
|
||||
|
||||
В конце execution-pack нужно выдать короткий final verdict:
|
||||
|
||||
* `GAP-01 CLOSED / NOT CLOSED`
|
||||
* `GAP-02 CLOSED / NOT CLOSED`
|
||||
* `GAP-03 CLOSED / NOT CLOSED`
|
||||
|
||||
И общий статус:
|
||||
|
||||
* `BLOCKER_PACK_ACCEPTED`
|
||||
* или `BLOCKER_PACK_ACCEPTED_WITH_LIMITATIONS`
|
||||
* или `BLOCKER_PACK_NOT_ACCEPTED`
|
||||
|
||||
---
|
||||
|
||||
# 13. Что не делать
|
||||
|
||||
1. Не переходить в новую большую proof-архитектуру.
|
||||
2. Не добавлять question modes как отдельный новый слой в этой задаче.
|
||||
3. Не делать mechanism discriminator в полном объёме до снятия GAP-01/02/03.
|
||||
4. Не пытаться чинить generic wording вместо structural guards.
|
||||
5. Не закрывать pack на основании Chat-only корпуса без trace-backed live/debug rerun.
|
||||
|
||||
---
|
||||
|
||||
# 14. Ожидаемый результат
|
||||
|
||||
После выполнения этого execution-pack система должна:
|
||||
|
||||
* держать правильный July 2020 temporal scope;
|
||||
* не путать supplier/customer и 60/62;
|
||||
* не использовать нерелевантное evidence как основание ответа;
|
||||
* честно деградировать в limited mode, если доказательной базы недостаточно;
|
||||
* предоставить trace-backed подтверждение того, что три blocker-gap’а реально сняты.
|
||||
|
||||
---
|
||||
|
||||
Так, я заметил, там историю ты хочешь, короче, изолироваться. Может, я просто неправильно понял, но вот может быть, я просто сейчас немного с другой точки зрения как бы к этому придрался. Но ты вот пишешь, короче говоря, что если мы обсуждаем июль 2020, да, ну вот и задаем по этому месяцу этого года вопрос, то мы не должны вылезать за пределы этого, ну, вот этого месяца или этого, короче, какой-то даты, короче. Но смотри, на бухгалтерии это взаимосвязано, и из сущности там могут быть цепочки, но если контракт, например, там, я не знаю, три года, ну, то может делаться три года. Это может быть вообще открытый договор на пять лет, например, и пять лет там что-то делается, какие-то процессы происходят. Но, короче говоря, это могут быть взаимосвязи за пределами определенной даты. Это не противоречит вот этому твоему запрету, который ты пишешь, нех неверное окно времени, вопрос по этому июлю, он должен уехать в другой год-период. Ну, то есть, ну, он может иметь корни, короче, в далекое время, вот о чем я.
|
||||
|
||||
Да, ты прав. Это не должно быть жёстким запретом “не выходить за июль 2020 вообще”.
|
||||
|
||||
Тут надо различать **два разных слоя времени**:
|
||||
|
||||
**1. Главный период вопроса**
|
||||
Это то, про что пользователь спрашивает.
|
||||
Например: “что происходило в июле 2020” или “почему на конец июля остался хвост”.
|
||||
|
||||
**2. Контекстная причинно-следственная зона**
|
||||
Это всё, куда система имеет право сходить, чтобы объяснить ответ:
|
||||
|
||||
* договор мог начаться раньше;
|
||||
* аванс мог прийти раньше;
|
||||
* закрывающий документ мог появиться позже;
|
||||
* цепочка могла тянуться через несколько месяцев или лет.
|
||||
|
||||
То есть моя мысль была не “запретить выходить за месяц”, а вот такая:
|
||||
|
||||
## Что реально должно быть запрещено
|
||||
|
||||
Запрещено **тихо подменять основной период вопроса**.
|
||||
|
||||
Пример плохого поведения:
|
||||
пользователь спрашивает про июль 2020,
|
||||
а система вдруг делает вид, что основной ответ строится по 2023 или 2026, просто потому что туда уехал route или live probe.
|
||||
|
||||
Вот это нельзя.
|
||||
|
||||
## Что должно быть разрешено
|
||||
|
||||
Разрешено выходить за пределы июля 2020, если это нужно для восстановления цепочки, **но с жёсткими правилами**:
|
||||
|
||||
### 1. Июль 2020 остаётся главным окном ответа
|
||||
|
||||
То есть вопрос всё ещё про июль 2020, а не про “вообще всё, что связано с этим договором”.
|
||||
|
||||
### 2. Внешние периоды можно использовать только как:
|
||||
|
||||
* предысторию,
|
||||
* источник причины,
|
||||
* последствие,
|
||||
* подтверждение закрытия/незакрытия,
|
||||
* долгий lifecycle сущности.
|
||||
|
||||
### 3. Система обязана маркировать роль внешнего периода
|
||||
|
||||
Например:
|
||||
|
||||
* “договор открыт ранее, это предыстория”;
|
||||
* “оплата была раньше июля, поэтому это объясняет состояние на июль”;
|
||||
* “закрытие произошло после июля, поэтому на конец июля хвост ещё был нормален/ненормален”.
|
||||
|
||||
### 4. Нельзя, чтобы внешние данные захватывали ответ полностью
|
||||
|
||||
То есть ответ не должен превращаться в:
|
||||
“нашли что-то в 2025, значит объясняем июль 2020 через это”.
|
||||
|
||||
Сначала должно быть:
|
||||
|
||||
* что видно в самом окне июля 2020,
|
||||
* потом — что объясняется данными вне окна.
|
||||
|
||||
Это очень важная разница.
|
||||
|
||||
---
|
||||
|
||||
## Как это правильно назвать в ТЗ
|
||||
|
||||
Не `temporal hard lock` в смысле “сидим внутри месяца и ни шагу в сторону”, а так:
|
||||
|
||||
### `primary_period_anchor + controlled temporal expansion`
|
||||
|
||||
То есть:
|
||||
|
||||
**Primary period anchor**
|
||||
|
||||
* вопрос жёстко привязан к основному периоду пользователя.
|
||||
|
||||
**Controlled temporal expansion**
|
||||
|
||||
* система может выходить за пределы периода,
|
||||
* но только по связанным сущностям,
|
||||
* только с объяснимой причиной,
|
||||
* только в ограниченной роли,
|
||||
* и не подменяя основной период ответа.
|
||||
|
||||
---
|
||||
|
||||
## Как бы я переписал это в ТЗ
|
||||
|
||||
Вот формулировка, которую лучше дать Codex вместо слишком жёсткого запрета:
|
||||
|
||||
### Temporal rules
|
||||
|
||||
1. Для каждого вопроса определить:
|
||||
|
||||
* `primary_period`
|
||||
* `allowed_context_window`
|
||||
* `context_expansion_reason`
|
||||
|
||||
2. `Primary_period` — это главный период ответа, который нельзя silently replace.
|
||||
|
||||
3. Выход за пределы `primary_period` разрешён, если:
|
||||
|
||||
* найден связанный договор / расчётный объект / документ / регистровая цепочка;
|
||||
* внешняя дата нужна для объяснения причины или последствия;
|
||||
* данные явно маркируются как `prehistory`, `carryover`, `post-period closure`, `long-running contract context`.
|
||||
|
||||
4. В answer/debug нужно различать:
|
||||
|
||||
* **что подтверждено внутри основного периода**;
|
||||
* **что подтянуто из соседних/дальних периодов как объясняющий контекст**.
|
||||
|
||||
5. Запрещено:
|
||||
|
||||
* заменять `primary_period` другим периодом без явного основания;
|
||||
* использовать out-of-period evidence как основной grounding, если оно не связано с сущностью вопроса;
|
||||
* строить ответ на future-dated / unrelated data.
|
||||
|
||||
---
|
||||
|
||||
## Самая правильная модель для бухгалтерии
|
||||
|
||||
Я бы описал её так:
|
||||
|
||||
**Есть период вопроса.
|
||||
Есть горизонт расследования.
|
||||
Период вопроса — это центр.
|
||||
Горизонт расследования — это допустимая зона обхода цепочки.**
|
||||
|
||||
И вот ваша система сейчас как раз, похоже, не различает эти две вещи:
|
||||
|
||||
* иногда слишком свободно уезжает из центра,
|
||||
* а иногда, наоборот, живёт на маленьком срезе и не дотягивается до причинной цепочки.
|
||||
|
||||
Поэтому тебе кажется, что “запрет на выход из месяца” опасен — и ты прав, если понимать его буквально. Буквально так делать нельзя.
|
||||
|
||||
---
|
||||
|
||||
## Коротко
|
||||
|
||||
Да, замечание правильное.
|
||||
Нужен не запрет выходить за пределы июля 2020, а:
|
||||
|
||||
**жёсткая фиксация главного периода вопроса + контролируемое расширение по цепочке связанных сущностей.**
|
||||
|
||||
____
|
||||
Да — **отдавать лучше одним пакетом**, а не тремя разрозненными ТЗ.
|
||||
|
||||
Но с важной оговоркой:
|
||||
|
||||
**одна ТЗ ≠ один слепой мах без промежуточной фиксации.**
|
||||
|
||||
Правильный режим такой:
|
||||
|
||||
## Как это лучше ставить Codex
|
||||
|
||||
Ты даёшь **одну общую ТЗ на blocker-pack**, где внутри уже прописано:
|
||||
|
||||
1. `GAP-01` — primary period anchor + controlled temporal expansion
|
||||
2. `GAP-02` — domain polarity guard
|
||||
3. `GAP-03` — evidence admissibility gate
|
||||
4. общий rerun и run-артефакты после всех трёх
|
||||
|
||||
То есть для тебя это **одна задача**, а для него — **один execution pack с внутренними этапами**.
|
||||
|
||||
---
|
||||
|
||||
## Почему не надо дробить на отдельные независимые ТЗ
|
||||
|
||||
Потому что эти штуки связаны:
|
||||
|
||||
* без временной фиксации периодов polarity может строиться на мусоре;
|
||||
* без polarity admissibility будет фильтровать не тот домен;
|
||||
* без admissibility temporal fix не спасёт от левых evidence.
|
||||
|
||||
Если их резать на три независимых задания, есть риск, что:
|
||||
|
||||
* один кусок “починился” локально,
|
||||
* а вся цепочка всё равно продолжает врать.
|
||||
|
||||
---
|
||||
|
||||
## Но почему нельзя “одним махом” совсем без структуры
|
||||
|
||||
Потому что тогда Codex легко:
|
||||
|
||||
* начнёт лезть шире, чем надо;
|
||||
* смешает fix и redesign;
|
||||
* сделает пачку изменений без понятного before/after;
|
||||
* и ты потом не поймёшь, что именно помогло, а что просто пошумело.
|
||||
|
||||
Поэтому правильная формула:
|
||||
|
||||
### Даёшь одним пакетом, но требуешь:
|
||||
|
||||
* делать **по subwave внутри одного run-пакета**;
|
||||
* после каждой subwave фиксировать изменения и локальные проверки;
|
||||
* в конце делать **единый rerun core-8**;
|
||||
* положить все артефакты в один новый run folder.
|
||||
|
||||
---
|
||||
|
||||
## Как это сформулировать ему одной фразой
|
||||
|
||||
Можно так:
|
||||
|
||||
**Выполни это как один Stage 4 blocker-closure execution pack, но реализуй внутри последовательно: сначала GAP-01, потом GAP-02, потом GAP-03, без выхода за scope, с обязательной фиксацией локальных результатов по каждой подволне и общим финальным rerun после всех трёх.**
|
||||
|
||||
---
|
||||
|
||||
## Это тюн или не тюн
|
||||
|
||||
Это уже **не просто тюн текста/маршрута**.
|
||||
Это **структурный corrective pack внутри Stage 4**.
|
||||
|
||||
Но это всё ещё:
|
||||
|
||||
* не новая архитектурная стадия,
|
||||
* не Stage 5,
|
||||
* не proof engine целиком,
|
||||
* не большой redesign.
|
||||
|
||||
То есть это **сильный runtime hardening**, а не “перестройка всего”.
|
||||
|
||||
---
|
||||
|
||||
## Мой совет
|
||||
|
||||
Отдавай **одним ТЗ**, да.
|
||||
Но прямо в начале добавь две жёсткие фразы:
|
||||
|
||||
**1. Не делать это как один большой неразмеченный рефактор.**
|
||||
**2. Выполнять как один pack с тремя последовательными subwave и общим финальным rerun.**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user