# Outlex Structured Brief v1 Version **v1**, dated **14 September 2026**. This is the mandatory brief `brand/precedence.md` §3 requires before any substantial design request starts, published as its own fetchable file so a planner or agent can pull the field list and the acceptance bar directly, without re-deriving it from the precedence statement each time. `brand/precedence.md` remains the source of the rule; this file is the working form. Precedence: current founder correction, then live canon (this file included), then project adapter, then surface-specific skill. Full statement: `brand/precedence.md`. **Use it for**: a new page, a new hero, a new campaign asset, a redesign of an existing surface, any request a founder or product owner could reasonably ask "beat what, for whom, proving what?" about. A one-line request ("make the hero better") is not a brief; fill the thirteen fields below before laying out anything. **The rule**: a design request missing these fields is incomplete, not merely terse. Return it and ask for the missing fields rather than guessing at them and composing anyway. A field that is genuinely not applicable to a given request still needs one line stating why it doesn't apply ("Required assets: none, copy-only change, no new imagery"). Leaving a field blank is never the same as marking it not applicable, and a blank field is treated as missing, not as answered. --- ## The thirteen fields ### 1. Audience **Answers**: who sees this, specifically. **A good answer contains**: a named role and situation, not a market segment: "a Series-A COO closing a data-room request," not "startups." If the surface serves more than one audience, name the primary one the composition is optimized for and state that a second audience is served incidentally, not equally. ### 2. Pain **Answers**: the real moment of friction this addresses today. **A good answer contains**: a specific, current moment of friction the viewer is in, described the way the viewer would describe it, not the way Outlex would describe its own feature. "I don't know if this NDA is safe to sign before the call in ten minutes" is a pain; "contract review is slow" is a category, not a moment. ### 3. Desired action **Answers**: what the viewer does next, concretely. **A good answer contains**: one verb, one destination: "book a demo," "start a free review," "read the DPA answer." A brief naming two competing desired actions for the same viewer at the same moment has not finished the thinking; pick the one the surface is actually optimized for. ### 4. Promise **Answers**: the one claim this surface makes, that it can back up. **A good answer contains**: a claim the product can prove today, not an aspiration. If the honest promise is narrower than what would look most impressive, state the narrower one. An unbackable promise is a defect the founder will catch at review, not a detail to fix later. ### 5. Story **Answers**: the one buyer story running through the whole composition. **A good answer contains**: a single through-line a first-time reader could restate in one sentence after seeing the page once. A composition trying to tell two stories at once (for example, "fast AI" and "human-reviewed trust") needs to pick which one leads and which one is secondary proof. ### 6. Product proof **Answers**: which real product moment, screenshot, or photograph proves the promise. **A good answer contains**: a specific, named artifact: a real screen, a real crop, a real photograph, not "a product screenshot" as a placeholder category. See `brand/compositions-v3.md` §1 for the product-moment contract if the proof is a UI crop, and `brand/imagery-v3.md` if it is a photograph. ### 7. Emotional tone **Answers**: what the viewer should feel, in plain words. **A good answer contains**: one or two plain feeling-words a non-designer would use ("reassured," "in control," "relieved"), not a mood board adjective like "elevated" or "premium" standing in for an actual feeling. `tokens/PRINCIPLES-v3.md` P-04 is the reminder that a technically clean composition with the wrong or absent feeling still fails. ### 8. Baseline **Answers**: the live surface (or nearest comparable) this has to beat, side by side. **A good answer contains**: a named, viewable URL or page, the current `design.outlex.ai` surface, the current corporate-website page being replaced, or the nearest comparable if there is no direct predecessor. `tokens/PRINCIPLES-v3.md` P-36: the live site is the bar, not a checklist. State which live surface this composition is being judged against before starting, so the comparison is possible at review time. ### 9. Reference mechanics **Answers**: the one or two mechanics borrowed from `brand/taste-v3.md`'s great wall, named explicitly. **A good answer contains**: a named panel and its one-line mechanic from `brand/taste-v3.md` §1 (for example, "Circle / the one number: one decisive value carries the whole section"), not the layout, asset, or brand the panel belongs to. Borrowing the mechanic, not the picture, is the whole point of the reference wall. ### 10. Required assets **Answers**: photography, product crops, icons, and their registration/rights status. **A good answer contains**: a list of what is needed, whether each item already exists and is registered (see `brand/imagery-v3.md` § Source and curation), or needs to be sourced, generated, or cropped fresh, and by whom. "Some photography, TBD" is not an answer. ### 11. Motion opportunity **Answers**: where motion earns its place, or "none." **A good answer contains**: either a specific, named moment where one of the sanctioned sweeps or entrances applies (see `tokens/GRAMMAR-v3.md` §6 and its v3.1 addendum), or the explicit word "none" if this surface doesn't need motion. Motion is earned per page (`tokens/PRINCIPLES-v3.md` P-27); "none" is a complete, valid answer, not a gap. ### 12. Constraints **Answers**: brand hard stops, accessibility, locale, technical limits. **A good answer contains**: anything that bounds the composition before it starts: a hard stop from `brand-v3.md` §19, a locale requirement (EN and pt-PT, for example), a technical limit (bundle size, no JS motion library, an existing component that must be reused), or a WCAG AA requirement beyond the default. "None known" is acceptable only after actually checking, not as a default. ### 13. Success test **Answers**: how the founder (or a calibrated reviewer) will judge this before ship. **A good answer contains**: the specific comparison or question that will decide accept versus reject, usually the composition review checklist in `brand/compositions-v3.md` §4, a side-by-side against the baseline (field 8), or a named prior calibration (`brand/taste-v3.md` §3). "Looks good" is not a success test; a side-by-side comparison the founder can actually run is. --- ## What happens without a completed brief A design request that skips this brief and goes straight to composition is returned, not completed provisionally. Use `grilling` or an equivalent structured interview to fill the fields with the requester before any layout, code, or image generation starts. This applies to every substantial request regardless of who or what is asking: a founder message, a Linear issue, or an agent-generated task all go through the same gate. Once the brief is filled, it hands off to the planner role (`brand/precedence.md` §4): the planner turns these thirteen fields into a concrete composition before a builder writes any code.