I'm running into an issue in a Rails 4 application related to class names and modules.

I have an `Event` class in my main application that inherits from `ActiveRecord::Base`. I also have a set of files in my /lib directory that have been grouped into a module I call `LibModule`. There's a class in that module that's also named `Event`. I noticed something interesting about referencing these classes. Here are some examples using the Rails console.

Example #1: When Event has never been referenced, the ActiveRecord version gets loaded:

```
> Event
=> Event(id: integer...)

```

Example #2: When LibModule::Event gets referenced first:

```
> LibModule::Event
=> LibModule::Event
> Event
=> LibModule::Event

```

As a result, when my server restarts (after updates, etc), I'll occasionally get the following error if a user engages in behavior that triggers server activity similar to Example #2:

```
superclass mismatch for class Event

```

I know there are a few ways to ensure that there's no conflict here. What's the best practice way of handling a situation like this?

1. I tried replicating the behavior from Example #2 with class names from gems and it seems like Rails completely segregates the classes in gems. Is there a way to do the same here? I think this would be my ideal situation.
2. Should I just change the name of `LibModule::Event`?
3. Should I ensure that the `ActiveRecord` class loads during initialization?
4. Some other Rails best practice I haven't thought of?