# 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 five layers at once:
- user intent;
- scenario tree and state continuity;
- object-centric dialog continuity;
- business usefulness of the answer;
- evidence 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.

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;
- reusable resolved bundle, for example provenance trace or sale trace.
- stable focus object, for example `focus_object` for a selected inventory item;
- reusable resolved bundle, for example `provenance_bundle` or `sale_trace_bundle`.

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.

6. 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.

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`.

5. 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.

## 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;
- a weaker question is answered than the one the user asked;
- the answer requires the user to reconstruct the conclusion from low-level evidence;
- the answer uses ambiguous field labels for business-critical entities.

## 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.

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:
- `по этой позиции`
- `покажи документы по ней`
- `когда купили ее`
- `это тот же поставщик?`

## 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`
- `provenance_bundle`
- `first_purchase_date`
- `supplier_if_known`
- `source_document_if_known`

If the runtime recomputes everything from scratch and loses the already resolved object, call that out as 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 out as 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`
- `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`
- `root_cause_layers`
- `broken_edge_ids`
- `violated_invariants`
- `focus_object_continuity_ok`
- `bundle_reuse_ok`
- `followup_action_resolution_ok`
- `recommended_state_objects`

## 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;
- `покажи документы по этой позиции` stays in item-level purchase documents instead of falling into counterparty documents;
- supplier and organization are not mixed up in the surfaced answer;
- `на эту дату` keeps the original stock date unless the user explicitly changed it.