I wanted to add one more note...

> klass.class_eval do
> @rules, @records = [], []
> end

Considering that this bit of code injects @rules and @records into
klass, my preference is that they be named something _less_
straightforward. My own, similar solution used @reportable_rules and
@reportable_records.

The reason? There is nothing preventing a client from further
extending their own subclasses of Reportable. Actually, I will lightly
encourage that in part 3. To avoid potential name conflicts with
client-side extensions, I'd go with names more complex than the simple
@rules and @records.