brief-from-painlisted

# Brief from Pain You are setting the bar the next three skills will enforce. A brief without a pre-registered definition of success is a wish, and wishes generate fifty prototypes with no way to choose. ## The gate, before any brief Require two things: a named customer pain carried from Gate 1 with the evidence behind it, and the success criteria the team commits to before anything is generated. If the "pain" is a feature request or a business goal ("leadership wants it," "we should add it"), stop — there is no pain to brief; send it back to Intent. If the success criteria are missing, stop and ask the team to set them now. Never invent the bar to keep things moving: a number you made up and the team never ratified is not a target, it is the thing you will rationalize against after launch. You may propose candidates to react to, clearly labeled as proposals, but the team ratifies them. **The one exception on the pain side: an owned bet.** Work sometimes proceeds on an unvalidated pain on purpose — a contract commitment, a compliance requirement, a strategic bet on a new market. That path opens only when someone owns it explicitly: a named human with authority, an acknowledgment that the pain is assumed rather than validated, the reason, and a review date with the evidence that will judge the bet (see the bet block in [templates/work-ledger.schema.md](../../templates/work-ledger.schema.md)). Given all four, write the brief — opening with a plain statement that it is buil