Evals Are Expectations Written Down

You can't blame the model for missing a target you never set.

When something goes wrong in a team, the first question is usually "who dropped the ball?" In my experience the better question is "did anyone say where the ball was supposed to go?"

I've managed engineers for a long time, and I've interviewed hundreds of them. The pattern I see most often has nothing to do with talent. Accountability fails when nobody set clear expectations. People can't hit a target they can't see, and a manager who only explains the target in the performance review is grading people, and calling it management.

Now I see the same thing with AI, almost word by word.

Evals are expectations written down.

If you never defined what a good answer looks like, you don't get to be disappointed in the model. You only get to be surprised, and surprise is a bad sign for a manager and for a product.

Feedback should never be a surprise

One belief I've kept from every team I've led: feedback should never be a surprise. If someone hears for the first time in a review that their work wasn't good enough, I failed earlier, in a 1:1 that didn't happen or a conversation I avoided because it was uncomfortable.

The fix is boring. You agree on outcomes up front. A task list tells you what people were busy with; outcomes tell you if anything changed. Then you check in often enough that the gap between "what we expected" and "what happened" never gets big.

Replace "person" with "model" and the paragraph still works.

Many teams building with AI treat the model like a new hire they never onboarded. They write a prompt, look at five outputs, say "looks good", and ship. Weeks later a user finds a bad answer, and everyone stares at the model like it betrayed them. But nobody ever wrote down what it was supposed to do. There was no expectation, so there is nothing to be accountable to.

What this looks like at Peripheral

At Peripheral we build an AI adviser for investment and strategy professionals. It reads documents, emails and transcripts, and it checks what management says against outside evidence. In that kind of product, "looks good" is not a standard. An answer that sounds confident and cites nothing is worse than no answer at all.

So our expectations are specific. A claim has to come with a source. The source has to actually say what we say it says. If the evidence is thin or contradicts management, the answer should say so instead of smoothing it over. We don't hope the model picks these up on its own. We write them down and test against them.

That discipline pays off in a place people don't expect: model releases.

We route across several providers, including Anthropic, OpenAI and Google, with automatic fallback when one of them has a bad day. A new model shows up almost every week now. For us that is mostly a test run. We put the new model on our real tasks, compare it against what's in production, and it only gets traffic if it does better on the things we care about.

None of that works without evals. Without them, every new model is an argument between people with opinions. One engineer tried it on three prompts and loved it, another tried it on two and hated it, and the decision goes to whoever talks louder in the meeting. With evals, the numbers settle it.

Gut decides what to build, evidence decides if it's good

I don't want to make this sound like everything should be measured. It shouldn't, at least not at the start.

A first version of anything is mostly conviction. You don't have users, you don't have data, you have a point of view about what matters. That is your gut, and you should trust it. If you wait for evidence before building version one, you will never build version one.

But once the thing is live, and especially once there is a model under it that keeps changing, your gut stops being a good judge of quality. Mine included. I have been sure about a feature we built, and the evidence later told a different story. That's fine. That is what evidence is for.

The honest move is to know which mode you are in. Use your gut to decide what to build. Use evidence to decide if it's good. Problems start when teams mix them up: they use data to avoid making a bold call early, or they use gut feeling to approve a model swap later.

Evals are where you switch from one mode to the other. Writing them forces the conversation that the gut can skip: what exactly do we mean by "good"?

Writing your first evals as a team

You don't need a platform or a framework to start. You need an afternoon and the people who understand the work. Here is the checklist I'd use.

1. Pick one task, not the whole product. Choose the thing users rely on most, or the thing that scares you most when it goes wrong.
2. Collect 20 to 50 real examples. Real inputs from real usage, including the ugly ones. Invented examples are always too polite.
3. Write down what good looks like, in plain words. "Every claim has a source." "Says 'I don't know' when the documents don't cover it." If the team can't agree on the sentence, you just found your real problem.
4. Write down what unacceptable looks like. Often easier and more useful. Made-up citations, confident wrong numbers, ignoring the user's question.
5. Have a human grade the first round. Before automating anything, people should score outputs by hand. You will learn more about your product in that hour than in a week of dashboards.
6. Then automate what you can. Simple checks first (is there a citation, does it point to a real document), model-graded checks after, and keep spot-checking the graders.
7. Run them on every change. New prompt, new model, new retrieval setup. Same evals, same bar.
8. Add every bug to the set. When something breaks in production, it becomes an example. Your evals should get harder to pass over time.
9. Review them like you review goals. Every few months, ask if the expectations still match what users actually need. Expectations go stale, for people and for models.

That's it. The first version will be incomplete, and that's okay. An incomplete written expectation is still better than a complete one that only lives in someone's head.

The manager's job didn't change

When I joined Pager as the first employee and we grew the team, I learned that most problems I blamed on people were really problems with what I never made clear. It took me longer than I'd like to admit.

Building with AI is giving me the same lesson again, faster and with less patience. The models are capable. They are also not mind readers, which puts them in the same category as every engineer I've ever worked with, and as me.

So before you blame the model, write down what you expected from it. If you can't, you have your answer, and it's a good place to start.

Emi