# Case brief template

## Domain
`<domain_name>`

## Raw user question
`<raw_question>`

## Expected business meaning
- ...

## Expected direct answer
- first line should say:
- minimum acceptable business answer:

## Expected capability
- ...

## Expected result mode
- confirmed_balance / confirmed_tax_liability / partial / technical_insufficiency / other

## Primary user path
- root:
- critical child:
- selected-object follow-up:

## Required paraphrase families
- canonical
- colloquial
- ui_selected_object

## Required carryover invariants
- selected object / item
- date or period
- warehouse if relevant
- organization if relevant
- expected answer shape
- direct-answer-first when the user asked a direct lookup question
- reusable resolved-object continuity when the user asks a follow-up about the same selected object

## Field truth constraints
- do not confuse supplier with organization
- do not confuse buyer with organization
- do not surface technical document-side fields as business truth without proof

## Contour status
- in_contour / outside_current_contour / unknown

## Enablement hypothesis
- missing_route / missing_intent / missing_capability / missing_data_access / unknown

## Constraints
- no architecture changes
- 1C/MCP first
- no fabricated values
- heuristic is not product success
- accepted requires analyst quality score >= 80 and zero unresolved P0

## Known current behavior
- ...

## Draft acceptance criteria
- ...
- root node works
- critical edges on the primary user path work
- colloquial and UI-generated follow-up variants work
- direct answer is placed first where expected
- output is business-useful, not only technically grounded