DJ Von Frank AI Implementation

Writing

Writing evidence-backed implementation case studies

A case study is a set of claims wearing a story, and most of them collapse under one question: says who? This is how I write ones that survive it: problem, build, outcome, with every number traced to a source I can defend in a room.

Three parts, in a fixed order

Every case study I publish has the same skeleton: the problem, the build, the outcome. The problem is told plainly, without a villain, because a reader can smell a strawman. The build shows mechanism rather than adjectives: what was actually made, and why that shape. The outcome carries the numbers, and only the numbers that trace. The fixed order is doing real work: it forces the outcome to be an answer to the problem, which is the connection most case studies quietly skip.

THE PROBLEMwhat was broken, told plainly THE BUILDwhat got made, mechanism visible THE OUTCOMEwhat changed, with the number THE SOURCEone file, one key per figure no source, no number. no number, say so in words.
The shape of every case study on this site. The arrow on the right is the part that makes the other three worth reading.

One source file, one key per figure

Every figure that appears anywhere in my case studies lives in a single metrics file, and the pages interpolate it rather than carrying their own copies. A number changes in exactly one place, so two pages can never disagree about the same fact. The file's own rule is written at the top: if a number is not in the source it traces to, it does not ship. The discipline extends to word forms: when prose spells a figure out, that spelling is a key in the same file, so a team of fifteen and 3 to 15 cannot drift apart either.

One subtlety earns its own mention: two different facts that happen to share a value get two separate keys. A client's monthly saving and an agency's retainer can both be a thousand dollars, and moving one must not move the other, because they are different claims with different owners. A shared key would weld two facts together at the hip, and the weld would fail silently the day one of them changed.

Counts are computed, never typed

Where a case study cites a count of things, the count is computed from the list it describes rather than written by hand above it. The failure this prevents is one I have committed: a demo header once claimed twelve agents above a roster of fifteen, because the header was prose and the roster was data and nothing tied them together. A summary that cannot drift from the table underneath it is not a flourish. It is the difference between a page that states its evidence and a page that is its evidence.

Lead with the smaller true number

A roster where everything is shipped is a lie, and a roster where everything is new is vapour. So the count that leads is not the total: it is the part with a dated execution record, and the remainder split by exactly what is missing. On my agents page that reads as 19 of 45 with a dated run, published in that order, because a spec that has never executed is a plan with good formatting, and a buyer who has been sold AI three times knows the difference. Publishing both numbers costs a few entries in the impressive column and buys the room.

WITH A DATED RUN 19 SPECIFIED IN FULL 45
The honest ledger, drawn. Both numbers are computed from the roster rather than typed here, so this chart cannot disagree with the page it cites.

Where there is no number, say so in words

Some outcomes are real and unverified, and the honest move is to go qualitative rather than to launder an estimate into a statistic. A pre-launch product's outcome is a state of play, not a growth figure. An early engagement is we are still early on it, in exactly those words. The rule is not no soft claims. It is no number without a source, and no story I cannot back, which leaves plenty of room for truthful sentences that simply decline to wear a percentage.

Name the owner of every dollar

A dollar figure floating free of an owner implies things. My favorite example is my own: a client saves more than a thousand dollars a month, and the case study says plainly that the engagement is pro bono and the saving is his, not my revenue. The sentence costs nothing and closes the exact gap a skeptical reader was about to open. The general form: for every number, be explicit about whose it is, what it is measured against, and what it is not claiming.

Never put words in a real person's mouth

The hardest rule, and the one enforced mechanically in my own build: a draft testimonial, meaning invented words attributed to a real, named person who has not seen them, can exist during development and can never launch. It is the one defect in a case study that damages somebody other than its author. If a quote is not verbatim and permitted, it is not a quote. Paraphrase in your own voice and attribute nothing.

Why the discipline is the differentiator

Specificity is what separates a case study from an ad, and specificity is only safe when every specific survives a hostile read. The practices above are not writing advice. They are an evidence pipeline: a single source per figure, computed counts, the honest ledger, words where numbers fail, owners on every dollar, and nothing invented in anyone's mouth. Build that pipeline once and the case studies write themselves faster, because the argument is already sitting in the data, waiting for prose.

On this site

The case studies this discipline produces are published, four of them at full length, with the breadth catalog beside them.