Building with LLMs: design the harness
An LLM is a probabilistic material, not a deterministic component. Building product with it means wrapping the model in a harness: the evals, guardrails, routing, and audit journals that hold it to a standard.
I wrote the rubric before I wrote the first prompt, and it cost about two weeks of demo time. Stakeholders were waiting on a pipeline that produced reports. What they got in week one was a scoring sheet: six criteria a senior researcher would judge a report on, plus an argument for why the sheet had to exist before any prompt did. Two weeks is the price of this advice. If your runway to a demo is shorter than that, you may reasonably decide you cannot pay it, and I would rather you had the number than took the advice as free.
Here is what the two weeks bought.
01A model is a material, so build the rig around it
Send a normal software component the same input twice and the same output comes back. Send a model the same prompt twice and you can get two answers, one of them wrong and fluent about it. That is the grain of the material. It is not a defect you patch out. So you stop treating the model as a component and start building the thing that holds it steady: a harness, in the plain mechanical sense of the word, the rig that takes the load and keeps the model from drifting off course.
On Articos, an AI user-research platform, that rig is the product. The model inside it is the part you can swap.
02The rubric, and what it became once it ran
Two of the six criteria I can put in front of you as I wrote them. One asks how specific the proof behind a claim is, because a theme resting on a paraphrase of three interviews reads like a finding and is not one. The other asks whether the model ever saw the hypothesis it was meant to test, because a report written by a model that already knew the answer is a mirror.
What follows is the rubric in the form that matters more to you: the checks it turned into. Each runs on every draft, and each can send it back.
- Source trace. A theme fails when the line supporting it cannot be resolved to a named paragraph in a named source. Sounding sourced does not pass.
- Coverage bar. A section has to hit a numeric citation coverage threshold before it counts as done, so prose that drifts off its sources goes back rather than out.
- Refuting pass. The blueprint stage has to go looking for sources that contradict the story taking shape. Nobody finds contrary material by accident.
- Unanimity cap. The synthesis stage lowers confidence when every source agrees, because agreement that clean usually means the model flattened a real split.
- Pin protection. The repair stage may rewrite weak prose and may not drop a source pin. A style edit is never allowed to cost you a trace.
- Cross-model critique. Whichever model drafts a section does not grade it. A different model runs the critique. Models are soft markers of their own work.
Each rule is small. Stacked, they are what makes an output something a researcher will put their name on.
03What it caught
Forty-six studies have gone through the harness. Of those, 36 passed the source-trace check end to end, and that check is narrower than it sounds: it fails any theme whose supporting line cannot be pinned to a specific paragraph in a specific transcript. The other ten failed on exactly the issues the rubric had named, before a human read a word of them. That is the part worth copying. Ten weak reports went back into repair instead of into a client meeting, and none of them cost a reviewer the time it takes to read a plausible report closely enough to start distrusting it.
Theme recall came out at 75% under a fixed judge, and I read that as a limit rather than a score. Here is the part that took me a while to accept. Bare prompting scored higher on recall, 85%. Ask a model for themes with no structure at all and nearly every finding a real research team published turns up somewhere in the answer. It turns up buried in roughly 141 themes at 6.7% precision, sixteen pieces of noise for every real one. The harness returns 18 themes at 42%. So recall is close to free, and precision is what the architecture actually buys. It filters bad reports. It does not promise you complete ones.
04Routing, because no model is best at everything
Some models are stronger at pulling structured fields out of messy text, some at long-form synthesis, some at short critique that does not flatter. So each stage goes to whichever model is strongest for that stage. Which model runs where is a call you make and record, not an accident of which API key was nearest to hand, and routing across models keeps the critique honest for the same reason you do not ask a writer to mark their own paper.
05The journal is what makes any of this checkable
Every run keeps an audit journal: which model ran each stage, which guardrail fired, which check failed and what the repair did, which claim maps back to which source paragraph. When a reviewer asks how you know, you point at the record.
That record is also where the limit shows up.
A trace proves where a line came from. It does not prove the line describes anyone.
06What the harness does not buy you
Everything above is about whether the system can show its work. None of it settles whether the work is right. A theme can trace cleanly to a real line in a real transcript and still describe nobody your product needs to care about. Auditability and validity are different properties. The numbers here speak to the first. If you build this way, keep saying so out loud, because a careful record around a wrong answer is its own kind of trap.
The other thing the harness does not fix is fluency. Without an external target, a model optimises for prose that reads well, and a senior reader drops a fluent report in the first paragraph without being able to say why. The rubric is how you find that out in a test run rather than in front of a customer. When the system cannot defend a report against its own rubric, refusing to ship it is the behaviour you want.
07One thing to try this week
Pick the failure your pipeline produces most often. Write the check that would have caught it, make it executable, and run it over whatever runs you still have stored. You will learn two things in an afternoon: whether the failure is as common as it feels, and whether you can state it precisely enough for a machine to test. The second is usually the hard part. It is why the rubric took two weeks.
What I still cannot tell you is which of the six criteria does most of the work. Each of the 11 failures names the rubric line it broke, so the answer is sitting in the journal, and I have not gone back and counted.
For the design side, Designing AI Behavior covers the behaviour this rig holds in place: confidence caps, the critique and repair loop, and the AI proposes, person decides handoff. Research → Product → Code sets out the order I work in, and the build itself is in the Articos case study.
08References
- UX Design Innovation: Challenges for Working with Machine Learning as a Design Material
- Defeating Nondeterminism in LLM Inference
- Your AI Product Needs Evals
- Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences
- Measuring Attribution in Natural Language Generation Models
- Evaluating Verifiability in Generative Search Engines
- Towards Understanding Sycophancy in Language Models
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
- LLM Evaluators Recognize and Favor Their Own Generations
- RouteLLM: Learning to Route LLMs with Preference Data
- Auditing large language models: a three-layered approach
- Why Language Models Hallucinate
09Further study
Branching by what you are actually trying to do next.
If you are about to write your first rubric.
- Your AI Product Needs Evals — the practical starting sequence, from looking at failures to executable checks; read before writing a single criterion.
- Who Validates the Validators? — expect your criteria to change once they meet real outputs; drift is the process working, not failing.
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — what an automated grader gets wrong, catalogued, before you trust one to enforce your rubric.
If a model is grading its own work.
- LLM Evaluators Recognize and Favor Their Own Generations — self-recognition causally inflates self-scores; the experiment behind the cross-model critique rule.
- Towards Understanding Sycophancy in Language Models — graders bend toward agreement because training rewarded it; why clean unanimity should lower your confidence.
- Why Language Models Hallucinate — the incentive analysis: evals that punish abstention breed confident guessing, so build ones that do not.
If your reports cite sources and you want to know what that proves.
- Measuring Attribution in Natural Language Generation Models — the precise definition of "attributable" a source-trace check needs before it can fail anything.
- Evaluating Verifiability in Generative Search Engines — measured citation coverage in shipped systems; the gap between sounding sourced and being sourced, in numbers.
- Auditing large language models: a three-layered approach — the layer above per-output checks; what a run journal has to record for an audit to mean anything.