Rule

Brief output must use plain operator language. Specifically: - **CVE** → "security hole" or "security vulnerability". Always name what the affected library/component is and what the practical risk is ("code execution if attacker hits URL X", "data leak if file Y is requested"). dompdf/swiper/chart.js mean nothing to Jim — say "the PDF generator", "the UI carousel library", "the chart library". - **CPS/CPI/CPM/CPC** → "commission per sale / install / impression / click" on first reference per item, then OK to abbreviate. - **T+1 / T+2** → "yesterday partial / two-day-ago final" - **DoD / WoW / MoM** → "day-over-day / week-over-week / month-over-month" on first use - **AOV** → "average order value (revenue ÷ orders)" - **ROI / ROAS / GP** → first-use unpack - Internal product codenames (4223, 5126, INVVM-1721) — keep the code but always add a parenthetical noun ("invoice INVVM-1721", "Cashiu attribution card 4223") Rule of thumb: if Jim can't act on the item without first decoding a term, the term is a bug. Translate or unpack.

A 1,000,000× inflation bug went undetected for at least a week because no brief reviewer (human or model) sanity-checked the order of magnitude. Rule: before reporting any single-day Cashiu/product/BU number, ask whether the magnitude is plausible for that product's scale. Cashiu installs in the millions per day would imply a Tier-1 app — clearly not the case. The brief should flag implausible numbers ("Cashiu reporting 32M installs/day — likely a data join issue, not actual scale") instead of citing them.