# Business-first analyst rubric

Use this rubric when evaluating one domain case, one multi-step scenario, or one full domain pack.

The analyst must not stop at route/debug correctness. The analyst must judge whether the answer is actually useful for a real business user.

## Core principle

The analyst evaluates these layers at once:
- user intent;
- scenario tree and state continuity;
- object-centric dialog continuity;
- action resolution on top of the current business object;
- compact micro-action answers on top of the current business object;
- business usefulness of the answer;
- evidence, temporal honesty, and field truthfulness;
- root cause and smallest defensible fix direction.

## Required analyst questions

For every critical turn or critical edge, answer these questions explicitly.

1. What did the user really ask?
- State the business meaning in one short sentence.
- Name the minimum direct answer the user expected.

2. What should the first line of the answer have been?
- If the user asked a direct lookup question, the first line must contain the direct answer.
- Technical explanation, limitations, and evidence come after the direct answer.
- Follow-up answers over a selected object must be action-first, not trace-first.

3. What object and scope had to survive from previous turns?
- selected item / selected contract / selected counterparty;
- originating date or period;
- warehouse or organization scope when still relevant;
- stable focus object, for example `focus_object` for a selected inventory item;
- reusable resolved bundle, for example `provenance_bundle`, `sale_trace_bundle`, or `answer_object`.

4. Did the answer stay on the same business object?
- item question -> item answer;
- supplier question -> supplier answer;
- buyer question -> buyer answer;
- old-stock question -> old-stock item list.

If the system silently switched to raw documents, movements, or another lower-level object, call it an answer-shape defect.

5. Did the runtime resolve the correct follow-up action on the same object?
- `кто это поставил` should stay on item -> supplier provenance;
- `когда` / `когда купили ее` should stay on item -> purchase date;
- `покажи документы по этой позиции` should stay on item -> purchase documents;
- `покажи все закупки по ней` should stay on item -> receipts / provenance documents;
- `каким документом купили` should stay on item -> source purchase document.
- `кому в итоге мы продали этот товар` should stay on item -> buyer / sale trace;
- `через какие документы товар прошел до продажи` should stay on item -> purchase-to-sale chain.

If the selected item stayed known but the action was reinterpreted as a different drilldown such as `documents_by_counterparty`, call that a `followup_action_resolution_gap`.
Treat this as an action-router failure over an already resolved object route, not as a generic wording miss.

6. Was the answer derived from the right state object?
- If the product already resolved supplier/date/document facts, the next narrow follow-up should reuse `answer_object` / `provenance_bundle` rather than replaying the whole trace.
- `когда` after a resolved provenance answer should normally be a derived lookup, not a fresh broad search.

7. Are the surfaced fields truthful and correctly labeled?
- do not confuse supplier with organization;
- do not confuse buyer with organization;
- do not present a document-side technical field as a business truth unless that mapping is proven.

8. Was temporal behavior honest?
- If the exact requested window has no rows and the runtime auto-broadens to nearest evidence, the answer must say so clearly.
- The direct answer must distinguish `no exact evidence in requested window` from `nearest available evidence outside the window`.
- Hidden or blurry out-of-window broadening is a defect.

9. Was the answer layered correctly?
- Layer 1: user-facing direct answer only;
- Layer 2: proof / evidence / details;
- Layer 3: service or methodological notes only if still useful.

If the answer opens with system headings, trace narration, or engineering hedging, lower business usefulness.

## Business usefulness rules

An answer is not accepted as business-useful when any of these are true:
- the direct answer is not placed first;
- the answer opens with technical hedging instead of the user-facing result;
- the answer is trace-first instead of action-first on a selected-object follow-up;
- the answer requires the user to reconstruct the conclusion from low-level evidence;
- the answer uses ambiguous field labels for business-critical entities;
- the answer puts system scaffolding such as `status`, `what was considered`, `row counts`, `exact contour`, or similar noise above the business answer.
- the answer opens with numbered scaffolding such as `Блок 1`, `Блок 2`, `Блок 3` instead of a clean business answer and lightweight separation.
- a root snapshot opens with service counters instead of a concise business summary and then the top relevant positions.

## State continuity rules

Follow-up continuity is a first-class acceptance object.

The analyst must verify:
- selected object continuity;
- date/period continuity;
- reusable evidence continuity;
- pronoun resolution continuity;
- follow-up action resolution continuity on the active business object;
- stable `focus_object` and stable `answer_object`.

Important pronoun examples:
- `эту позицию`
- `этот товар`
- `его`
- `по нему`
- `по этой позиции`

If the previous turn already resolved a concrete object, the next turn must reuse it instead of asking for the anchor again.

Short follow-up examples that should first resolve against the active object or answer bundle:
- `по этой позиции`
- `покажи документы по ней`
- `когда купили ее`
- `это тот же поставщик?`
- `когда`

## Reusable answer-object cache

For follow-up-heavy domains, the analyst should explicitly look for evidence that the product behaves as if it had a reusable resolved object bundle.

Examples:
- `current_item`
- `current_as_of_date`
- `current_provenance_trace`
- `current_sale_trace`
- `focus_object`
- `answer_object`
- `provenance_bundle`
- `purchase_date`
- `supplier_if_known`
- `source_document_if_known`
- `provenance_docs`

If the runtime recomputes everything from scratch and loses the already resolved object, call that a state-layer defect.
If the runtime retains the object but fails to reuse a resolved supplier/date/document bundle for the next adjacent lookup, call that a `bundle_reuse_gap`.

## Root-cause layers

Use one or more of these root-cause layers explicitly:
- `semantic_understanding_gap`
- `runtime_capability_gap`
- `edge_carryover_gap`
- `object_memory_gap`
- `followup_action_resolution_gap`
- `bundle_reuse_gap`
- `field_mapping_gap`
- `temporal_honesty_gap`
- `answer_shape_mismatch`
- `ordering_semantics_mismatch`
- `business_utility_gap`
- `loop_coverage_gap`
- `domain_anchor_gap`

## Minimum machine-readable verdict fields

The analyst verdict should expose at least:
- `user_intent_summary`
- `expected_direct_answer`
- `actual_direct_answer`
- `direct_answer_ok`
- `business_usefulness_ok`
- `business_utility_score`
- `direct_answer_priority_score`
- `state_continuity_score`
- `answer_shape_score`
- `evidence_clarity_score`
- `focus_object_continuity_ok`
- `bundle_reuse_ok`
- `followup_action_resolution_ok`
- `temporal_honesty_ok`
- `field_truth_ok`
- `answer_layering_ok`
- `recommended_state_objects`
- `root_cause_layers`
- `broken_edge_ids`
- `violated_invariants`

## Inventory-specific reminders

For inventory follow-up chains, verify all of these:
- the selected item remains the current focus object after the user clicks a result;
- provenance questions answer supplier/date/document first, not only raw movement rows;
- `когда купили` can reuse the already resolved provenance bundle and should not replay a full provenance packet;
- narrow micro-actions like `кто`, `когда`, `каким документом`, `покажи документы` should answer compactly first and should not open with a generic multi-block summary packet;
- `покажи документы по этой позиции` stays in item-level purchase documents instead of falling into counterparty documents;
- supplier and organization are not mixed up in the surfaced answer;
- if the exact requested stock date has no purchase evidence and the runtime shows nearest earlier evidence, the answer says this honestly and keeps the distinction clear;
- `на эту дату` keeps the original stock date unless the user explicitly changed it.