The six workflow stages
Why six categories, not five or eight. Where the boundaries between extract, ablate, heal, evaluate, fine-tune and misc actually sit. What ends up in misc and why that category is doing more work than its name suggests. The taxonomy the catalog uses and the taxonomies it deliberately does not.
The /datasets catalog groups alignment corpora into six workflow stages: extract, ablate, heal, evaluate, fine-tune, and misc. The first four track the four operations that constitute a complete abliteration pipeline (identify the refusal direction, remove it, recover capability, verify the result). Fine-tune is included as a peer stage rather than as a competing method because SFT-based uncensoring uses the same kinds of upstream corpora and answers the same practical question. Misc is a real category, not a fallback: it contains concept-erasure corpora, steering-vector datasets, quantization-repair calibration sets, and safety-classifier training data, all relevance-matched but structurally different from the five pipeline stages. This article explains where the boundaries sit, what tests decide a borderline case, and why the taxonomy avoids finer subdivisions that would look tidier but degrade in practice.
- Why the pipeline maps to four operational stages
- Why fine-tune sits alongside them as a peer, not a competitor
- What genuinely belongs in misc and why it is a first-class category
- The decision tests that separate extract from ablate, and heal from fine-tune
- Why we do not split evaluate into 'benchmark' vs 'probe' vs 'judge'
- What a seventh stage would need to look like to earn inclusion
- The taxonomies this classification deliberately does not adopt
Four operations, one pipeline
An abliterated model is the output of a four-operation pipeline. The operations do not always run in the same order, do not always use the same tools, and can be repeated or looped, but they are the four things that have to happen for a produced release to be called abliterated in the technical sense the field currently uses:
- Identify the refusal direction in the base model's activation space.
- Ablate that direction from the weights.
- Heal the capability drop the ablation caused.
- Evaluate whether the resulting model behaves as intended.
Each operation reads and writes specific kinds of data. Identification needs paired examples that isolate the behavior being extracted. Ablation needs, at minimum, an activation snapshot from the base model on a probe set. Healing needs preference pairs that reward the recovered behavior. Evaluation needs benchmarks and judges that can distinguish success from failure without being fooled by templates.
The first four categories in the /datasets catalog map one-to-one to these four operations: extract, ablate, heal, evaluate. The mapping is not merely descriptive; it is enforced by the enrichment pipeline's classification rules, which look at each dataset's id, tags, description and known provenance and assign exactly one stage.
Fine-tune as a peer stage
The fifth category, fine-tune, does not sit inside the four-operation pipeline. It sits alongside it as an alternative path to the same destination. Fine-tune-based uncensoring, in the Hartford Dolphin tradition, removes refusal by training on filtered instruction data rather than by editing weights. See the M6 article for why this is ontologically different from abliteration and what makes both approaches worth tracking in the same catalog.
The reason fine-tune is a peer stage rather than its own top-level section is practical: a practitioner comparing paths asks the same question of both approaches, and the datasets involved are similar enough in shape (large instruction corpora with filtering criteria and license terms) that separating them into a whole different catalog would create friction without adding clarity. When you land on /datasets, you should see all the corpora that address "how do I get a compliant open-weight model" side by side, even if the answers you find represent two different methods.
Misc is a first-class category
The sixth category, misc, is the one that most often looks like a fallback but is doing structural work. Its definition is "relevance-matched, does not fit the five workflow stages." Concrete inhabitants:
- Concept-erasure corpora. Datasets used by techniques adjacent to abliteration (LEACE, RepE-style interventions) that erase or steer specific concepts. Related to ablate but methodologically separate.
- Steering-vector datasets. Prompt pairs used to compute activation-steering vectors, which is a technique adjacent to refusal-direction extraction but pointed at different behaviors.
- Quantization-repair calibration sets. imatrix files and calibration corpora used to soften the accuracy loss when abliterated models are quantized to GGUF. Relevant to the abliteration lifecycle but downstream of the four pipeline stages.
- Safety-classifier training data. Corpora used to train guardrail models that sit on top of, rather than inside, an abliterated release. Aegis, Llama-Guard-style data, WildGuard training splits. Adjacent to evaluate but conceptually different (a classifier is not an evaluation).
- Character and role corpora. Persona datasets, roleplay corpora, character-card collections. Sometimes used as fine-tune inputs, sometimes as evaluation contexts, sometimes as pure creative material.
Putting all of these into a single stage would look messy in a taxonomy diagram, but in practice it works because a reader browsing /datasets/misc is already in an exploratory mode. They are not looking for the canonical extraction pair. They are looking for something adjacent that they might not otherwise find. The category serves that intent well precisely because it is broad.
Borderline tests
Every classification runs into cases where two rules apply. The pipeline resolves these with a small set of ordered tests:
Extract vs Ablate. A dataset of paired harmful/harmless prompts goes to extract if it is intended as input to a direction-extraction pipeline. It goes to ablate if it is specifically an activation snapshot, a residual-stream probe, or a corpus already annotated with a direction. The test: does the dataset ship raw text (extract) or already-computed representations (ablate)?
Heal vs Fine-tune. A DPO-style preference dataset with chosen/rejected pairs goes to heal if the framing is capability recovery after ablation. It goes to fine-tune if the framing is uncensored instruction tuning as an alternative to ablation. The test: does the dataset present itself as a second pass over an already-ablated model (heal) or as a standalone training set that produces an uncensored model directly (fine-tune)?
Evaluate vs Extract. A benchmark like walledai/AdvBench that ships harmful behaviors could plausibly land in either category. We resolve toward evaluate for the canonical benchmark releases and extract for the derivatives that are packaged as training inputs. The test: does the dataset have a documented benchmark scoring protocol (evaluate) or is it presented as a prompt pool (extract)?
Evaluate vs Misc. A safety-classifier training set is not a benchmark, even though it is often confused with one. It trains a classifier that then evaluates something else. That indirection makes it misc, not evaluate. The test: does the dataset directly produce a benchmark score (evaluate) or is it an input to a model that produces such scores (misc)?
These tests are visible in the classifier's rules and are stable across enrichment runs. When a dataset is genuinely ambiguous, it goes to misc; force-fitting is worse than admitting the classification is not clean.
Taxonomies we deliberately do not use
Three finer taxonomies were considered during the initial classification design and rejected:
Splitting evaluate into "benchmark" / "probe" / "judge." HarmBench is a benchmark. XSTest is an over-refusal probe. HarmBench-Llama-2-13B-cls is a judge model corpus. These are three different roles in the same workflow. Splitting them would triple the size of the evaluate menu without helping anyone find what they need, because practitioners think of them collectively as "the verification stack" and read them together.
Splitting heal into "DPO" / "ORPO" / "KTO." The differences among preference optimization variants are technically real but do not usefully partition the datasets. The same 40k preference mix can be consumed by DPO, ORPO or KTO depending on which trainer the practitioner picks. Splitting by algorithm would misclassify most datasets, because they are typically algorithm-agnostic.
Adding a "post-processing" category for quantization repair. imatrix calibration and quantization repair are a real workflow, but the field is small (mainly DavidAU and a few adjacent authors) and the datasets involved are few (under twenty). A whole category for under twenty datasets would look padded. They live in misc with a recipe entry that surfaces the workflow when someone lands on the page.
What a seventh stage would need to look like
A future seventh category would need three things to earn inclusion. It would need to correspond to an operation that a substantial fraction of published pipelines perform. It would need to have a corpus base of at least fifty distinct datasets so the category has something to show. And it would need a set of decision tests that cleanly separate it from the six existing categories so classification stays deterministic.
The current best candidate is artifact-aware evaluation: a category for the newer wave of benchmarks (WildGuardMix and descendants) that explicitly annotate refusal artifacts separately from harmfulness. Right now these live in evaluate; a case could be made for splitting them out. The corpus base is not yet large enough (the newer benchmarks are under thirty distinct releases) and the decision tests would be subtle (an "artifact-aware" benchmark shares almost all metadata signals with a classic benchmark). We are watching this space; if either constraint changes, a split becomes feasible.
Every taxonomy is an editorial choice. The six-stage version has held up across two enrichment runs and 2,443 classified datasets. It will change when the field changes, and the criterion for changing it is not tidiness but usefulness to a reader who arrives at /datasets with a real question.