Refusal-vector ablation

Refusal-vector ablation is the edit that takes a refusal vector and removes its effect. You have a direction. Ablation stops the model from using that direction as strongly, or at all, when it decides the next token. The simplest description is subtraction: take the activation, remove the component that lies along the refusal vector, and let the rest of the forward pass continue. Do the equivalent change in the weights and you have a checkpoint that no longer needs the subtraction at runtime. That checkpoint is what people ship, and what an API then hosts.

What you should see if it worked

Prompts that used to end in a short refusal get a normal continuation instead. Prompts the base model already answered should look about the same. You check both. A model that only "works" on the refused set, and rambles on everything else, was not ablated cleanly. It was damaged. Public write-ups argue about how much capability survives. This glossary does not pick a percentage. Measure the checkpoint you have, on the tasks you have.

Ablation next to orthogonalization

Ablation is aimed at the component. Orthogonalization is aimed at the weights that write the component. A practical recipe may subtract the direction and also orthogonalize the writing matrices so the direction does not come back two layers later. If you only subtract at one layer and leave the writing weights untouched, a later block can put the signal back. That is the usual reason a "one line" ablation under-delivers. The orthogonalization page is the weight-side edit.

None of this is a jailbreak. A jailbreak does not change the vector or the weights. It tries to route around them for one generation. After ablation, the weights are different, so the next request does not need the trick. Refuseless serves checkpoints on the far side of that kind of edit. The four-way comparison is the decision page if you are still choosing which intervention you wanted.