I've tended to think of the model as business objects, and the run modes as business logic. If I want to change the way the application flows, I change the logic in my run modes (business logic). If I want to change the people, places, and things in my app act I change the model (business objects).

I guess it comes down to how you conceptualise things in your application environment. I tend to think as model as both business object (e.g. customer) and the rules and interactions that the object can undertake (kind of analogous to a programming object being both the data and the methods for manuipulating the data).

In my run modes, I either simply pass user input to the model package (after validating with the ValidateRM plugin), or I generate the output using HTML::Template. I used to have a bit more logic in my runmodes, but I've found that keeping them minimalistic and moving everything involving db access or business rules to other packages has made things leaner and easier to maintain

However, my apps don't tend to have complex application flows (e.g. you enter content or you update content), so maybe the logic/object separation works well for you. Anyway, I believe the MVC definitions aren't especially rigid - but some people tend to take religious positions defending their particular framework/point-of-view, but I don't find that particularly useful