diff --git a/doc/APIreference/APItypes.rst b/doc/APIreference/APItypes.rst
index b0329c49..d3e78000 100644
--- a/doc/APIreference/APItypes.rst
+++ b/doc/APIreference/APItypes.rst
@@ -20,7 +20,12 @@ MuJoCo defines a large number of types:
 
 - :ref:`C struct types<tyStructure>`. These can be classified as:
 
-  - :ref:`Main struct types<tyMainStructure>`. These are :ref:`mjModel`, :ref:`mjOption` and :ref:`mjData`.
+  - Main structs:
+
+    - :ref:`mjModel`.
+    - :ref:`mjOption` (embedded in :ref:`mjModel`).
+    - :ref:`mjData`.
+
   - :ref:`Auxillary struct types<tyAuxStructure>`, also used by the engine.
   - Structs for collecting :ref:`simulation statistics<tyStatStructure>`.
   - Structs for :ref:`abstract visualization<tyVisStructure>`.
@@ -581,21 +586,14 @@ Capabilities declared by an engine plugin.
 Struct types
 ------------
 
-
-.. _tyMainStructure:
-
-Main
-^^^^
-
 The three central struct types for physics simulation are :ref:`mjModel`, :ref:`mjOption` (embedded in :ref:`mjModel`)
-and :ref:`mjData`. An introductory discussion of these strucures can be found in the Overview under :ref:`Separation of
-model and data<Features>`.
+and :ref:`mjData`. An introductory discussion of these strucures can be found in the :ref:`Overview<ModelAndData>`.
 
 
 .. _mjModel:
 
 mjModel
-~~~~~~~
+^^^^^^^
 
 This is the main data structure holding the MuJoCo model. It is treated as constant by the simulator. Some specific
 details regarding datastructures in :ref:`mjModel` can be found below in :ref:`tyNotes`.
@@ -607,7 +605,7 @@ details regarding datastructures in :ref:`mjModel` can be found below in :ref:`t
 .. _mjOption:
 
 mjOption
-~~~~~~~~
+^^^^^^^^
 
 This is the data structure with simulation options. It corresponds to the MJCF element
 :ref:`option <option>`. One instance of it is embedded in mjModel.
@@ -618,7 +616,7 @@ This is the data structure with simulation options. It corresponds to the MJCF e
 .. _mjData:
 
 mjData
-~~~~~~
+^^^^^^
 
 This is the main data structure holding the simulation state. It is the workspace where all functions read their
 modifiable inputs and write their outputs.
diff --git a/doc/overview.rst b/doc/overview.rst
index 45616df4..8d2276bf 100644
--- a/doc/overview.rst
+++ b/doc/overview.rst
@@ -80,19 +80,21 @@ Model compilation
    the built-in compiler into the low-level data structure :ref:`mjModel`, which is cross-indexed and optimized for
    runtime computation. The compiled model can also be saved in a binary MJB file.
 
+.. _ModelAndData:
+
 Separation of model and data
    MuJoCo separates simulation parameters into two data structures (C structs) at runtime:
 
-   -  ``mjModel`` contains the model description and is expected to remain constant. There are other structures embedded
-      in it that contain simulation and visualization options, and those options need to be changed occasionally, but
-      this is done by the user.
-   -  ``mjData`` contains all dynamic variables and intermediate results. It is used as a scratch pad where all
+   -  :ref:`mjModel` contains the model description and is expected to remain constant. There are other structures
+      embedded in it that contain simulation and visualization options, and those options need to be changed
+      occasionally, but this is done by the user.
+   -  :ref:`mjData` contains all dynamic variables and intermediate results. It is used as a scratch pad where all
       functions read their inputs and write their outputs -- which then become the inputs to subsequent stages in the
       simulation pipeline. It also contains a preallocated and internally managed stack, so that the runtime module
       does not need to call memory allocation functions after the model is initialized.
 
-   ``mjModel`` is constructed by the compiler. :ref:`mjData` is constructed at runtime, given
-   ``mjModel``. This separation makes it easy to simulate multiple models as well as multiple states and controls for
+   :ref:`mjModel` is constructed by the compiler. :ref:`mjData` is constructed at runtime, given
+   :ref:`mjModel`. This separation makes it easy to simulate multiple models as well as multiple states and controls for
    each model, in turn facilitating :ref:`multi-threading <siMultithread>` for sampling and :ref:`finite
    differences <saDerivative>`. The top-level API functions reflect this basic separation, and have
    the format: