diff --git a/docs/architecture/index.md b/docs/architecture/index.md
index e37b829c671a0840ab56e50900aa296f65a66012..cca032968f431ae17cfd82c785406a811d8a6516 100644
--- a/docs/architecture/index.md
+++ b/docs/architecture/index.md
@@ -8,7 +8,8 @@ versions all configuration, and it's also responsible for managing mechanisms su
 
 The stack of tools is kept limited:
 
-* Ansible is the tool that deploys configuration and orchestrates changes.
+* Workflow Orchestrator ({term}`WFO`) orchestrates all changes.
+* Ansible is the tool that deploys configuration.
 * If needed, custom Python scripts can support extra functionality.
 
 This approach works well for the deployment of 'base configuration'. For service fulfillment, three more components are
@@ -18,7 +19,10 @@ introduced:
 * A service database.
 * A workflow engine.
 
+All three of these components are deployed as part of {term}`WFO`. More information about {term}`WFO` can be found on
+their website <a href="https://workfloworchestrator.org/" target="_blank">here</a>.
 
+(configuration-decomposition)=
 ## Configuration (de)composition
 
 The configuration of a network element can be decomposed in different functional parts:
@@ -75,48 +79,3 @@ All services offered can be summarised in the following four categories. Some ex
 |---------|-------------|------------------|
 | Layer 2 | VPLS / EVPN | Layer 2 circuits |
 | Layer 3 | L3VPN       | Core links       |
-
-### Decomposition of objects
-
-Every object -- both services and access ports -- is composed of the following building blocks:
-* Administrative metadata
-  * Object ID
-  * Status
-  * Owner
-* Configuration data that depends on the specific service, some examples:
-  * Access port
-    * Access port type
-    * Physical interfaces
-  * IP trunk
-    * IPv4 network
-    * IPv6 network
-    * IS-IS metric
-* Placement metadata
-  * Access node
-  * Service delivery point
-
-
-### Services and ports
-
-While a port shouldn't be configured in case there is no service insisting on it, it could happen that multiple
-services are insisting on the same port. For this reason, we define the following entities:
-
-{term}`SDP`
-: Service Delivery Point: the logical interface where a service is delivered
-
-{term}`GA`
-: Access Port: an access point into the GÉANT network
-
-{term}`GP`
-: Physical Port: the physical boundary for the {term}`GA`
-
-{term}`GAN`
-: Access Node: the node where a service is delivered
-
-These concepts apply to both {term}`CFS`es and {term}`IFS`es.
-
-```{figure} ../static/access_port_diagram.png
-:alt: Diagram that displays the different entities that make up a GÉANT service.
-
-A visualisation of how services insist on ports.
-```
diff --git a/docs/glossary.md b/docs/glossary.md
index 64541eb760c919943e3eb473c0757abcaaabef9d..232a07395efe6b82d890316cbaba0d24ce692656 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -34,6 +34,9 @@ MPLS
 MTTR
 : Mean Time To Repair
 
+MTU
+: Maximum Transmission Unit
+
 OOB
 : Out-of-band
 
diff --git a/docs/index.md b/docs/index.md
index 528a1629dd6b2a11890370c110cd6c5340f6136d..b567f7ecdd4fda6c09978c5b5fdbd91131565e77 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -3,7 +3,7 @@
 Welcome to the documentation of the GÉANT Automation Platform, or {term}`GAP` for short. \
 The focus of this platform is configuration management and service orchestration for the GÉANT IP/{term}`MPLS` network.
 
-This documentation contains the following sections:
+This documentation has the following sections:
 
 ```{toctree}
 :caption: Background
@@ -12,6 +12,13 @@ overview/index.md
 architecture/index.md
 ```
 
+```{toctree}
+:caption: Modeling
+:maxdepth: 2
+modeling/index.md
+modeling/ports.md
+```
+
 ```{toctree}
 :caption: Processes
 :maxdepth: 2
diff --git a/docs/modeling/index.md b/docs/modeling/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..e8839296b5410759e2403a396ec1eb1d8461804c
--- /dev/null
+++ b/docs/modeling/index.md
@@ -0,0 +1,23 @@
+# Data models
+
+To be able to model network objects, a data model must exist for every configuration item in the network. This allows
+for describing the network, and the services as a composition of abstract objects.
+
+## Decomposition of objects
+
+Every object -- both services and access ports -- is composed of the following building blocks:
+* Administrative metadata
+  * Object ID
+  * Status
+  * Owner
+* Configuration data that depends on the specific service, some examples:
+  * Access port
+    * Access port type
+    * Physical interfaces
+  * IP trunk
+    * IPv4 network
+    * IPv6 network
+    * IS-IS metric
+* Placement metadata
+  * Access node
+  * Service delivery point
diff --git a/docs/modeling/ports.md b/docs/modeling/ports.md
new file mode 100644
index 0000000000000000000000000000000000000000..99e1cb9331008efb7f4062ecad581dfd41f01a0d
--- /dev/null
+++ b/docs/modeling/ports.md
@@ -0,0 +1,38 @@
+# Services and ports
+
+While a port shouldn't be configured in case there is no service insisting on it, it could happen that more than one
+service is insisting on one port. For this reason, the following entities exist:
+
+{term}`SDP`
+: Service Delivery Point: the logical interface where a service is delivered
+
+{term}`GA`
+: Access Port: an access point into the GÉANT network
+
+{term}`GP`
+: Physical Port: the physical boundary for the {term}`GA`
+
+{term}`GAN`
+: Access Node: the node where a service is delivered
+
+These concepts apply to both {term}`CFS`es and {term}`IFS`es.
+
+```{figure} ../static/access_port_diagram.png
+:alt: Diagram that displays the different entities that make up a GÉANT service.
+
+A visualisation of how services insist on ports.
+```
+
+## Peer-to-peer and multipoint services
+
+There is a distinction between services -- as mentioned in [configuration (de)composition](#configuration-decomposition)
+-- between peer-to-peer and multipoint services. In both cases, {term}`SDP` is the delivery point of a service.
+However, for multipoint services customers are supposed to be dual-homed in at least two different {term}`GAN`s.
+
+To give some examples, the figure below shows a decomposition of a GeantIP service for an NREN.
+
+```{figure} ../static/geant_ip_ports_diagram.png
+:alt: Diagram that displays the different entities that make up a GeantIP service instance.
+
+A visualisation of an instance of a GeantIP service that consists of different configuration objects.
+```
diff --git a/docs/static/geant_ip_ports_diagram.png b/docs/static/geant_ip_ports_diagram.png
new file mode 100644
index 0000000000000000000000000000000000000000..5e72025208d9a219a648a0507242dd29a68dd3ad
Binary files /dev/null and b/docs/static/geant_ip_ports_diagram.png differ
diff --git a/docs/vale/styles/Vocab/geant-jargon/accept.txt b/docs/vale/styles/Vocab/geant-jargon/accept.txt
index b164bf925229b62a35202cc47950263e69ce1a01..670f8943917139acd79785c8ad0967492b8d19da 100644
--- a/docs/vale/styles/Vocab/geant-jargon/accept.txt
+++ b/docs/vale/styles/Vocab/geant-jargon/accept.txt
@@ -17,3 +17,6 @@ GAP
 WFO
 BGP
 FXP
+NREN
+MTU
+OOB