The Impossible Family Tree of Open Models

This is satire, which is fortunate, because the Open Model Lineage Registry has just classified its newest release as both a 7B base model and the great-uncle of itself. Engineers are advised not to panic. The model is fully open in the modern sense: its weights are downloadable, its training data is described as “the public internet, respectfully,” and its family history is available in a 14,000-node diagram that can be rendered only by a workstation with 192 GB of RAM and a minor in genealogy.

Start with the base model, if one exists

Every family tree begins with a base model: the foundational ancestor, trained on an amount of text conventionally measured in “more tokens than there are regrets in a large enterprise migration.” The base model has a simple name such as Granite-Heron-3, unless it has been renamed GraniteHeron, Heron-Granite, G3-H, G3H-Instruct-Base, or FINAL_granite_v2_USE_THIS_ONE.

In theory, this checkpoint predicts the next token. In practice, it has already accumulated four incompatible origin stories. One repository says it was trained from scratch. Another says it continues pretraining from an earlier model. A third says it is “architecturally inspired by” an unnamed predecessor. The project README clarifies this with a helpful arrow diagram: Ancient Corpus → Foundation → Improved Foundation → Truly Foundation, each arrow labeled “details forthcoming.”

To establish provenance, inspect the config file. If it contains a field called model_type, you may learn that the model is a language model. If it contains a field called original_model, you may learn that the original model was “unknown.” This is not a failure of documentation. It is a commitment to decentralization.

Identify the distillation event

Next comes distillation, the dignified process by which a smaller model learns from a larger model, usually through an intermediate file named responses_final_revised_cleaned_v3.jsonl. The small model is then described as “trained on synthetic reasoning data,” a phrase that communicates both a technical method and the sensation of discovering that your family tree was compiled from airport novels.

The teacher model may be disclosed, partially disclosed, or referred to as “a capable frontier system.” This permits the community to conduct the traditional open-model exercise of examining punctuation preferences, comparing refusal phrasing, and announcing that the source is definitely Model X, definitely not Model X, or an ensemble of six models wearing a trench coat.

• If the student is smaller but unexpectedly eloquent, call it a distill.
• If the student is the same size but suddenly uses numbered lists, call it a reasoning variant.
• If the student refuses to explain where it came from, call it production-ready.
• If the teacher has never been named, describe lineage as “community inferred.”

Observe the fine-tune migration

Fine-tuning begins when the base model receives a specialized education in instructions, code, medicine, legal analysis, customer support, or the exact speech patterns of a project manager asking whether an API can be made “more intelligent.” The resulting model is often named by appending a suffix: -Instruct, -Chat, -Code, -Math, -Reasoning, -Uncensored, -Aligned, -Sovereign, or -ActuallyGood.

A model may receive several suffixes at once. This produces names like Falconet-Quarry-12B-Code-Math-Instruct-Uncensored-Safe, which should be read not as a contradiction but as a record of its journey. Each suffix represents a dataset, a goal, a weekend experiment, or an argument in a community chat server about whether the word “assistant” makes the model too agreeable.

At this stage, the model card typically says it is “based on” another model. This phrase has a wide technical meaning. It can mean weights were continued from the parent checkpoint. It can mean the tokenizer was reused. It can mean one contributor looked at the parent model’s benchmark chart and felt encouraged. The distinction is preserved in a footnote linking to a deleted spreadsheet.

Survive the merge

Model merging is where the family tree stops being a tree and becomes a municipal plumbing diagram. A merge combines checkpoints, often to preserve coding ability from one model, mathematical habits from another, multilingual performance from a third, and an inexplicable tendency to begin every answer with “Certainly!” from a fourth.

The merge recipe may specify weights with great precision: 0.37 of Model A, 0.41 of Model B, and 0.22 of “the one that did well on the vibes benchmark.” Occasionally, the recipe contains a negative coefficient, because apparently the correct way to improve a language model is to subtract an ancestor. This is accepted science in the same sense that a casserole can be improved by removing 18 percent of Thanksgiving.

After three merges, nobody can honestly claim the output has one parent. Maintainers therefore use the phrase “lineage-inspired composite,” which is a polite way of saying that the model’s family reunion requires a graph database and a legal waiver.

Apply quantization, then add a new surname

Finally, the model is quantized: transformed into a smaller numerical representation so it can run on hardware owned by people who did not accidentally purchase a data center. This should be a deployment detail. Naturally, it becomes a second identity system.

The same model now exists as FP16, BF16, FP8, INT8, Q8, Q6, Q5_K_M, Q4_K_S, IQ4_XS, EXL2-4.25bpw, and a community build called Potato-3bit. Each format may be published by a different volunteer, tuned for a different runtime, with a filename that gives equal prominence to the model architecture, the quantizer version, the shard count, and the maintainer’s dog.

Users ask which version is the real model. The answer is yes. A quantized checkpoint is often recognizably the same model in a practical sense, but it can differ in accuracy, speed, memory use, supported tooling, and occasionally its willingness to put semicolons in shell scripts. The family registry responds by assigning it a branch label, a badge, and a separate leaderboard entry.

A modest protocol for explaining any model

When someone asks, “What is this model based on?”, do not answer with the full ancestry. They have meetings. Instead, provide five facts:

1. The earliest known base checkpoint and its architecture.
2. Whether it was continued-pretrained, instruction-tuned, distilled, merged, or all four.
3. Which datasets or teacher systems are actually disclosed.
4. Whether the release is original full-precision weights or a derivative quantization.
5. What remains unknown, including whether “based on” means technically descended or emotionally adjacent.

The joke is that this is now the short version. But the true observation beneath it is useful: model names and benchmark scores are not provenance. For engineers choosing a model, understanding its lineage, training claims, modifications, and deployment format is part of understanding what behavior to expect—and what you cannot safely infer.