These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.
A local model hit 24 out of 24 on the benchmark I had spent days trying to fix. I did not promote it, and I did not even let it see the final test. That sounds overly cautious until you look at how easy it is for an evaluation to stop measuring what you think it measures.
The model was a 4-billion-parameter local candidate running on the same Windows PC I use every day. I was trying to teach it a narrow judgment boundary inside Eterna: supporting information can be persuasive, but it must not override the authoritative state that actually governs a decision. The existing comparator was already strong at 23 of 24 development cases. One miss still mattered because it represented exactly the kind of failure I care about in an operating system: a model seeing plausible evidence and treating it as stronger than the source that actually owns the truth.
The interesting part was not whether I could make that one case turn green. I eventually did. The interesting part was learning how many different ways a model can appear to improve while becoming less trustworthy.
The first correction worked — and made the model worse
The first narrow supervised correction was very good at the behavior I had targeted. It repaired the explicit relationship I was trying to teach, and then the wider result collapsed. Productive performance in the evaluation mode I was using fell from 23/24 to 18/24. The model had learned to be more decisive around authoritative evidence, but it also started choosing in cases where no authoritative owner evidence existed and the correct behavior was to abstain or request more evidence. One of those selections crossed the unsafe-adoption boundary as well.
The training loss was extremely low and the target behavior improved. Neither fact made the candidate better. This is the stability-plasticity problem in a practical form: plasticity is the ability to learn something new; stability is the ability to retain what was already right. If you measure only the behavior you are trying to add, you can mistake successful adaptation for successful improvement.
That gave me the first rule I would keep from the campaign: every targeted improvement needs a retained-behavior budget. If the new behavior costs an old behavior you still need, the cost has to appear in the evaluation immediately. Otherwise the model can improve forever by quietly moving the damage somewhere you are not looking.
A benchmark changes the moment you start training against it
The next problem was subtler. I knew the one failing case in the 24-case set. I had examined it, used it to decide what to train, looked at candidate results and changed the next experiment because of them. The benchmark was still useful, but it was no longer a truly blind final test. It had become part of the development loop.
That distinction is easy to lose because the file itself has not changed. The questions can be identical and the scoring can be identical, but the epistemic role has changed. Once a benchmark influences what data you create, what method you choose or which candidate you keep, performance on that benchmark is partly performance against information you have already consumed.
So before building the next training corpus, I built a new final evaluation first: 60 cases covering the same kinds of authority decisions from different angles. The raw cases were kept away from the part of the workflow creating training data. Candidate recipes had to be frozen before the seal could be opened, and once I saw the result I would not train against it afterward and still call it final evidence. The useful part of a blind holdout is not the number of questions; it is the fact that it can still tell you something you did not already optimize for.
I separated “safe” from “productive”
The campaign also forced me to separate safety from usefulness. If a model has enough authoritative evidence to select the correct option but abstains instead, that may be safe, but it is not productive. Reverse it and the problem changes: if the model confidently selects something when the available evidence does not authorize any selection, it may look productive because it gave an answer, but it is not safe.
I did not want one headline score hiding those different failures. The current gate therefore tracks both. A candidate can be 24/24 safe and still fail because it unnecessarily abstained. It can be highly productive and still fail because one accepted decision crossed an authority boundary. A production model needs the intersection: act when the evidence earns action, and stop when it does not.
That distinction became important again in the newest experiment, because the model did not make a dangerous choice. It simply failed to make a choice it had enough evidence to make. The result looked conservative, but conservative was not the same as improved.
Preference optimization helped, but not in a straight line
After the supervised correction overfit the target, I moved toward preference-based methods anchored to the stronger 23/24 model. Instead of simply showing the model more examples of the desired answer, preference optimization trains on pairs: a response I want versus a plausible response I do not. The reference model acts as an anchor so the new policy does not drift arbitrarily far from behavior that was already useful.
In the TRL implementation I was using, beta controls how strongly the policy is constrained relative to that reference; higher beta means less deviation. That makes beta more than a generic tuning knob in this experiment. It is one way of expressing how much change I am willing to buy in exchange for the correction.
One anchored preference candidate preserved the strong behavior extremely well: 23/24 productive, 24/24 safe, with no unsupported selections. The original miss was still wrong. The candidate was clean, stable and safe, but it was not an upgrade. Then another method finally reached the number I had been chasing: 24/24 on the strict founder-boundary benchmark while preserving the retained behavior I was checking. That should have been the moment to celebrate.
It failed the next gate.
The 24/24 candidate still failed an older adversarial suite
I had an older 12-case adversarial set designed to stress the same relational boundary through a different evidence formulation. The 24/24 candidate scored 11/12 there. Nothing catastrophic happened and it did not suddenly become unsafe; it simply failed to improve a boundary it was required to preserve.
So the candidate stopped, and the 60-case blind seal remained unopened. That is the point of gates. A gate is a promise you make before seeing the result about what evidence will count afterward. Without that promise, a good-looking number creates enormous pressure to reinterpret the rules in its favour.
I could have opened the final 60 cases anyway and learned something about that candidate. I also would have spent some of the blindness of the evaluation on a model that had already failed admission. I would rather preserve that test for a candidate that earns the right to see it.
The next two-hour run made the lesson even clearer
The newest experiment finished while I was working on this editorial set. The previous development-fixing candidate had shown that a preference method could learn the 24-case correction but fail to generalize to the older adversarial formulation. The next run tested a causal hypothesis: reduce the reference constraint and see whether a less-constrained DPO step generalized the correction better.
Everything else stayed frozen: the same 72 preference pairs, source adapter, learning rate of 1e-6, one epoch and seed. Beta moved to 0.1. The run trained for about one hour and fifty-five minutes and came back 23/24 productive and 24/24 safe.
The one miss was revealing. In an authoritative-but-not-adopted policy case, the model did not choose the wrong candidate and did not make an unsafe adoption. It abstained. Safe, but not better. The experiment was eliminated at Gate 1: no retention sentinel, no Gate 2, no Gate 3 and no blind seal. A weaker reference constraint did not produce the generalization gain the hypothesis predicted. It produced a negative result, which is exactly what a controlled experiment is supposed to be allowed to do.
Training is not the product; admission is the product
This changed the way I think about local model work. It is tempting to treat training as the main event: the GPU spins for two hours, the loss falls, a new adapter appears, and the natural question is how good the model is now. For an operational system, that is only half the question. The harder question is whether the evidence is strong enough to let the candidate change anything real.
That requires an admission process around the model: a development benchmark, retained-behavior checks, adversarial cases, clear safety/productivity criteria and a final holdout that has not been spent during iteration. Training creates a candidate. The surrounding evaluation system decides whether the candidate deserves authority.
This is why negative results are not failed work. The 18/24 over-correction told me the new behavior was destabilizing unresolved cases. The stable 23/24 preference candidate told me the anchor preserved behavior but underlearned the correction. The 24/24 candidate told me the development fix had not generalized to an older adversarial formulation. The newest 23/24 run told me that simply loosening the reference constraint was not the missing ingredient. Each rejection removed a bad explanation, which is progress even when the production model does not change.
The most important test may be the one you have not run yet
OpenAI's recent guidance on trustworthy evaluations makes a similar point at a broader scale: evaluation results can be distorted by contamination, broken tasks, reward hacking, refusals and the harness around the model. A score is evidence only to the extent that the evaluation still supports the claim you think you are making.
That has become the practical standard I want inside Eterna. If I know the benchmark and keep adapting to it, I call it development evidence. If a behavior is safety-critical, I measure safe and productive outcomes separately. If a candidate improves one boundary, I test what it was supposed to retain. If it fails an earlier gate, I stop before spending later evidence. If the final test is supposed to be blind, I protect its blindness like any other finite resource.
The local model still has no production role, and the final 60 cases are still sealed. At this point, that unopened file is one of the most valuable artifacts in the entire campaign — not because I expect it to give me a perfect score, but because it still has the ability to tell me I am wrong.
AI disclosure: This article is based on my own Eterna build notes and experience. I used AI as a drafting and editing partner; I reviewed the final piece and stand behind the technical substance and claims.
Top comments (0)