Training, or post-training?
“Post-training” is an operational context, not a technique class. It marks the point after which a model already exists and may carry obligations.
Where the boundary actually falls
The line is training, not deployment. A technique is in scope once a model exists — the paper's rule is a model "that has been trained and may already be deployed". Adaptation before a model ever ships counts just as much as adaptation in service.
Out of scope
Training
building the model from
scratch
In scope — 48 techniques
Before it ever ships
Specialising a foundation model for a task, aligning it, compressing it to fit, extending it to a new modality — all of this happens to a trained model that has never been deployed.
Once it is in service
Repairing drift, adding new knowledge, personalising to a user, removing data on request — adaptation to a model already carrying obligations.
Drift is one reason among many. Of the taxonomy's 19 adaptation goals, exactly one is drift remediation. The rest — specialisation, alignment, safety, efficiency, privacy, knowledge removal and so on — have nothing to do with the world changing underneath the model. See all 19 goals.
Five things that all look like “updating the weights”
Each pair below shares most of its profile. The column that matters is the last one: only a dimension where the two share no value actually separates them.
| Pair | Identical on | Overlapping | Separated by |
|---|---|---|---|
| Training vs Retraining | D1, D4, D5, D6 | — | D2, D3 |
| Retraining vs FT (full) | D1, D4, D5 | D6 | D2, D3 |
| FT (full) vs FT (partial) | D1, D2, D4, D6 | — | D3, D5 |
| FT (partial) vs PEFT (LoRA, adapters) | D1, D3, D4, D6 | D2, D5 | — |
| Retraining vs CL | D1, D3 | D6 | D2, D4, D5 |
| FSL vs ICL | — | D2, D3 | D1, D4, D5, D6 |
Computed from the taxonomy data
Partial FT and PEFT have no separating dimension: PEFT strictly extends Partial FT rather than differing from it. A two-state comparison would report them as “separated”, which would be wrong.
What drift means
Covariate shift
The inputs change; the input–output relationship holds.
Concept drift
The input–output mapping itself changes, invalidating learned behaviour.
Prompt drift
How people interact with the model evolves.
Alignment drift
Static behaviour diverges from shifting safety or cultural standards.
Monitoring for drift may be treated as a safety and reliability control, not only as a technical optimisation.
What is in scope — and what is not
Core
Methods applied after training that modify parameters, inference context, or outputs — fine-tuning, PEFT, alignment, RAG, knowledge editing.
Boundary extension
Training-time data-pipeline strategies applied to an existing model as an adaptation mechanism — augmentation, curriculum learning, active learning. Marked pipeline-mediated so their status stays visible.
Excluded
Deployment-layer controls: output guardrails, content moderation, watermarking, post-processing, human-in-the-loop review. Also foundational learning paradigms and low-level optimisations.
Why the exclusions matter. Deployment-layer controls are excluded because they do not modify the model's parameters, inference context, or adaptation pipeline as this taxonomy defines them. That is a scope boundary, not a claim of regulatory irrelevance.
Two names, one scope
Model adaptation is the academic umbrella, used when discussing technical properties. Post-training techniques is the industry and regulatory framing, used when the point is that the model already exists and may carry obligations. Same 48 techniques either way.