diff --git a/doc/src/01000-intro.md b/doc/src/01000-intro.md
index f2dd744b..0be7ca3f 100644
--- a/doc/src/01000-intro.md
+++ b/doc/src/01000-intro.md
@@ -15,35 +15,35 @@ section.
 
 ## The Problem {#sec:intro:problem}
 
-The problem imag wants to solve is rather simple. When the project was
-initiated, there was no PIM-Suite available which
+The problem this project tries to solve is to provide a modular commandline
+application for personal information management.
 
-* was for this domain of users ("power-users", "commandline users")
-* uses plain text as storage format
-* was scriptable
-* was modular
-* contained functionality to link content
+It targets "power users" or "commandline users", uses plain text as a storage
+format and tries to be scriptable.
+imag offers the ability to link data from different "PIM aspects" (such as
+"diary" and "bookmark" for example).
 
-The latter point is the bigger one: "imag" wants to offer the ability for users
-to link content. This means not only that a contact may be linked to a
-date, but that _all things_ can be linked together. For example that a wiki
-article can be linked to a date which is linked to a todo which is linked to a
-note which is linked to a contact.
+One major goal of imag is to make the PIM data traverseable and queryable.
+For example: a wiki article can be linked to an appointment which is linked to a
+todo which is linked to a note which is linked to a contact.
 
-Also, having an all-in-one scriptable modular commandline personal information
-management suite seemed nice at the time and still does.
+imag wants to offer an all-in-one scriptable modular commandline personal
+information management suite for all PIM aspects one can think of.
+Because imag uses plain text (TOML headers for structured data and plain text
+which can be rendered using markdown, for example, for continuous text)
+the user is always able to access their data without the imag tools at hand.
 
 ## The Approach {#sec:intro:approach}
 
 The approach "imag" takes on solving this problem is to store content in a
 "store" and persisting content in a unified way.
-Meta-Information is attached to the content which can be used to store
+Meta-information is attached to the content which can be used to store
 structured data.
 This can be used to implement a variety of "domain modules" using the store.
 While content is stored in _one_ place, imag does not duplicate content.
 imag does not copy or move icalendar files, emails, vcard files, music or
-movies to the store, but indexes them and stores the meta-information in the
-store.
+movies to the store, but creates references to the actual files and stores
+meta-information in the store.
 
 Detailed explanation on this approach follows in the chapters of this work.