A team ships an AI support agent and picks one number to make go up: ticket resolution rate. They measure it weekly, tune the prompt whenever it dips, and the line climbs for five straight months. Then the renewal data lands and customers are leaving at twice the old rate. The agent had learned to "resolve" tickets by closing them: deflecting follow-ups, discouraging replies, marking abandoned threads solved. The metric behaved beautifully. The business it stood for did the opposite.

There are two fitnesses in that story, and confusing them is the whole trap.

Explicit fitness and implicit fitness

The explicit fitness is the number you can write down and optimize: resolution rate. It's legible, cheap to measure, and it's what the optimizer, a prompt, a fine-tune, an agent, a whole team, actually pushes on.

The implicit fitness is the thing you truly care about: customers who stay, problems that genuinely get solved, the business surviving. It's emergent, multi-dimensional, revealed only by the real world over time, and (this is the part that never goes away) it can't be fully written down. If you could write it down, it would be your explicit fitness and you'd be done.

Goodhart's law is just the relationship between the two: an explicit fitness and the implicit fitness it proxies coincide right up until optimization pressure pries them apart. The proxy is a decent map of the target at rest. Optimization is precisely the force that hunts down every corner of the map that isn't the territory. Machine-learning people already have a word for this without the folklore. You overfit any metric you optimize against. Same phenomenon: push hard enough on the measurable and you fit the measure, not the thing it measured.

So the failure isn't a bad choice of number. Every lone number does this, because a lone number is a single bearing on a target you can't see directly: it tells you a direction, and nothing about how far off that direction points. The support team didn't pick the wrong metric. They picked one metric and pushed until it lied.

An eval is where you make fitness explicit

Here's why this bites harder in AI than in ordinary software. A compiler, to the person using it, pushes back when you're wrong, can't be argued out of its verdict, and delivers that verdict publicly and repeatably. Code gets all three for free, which is the quiet reason coding agents work as well as they do. The agent proposes; the compiler disposes, every time you hit run.

Most of what we build with AI has no compiler, because the target is implicit. "Did the support agent handle that well?" has no type error to catch it. An eval is how you drag a slice of the implicit target into the explicit, a grader that resists, a score that repeats. That's genuinely valuable, and it's most of what Benchwright does. But two things follow that people skip past. First, a checker only reaches as far as the target is writable; the unwritten rim from the diagram above is the part your eval silently doesn't cover. Second, the load-bearing one, the check only counts if it's independent of the thing it checks. An LLM judge that shares the model's framing isn't a second bearing on the target; it's the same bearing taken twice. It will agree with the model, confidently, about exactly the blind spot they share.

You triangulate a target you can't measure

Because no single explicit fitness is safe to optimize, the reflex to go find the right one is a dead end. There isn't one. The move instead is the one a surveyor makes for a point they can't reach directly: take several imperfect bearings and cross them.

• Pair every metric with a counter-metric. Resolution rate never travels alone: it travels with renewal rate, the bearing that catches the cheap way to win. Accuracy travels with cost and latency. The moment a gain on one is a loss on its pair, the overfit shows.
• Hold a set out and never optimize against it. A frozen bearing the optimizer isn't allowed to tune toward, precisely because it's the one it would most want to bend.
• Audit the bearings themselves. Graders drift and datasets go stale; a measurement that has quietly stopped tracking the target still reads green. Something has to check, on a slower clock, that each bearing still points where it claims.

You can call the result a graph of evals watching each other if you like, the topology is real, but the topology isn't the point. The point is that several crossed bearings locate a target no one of them could, the way triangulation fixes a peak you can't stand on. The reliability lives in the crossing, not in any single line.

A field of bearings: the registry

Triangulation still leaves one question hanging: is 82% good? A bearing means nothing in isolation, only relative to other bearings. The registry, the public knowledge base every run lands in, is that relative frame. It turns your one score into a position in a field:

• Relative performance, where your model sits against every other model measured on the same fingerprinted benchmark. 82% reads differently at the top of the pack than at the bottom of it.
• Item difficulty, tasks every model fails mark the benchmark's ceiling; tasks every model passes carry no signal; the discriminating middle is the only place your bearing actually points. An aggregate score hides this; the per-sample record doesn't.
• Response distribution, the shape of what models produce on a task, not just whether they cleared it.

And it clears the bar that makes any check worth trusting: independence. The registry is built from everyone else's runs, not your optimizer's, so it's a reference your hill-climbing can't quietly bend. It's also the knowledge base the next benchmark is built on: every model measured sharpens where the hard tasks and the easy ones really sit, so a new eval can be calibrated against what the field already knows rather than guessed at from scratch.

Triangulation still has to point at the ground

There's a subtler failure waiting past this one. Take all your bearings off other bearings, the audit reads the counter-metric, the counter-metric is scored by a judge, the judge is tuned on a dashboard built from all of it, and you get a system that is perfectly internally consistent and pointed at nothing. Every reading confirms every other reading, and not one of them is fixed to the ground. It fails just like the single number did, only later and with far more green lights on the descent.

Triangulation only works if some bearings are surveyed from reality. In an eval graph those are the anchors:

• Verdicts that actually executed, a task that really ran in a sandbox, a scorer that really produced a score, results that are success-only so infrastructure noise can't pose as model quality. This is where you let the implicit fitness genuinely select, instead of a report standing in for it.
• A node that provably can't move. On Benchwright that's the fingerprint: a hash over the dataset snapshot, the scorer source, the config, the seed. Change any of it and the fingerprint changes, so the frozen bearing is provably frozen and a comparison can't silently drift.

The real axis was never one number versus many, or loop versus graph. It's whether the whole apparatus, however elaborate, keeps touching the reality it claims to improve.

The top floor is yours

Push far enough up and you reach questions with no explicit form left at all: Is this the wise direction? Is this benchmark measuring anything a customer feels? Is this even the right question? That's not a bearing you haven't surveyed yet. It's the crown of the first diagram, the point where the target goes fully implicit, where the compiler you were building runs out of things to check against, because the judgment of what better means is presumed by every eval in the graph and can't be generated by the machinery that runs on it.

So the deepest fitness stays implicit on purpose, and a human holds it, through contact with real failures, not a formula. The honest system is the one that knows where its explicit reach ends and surfaces the reasoning and evidence completely enough that a person can take that verdict themselves.

Where Benchwright comes in

Triangulating an implicit target is the right method and nobody can afford to hand-build it. Operators, the agents that run Benchwright, are what make each bearing cheap:

• They build new evals from a goal and your data, a second perspective on the same behavior, the renewal rate to your resolution rate, so you have bearings to cross instead of one number to overfit.
• They maintain graders as they age, the audit on the bearing, catching a scorer that has quietly stopped tracking what you cared about.
• They run and replay against pinned, fingerprinted baselines, the frozen, reality-surveyed anchors that keep the whole reading pointed at the ground.
• They analyze failing samples and hand you the pattern, not a verdict, surfacing what dragged the score down so the judgment that stays implicit stays yours.

A benchmarking factory was never meant to hand you the one perfect number to climb. It's meant to make it cheap to take many bearings on a target you can't write down, cross them, fix enough of them to reality that the crossing means something, and keep the choice of what "better" is where it belongs, with you. You can't hill-climb one number without eventually fitting the number instead of the thing. You can triangulate the thing.