I wrote up my best client win. Then legal killed it.

A year ago I had one of the best client results the agency had ever produced. Real numbers, a happy customer, a story any buyer would want to read. I wrote it up. It was good.

Then I went to get sign-off, and legal killed it.

Not because the work was wrong. Because I'd asked at the end instead of the beginning. By the time the draft existed, the client's counsel was reading a finished document full of numbers they'd never formally agreed to release — and the safe answer for any lawyer looking at that is no. Months of the strongest evidence I owned, sunk, one signature short.

That failure is why I built @di-atomic/case-studies. And the first thing it does is the thing I got wrong.

Get the release before the interview, not after the draft

This is the counterintuitive part, so let me say it plainly. You secure the legal release before you sit down for the interview — not after you've written the story. It feels backwards. You want to prove the story is worth publishing before you spend the client's goodwill asking for permission. But that order is exactly what kills case studies at month six: you build the entire asset, then discover the yes was never really available.

Flip it. The ask comes first, from the person closest to the customer — usually me, not marketing. The pitch is control, not exposure: you review every draft, nothing goes live without your approval, and here's the release that says so. People say yes to control. They stall on open-ended requests. Once the release is in hand, the interview and the writing are the easy part.

case-studies reads that gate. It can never write it. An agent that can both request and grant its own approval has no gate at all — so the skill checks the board for a human-owned sign-off and simply refuses to publish without one. It will stop and wait on me. That's the design, not a bug.

The two beats every case study drops

Most case studies read like a straight line from problem to triumph. That's the tell. A story with no friction reads as fabricated, because real work never runs clean.

So the skill enforces two beats that an AI writing from training data reliably skips:

• What they tried before. The failed tools, the workaround that half-worked, the reason the problem was still open when we showed up. This is what makes the intervention mean something.

• The bumps. Where the rollout stalled, what we got wrong on the first pass, the week it looked like it wasn't working. Including the low points doesn't weaken the story — it's what makes a skeptical buyer believe the high points.

Underneath those two beats sits a six-part arc — Situation, Challenge, Intervention, Result, Lessons, a clear next step — and a script that fails the build if any section is a stub. The shape isn't the interesting part. The discipline that the shape can't be faked is.

Every number carries its source, or it doesn't ship

The Result section is where case studies quietly lie, and where mine refuses to.

One script walks the numbers one by one. No figure ships without a resolvable source — a dashboard link, an approved snapshot, an internal report ID. And any percentage over 100% has to show the absolute it came from. "Leads up 1,200%" fails. "Leads up 1,200% (3 → 39 a month)" passes — and reads more honest, because nobody trusts a four-digit percentage on its own. We assume the starting point was near zero, which it usually was.

There's a harder case the skill handles instead of hiding: the before-number that was never measured. Plenty of engagements predate any consistent baseline capture. You cannot reverse-engineer a metric you never took. When that happens, the skill will not invent a plausible one under pressure. Its honest branch is: we can't publish a result for this engagement — here's the study we can run without a Result section, and here's exactly what to instrument from now on. A missing number is a note to your future self, not a blank to fill with a guess.

Never claim a status a regulator confers

A lot of Di-Atomic's best stories sit in regulated verticals — chemicals, biocides, REACH and CLP work. Case studies there fail in a specific way: they claim a status the agency can't confer.

So the compliance lint is a hard gate. The skill writes "supported the REACH dossier," never "made them compliant." It designs, reduces, helps — it does not guarantee. Absolutes lose their footing inside a document full of measured claims anyway, so this makes the writing better, not just safer. The one exception the lint understands is a genuine measurement over a bounded population — "every one of the eight sites cut turnaround" is a count, not a claim, and it lets that through.

What it actually is

case-studies does nothing on its own, on purpose. It's guidance-only: it decides the structure, gates the metrics, gates the compliance framing, reads the approval — and it composes the skills that do the work. copy-engine writes the sentences. voice-builder carries the customer's register instead of mine. explainer-illustrations plans the before/after diagrams. section-designer lays out the library page. And @spideriq/publish-skills ships it — page, PDF, and a gated download form.

Publishing it once, in one format, is the single biggest waste I see. The same approved story should render three ways: the deep page for a skeptical buyer, the one-sheet a sales rep actually forwards, the short cut for social. Atomize from the start.

Under the hood it's backed by 25 real, sourced exemplars, two ask-and-release templates you can send today, 20 learnings pulled from what actually went wrong, and six scripts that print PASS or FAIL with numbers the agent can't fudge.

I built it because the strongest proof I own was stuck in meeting transcripts, and every attempt to free it turned into a bespoke negotiation I kept getting wrong. Now the order is fixed, the numbers carry their sources, and the client holds the pen.

Get @di-atomic/case-studies free on the OPVS marketplace — and turn your best client win into proof you can actually publish.