Read together, those point one direction: serious fine-tuning now happens on open-weight models that you run — and own — yourself. Venture capital has a name for the research-company version of this shift: neolabs, companies built on a domain-specific corpus, a proprietary training loop, and a verifier, betting that value has moved from pretraining to what happens after. SAP paid over €1 billion for one of them this year.
But the same shift is happening, more quietly, inside ordinary enterprises — and it's creating a problem almost nobody is writing down.
Every fine-tune is a fork
A fine-tune is not a setting. It's a build event. Take a base model, apply your data with a method, and you have produced a new model — one whose knowledge and behavior differ from the original in ways that depend entirely on what you fed it and how.
Which means every fine-tune has a lineage: which base model, at which exact version; what dataset, from where, under what license; what method, with what parameters; what was evaluated before it shipped, and what wasn't. That's four or five facts per variant. Now multiply. The frontier era had a handful of models built by a handful of labs. The fine-tuning era has one enterprise producing dozens of variants a year — a fork for support, a fork for underwriting, a fork per region. Each one a model. Almost none of them with a record.
A model you fine-tuned is a model you built
Ownership is the point of fine-tuning — your data, your advantage, your model. But building comes with the builder's questions, and they arrive whether you prepared or not. What data produced this variant's behavior? Was any of it licensed, poisoned, or contaminated? Did the tune degrade the safety behavior the base model shipped with? Which of your forty variants is the one the auditor is asking about?
Regulation is moving the same direction: under the EU's guidance for general-purpose AI models, a significant enough modification can shift documentation duties onto whoever made the modification. Fine-tune hard enough and you're not a customer anymore — you're a provider, with a provider's paperwork.
The record that answers all of this already has a name: model-build lineage — the AI bill of materials. Fine-tuning just multiplies how often you need one. Fine-tune lineage is the same record, scoped to a modification: base-model hash, dataset, method, evals, date — signed, and verifiable by someone who doesn't trust you.
The custodial catch
Here's the irony of the boom. The platforms teaching everyone to fine-tune are custodial: your data and your training run live on their infrastructure, and the record of what happened is their dashboard. For a startup iterating on a product, that's a fine trade. For a bank, a hospital, or an agency, it recreates exactly the dependency fine-tuning was supposed to end — with your most sensitive data in the training set this time.
And rented capability can be withdrawn. OpenAI's fine-tuning customers are living that right now: a capability they built workflows on, deprecated on someone else's schedule. We made this argument about sovereignty already — own the weights, own the build record, own the exit — and the fine-tuning boom is the argument happening in public.
How STEAV handles it
CID treats a fine-tune the way it treats any build: as a pipeline run in your environment — on-prem, air-gapped, or sovereign cloud — with every stage signed into a tamper-evident record. The base model enters by hash. The data is gated before it trains. The result is benchmarked and validated before it ships, and the whole chain — base, data, method, evals — lands in a lineage record an outside auditor can verify without trusting our dashboard or yours. When the data can't leave its owners, federated training runs the same loop across parties without pooling it.
Take the full loop in CID. Start from a base model pinned by hash. Train LoRA adapters against it — cheap, enumerable variants, each its own gated run rather than a full retrain. Then blend the winners: CID's elixir stage averages the adapters that each solved part of the problem into one stronger variant — a model soup — with the recipe itself recorded as a build step: versioned, checksummed, replayable byte-for-byte. Attest the result — base hash, datasets, adapter configs, blend recipe, eval scores, all signed into the lineage record — then deploy through the same pipeline that produced the evidence, so the model serving traffic is provably the model the record describes. Attestation without deployment is a certificate in a drawer; deployment without attestation is a leap of faith.
Fine-tuning is how you start owning a model. Lineage is how you prove what you own.
Why this matters now
The boom is young, and the variants are piling up faster than anyone's records. The enterprises that treat each fine-tune as a build event — recorded, signed, provable — will spend their audits handing over documents. The ones that treated it as a setting will spend their audits doing archaeology.
Fine-tuning is how you start owning a model. Lineage is how you prove what you own.