diff --git a/source/concepts/what.rst b/source/concepts/what.rst
index 76d53ce2e1b499d284937948555639d23831e396..18c776c13bc7ec10ba7103d0be43f80226ded29c 100644
--- a/source/concepts/what.rst
+++ b/source/concepts/what.rst
@@ -13,25 +13,7 @@ Classification
 --------------
 
 You can think of many kinds of scientific databases that handle personal
-information:
-
-study database
-    contains all data that is collected during a study
-
-    only the researchers that are involved with the study have access to
-    the data
-
-study archive
-    contains data from past studies that is relevant for scientific
-    reasons, e.g. reproducibility
-
-research archive
-    contains data that has been collected during one study, but may be
-    reused in another one
-
-    reusing data saves time for both the researcher and the test subject
-
-    examples include image archives and biobanks
+information. What Castellum is:
 
 recruting database
     contains some data about (potential) test subjects that allows you to
@@ -49,30 +31,35 @@ contact database
 pseudonym service
     used to store relations between the different datasets
 
-Of these, castellum implements a recruting database, a contact database, and a
-pseudonym service. All data that is actually related to studies must be
-stored separately.
+What Castellum is not:
+
+study database
+    contains all data that is collected during a study
+
+    only the researchers that are involved with the study have access to
+    the data
+
+study archive
+    contains data from past studies that is relevant for scientific
+    reasons, e.g. reproducibility
 
-Boundaries
-----------
+research archive
+    contains data that has been collected during one study, but may be
+    reused in another one
 
-Internal steps
-``````````````
+    reusing data saves time for both the researcher and the test subject
 
-Some steps need to be deeply integrated with contact management. A good example
-for this is the recruitment, which is centered around communication with the
-subject.
+    examples include image archives and biobanks
 
-Django works best when all data is in the same database. However, it is also
-possible to split some data to a separate database. We use this mechanism for
-contact data. The data is still held internally, but there is an additional
-layer of security.
+How do we decide what to integrate?
+-----------------------------------
 
-External steps
-``````````````
+Some workflows need to be deeply integrated with contact management. A good
+example for this is the recruitment, which is centered around communication
+with the subject. These workflows are integrated in Castellum.
 
-Some steps should be kept completely separated. For example, research data
-should not be stored inside castellum. Note that there is no need for a
+Any other workflows should be kept completely separated. For example, research
+data should not be stored inside Castellum. Note that there is no need for a
 streamlined, integrated UI because research data is (or at least could be)
 handled by completely different staff than contact data and recruitment.
 
@@ -81,12 +68,12 @@ handled by completely different staff than contact data and recruitment.
    search attributes both contain traces of research data, but are required for
    the recruitment process.
 
-Steps will also be kept out of Castellum if there are well established
+Workflows will also be kept out of Castellum if there are well established
 processes that do not need to be replaced. Examples might include calendars or
 room management.
 
 The integration with external processes is usually manual. For example, a
-pseudonym generated by castellum would usually be entered into a MRI device by
+pseudonym generated by Castellum would usually be entered into a MRI device by
 hand.
 
 However, if sufficiently established protocols are available, we try to support