Write an AI project case study a hiring manager will finish

The order readers expect

A reader skimming a case study is trying to answer, in sequence:

1. 1What problem, for whom?
2. 2Did it work, and how do you know?
3. 3What did you decide that mattered?
4. 4What went wrong, and what did you do?
5. 5What would you do next with more time or real data?
6. 6Can I see it?

Tools and architecture fit inside answer 3, only where they explain a decision.

A complete short example, annotated

The example below writes up a synthetic project: a version of the support-reply drafter specified in the portfolio-pieces article in this series. The annotations in quotes explain why each paragraph is there.

The case study

**Drafting replies to warranty queries for a fictional appliance brand** Support agents at a fictional appliance company spend much of their day answering warranty questions that are covered, but scattered, across ten policy documents. I built a drafting assistant that answers from those documents with section citations, and hands the query to a human when the policies don't cover it.

Annotation: one sentence of problem, one sentence of solution. No stack yet.

**Result.** On a held-out set of 60 synthetic customer messages, 34 of 40 answerable questions received a correct, correctly cited draft, and 17 of 20 unanswerable questions were handed off rather than answered. Hinglish messages performed worse: 9 of 13 correct, against 25 of 27 in English.

Annotation: numbers on the first screen, with the denominator and a weaker slice. The weaker slice signals honesty before the reader looks for it.

**The decision that mattered: chunking by section.** My first version split documents into fixed-length chunks. It often retrieved half of a warranty clause and missed the exception in the next chunk. Switching to one chunk per policy section, with the section title prepended, raised correct retrieval in the top three from 27 to 36 of 40 on the same questions.

Annotation: one decision, the evidence for it, and a before/after on the same test set.

**What still fails.** Three unanswerable questions about installation charges received confident answers, because the installation policy mentions charges without stating amounts. I added an instruction to refuse when an amount is not stated in the source; it now refuses in two of three runs, which is not reliable enough. The next step is a check in code that any rupee amount in a draft appears verbatim in a cited passage.

Annotation: specific failure, a partial fix stated as partial, and a concrete next step. This is the paragraph interviewers remember.

**Limits.** All documents and messages are synthetic, written by me. The results say nothing about performance on a real company's policies or customer tone.

Annotation: two sentences. More would read as defensive.

**Links.** Repository with question set, answer key, failure log and one-command setup.

Why this works

It is about 350 words, it can be read in two minutes, and every paragraph earns its place. It states the evaluation, a decision with evidence, a live failure and its limits. It never claims business impact, because none was measured.

Edits that remove padding

After a first draft, make these cuts:

Titles that work

A good case study title names the user and the task, not the technology. Compare:

• Weak: "RAG Chatbot using LLMs"
• Better: "Cited warranty-reply drafts for support agents, with hand-off"

The second tells the reader who it is for and hints at the design choice.

Where to put it

Put the case study at the top of the repository README and link it from your resume's project line. If you keep a personal site, a copy there is fine, but the repository version is the one reviewers verify. On LinkedIn, a short post summarising the result and the failure, with a link, reaches people who never open GitHub.

Checking before you publish

Ask a friend who is not technical to read only the first two paragraphs and tell you what the project does and whether it worked. If they can't, rewrite the opening. Then ask a technical friend to find one claim they could not verify from the repository. Fix or remove it.

If your project is a basic document chatbot, first run the RAG portfolio audit so there is something substantial to write up. For projects designed to produce a case study like this from the start, see the three LLM portfolio specs. The Generative & Agentic AI add-on ends each project with a written review of this kind.