NODEDC_1C/.codex/skills/domain-case-loop/references/business_first_analyst_rubric.md

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.