Modeling languages, like the Unified Modeling Language (UML), are designed according to a schema called meta-level architecture (aka meta-data architecture). While the term may sound mystik, meta-level architectures are actually not that difficult to understand.
Let us have a closer look at the architecture of meta-levels on an informal level. We will start at the top left, see the figure. To make the discussion concrete, we refer to conceptions as you know them from modeling with classes and objects. The abbreviation CD stands for Class Diagram. A class diagram consists of classes, associations, inheritance and so on. These conceptions, the conceptions you are allowed to use for a CD are defined by CM, the Class Model, as we call it. The CM is a specification of conceptions, of which a concrete CD is an instance of. That's why there is an arrow labeled with "instanceOf" between CD and CM. The Class Meta-Model (CMM) specifies the language constructs available for use on CM. In other words, the CM is one concrete specification of a modeling language, whose specification concepts are defined by CMM. In that sense, CM is an instance of CMM. All this is pretty straight forward and not in conflict with the common understanding of meta-level architectures.
However, and this is often overlooked, the same argumentation holds on the row below. An Object Diagram (OD) consists of objects, values, references etc. These conceptions are defined by the Object Model (OM). The Object Meta-Model (OMM) specifies the language constructs available for use on OM. Again, this is pretty straight and clear. Now comes the interesting part.
Of course, the world of classes and the world of objects are somehow interconnected. This interconnection is defined through a relationship between the Class Model (CM) and the Object Model (OM). This relationship determines how OD and CD are related. Objects are instances of classes, meaning that a certain class is the input to a factory, which "produces" an object, whose type property is a pointer to the class and whose values are data stores including pointers to the class attributes. That is what we call an "instanceOf" relationship. This relationship is defined by the OM/CM arrow.
The means to describe an interconnection between OM and CM is defined by the arrow between OMM and CMM. Otherwise, one could only describe self-contained models of OM and CM, but not interrelate these models, which -- in turn -- would prevent to specify the "instanceOf" relationship between OD and CD. As one can observe, the reasoning is absolutely "symmetric".
Now, let's do some grouping. Let us refer to OD as meta-level zero (M0) and to CD as meta-level one (M1). CM and OM together constitute meta-level two (M2), CMM and OMM constitute meta-level three (M3).
We are done and have come up with a completely coherent description of the meta-level architecture, which -- in principle -- could be extended by further, higher levels.
One might ask, why we have not grouped OD and CD in the very same way, as we have done it for OM and CM and for OMM and CMM, respectively. Such an argument would call for a three-level meta-architecture instead of a four-level meta-architecture. However, there is finer point in here. Of all arrows labeled with "instanceOf", there is only one arrow, whose semantics can be arbitrarily defined in the meta-level architecture: it is the arrow between OD and CD, which is in fact defined on M2. In that sense, the "instanceOf" arrow between OD and CD is of a different kind than that all the other "instanceOf" arrows -- it is of a different "quality", so to speak.
By the way, could there be reasons to introduce higher levels in the meta-level architecture, like M4, M5 etc? Yes, there could. The arrow between OMM and CMM on M3 is a necessity in order to have means to define the relationship between CM and OM in M2. If you want to define the relationship between OMM and CMM yourself, you need a higher level, which provides the infrastructure to do so. The four-level meta-architecture is the smallest number of levels needed by a modeling language designer in order to have means to specify M0, M1 and their interrelationship of instantiation. In practice, higher levels are possible but rarely needed.
Note that you will find a lot of figures in literature depicting the meta-level architecture, which are not accurate -- if not almost false. Even the UML 2.0 Standard (and previous versions of the UML Standard) is not 100% correct in its description of the meta-level architecture. Even though I said that the meta-level architecture is easy to understand, many miss to get the full picture and forget about the relation between M0 and M2.