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