Yes. It's used to denote that you're including a module that adds
behavior/data/whatever to a class, such that you can do whatever to
its instances -- i.e., they are whateverable. It's particularly
useful when you want to explicitly duck-type a parameter or
association (primarily polymorphic).
For instance, suppose you wish you could gribbulate (made-up verb)
instances of some large number of classes, possibly even unrelated.
They'd need to have some specific data and/or behavior added, like a
#gribbulate! method, accessor for its gribbulator, enumerated
gribbulation type, default but overridable gribbulation response
(something custom for it to do after being gribbulated), etc. You can
add that code to all those classes manually, or stick that in a module
for these various classes to include. By convention, such a module
would be called Gribbulatable.
Then, suppose you also have class Gribbulator. Many of its methods
will ass-u-me that their main parameter is a Gribbulatable. Having
module Gribbulatable makes it easy for you to construct objects
suitable for feeding to a Gribbulator.
And if you want to keep track of when each Gribbulatable was
gribbulated, you might have class Gribbulation to keep track of which
Gribbulator gribbulated which Gribbulatable, and when. It will hold a
reference to a Gribbulatable, as a polymorphic association if you have
multiple Gribbulatable classes. (In addition to a presumably
non-polymorphic one to the correct Gribbulator.)
Unlike a lot of Rails "magic", though, I don't think anything depends
on adhering to this convention.