Three Levers,
One Loop

Most conversations about enterprise AI start with model choice. Which base. Which size. Which lab. Which recipe. That conversation is not wrong. It is the wrong place to start.

Over one continuous program, on one GPU, on one fully open 32B instruct model, we ran eighteen training rounds against a deterministic golden set with a strict promotion bar. In about a day of wall-clock time, the production pass rate moved from roughly one in two to roughly two in three. One fine-tune was promoted. The training lever accounted for less than half of the gain. The rest came from two levers the industry rarely names in the same sentence as fine-tuning: the harness that runs around the model at inference, and the evaluation discipline that decides what ships.

This essay is the read on that program. It is also, on purpose, a statement of how SAVRN builds. Three arguments run underneath it. I want to name them up front so the evidence lands where it should.

The rest of the piece is the evidence for those three claims, in that order. This is part one. It covers rounds one through eighteen. Part two will pick up at round nineteen.

We chose the base model on purpose. Ai2's OLMo 3 release is not just open weights. Ai2 calls it the model flow: the pretrained base, the mid-training checkpoints, the supervised fine-tuning stage, the DPO stage, the reinforcement learning stage, the training code, the data recipe, and the datasets themselves, all released together under permissive licenses (Ai2 · OLMo 3). The 32B instruct variant we tuned is pretrained on the Dolma 3 mix, about six trillion tokens of web, science, code, and math data, and post-trained on the Dolci suite. Checkpoints from each training stage are published alongside the final model (Hugging Face · Olmo 3.1 32B Instruct).

That level of openness is the precondition for everything below. A closed API gives you a knob. An open-weights release gives you a model. A fully open flow, weights plus data plus training code plus intermediate checkpoints, gives you the same engineering surface the original lab had. You can reproduce their recipe. You can resume from any stage. You can diagnose failures against the actual pretraining mixture. You can align your fine-tune to the schedule the base was trained under.

None of the eighteen rounds below would have been possible on a rented commercial model. Only the first few would have been possible on a weights-only release that ships without its training data or recipe. Two of the highest-ceiling levers still in front of us exist only because the entire flow is open: a multi-epoch fine-tune aligned to the base's own published schedule, and reinforcement learning against verifiable rewards.

The industry is moving in this direction for reasons that are not ideological. AT&T now routes 40 percent of its employees' AI requests through open-source models and is targeting 60 to 70 percent in the coming years. On coding and some other advanced tasks it reports cost cuts of as much as 56 percent with a 2 percent decline in quality, using model routers to send each task to the cheapest model that can do the job (PYMNTS, Aug 20, 2026, reporting first carried by The Information). The cost story is real. The compounding story is the one that decides who is still competitive in three years: a team that owns the full flow gets a better model on the same infrastructure every quarter.

SAVRN's position is that the complete model, the organized proprietary data, the dataset-to-training pipeline, and the owned training and inference infrastructure are one apparatus, not four line items. I made the case for that in The Ownership Divide. This essay is what it looks like on an ordinary working day.

The training lever is the one every team reaches for first. It is also the noisiest, the most expensive per unit of movement, and, below a certain data scale, the one with the lowest ceiling. The harness lever is nearly free, compounds across every future model version, and in our program moved the production number more than training did. The evaluation lever produces no score improvement on its own. Without it, the other two are indistinguishable from noise.

An engineering-first program pulls all three. The rest of this section walks each one, with the evidence.

Eighteen rounds. One base model. One GPU. A corpus in the low thousands of rows after quality filtering. The recipes spanned aggressive LoRA, gentle LoRA, completion-only supervised fine-tuning, Direct Preference Optimization on preference pairs, continued training from the current winner, and harness-aligned prompt formatting. LoRA is the standard parameter-efficient path for enterprise fine-tuning. It freezes the base weights and trains small low-rank adapters, cutting trainable parameters by orders of magnitude while keeping most of the quality of full fine-tuning (Hu et al. · LoRA, ICLR 2022). DPO is the standard preference step. It replaces the reward model and the PPO loop with a single closed-form loss over chosen-versus-rejected pairs (Rafailov et al. · DPO, NeurIPS 2023).

The harness is everything the platform does around the model at request time. Skill routing. Retrieval. Deliverable contracts. Length rules. Exemplar pinning. Output validation. Repair loops. It is deterministic code, not weights.

In the same day the training lever moved the production pass rate by about six points, the harness lever moved it by about seven, on the same model. Four harness changes did most of that work.

Evaluation is the lever that produces no visible score movement and without which the other two are guesswork. Ai2's Tülu 3 post-training work makes the point explicitly. Its recipe treats a standardized evaluation suite for development, decontamination, and final evaluation as a first-class stage alongside data curation, SFT, DPO, and RL (Lambert et al. · Tülu 3).

Four evaluation decisions changed how our program was run.

Naming three levers is easy. Pulling the right one on the right day is the actual work. It is also the argument for building this way in the first place.

Consider what each lever costs. A training round on a 32B model consumes GPU-hours, engineer attention on recipe design, corpus curation cycles, and calendar time waiting for a run to finish before the next one can be evaluated. A harness change is typically a few hundred lines of deterministic code, a code review, and a deploy. An evaluation change is a golden-set edit and a re-run of the harness. The cost ratio between the three, at our scale, is roughly two orders of magnitude. In our program the two cheaper levers accounted for the majority of the production gain.

That ratio is why the training lever should be the last resort, not the first move. A team that fine-tunes before it has instrumented the harness and pinned down the noise floor on its eval is buying signal it cannot read with money it did not need to spend. A team that has done both is running each fine-tune as a targeted intervention against a failure that has already been ruled out at the harness and eval layers.

The failure walls in the training table make the point concrete. A strict JSON output shape and a length-and-grounding requirement on memos did not move under any of eighteen training recipes. Both moved once they were addressed at the harness layer, on the same weights, in a fraction of the time. That is what leverage looks like. The cheapest lever, applied at the correct layer, produces the movement the expensive lever could not.

None of this argues against fine-tuning. It argues for fine-tuning as a precision instrument rather than a first response. The round we did promote was a supervised fine-tune with a revised recipe and a low learning rate. A small, targeted intervention that cleared the bar and survived a confirmation run. It moved the model where the model needed to be moved. Everything else was a harness or evaluation problem in disguise.

The queue at the end of the eighteenth round is deliberate.

The first lever is a multi-epoch supervised fine-tune aligned to the base model's own published training recipe: the same optimizer settings, warmup schedule, weight decay, and epoch count that OLMo-core uses in its reference SFT configuration. Three epochs instead of one. Linear warmup over the first three percent. Weight decay at zero. This is the lever a fully open release specifically enables. You align your fine-tune to the schedule the base was actually trained under, rather than guessing.

The second is Reinforcement Learning with Verifiable Rewards against the golden checks themselves. RLVR was introduced in Tülu 3 as a way to train language models on tasks where correctness is checkable by a verifier rather than judged by a preference model. Ai2 reports gains of up to 1.7, 3.3, and 1.3 points over the DPO checkpoint on MATH, GSM8K, and IFEval when RLVR is added (Lambert et al.). The optimizer we plan to use is Group Relative Policy Optimization, the critic-free variant of PPO introduced in DeepSeekMath. It estimates the advantage from a group of sampled completions instead of a learned value function, the same optimizer behind DeepSeek's R1 reasoning training (Shao et al. · DeepSeekMath (GRPO)). Our deterministic golden checks are exactly the verifiable rewards RLVR was designed for.

Both levers exist because the base model's full flow is open. On a closed model, neither is available. On a weights-only release, only the first is, and it has to be reverse-engineered. This is the compounding story in a single paragraph. The deeper the openness of the base, the more levers you have, the more precisely you can pull each one, and the further the same team on the same infrastructure gets in the same quarter. Part two covers what those rounds returned.

Each layer is instrumented. Each failure is diagnosed at the layer responsible. Each fix compounds. That is what vertical integration is for. It is not a slogan. It is the reason eighteen rounds in one day produced a promoted model plus a characterized noise floor plus a characterized corpus ceiling plus a harness that carries forward, instead of eighteen inconclusive fine-tunes.

Eighteen rounds in one day is not a story about a fine-tune. It is a story about a loop. One that diagnoses each failure at the layer responsible, fixes it there, and lets the gains compound across every model that comes after. That loop is the product. The weights are one output of it. This is how SAVRN builds.