Rails: Skinny Controller vs. Fat Model, or should I make my Controller Anorexic?

There is an old saying,

Smart data structures and dumb code works a lot better than the other way around.

Everything you have described is about how one piece of data relates to another. That itself is your clue that the logic for those relationships, including validation should be in the model or database layer.

An anorexic controller is a sign of well-designed (smart?) data. My experience tells me that the more effort you put into designing your data, the less code you have to write overall.

Controllers are best at parsing inputs, calling the appropriate models, and then formatting the outputs.

I would put the logic in my model, especially if I'm TDD'ing (and I always TDD, except when I don't.) Testing the model is usually much easier than testing the controller.

I like to approach questions like this by thinking about responsibility. What in this case is "responsible" for verifying the VIN? The model. The controller is simply there to pass along the parameters...to "control" based on user input.

If it's not entirely clear, think of it this way: where will putting this code cause the least amount of impact if it needs to be re-used? Say...if two different actions in two different controllers both need to verify a VIN, what would need to be done? If you left this code in the controller, you'd essentially have to duplicate it in the new controller as well, but if you had placed it in the model, you'd simply call the check_vin method from the new controller, and no code duplication would be needed. By assigning responsibilities where they make the most sense, you've improved the re-usability of your code.