I. How training creates a checkpoint
What a training stage changes
A training stage repeatedly evaluates a computable objective and changes model parameters to reduce it. The stage starts from some parameter state—perhaps a fresh initialization or a capable existing checkpoint—and produces a new one. The objective, data, schedule, and optimization budget determine the pressure applied along that path.
Runtime input versus learned state
A prompt follows a different path. It changes the current input and therefore the computation performed with fixed parameters; ordinary inference does not rewrite the checkpoint. Prompting and In-Context Learning develops that invocation-time mechanism. Weight-updating stages include broad pretraining, continued training, and the response-oriented methods introduced in Post-training and Alignment, but those stages need not share an objective or purpose.
| Intervention | Starting state | What changes | Typical purpose |
|---|---|---|---|
| Prompting | Fixed checkpoint | Current input and activations | Specify or demonstrate the current task |
| Initial pretraining | Fresh or minimally initialized model | Parameters through large-scale prediction | Establish broadly reusable capabilities |
| Continued pretraining | Existing pretrained checkpoint | Parameters under further prediction training | Extend exposure, context, or capability |
| Behavioral post-training | Pretrained or continued checkpoint | Parameters under demonstrations, preferences, or rewards | Shape responses and task behavior |
From recorded text to parameter updates
In causal language-model training, a recorded sequence supplies many prediction events. For tokens build, the, index, the model predicts the from build, then predicts index from build the. Teacher forcing means that each prediction sees the recorded prefix rather than an earlier sampled model output. Causal masking prevents a position from reading future targets; the full mechanism is developed in Predicting recorded successors.
One sequence, many scored positions
The model does not store the document as an ordinary database row. Each scored prediction contributes numerical pressure shared across parameters and across many examples. Consequently, a source’s influence depends on how it is sampled, tokenized, masked, weighted, repeated, and combined with other examples—not merely on whether its files appear in a corpus.
Objectives define the prediction problem
A self-supervised objective constructs targets from the observations themselves. Its design determines what information is visible and what must be recovered. Under causal prediction, a position sees only an allowed prefix and predicts a successor. BERT-style masked prediction corrupts selected positions and recovers their original tokens using surrounding context. T5-style span corruption replaces consecutive spans with sentinels and generates the removed spans as a target sequence. The source text may be identical, but these are different learning problems.
One sequence, four prediction problems
ExampleThe objective changes what the model can see and which recorded tokens it must predict.
Read the diagram as text
- Causal input: build the. At this scored position, only the recorded prefix is visible. The target token index is excluded.
- Target: index. Predict the recorded successor. Other eligible positions supply their own prefix–successor prediction events.
- Masked input: build [MASK] index. The selected middle token is corrupted; both surrounding tokens remain visible.
- Target: the. Recover the original token at the selected position, using surrounding context.
- Span input: build <s1>. Replace the consecutive span the index with a sentinel marking its location.
- Target: <s1> the index <s2>. Generate the removed span after its corresponding sentinel, then a final sentinel. Uncorrupted input text is not repeated in the target.
- FIM input: <prefix> build <suffix> index <middle>. Place the prefix and suffix before the missing middle. Marker names describe their roles rather than a specific tokenizer.
- Target: the. Generate the removed middle conditioned on both surrounding pieces, using a causal decoder.
- Causal input: build the → Target: index: predict successor.
- Masked input: build [MASK] index → Target: the: recover selected token.
- Span input: build <s1> → Target: <s1> the index <s2>: generate removed span.
- FIM input: <prefix> build <suffix> index <middle> → Target: the: generate missing middle.
| Objective | Visible information | Scored target | Useful pressure |
|---|---|---|---|
| Causal prediction | Permitted preceding tokens | Recorded successors | Continue sequences from prefixes |
| Masked-token recovery | Corrupted sequence with surrounding context | Original selected tokens | Use bidirectional context to recover missing content |
| Span corruption | Input with sentinel-marked gaps | Removed spans in target order | Recover longer missing regions |
| Fill in the middle | Prefix and suffix arranged before the missing span | The removed middle | Generate content constrained by both sides |
Fit is narrower than capability
Lower loss establishes better prediction under the implemented scoring procedure. It does not by itself establish truthful answers, reliable reasoning, safe action, or product value. TruthfulQA, for example, was designed around plausible falsehoods that can be well represented in human text: accurate imitation of a distribution is not the same property as factual correctness. The general objective warning belongs to Machine Learning Fundamentals.
II. How staged training developed
Must-know turning points
Predictive training long predates the modern foundation-model pipeline. The important history is not a march through product releases; it is a sequence of bottlenecks that prompted new forms of representation sharing, transfer, scale allocation, and checkpoint reuse.
From shared representations to checkpoint reuse
2003Neural Probabilistic Language ModelJointly learns word representations and next-word probabilities so related sequences share statistical strength.
Contributors: Bengio and colleagues.
What changed: Addresses sparse observations beyond short-history n-gram counts: learned representations let observed sequences inform predictions for related unseen sequences.
2006Deep Belief NetsGreedy layer-wise learning initializes a difficult multilayer generative model.
Contributors: Hinton, Osindero, and Teh.
What changed: Preliminary learning makes subsequent whole-model refinement practical in the studied digit-image setting. This is initialization-oriented pretraining, not broad language pretraining.
2018ELMo, ULMFiT, and GPTELMo reuses frozen contextual features; ULMFiT adapts on target text; GPT transfers a shared transformer to supervised tasks.
Contributors: The ELMo and ULMFiT research teams; OpenAI’s generative-pretraining team.
What changed: These approaches establish distinct reuse strategies rather than a single replacement sequence. ULMFiT uses an LSTM; ELMo can adapt its language model before freezing it. OpenAI’s June 11 announcement describes language-model training followed by supervised adaptation of the same transformer core.
2020Scaling Laws for Neural Language ModelsFits relationships among prediction loss, model size, data, and compute.
Contributors: Kaplan and colleagues.
What changed: Makes allocation a quantitative design problem. Under the studied accounting and regimes, the compute-efficient prescription favors larger models stopped well before convergence.
2022ChinchillaEqual-compute comparisons favor scaling training tokens and parameters in roughly equal proportion.
Contributors: Hoffmann and colleagues.
What changed: Compared with the earlier fitted prescription, the results favor more tokens relative to parameters. Training horizons and learning-rate decay are matched in the comparisons; the result is an empirical allocation model, not a universal constant.
2024–2026OLMo 2, GLM-4.5, and Krea 2Use midtraining for different later capability-focused stages, without a shared operational boundary.
Contributors: The OLMo 2, GLM-4.5, and Krea teams.
What changed: OLMo 2 changes its curated mixture while annealing; GLM-4.5 introduces repository and reasoning structures with longer contexts; Krea 2 places capability-focused midtraining before SFT. The interval groups these recipes, not an invention date. The OLMo 2 report is a January 2025 preprint; Krea’s report is dated June 2026.
Autoregressive, masked, and text-to-text objectives continue to coexist because they expose different information and serve different architectures. Similarly, freezing a representation, adapting the whole model, and continuing self-supervised training remain alternative reuse strategies. Newer practice expanded the design space; it did not make every earlier approach obsolete.
III. Designing model exposure
Mixture weight is not corpus size
A data mixture is a sampling distribution over source groups. It is not merely a list of datasets. A source can contain many eligible bytes yet receive little training exposure, while a small source can be sampled repeatedly. Eligibility and lineage belong to A release is a dependency graph; this chapter begins after a source has become eligible for a particular run.
Selection becomes exposure
Consider two sources selected equally often by document. If source A’s documents contain 100 scored tokens and source B’s contain 900, consuming whole documents yields about 10% versus 90% of processed tokens. If the loss is then averaged across every valid token, B also supplies roughly nine times as many loss terms. Equal document-selection probability, equal token exposure, and equal source-level loss influence are therefore different policies.
From eligible sources to update influence
Source size and selection probability pass through document length, packing, masking, and reduction before becoming loss influence.
Read the diagram as text
- Eligible source A. A source with its own size and document-length distribution.
- Eligible source B. Another source whose size need not match its sampling weight.
- Mixture sampler. Selects sources and examples under declared probabilities.
- Tokenize and pack. Document length and packing determine realized token exposure.
- Mask and reduce loss. Only scored positions enter the declared aggregation.
- Parameter update. Combined loss contributions produce gradients used by the optimizer.
- Eligible source A → Mixture sampler: eligible examples.
- Eligible source B → Mixture sampler: eligible examples.
- Mixture sampler → Tokenize and pack: selected documents.
- Tokenize and pack → Mask and reduce loss: packed token positions.
- Mask and reduce loss → Parameter update: aggregated prediction error.
Coverage versus repetition
Upsampling increases a source’s opportunities to affect updates but also increases repetition. Downsampling preserves budget for other sources but may reduce coverage. Multilingual XLM-R experiments illustrate the tension: stronger smoothing increased exposure for low-resource languages, whereas less smoothing favored high-resource languages; fixed capacity also created dilution tradeoffs as more languages were included. No sampling exponent is universally correct.
Schedules change exposure over time
A training schedule says how update conditions vary with progress. Learning-rate schedules change update scale. Data schedules change source or task exposure. Sequence schedules change the length and structure of examples. A curriculum changes the distribution of examples—often, but not necessarily, from easier to harder cases. These are separate interventions even when one training recipe changes several together.
| Schedule dimension | What changes | Question it creates |
|---|---|---|
| Learning rate | Update scale over steps | Was adaptation speed or instability caused by rewarming or decay? |
| Source shares | Sampling distribution over data groups | Did a later capability change because of composition or recency? |
| Sequence length | Tokens and relationships available per example | Did longer context help, or did extra computation and changed data structure confound the result? |
| Final annealing | Late exposure and learning rate | Which effect came from curated data, reduced learning rate, or their combination? |
Order matters because neural optimization is path-dependent: each update changes the state on which later gradients operate. Equal cumulative tokens therefore do not imply equivalent checkpoints. Attribution becomes especially weak when a phase simultaneously changes its mixture, sequence construction, learning rate, and token budget. A useful comparison changes one hypothesis at a time or reports the bundle honestly as a recipe.
IV. Allocating finite training work
Parameters, tokens, and compute form a budget
Training work couples model capacity with exposure. For a simplified dense transformer, a common approximation is
A conditional allocation model
Why fitted optima differ
Kaplan-style fits favored relatively rapid parameter growth and shorter training under the studied setup. Chinchilla’s equal-compute comparisons and matched learning-rate horizons favored roughly proportional growth of parameters and tokens. Later reconciliation work showed that parameter accounting—especially embeddings in small models—can materially change fitted prescriptions. These are empirical models of measured regimes, not physical constants.
Freshness and lifetime demand
Processed tokens are not necessarily distinct information. Controlled repetition studies found that repeated data can remain useful but has declining marginal value; some heavily repeated runs developed rising validation loss. Nor is training loss always the final economic objective. When a model will answer many requests, a smaller model trained longer may reduce lifetime inference work, but that conclusion depends on forecast demand and on loss being an adequate quality proxy. Replit described this practical tradeoff for latency-sensitive code completion: spend more training work on a smaller model so later inference can remain fast, with training cost amortized across use.
Parallel execution sets feasibility
Large runs can exceed one accelerator because model parameters and attention activations consume memory. Distributed execution partitions work or state across devices. Its implementation belongs to Distributed Training and Inference; here, the relevant point is that parallelism defines which model, sequence length, and batch are feasible within a time budget.
| Constraint | Observable consequence | Planning implication |
|---|---|---|
| Parameter state | Model does not fit on one device | Partitioning parameters may make placement feasible. |
| Attention activations | Out-of-memory remains after parameter sharding | Activation or context parallelism needs a separate intervention. |
| Inter-node communication | Accelerators wait during synchronization | Topology and node count constrain useful scaling. |
| Input pipeline | Low utilization while batches load | Storage and preprocessing throughput limit realized progress. |
Adding devices does not guarantee proportional speedup. Global batch size can become too large for the intended optimization regime, and accelerators can be underused. Stage planning should therefore use measured tokens per second and utilization—not accelerator count alone.
V. Checkpoints as evidence
A checkpoint is more than weights
A model checkpoint identifies learned parameter values at a point in training. Those weights may be sufficient for inference when the architecture and tokenizer are separately known. A resumable training checkpoint has a larger responsibility: it may need optimizer moments, scheduler state, random-number-generator state, gradient-scaler state, progress counters, and the sampler or dataloader position that determines what examples come next.
| Preserved state | What it supports | What remains separate |
|---|---|---|
| Model parameters | Load learned weights | Architecture, tokenizer, and behavioral evidence |
| Optimizer and scheduler | Continue update dynamics | Exact next examples and random operations |
| RNG and data-iterator position | Reconstruct subsequent sampling more faithfully | Environment-dependent numerical execution |
| Corpus order and configuration lineage | Explain what the checkpoint encountered | A guarantee of identical rerun results |
Identity and lineage
Logical restoration is not a promise of bitwise-identical continuation across releases, platforms, or CPU and GPU implementations. PyTorch explicitly limits such reproducibility guarantees. For experimental use, give each checkpoint immutable identity and parentage, then bind it to tokenizer, code revision, data release, mixture, schedule phase, cumulative exposure, and evaluation records. This is analogous to identifying what software was tested and released, but a checkpoint is not merely a source commit.
Checkpoint ancestry binds training and evidence
ExampleImmutable checkpoint nodes make branches, rollback points, and exact evaluation targets visible.
Read the diagram as text
- Checkpoint C0. Starting learned state with immutable identity.
- Run A manifest. Mixture A, schedule A, code revision, and processed-token budget.
- Checkpoint C1-A. Branch produced by Run A with resumable-state inventory.
- Run B manifest. Matched alternative with one declared intervention changed.
- Checkpoint C1-B. Alternative descendant retained for comparison or rollback.
- Evaluation receipt A. Metrics and artifacts bound to C1-A.
- Evaluation receipt B. Metrics and artifacts bound to C1-B.
- Checkpoint C0 → Run A manifest: starts training branch.
- Run A manifest → Checkpoint C1-A: produces.
- Checkpoint C0 → Run B manifest: starts matched branch.
- Run B manifest → Checkpoint C1-B: produces.
- Checkpoint C1-A → Evaluation receipt A: assessed as exact version.
- Checkpoint C1-B → Evaluation receipt B: assessed as exact version.
Measure gains and regressions separately
Training loss measures fit on optimization examples. Held-out prediction loss estimates the same kind of prediction on separate data. Targeted capability assessments test behavior the stage was meant to improve. Broad regression suites test capabilities the starting checkpoint already possessed. Application assessments add workload, latency, cost, and human consequences. These layers answer different questions and should not be collapsed into one unexplained score.
One scalar cannot describe a checkpoint
Prediction loss and desired behavior can move differently. Fill-in-the-middle experiments found training choices with small loss differences but substantial differences on executable code infilling. XLM-R’s downstream task performance continued improving after validation perplexity had plateaued. Conversely, a small-model workshop reported falling training loss alongside rising held-out loss later in one run. The generalization contract is developed in Generalization to new cases.
| Evidence layer | Required binding | Supported claim |
|---|---|---|
| Held-out prediction loss | Checkpoint, tokenizer, corpus, scoring context | Fit to the specified prediction distribution |
| Target capability suite | Exact cases, protocol, checkpoint | Change on the intended capability |
| Retention suite | Starting and candidate checkpoints on matched work | Known capability gains or regressions within suite coverage |
| Application assessment | Complete deployed configuration and workload | Usefulness under the evaluated operating conditions |
Protect independent capability evidence
Contamination occurs when assessment information reaches parameter fitting or model selection through a path the evaluation intended to keep independent. Exact item overlap is only one route. Paraphrases, translations, benchmark-derived synthetic examples, shared source documents, published solutions, runtime retrieval, and repeated tuning against reported scores can all provide causal access to protected information. Protect the independent assessment develops the evaluation boundary.
How protected assessments can influence a result
Contamination includes indirect paths through synthetic data, runtime tools, and adaptive checkpoint selection—not only direct training overlap.
Read the diagram as text
- Protected assessment. Cases, source documents, solutions, and reported outcomes intended to remain independent.
- Corpus construction. Direct overlap or transformed derivatives enter training data.
- Runtime retrieval. Tools expose a solution or source during the evaluated trial.
- Adaptive selection. Repeated scores guide schedules, prompts, or checkpoint choice.
- Fitted parameters. Assessment information can influence learned weights.
- Evaluation trial. Runtime access changes what information the system can use.
- Selected checkpoint. Selection depends on the reused assessment.
- Protected assessment → Corpus construction: items or paraphrases copied.
- Corpus construction → Fitted parameters: training exposure.
- Protected assessment → Runtime retrieval: solution remains reachable.
- Runtime retrieval → Evaluation trial: runtime information.
- Protected assessment → Adaptive selection: results repeatedly inspected.
- Adaptive selection → Selected checkpoint: model-selection influence.
Surface separation is not independence
Literal n-gram decontamination is useful but incomplete. Rephrased benchmark derivatives can evade surface-overlap detectors while still improving benchmark scores when included in training. Semantic detectors introduce their own retrieval and judgment errors. A detector can provide evidence of overlap; failure to detect overlap is not proof that none exists.
Scores can leak into selection
Selection is another access path. If engineers repeatedly choose schedules or checkpoints after inspecting one held-out suite, that suite has influenced development even when its rows never enter a gradient calculation. Preserve useful cases as regression tests, but use fresh, independently sampled cases for an ordinary final holdout claim. Corpus membership and transformations should remain traceable through data lineage.
Tool access can violate the same boundary at evaluation time. In SWE-rebench, checking out an old commit did not prevent an agent from reading future Git history; after that history was removed, the agent could retrieve the public issue and solution through other tools. The lesson is not that web access is always invalid. It is that allowed information paths must match the capability claim and be enforced across equivalent tools.
VI. Extending an existing model
Continue rather than restart
Continued pretraining performs further parameter updates from an existing pretrained checkpoint. It often retains a self-supervised objective family while changing the corpus, mixture, schedule, context regime, or token budget. The starting checkpoint supplies reusable capabilities, making continuation potentially cheaper than rebuilding them from initialization. It also supplies path dependence: the incoming data must modify a model that already represents many capabilities.
The inherited state creates choices
Continuation is not one mechanical operation. Rewarming the learning rate can speed adaptation while increasing forgetting; replaying earlier-distribution data can protect retention; resetting optimizer state changes the trajectory; tokenizer changes require compatible embeddings; and longer sequences alter both example structure and computation. Each belongs in the run contract and matched comparison.
What continuation can change
Concrete recipes illustrate the design space. Replit continued training a code model on filtered public Replit code with language emphasis matching its users. YouTube described continued training that linked text with semantic video identifiers and learned relationships from watch sequences. GLM-4.5 placed related files, issues, pull requests, and commits into longer repository-level contexts. These examples show changed exposure and sequence construction; none alone proves that continuation always dominates restarting.
Adapt to a target distribution
Domain adaptation aims to improve behavior on a target distribution. Domain-adaptive pretraining continues self-supervised training on domain-relevant material. Task-adaptive pretraining narrows the incoming material to unlabeled inputs associated with a target task; task labels are not its prediction targets. Both differ from instruction fine-tuning even when all are implemented with token-level cross-entropy, because their data and supervision contracts differ.
| Shift | Needed exposure | Target evidence | Retention concern |
|---|---|---|---|
| Domain | Representative documents, discourse, and workflows | Transfer across domain tasks | General capability and other domains |
| Language | Text varieties and relevant scripts or registers | Language-specific and cross-lingual tasks | Capacity dilution and high-resource languages |
| Format | Repositories, long records, structured events, or multimodal units | Tasks requiring those relationships | Short-form or ordinary-text behavior |
| Task inputs | Unlabeled inputs from the intended task distribution | Later supervised task behavior | Over-specialization to one input family |
Target gain and broad retention
Useful adaptation requires more than a glossary. ChipNeMo continued Llama 2 base models on chip-design code and documentation, improving domain assessments while reporting slight degradation on general benchmarks in detailed results. A Thomson Reuters example mixed legal and public data, retaining a majority representative of the earlier distribution; the reported run improved LegalBench by about five percentage points without reported general-capability loss, but the base model, mixture, and retention suite were not fully specified. These outcomes are recipe-specific evidence, not guarantees.
Retrieval, prompting, continued training, and behavioral post-training solve different problems. Frequently changing facts may belong in retrieval or current context; stable patterns repeatedly needed across many requests may justify parameter adaptation. Distribution shift provides the broader vocabulary for defining the target population.
Classify the stage by its contract
“Midtraining” is useful as a recipe label, but it has no field-wide operational definition in the inspected sources. It commonly names a weight-updating stage after broad pretraining and before response-oriented post-training. Continued pretraining names a mechanism, domain adaptation names a purpose, and midtraining usually names a stage’s role or position. A single run can satisfy all three descriptions.
| Recipe | Starting state and signal | Authors’ use of the stage |
|---|---|---|
| GLM-4.5 | Broad pretrained model; later prediction training on repository and reasoning structures | Calls several domain-focused, longer-context stages mid-training. |
| OLMo 2 | Initial checkpoint; changed curated mixture with learning rate reduced to zero | Calls the later capability-focused phase mid-training. |
| Krea 2 | Higher-resolution pretrained image model; undisclosed exact midtraining recipe | Places midtraining before SFT and uses it to move toward downstream use and add capabilities. |
| Llama 3 | Existing pretraining trajectory; long-context continuation and final annealing | Keeps those stages within its pretraining recipe rather than requiring the label midtraining. |
| ChipNeMo | Llama 2 base checkpoint; autoregressive prediction on chip-design material | Describes domain-adaptive pretraining, followed separately by response adaptation. |
Instruction formatting or synthetic provenance does not determine the category by itself. GLM-4.5 includes instruction data in stages it calls mid-training; another recipe might reserve instruction-response pairs for SFT. State the starting checkpoint, objective, loss mask, data form, breadth, sequence construction, and intended change. That contract tells readers more than the label.
Specialization can interfere with retention
Capabilities share parameters. Gradients that improve behavior on a narrow or shifted distribution can alter representations used elsewhere. Catastrophic forgetting names a severe loss of earlier capability, but retention is normally a collection of measured changes rather than one binary property.
Optimization and capability can disagree
The target gain–retention balance depends on incoming mixture, replay of earlier data, learning-rate restart, update magnitude, duration, and checkpoint selection. In controlled continuation experiments, learning-rate rewarming accelerated adaptation while increasing forgetting; replay comparisons kept continuation compute constant and improved earlier-data retention in some settings. ChipNeMo also shows that a lower training or validation loss under a higher learning rate need not translate into better task benchmarks.
Mitigate, measure, and retain rollback
Mixing broad data, limiting updates, using parameter-efficient adapters, and regression-aware selection can reduce risk, but none proves preservation. Even a small adapter constrains where updates occur rather than establishing that every unrelated behavior remains unchanged. Evaluate the target capability and retained capabilities on matched checkpoint versions, then stop or roll back according to predefined tolerances.
VII. Choosing the next stage
Write the training decision before the run
A corpus and accelerator budget do not constitute a training plan. Begin with an exact starting checkpoint and a measured capability gap. State why adding current context, retrieval, tools, prompting, or behavioral post-training is insufficient. Then freeze the capability hypothesis and the smallest training intervention capable of testing it.
| Decision field | Required statement |
|---|---|
| Starting state | Immutable checkpoint, tokenizer, architecture, prior exposure, and available resume state |
| Capability hypothesis | Specific behavior expected to improve and why parameter training is needed |
| Training contract | Objective, loss masks, eligible corpus release, mixture, schedule, sequence construction, processed-token and compute budgets |
| Matched comparison | Baseline or branch that isolates the intended intervention as far as practical |
| Evidence | Development metrics, protected target assessment, retention suite, and contamination controls |
| Decision points | Branch checkpoints, stop criteria, acceptable regressions, and rollback target |
Precommit what would cause the run to continue, branch, stop, or roll back. The latest checkpoint is not automatically the best one. A prior checkpoint may offer a better balance of target gain, retained capability, inference cost, and evidence quality. Preserve every assessment against immutable checkpoint identity so a later decision can be reconstructed.
The central discipline is simple: change a bounded part of the learning contract, measure the capability it was meant to change, protect evidence from the training and selection process, and retain a recoverable alternative. A stage name summarizes that contract only after the contract has been written.
Open questions
How should a field-wide vocabulary distinguish continued pretraining, midtraining, domain adaptation, and early behavioral data when real recipes mix objectives and move the same data between stages? Progress would look like reports publishing operational stage contracts rather than labels alone.
Can practitioners predict the specialization–retention frontier before running a costly adaptation? The difficulty is that shared parameters, data order, update magnitude, replay, and evaluation coverage interact. Progress would require controlled studies that vary these factors while reporting several target and retained capabilities in their native units.
How can benchmark independence be established when pretraining corpora are incompletely disclosed and paraphrased or synthetic derivatives evade literal overlap checks? Progress would combine auditable lineage, protected sources, detector validation, and fresh confirmatory cases rather than claiming a perfect decontamination filter.
What is the best allocation when unique high-quality data are scarce but lifetime inference demand is large? Repetition, model size, data quality, and expected serving volume change the objective in different ways. Progress would connect controlled data-constrained training curves to task quality and measured deployment economics.






























