You built the binder. Now cut it down to a case study a hiring manager can skim in two minutes — and still believe you ran the whole operation.
By Week 12 you have a binder. A rubric. An agreement analysis. A preference dataset. An eval suite. A pipeline design. A QA/drift audit. A leadership playbook. A governance statement. A capstone program brief. "I can run a human-data operation end to end" stops being a claim and becomes a binder of artifacts with your name on them. That's the win — and it's also the problem. A binder nobody can skim is a binder nobody reads. A hiring manager will not page through nine documents. They give you two minutes of attention, and if the work isn't legible in those two minutes, it doesn't exist to them.
The job now is packaging: making the work legible, public, and confidentiality-safe. You already know this instinct. You've spent a career in post — you don't hand a client three hours of raw footage and say "the good stuff is in there." You cut a reel: the strongest beats, in order, scored, under two minutes, built so the viewer feels the whole production from a fraction of it. A data portfolio is the same edit, pointed at a different audience. The binder is your footage. The case study is your reel. This briefing teaches the cut.
Your binder proves you did the work. Your case study proves it in the two minutes you actually get. Packaging isn't decoration — it's the difference between "I have artifacts" and "a stranger read one page and decided to interview me."
Here's the trap that ends a portfolio before it starts: you work at xAI, and the most impressive work you've done uses xAI's prompts, xAI's data, and xAI's internal numbers. None of that can go in a public portfolio. Proprietary prompts, real datasets, model version internals, and any quantitative result a court would call a trade secret stay inside the building. Publishing them isn't a portfolio — it's a fireable, possibly actionable mistake.
But you don't need the proprietary data to prove the skill. The move is to recreate the method on synthetic or public data and describe the real impact qualitatively. The lab's synthetic dataset is built for exactly this: it lets you run your real rubric, your real slice analysis, your real eval suite end to end, in public, with nothing confidential attached. The method is what a hiring manager is buying — and the method is portable. So you show the full pipeline running on synthetic data, then add one honest sentence about the real-world result: "applied to a production image-generation dataset, this raised inter-rater agreement from a low baseline to a strong, stable κ" — direction and magnitude, no proprietary numbers. You demonstrate the engine publicly; you reference the mileage privately.
No real prompts, no real datasets, no internal metrics, no model-version specifics, no screenshots of internal tools. When in doubt, leave it out. Recreate the method on the lab's synthetic set and describe real impact in qualitative, direction-and-magnitude terms only. A portfolio that leaks confidential data is worse than no portfolio — it tells every future employer how you'll treat their secrets.
You have nine artifacts. Each one proves a distinct claim, and each one has a natural format. The mistake is to dump all nine as raw files. Instead, decide for each: what does it prove, and how should it be presented so it's skimmable? This table is your packaging plan.
| Artifact | What it proves | How to present it |
|---|---|---|
| Rubric | You can define "good" precisely enough that strangers agree. The foundation of every other artifact. | Clean PDF, 1–2 pages: scale, anchors, examples. Versioned (v1→v2 changelog) to show iteration. |
| Agreement analysis | You measure rater reliability and act on it — κ before/after a rubric revision. | One-pager: the metric, the slice breakdown, what you changed, the re-measured result. |
| Preference dataset | You can produce clean, documented training data — the actual deliverable of the role. | GitHub repo: synthetic data + schema + a datasheet README. Sample rows visible inline. |
| Eval suite | You can prove a change worked with code, not anecdote. | GitHub repo that runs from the README; outputs a per-slice quality report, not one number. |
| Pipeline design | You think in systems — collection → labeling → QA → delivery — not just single ratings. | One pipeline diagram (PNG/SVG) plus a one-page narrative of each stage and its owner. |
| QA / drift audit | You catch quality decay over time and have a control loop for it. | One-pager: the control chart, the drift you caught, the corrective action, the recovery. |
| Leadership playbook | You can run people, not just data — onboarding, calibration, escalation, feedback. | Short PDF or repo doc: your operating cadence and the calibration ritual you run. |
| Governance statement | You can account for a dataset on paper — provenance, bias, gaps, retention — before it ships. | The one-page Article-10-mapped statement from the Governance briefing, plus its datasheet. |
| Capstone program brief | You can scope and run a full human-data program end to end, with an exec brief on top. | PDF program doc + a one-page exec brief; this is the spine the case study is written from. |
Before an artifact goes in the binder, write the single sentence it proves ("This shows I can lift inter-rater agreement by rewriting ambiguous anchors"). If you can't write that sentence, the artifact isn't ready — or doesn't belong. The binder's table of contents is just those sentences in a column.
This is the reel. If a hiring manager reads one thing you made, it's this. It fits on a single page, it's written so the eye can skim it in two minutes, and it tells one complete story: a problem, a metric you moved, the method you used, the result, and where the proof lives. Use this fill-in template.
HUMAN-DATA CASE STUDY — {Program / project name}
Your name · Role: {e.g. Human Data Lead} · {date}
PROBLEM
{One or two sentences. What was broken or missing? Why did it
matter to the model and the business? e.g. "Raters disagreed on
prompt-adherence quality, so the preference data was noisy and
the reward model trained on conflicting signal."}
METRIC BEFORE -> TARGET / RESULT
{Primary metric, e.g. inter-rater agreement (Cohen's kappa)}
{0.41} -> {0.78}
{Secondary metric, optional, e.g. worst-slice quality}
{0.58} -> {0.80}
METHOD
- Rubric: {what you defined / revised; how anchors were fixed}
- Pipeline: {collection -> labeling -> QA -> delivery, one line}
- Data: {preference dataset built on SYNTHETIC/public data}
- Eval: {the eval suite + slice axes you read, not the mean}
RESULT
{Qualitative + the eval that proved it. e.g. "Agreement rose to a
strong, stable level; the dark-scene slice closed from worst to
parity. The eval suite (linked) reproduces the per-slice report."}
{One honest, non-proprietary line on real-world impact, if any.}
ARTIFACTS
- Rubric (PDF) .............. {link}
- Eval suite (GitHub) ....... {link}
- Preference dataset ........ {link}
- Pipeline diagram .......... {link}
- Governance statement ...... {link}
YOUR ROLE
{One or two sentences. What did YOU own vs. the team? e.g. "I
owned the rubric, the calibration cadence, and the eval design;
I directed three raters and shipped the dataset."}
Write each section tight. Problem is two sentences that make the stakes obvious — no setup, no history; lead with what was broken. Method is four bullets, not four paragraphs; a reader should grasp the whole pipeline at a glance, and "synthetic/public data" belongs right there so nobody wonders about confidentiality. Result pairs one qualitative claim with the eval that backs it — the eval is what turns a boast into a fact, so link it. Your role is the most-skipped and most-important section: separate what you owned from what the team did, because a lead is hired for ownership, and vague "we" language reads as someone who was in the room but not driving.
Three homes, in order of how much you need them. A clean PDF of the one-page case study is non-negotiable — it's what you attach to an application and slide across a table. A GitHub repo is where the code and synthetic data live so a technical interviewer can actually run your eval; a repo that runs is worth more than ten that only describe. A simple personal page is optional polish — one URL that hosts the case study and links the artifacts, so "send me your work" is answered with a single line.
The repo carries most of the technical credibility, and a repo lives or dies by its README. A good one opens with a one-line summary of what the project proves, then states the problem and the result up top (most readers stop there). It explains the data is synthetic/public and confidentiality-safe. It gives exact run instructions — clone, install, one command — that you have re-run from a clean checkout. It shows a sample of the output (the per-slice report, an example row) inline so a reader sees the result without running anything. And it links back to the one-page case study. A README that buries the result under setup instructions has the edit backwards.
The fastest way to kill technical credibility is a repo that doesn't run. Before you publish, clone it into a fresh folder, follow your own README line by line, and confirm it produces the output you claim. If it doesn't run for you from scratch, it won't run for them — and "it works on my machine" is the opposite of the impression you're building.
Run this before the binder leaves your hands. Every item is a yes/no you can verify by looking, not by hoping.
"Here's a one-page case study, and the eval behind it is a GitHub repo you can clone and run in a minute. It's all on synthetic data — the method is identical to what I run in production, just without anything I can't share." That single answer signals legibility, technical depth, and judgment about confidentiality all at once.
Take your Week 12 capstone program and produce the two artifacts a hiring manager actually touches: a one-page case study PDF, and a binder table of contents where every artifact earns its sentence. Use the lab's synthetic dataset so everything is public-safe.
case-study.pdf. Clean, one page, your name and target role and contact at the top.Artifact out: case-study.pdf plus a binder index. When both exist, "send me your work" is answered with one PDF and one URL — and the reader knows in two minutes that you ran the operation.