Ds Brief

---
name: ds-brief
description: Rewrites a technical write-up as a one-page brief for a non-technical reader — no metric names, framed in money, percentages, and counts. Use when someone asks to explain results to an executive, a business audience, or anyone who does not know what AUC means. Use when a plainer version is wanted for business stakeholders. Use when a summary needs to fit on one page with the jargon stripped out.
---

# ds-brief — Executive Brief

## Overview

`/ds-report` is written for a technical-enough stakeholder who can sit with RMSE,
AUC, fold spread, and a slice table. Most of the people who actually decide whether
a model ships are not that reader. This stage translates — it never re-derives —
`/ds-report`'s findings into language a non-technical audience can act on without
first learning what a confusion matrix is.

## When to Use

- After `/ds-report` has produced its narrative.
- Whenever asked to explain results to executives, a business audience, a board, or
  any stakeholder without a DS/ML background.
- NOT for: producing new findings or a different recommendation than `/ds-report`
  reached (that would be re-analysis, not translation) — if the technical report's
  conclusion needs to change, go fix `/ds-report` first, then translate the
  corrected version.

## Core Process

1. **Gate check:** confirm `.last-ds-mile/stages/09-report.md` exists. If it doesn't,
   run `/ds-report`'s work yourself now — this stage translates an existing narrative,
   it doesn't build one from raw evaluation results, but "existing" means "produced in
   this run if it wasn't already there," not "handed off to the user to go create."
2. **Strip every metric name and statistical term** — RMSE, AUC, PR-AUC, F-beta,
   SHAP, p-value, standard deviation, fold, quintile/decile, calibration,
   coefficient, feature importance, confound. If a sentence can't be said without
   one of these words, translate it using `/ds-report`'s own cost-translation
   section (the dollar figure, rate, or count it already computed) — not by
   inventing a new plain-language number that wasn't in the technical report.
3. Structure as five short sections, in this order:
   - **What we built and why** — one or two sentences, tied to the decision named in
     `/ds-frame`. No architecture, no model names as a selling point.
   - **How well it works** — dollars, percentages, or counts only (e.g. "catches 9
     of 10 at-risk customers" or "typical pricing error is about $20,000"), pulled
     directly from `/ds-report`'s cost translation.
   - **Where it's weaker** — named plainly with a real-world reason, not a
     statistical one (e.g. "less reliable for the cheapest homes, which include more
     distressed or family sales" — not "higher RMSE in the Q1 slice").
   - **The recommendation** — stated as plainly as `/ds-report`'s own, e.g. "deploy
     as a suggestion, with a person reviewing the flagged cases."
   - **What happens next** — who owns the decision, and the one or two assumptions
     that would need to hold (from `/ds-report`'s Assumptions section) for the
     recommendation to still be right.
4. **No new claims.** Every sentence must trace back to something already stated in
   `/ds-evaluate`, `/ds-explain`, or `/ds-report`. This stage's job is
   simplification, not additional analysis — if a genuinely new finding surfaces
   while writing this, that belongs back in `/ds-report`, not smuggled into the
   brief alone.
5. **Length discipline:** roughly 300–500 words, one page. A "brief" the length of
   the technical report has failed at the one thing it exists to do.
6. Write to `.last-ds-mile/stages/09b-brief.md` — a companion to `09-report.md`, not
   a renumbering of the pipeline; not every project needs this artifact, so it isn't
   a gate anything downstream depends on.

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "A few technical terms add credibility" | The brief's rigor is inherited from `/ds-report`; restating jargon here doesn't add precision, it adds a comprehension barrier for the one audience this document exists for. |
| "Executives can just ask if they don't understand a term" | Usually they won't — they'll either disengage or silently misread the term (mistaking "AUC" for a plain percentage is a common, costly misread). |
| "The technical report already has a plain-English recommendation, this is redundant" | A one-sentence recommendation buried in a report full of metrics still requires reading the metrics to trust it — a genuinely separate, short artifact gets read by people who will never open the full report. |

See `ds-method` for the shared Rationalizations that apply to every stage.

## Red Flags

| Red Flag | What it usually means |
|---|---|
| Any metric name or statistical term appears anywhere in the brief | This stage's translation step was skipped — go back to step 2. |
| A claim in the brief has no matching statement in `/ds-evaluate`, `/ds-explain`, or `/ds-report` | The brief is inventing a finding, not translating one — remove it, or add it to `/ds-report` first with real evidence. |
| The brief is longer than roughly one page | It's restating the technical report rather than distilling it. |

## Verification

- [ ] Gate check passed: `.last-ds-mile/stages/09-report.md` exists and was read
      before writing began.
- [ ] No metric name or statistical term appears anywhere in the brief.
- [ ] Every claim traces back to `/ds-evaluate`, `/ds-explain`, or `/ds-report` —
      nothing new introduced.
- [ ] All five sections present: what/why, how well, where weaker, recommendation,
      what happens next.
- [ ] Roughly 300–500 words — one page, not a restatement.
- [ ] `.last-ds-mile/stages/09b-brief.md` written.