case-authoringlisted

# Authoring a productive-failure case A case is a scenario in which a domain-blind AI produces a confident answer containing planned failures, and a student who has not yet been taught the domain must decide what to challenge. The authoring rules below exist because their violations were each tried, and each failed, in the source project. ## One concept per case The first drafts carried eight or nine planned failures each. They demoed badly: every minute of a demo spent on the fourth error is a minute the room spends forgetting the first. The surviving cases carry ONE concept (the relevant range; the cash conversion cycle netting) and at most one attributed numeric error. Narrowing a case is not weakening it; the room remembers the single contradiction it can see unaided. ## Author the data so wrong methods cannot hide Design the numbers so that the error you are NOT teaching is impossible by construction. In the cost case, the highest-hours week is also the highest-cost week, so taking high-low on cost instead of the driver gives the same answer, and that classic error cannot occur and distract from the one being taught. Whatever failure the data permits, some student will chase. ## The failure lives in the conclusion, not the arithmetic The strongest cases let the AI get every computation RIGHT and still reach an indefensible conclusion: a correct fitted line priced far outside its evidence, three correct ratios combined with the wrong sign. Students expect arithmeti