How we label the method used to modify each model

Why we label at all

Fifteen thousand modified language models is a wall of names until you can tell what was done to each. Downloads and quantizations answer secondary questions. The primary question is how was this made: single-direction ablation, layer-wise, merge, quantization of somebody else's abliterated base. The answer changes what you expect from the model and how you compare it to alternatives. This page explains how our labels are produced, and where they end.

The S and P analogy

Our labels are what S and P is to companies: not intrinsic truth, but a transparent methodology applied consistently and revised openly. Disagreement with the method is expected. Revision is expected. Reclassification is logged. The construct earns trust by being about itself, not by hiding.

The four data sources

Every classification starts from what is readable in the public record on Hugging Face. We use four sources, listed in order of how reliably they carry method information.

1. The tags array

Authors attach tags to their models. These are curated, structured, and unambiguous when present. When we see a model with the tag merge or mergekit, this is a strong signal that a merge process was involved. When we see abliterated as a tag, the author is deliberately declaring that abliteration was performed. Tags are our first-priority source because the author took a deliberate action to attach them.

2. The model name

The name in the format author/model-name often contains method markers directly. Names like Foo-abliterated-GGUF, Bar-Heretic-Uncensored, or Baz-dare-ties-merge reveal both the technique and (frequently) the toolchain.

3. The yaml metadata in the model card

The most useful yaml fields for us are base_model (what upstream model this was built on), license, and library_name. When base_model is set to a known abliterated model, we can infer that this model inherits at least one abliteration method through its lineage.

4. The file structure

We inspect the files themselves. If a model is distributed as .gguf files, we know quantization (M8) is in play. If we see .safetensors in the standard layout, we know it is a full-precision base model. If we see MoE architecture signatures in the config, we know a merge or a native mixture-of-experts model is at hand.

None of the four sources is complete on its own. The rules combine sources so a model with three of four signals still gets a confident label.

The twelve rules, in priority order

Rules fire from most specific to most general. The first rule that matches a model wins. Specific patterns deserve confident labels; general patterns deserve cautious labels; total absence of signals deserves an honest "unknown".

R1. Heretic-produced (M3 + M1, high confidence)

Signal: the string heretic appears in the model name.

Label: primary M3, secondary [M1], high confidence.

Heretic is an automated abliteration pipeline that internally uses layer-wise optimization (M3) built on top of Arditi-style direction removal (M1). When an author names a model with "heretic", they are declaring which tool they used. This is our most confident automatic label. Coverage: about 1731 models (11 percent of the catalog).

R2. huihui-ai base model (M3, high confidence)

Signal: author is huihui-ai, file structure is not GGUF, and the model has an abliteration marker.

Label: primary M3, high confidence.

huihui-ai is the recognized specialist for M3 layer-wise ablation and publishes hundreds of models using this method.

R3. huihui-ai GGUF (M8 + M3, high confidence)

Signal: author is huihui-ai and file structure is GGUF.

Label: primary M8, secondary [M3], high confidence.

When huihui-ai releases GGUF files, they quantize their own layer-wise abliterated base. The outer method is M8 (quantization); the inner method is M3.

R4. mradermacher from an abliterated base (M8 + inherited, high confidence)

Signal: author is mradermacher, file structure is GGUF, and the yaml base_model points to a model whose name or path contains an abliteration marker.

Label: primary M8, secondary inherited from the base model, high confidence.

mradermacher is the largest GGUF producer in the ecosystem (over three thousand models, about twenty percent of the entire catalog). They never originate abliteration; they quantize others' work. When their base is a Heretic-produced model, the inherited method is M3+M1. When their base is a huihui-ai model, the inherited method is M3. When the base is a generic "abliterated" model, we default the inheritance to M1. Coverage: about 2514 models (16 percent of the catalog).

R5. Known quantization producers (M8 + optional inheritance)

Signal: author is one of the recognized quantizers (bartowski, TheBloke, QuantFactory, DevQuasar, tensorblock, mlx-community, Zoyd, RichardErkhov, noctrex) and file structure is GGUF.

Label: primary M8. If the base is present and looks abliterated, secondary [M1] and confidence high. Otherwise confidence medium.

R6. Frankenstein merge (M5-frankenstein, medium confidence)

Signal: presence of a merge tag or dare-ties in the name, plus the name suggests an unusual architecture combination (MoE, "frankenmerge", or a NxNB pattern like "8x7B", "4x8B").

Label: primary M5-frankenstein, secondary [M1] if abliterated marker is present, medium confidence.

Not every merge is a Frankenstein. Regular merges of same-size same-architecture models get R7 (below). See the "Frankenstein's creature" section below for our conventions on this term.

R7. Regular merge (M5, medium confidence)

Signal: merge or mergekit tag, or dare-ties/slerp in the name, without unusual architecture patterns.

Label: primary M5, secondary [M1] if abliterated marker present, medium confidence.

R8. Healed / DPO patterns (M4, medium to low confidence)

Signal: the words "healed", "orpo", or (with abliterated context) "dpo" appear in the name. Also fires for mlabonne authored abliterated models regardless of these keywords.

Label: primary M4, secondary [M1], medium confidence for "healed" or mlabonne, low for plain "dpo".

M4 is the abliteration-plus-heal pipeline where a healing pass (typically DPO or ORPO) restores capability after ablation damages it.

R9. Generic abliterated base (M1, medium confidence)

Signal: "abliterated" in name or tags, file structure is not GGUF, and no more specific rule fired.

Label: primary M1, medium confidence.

When we know a model was abliterated and we have no producer-specific information, we default to M1. This is the most common method in the ecosystem, so it is the reasonable default when nothing more specific is known. Coverage: about 3456 models (22 percent of the catalog).

R10. Generic abliterated GGUF (M8 + M1, medium confidence)

Signal: "abliterated" in name or tags, file structure is GGUF, and no more specific rule fired.

Label: primary M8, secondary [M1], medium confidence. Coverage: about 1933 models (12 percent).

R11. Uncensored only (M-uncensored, low confidence)

Signal: "uncensored" in name or tags, "abliterated" does not appear, and no more specific rule fired.

Label: primary M-uncensored, low confidence.

Many authors publish models labeled "uncensored" without ever declaring abliteration. This may mean the model was actually abliterated but the author used different terminology. It may mean the model was DPO fine-tuned to remove refusals without any weight-space intervention. It may mean a merge of already-uncensored bases. We do not know, so we assign the honest label M-uncensored with low confidence. Coverage: about 2799 models (18 percent). This reflects a genuine ambiguity in the ecosystem, not a failure of the classifier. See abliterated vs uncensored for the distinction.

R12. Fallback (unknown)

Signal: none of the above patterns match.

Label: primary unknown, unknown confidence.

Some models were included because they appeared in adjacent searches but do not declare abliteration or uncensored status themselves. We label these unknown rather than guessing. Coverage: about 1512 models (10 percent).

Primary and secondary methods

Many models are the result of a chain of operations. A typical chain: Meta releases Llama 3, huihui-ai applies M3 layer-wise ablation, mradermacher quantizes the result into GGUF (M8). The final file is the result of all three steps. How should we label it?

We use two fields. Primary method is the last operation applied, because that is what most immediately shapes what the file is and how it behaves. In the example above, primary is M8. Secondary methods is a list of everything that came before, that we can identify. In the example above, secondary is [M3]. In our UI, primary is shown large and secondary is shown below it, with full method names.

Primary is not always the "most important" method by content. In the example above, the layer-wise ablation is arguably more content-rich than the quantization. But it is the earlier step. We chose "last operation" as the definition of primary because the file you are actually holding is the output of the last step. Reasonable people can disagree with this convention.

The three confidence levels

High (31 percent of catalog). Producer identity plus method-specific naming or tags. Another careful reader looking at the same evidence would reach the same conclusion. Rules R1 through R5.

Medium (39 percent). General signals rather than method-specific ones. Reasonable default, useful for filtering and aggregate analysis, less useful cited authoritatively for individual models. Mostly R9 and R10.

Low (18 percent). Weak or ambiguous signals. Best guess, read as such. R11 (uncensored without abliterated) and some R8.

Unknown (10 percent). No classification signals present.

On the term Frankenstein's creature

We call this pattern M5-frankenstein: Frankenstein's creature. Something stitched from pieces that were not meant to fit, existing and acting despite that. The community calls it "frankenmerge" (Undi95). We use the Shelley reference to keep the weight.

The distinction from regular M5 matters practically. Merges that combine different architectures or sizes (an 8x7B MoE built from Llama and Mistral parts) behave less predictably than merges of same-size same-architecture models. Fine-tunes trained on the base rarely generalize. Standard benchmarks produce surprising numbers. Users should know upfront whether they are handling one or the other.

For the full account, including the three seams that make a merge a Frankenstein, a worked example, and the gallery of them in the catalog, see the dedicated article: Frankenstein's creature.

On the limits of author-declared classification

Every rule starts from what the author declared: name, tags, yaml, files. We do not observe the computation that produced the weights. If the author is imprecise, mistaken, or misleading, the label inherits it. Concrete failure modes: an author who built with mergekit but named the model "abliterated" without the merge tag; an author who omitted the M5 middle step in an M1-M5-M8 chain; an author who labeled a DPO fine-tune "abliterated" for attention. We catch these when tags are honest and miss them otherwise. Undocumented models get R12 (unknown) rather than a guess.

The technique that would replace declaration with observation is method reverse-engineering from weights. As of August 2026, two independent groups (Hurtado, Messenger) have shown that whether refusal was removed can be detected from internal signals at AUROC around 0.95, and Messenger's four-class taxonomy distinguishes a few method families. But no published work outputs a specific M1-M9 label from weights alone. The specific gap, the enabling literatures that could close it, and why the catalog is uniquely positioned as the labeled training data are surveyed in the dedicated Frontiers article: Reverse-engineering the abliteration method from weights.

Reclassification and the public history log

The classifier will improve. New producers will emerge and get their own rules. Discovered patterns will refine existing rules. When we update the classifier and re-run it, some models will get new labels. This is expected and healthy.

Every reclassification is logged in the method_history table with the old label, the new label, the classifier version that changed it, and a change reason. This log is public. You can query it to see which models have been reclassified, when, and why. This is our commitment to reversibility: labels are not gospel, and the historical record shows they were not gospel.

The current classifier is version v1.0.0 (published August 2026). Major version bumps will accompany substantial rule changes or new methods added to the taxonomy.

Verified authors (the blue star)

A small blue star next to an author name means we confirmed the account is who it claims to be: an original method creator (FailSpy, huihui-ai, mlabonne), a recognized producer (mradermacher, bartowski, TheBloke), or an upstream base-model organization (Meta, Google, Qwen, Mistral). The star is identity confirmation, not endorsement.

Impersonation warnings sit on the opposite side. When an account name could reasonably be mistaken for an established organization or figure and we can confirm the account is not that entity, model pages carry an explicit warning banner. These warnings are applied conservatively and only where we can verify the mismatch.

Initial verified list: 40 accounts, criterion is "would a reader trust this because they recognize the name". Unmarked is the default and carries no negative meaning. Most accounts in the catalog are unmarked; the star is reserved for cases where identity matters to the reader's judgment.

How to read a label on a model card

On each model card, a label block shows: primary method as a large colored plate with method name spelled out (click to jump to the method's wiki page); secondary methods listed below with full names (each also linkable); confidence shown as a labeled bar (High / Medium / Low) with a one-line hint; evidence trail collapsible, showing exactly which signals triggered this label.

If the primary method is M-uncensored or unknown, the evidence trail explicitly says what is missing. This is not a bug; it is honesty.

If you think we got a label wrong

Send us the model URL and what you think the correct label should be, with reasoning. If you are the author of the model and we have misclassified it, we especially want to hear from you. We will update the label and log the change in method_history.

Contact: through the abliteration.org repository issue tracker on GitHub, or via the email address published on the About page.