The role of the checker is to compare results with expected results. They can come in several forms. One example, and currently the most common meaning of checker, is an assertion which may operate locally within a design to ensure that behavior is correct. Its role may be to ensure that no data gets lost within a FIFO.
A checker could also work in tandem with a reference model or scoreboard which would allow for greater flexibility in result matching.
When abstractions change, it is possible to see different behaviors resulting from temporal differences. A timing change may change the order in which things happen, which in turn may cause significantly different behaviors. Neither is incorrect. Some companies have implemented checkers that can adjust the behavior within system-level models so that they can guide it towards the actions actually seen and in turn for the system-level model to then issue an error if the behavior is not allowed by the model.